Internal Ttp Catalogue

An organisation-owned catalogue of tactics, techniques, and procedures that extends public frameworks with local behaviours seen in the environment. It gives teams a controlled reference for detections, playbooks, and mappings when external taxonomies are too broad or too slow.

Expanded Definition

An internal TTP catalogue is an organisation-owned reference of observed attacker and misuse patterns that extends public frameworks such as MITRE ATT&CK with environment-specific behaviours, tool usage, and detection cues. In NHI security, it is most useful when service accounts, API keys, CI/CD identities, and agent execution paths produce repeatable behaviour that public taxonomies describe too generally.

Definitions vary across vendors and blue-team programs, but the practical goal is consistent: convert local incident evidence into a controlled corpus that supports detection engineering, hunt hypotheses, and response playbooks. A mature catalogue should separate verified observations from speculation, record evidence sources, and map entries back to shared taxonomies so teams can compare internal findings with external standards like the NIST Cybersecurity Framework 2.0. It should also remain versioned, reviewed, and retired when behaviours change, especially in environments with autonomous agents or heavily automated service identities.

The most common misapplication is treating any suspicious activity as a catalogue-worthy TTP, which occurs when teams skip evidence thresholds and record one-off alerts as reusable adversary behaviour.

Examples and Use Cases

Implementing an internal TTP catalogue rigorously often introduces documentation overhead and review burden, requiring organisations to weigh faster detection reuse against the cost of maintaining high-quality entries.

• A cloud platform team records repeated API key abuse patterns from leaked CI variables, then maps them to a local detection rule and incident playbook.
• A SOC adds a recurring service-account abuse sequence to the catalogue after confirming it appears across multiple alerts, not just one isolated case.
• An automation team tracks how an AI agent escalates tool access through mis-scoped tokens, then aligns the behaviour with MITRE ATT&CK for broader reporting.
• A detection engineer notes that a particular deployment pipeline always generates the same unusual token refresh pattern before privilege escalation, so the behaviour becomes a hunt hypothesis.
• A governance team compares internal behaviours with the research and lifecycle guidance in Ultimate Guide to NHIs to decide which patterns reflect NHI risk rather than ordinary operational noise.

Catalogues are most effective when they capture local context such as asset ownership, identity type, and environment-specific preconditions. They are less useful when they become a dumping ground for every alert label the SIEM produces.

Why It Matters in NHI Security

Internal TTP catalogues matter because NHI incidents often repeat in the same ways: overprivileged service accounts, hardcoded secrets, stale tokens, and automation that behaves predictably once abused. Without a local catalogue, those repeatable patterns stay buried in tickets and logs instead of becoming durable defensive knowledge. That gap is especially risky in environments where Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, because the same privilege misuse can show up in different tools but follow the same attack path.

An internal catalogue also supports better governance under NIST Cybersecurity Framework 2.0 by making local detection logic traceable, reviewable, and easier to validate during incidents and audits. For NHI programs, that traceability helps connect identity behaviour to response decisions, rather than relying on ad hoc analyst memory.

Organisations typically encounter the value of an internal TTP catalogue only after a breach repeats an earlier pattern, at which point the catalogue becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• How should organisations reduce internal file exposure in Teams and SharePoint?
• When does broad internal sharing become an insider-risk issue?
• Why do guest accounts create more risk than internal users?