How do you use CAPEC attack patterns and their CWE links during a design review?

## What an attack library is Threat elicitation can be driven two ways. **Design-driven** elicitation starts from your diagram, your assets and your trust boundaries and reasons outward to what could go wrong. **Library-driven** elicitation starts from a catalog of attacks other people have already seen and asks, for each one, "does this apply here?" An attack library is the catalog that makes the second style possible. CAPEC - Common Attack Pattern Enumeration and Classification, maintained by MITRE - is the reference example. It is a public, versioned catalog of attack *patterns*: reusable descriptions of an attacker's approach, abstracted away from any one product or incident. ## How CAPEC is structured CAPEC is hierarchical along two independent axes. **Abstraction.** Patterns come at three levels of specificity. A **Meta** pattern describes an attack approach in the broadest terms. A **Standard** pattern describes a specific, recognisable technique. A **Detailed** pattern describes a concrete variant of that technique. Parent/child links connect them, and additional relations express sequencing - one pattern can precede or follow another. **Views.** The catalog is presented through top-level views: one that organises patterns by the *mechanism* of the attack, and one that organises them by the *domain* they operate in (software, hardware, communications, supply chain, social engineering, physical). The domain view is how you find your way in when you are starting from a system rather than from an attack. Each entry is a small structured record: a description, **prerequisites** (what must be true of the target for the attack to be possible), an **execution flow**, the **skills and resources required**, an indicative likelihood and severity, candidate **mitigations**, and **Related Weaknesses**. ## The CWE linkage, and which way it points The Related Weaknesses field is the hinge of the whole thing, and interviewers check that you have the direction right. - **CAPEC describes the attacker's method** - what someone does to your system. - **CWE describes the weakness** - the class of defect in the code, configuration or design that makes the method work. A pattern points *to* the weaknesses it exploits; a weakness points *back* to the patterns that exploit it. Neither is a list of specific flaws in a specific product - that is a different kind of identifier entirely. That two-way link gives you two entrances. Attack-first: you suspect a class of attack and follow it down to the weaknesses you would have to have in order for it to land, which tells you what to look for in the design. Component-first, which is the more common move in a design review: you know you are building, say, an untrusted-input parser, so you start from the weakness families such components suffer and follow the reverse links to the patterns that exercise them. ## Using it on a real design Take an insurance claims ingest that accepts EDI documents and PDF attachments submitted through broker portals. The submitter is effectively anonymous - anyone with a broker account, and in practice anyone the broker's own workflow lets in. What is at stake is the availability of the ingest pipeline and the personal data inside the claims. A whiteboard session will reliably produce "someone uploads a malicious file" and stop there. The catalog will not. Attacks against document and structured-message parsers are extensively documented: resource exhaustion through expansion of nested structures, path traversal via attachment file names, retrieval of external references embedded in the document, deserialization of attacker-controlled structures, and oversized or malformed input driving the parser into pathological behaviour. This is exactly where library-driven elicitation earns its keep - the failure modes are well catalogued and no team recalls them all unaided. The practical loop is: enumerate the entry points and component types in the design, pull candidate patterns for each, **test the prerequisites against the actual design** (a pattern whose preconditions do not hold in your architecture is not a threat here, and saying so out loud is part of the work), and for the ones that survive, follow the CWE links and record a design decision. ## What the catalog does not do for you Three limits are worth stating before an interviewer states them for you. 1. **It does not rate risk for you.** The severity and likelihood attributes on an entry are generic catalog-level judgments made with no knowledge of your exposure, your asset value or your existing controls. Use them to triage which patterns to read, then rate against your own design. 2. **It does not know your business rules**, so it cannot contain the abuse that consists of legitimate operations combined in a way your rules did not anticipate. 3. **Its mitigations are a starting point**, phrased generically. Turning one into a decision your team can implement in this architecture is still your job. ## Keeping the pass proportionate The common failure is volume: a junior reviewer walks the catalog exhaustively and produces eighty low-value entries that nobody triages. Prune hard. Scope to the entry points and technologies actually present, work at the Meta and Standard abstraction levels, and drop to Detailed patterns only when the extra specificity would change what you build. A short list of patterns whose prerequisites you have genuinely checked beats a full traversal every time.