Attack Models

Attack Models capture information used to think like an attacker: threat modeling, abuse case
development and refinement, data classification, and technology-specific attack patterns.

Attack Models Level 1

[AM1.2: 68] Create a data classification scheme and inventory.

The organization agrees upon a data classification scheme and uses the scheme to inventory its software according to the kinds of data the software handles, regardless of whether the software is on or off premise. This allows applications to be prioritized by their data classification. Many classification schemes are possible—one approach is to focus on PII. Depending on the scheme and the software involved, it could be easiest to first classify data repositories and then derive classifications for applications according to the repositories they use. Other approaches to the problem are possible. For example, data could be classified according to protection of intellectual property, impact of disclosure, exposure to attack, relevance to SOX, or geographic boundaries.

[AM1.3: 36] Identify potential attackers.

The SSG identifies potential attackers in order to understand their motivations and capabilities. The outcome of this exercise could be a set of attacker profiles including generic sketches for categories of attackers and more detailed descriptions for noteworthy individuals. In some cases, a third-party vendor might be contracted to provide this information. Specific and contextual attacker information is almost always more useful than generic information copied from someone else’s list.

[AM1.5: 50] Gather and use attack intelligence.

The SSG stays ahead of the curve by learning about new types of attacks and vulnerabilities. The information comes from attending conferences and workshops, monitoring attacker forums, and reading relevant publications, mailing lists, and blogs. Make Sun Tzu proud by knowing your enemy; engage with the security researchers who are likely to cause you trouble. In many cases, a subscription to a commercial service provides a reasonable way of gathering basic attack intelligence. Regardless of its origin, attack information must be made actionable and useful for software builders and testers.

Attack Models Level 2

[AM2.1: 9] Build attack patterns and abuse cases tied to potential attackers.

The SSG prepares for security testing and architecture analysis by building attack patterns and abuse cases tied to potential attackers (see [AM1.3 Identify potential attackers]). These resources don’t have to be built from scratch for every application to be useful. Instead, there could be standard sets for applications with similar profiles. The SSG will add to the pile based on attack stories. For example, a story about an attack against poorly designed mobile application could lead to a mobile security attack pattern that drives a new type of testing. If a firm tracks fraud and monetary costs associated with particular attacks, this information can be used to prioritize the process of building attack patterns and abuse cases.

[AM2.2: 8] Create technology-specific attack patterns.

The SSG creates technology-specific attack patterns to capture knowledge about attacks that target particular technologies. For example, if the organization’s cloud software relies on the cloud vendor’s security apparatus (e.g., cryptography), the SSG could catalogue the quirks of the crypto package and how it might be exploited. Attack patterns directly related to the security frontier (e.g., mobile security and wearable computing) can be useful. Simply republishing general guidelines (e.g., “Ensure data are protected in transit”) and adding “for mobile applications” on the end does not constitute technology-specific attack patterns.

[AM2.5: 14] Build and maintain a top N possible attacks list.

The SSG helps the organization understand attack basics by maintaining a living list of attacks most important to the firm and using it to drive change. This list combines input from multiple sources: observed attacks, hacker forums, industry trends, etc. The list does not need to be updated with great frequency and the attacks can be sorted in a coarse fashion. For example, the SSG might brainstorm twice per year to create lists of attacks the organization should be prepared to counter “now,” “soon,” and “someday.” In some cases, attack model information is used in a list-based approach to architecture analysis, helping to focus the analysis as in the case of STRIDE. Don’t just build the list; use it.

[AM2.6: 14] Collect and publish attack stories.

To maximize the benefit from lessons that don’t always come cheap, the SSG collects and publishes stories about attacks against the organization. Over time, this collection helps the organization understand its history. Both successful and unsuccessful attacks can be noteworthy. Discussing historical information about software attacks has the effect of grounding software security in the reality of a firm. This is particularly useful in training classes to counter a generic approach over-focused on top 10 lists or irrelevant and outdated platform attacks. Hiding information about attacks from people building new systems does nothing to garner positive benefit from a negative happenstance.

[AM2.7: 10] Build an internal forum to discuss attacks.

The organization has an internal forum where the SSG, the satellite, and others discuss attacks and attack methods. The forum serves to communicate the attacker perspective. The SSG could maintain an internal mailing list where subscribers discuss the latest information on publicly known incidents. Dissection of attacks and exploits that are relevant to a firm are particularly helpful when they spur discussion of development mitigations. Simply republishing items from public mailing lists doesn’t achieve the same benefits as active discussion, nor does a closed discussion hidden from those actually creating code. Everyone should feel free to ask questions and learn about vulnerabilities and exploits. Vigilance means never getting too comfortable.

Attack Models Level 3

[AM3.1: 4] Have a science team that develops new attack methods.

The SSG has a science team that works to identify and defang new classes of attacks before real attackers even know they exist. Because the security implications of new technologies have not been fully explored in the wild, doing it yourself is sometimes the best way forward. This isn’t a penetration testing team finding new instances of known types of weaknesses—it’s a research group innovating new types of attacks. A science team may include well-known security researchers who publish their findings at conferences like DEF CON.

[AM3.2: 1] Create and use automation to do what attackers will do.

The SSG arms testers and auditors with automation to do what attackers are going to do. For example, a new attack method identified by the science team could require a new tool. The SSG packages the new tool and distributes it to testers. The idea here is to push attack capability past what typical commercial tools and offerings encompass and then package that information for others to use. Tailoring these new tools to a firm’s particular technology stacks and potential attackers is a really good idea.