Intelligence: Attack Models (AM)
The overall goal for the Attack Models practice is the creation of customized knowledge on attacks relevant to the organization. Customized knowledge must guide decisions about both code and controls.
AM Level 1: Create attack (attackers, possible attacks, and attack stories) and data asset knowledge base. The SSG must identify potential attackers and document both the attacks that cause the greatest organizational concern and any important attacks that have already occurred. Managers must create a data classification scheme that the SSG uses to inventory and prioritize applications.
AM1.1
Build and maintain a top N possible attacks list. The SSG helps the organization understand attack basics by maintaining a list of the most important attacks. 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.
AM1.2
Create 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. This allows applications to be prioritized by their data classification. Many classification schemes are possible—one approach is to focus on PII. Depending upon the scheme and the software involved, it could be easiest to first classify data repositories, then derive classifications for applications according to the repositories they use. Other approaches to the problem are possible—data may be classified according to protection of intellectual property, relevance to SOX, or geographic boundaries.
AM1.3
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 broad categories of attackers and more detailed descriptions for noteworthy individuals. In some cases, a third-party vendor may be contracted to provide this information. Specific attacker information is almost always more useful than generic information copied from standards.
AM1.4
Collect and publish attack stories. In order to maximize the benefit from lessons that do not 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.
AM1.5
Gather 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. In any case, the information must be made actionable and useful for software builders and testers.
AM Level 2: Provide outreach on attackers and relevant attacks. The SSG must gather attack intelligence and expand its attack knowledge to include both higher-level attack patterns and lower-level abuse cases. Attack patterns must include technology-specific information relevant to the organization. The SSG must communicate attacker information to all interested parties.
AM2.1
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. These resources do not have to be built from scratch for every application in order 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 managed entitlements could lead to an entitlements 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 guide the process of building attack patterns and abuse cases.
AM2.2
Create technology-specific attack patterns. The SSG creates technology-specific attack patterns to capture knowledge about technology-driven attacks. For example, if the organization’s Web software relies on cutting-edge browser capabilities, the SSG could catalogue the quirks of all the popular browsers and how they might be exploited. Attack patterns directly related to the security frontier (currently mobile security and cloud security) may be useful.
AM2.4
Build internal forum to discuss attacks. The organization has an internal forum where the SSG and the satellite discuss attacks. The forum serves to communicate the attacker perspective. The SSG could maintain a security interest mailing list where subscribers share the latest information on publicly known incidents. Vigilance means never getting too comfortable. (See [SR1.2]: Create Security Portal.) Dissection of attacks and exploits that are relevant to a firm can be particularly helpful, especially if they spur discussion of development mitigations.
AM Level 3: Research and mitigate new attack patterns. The SSG must conduct attack research on corporate software to get ahead of attacker activity. The SSG must provide knowledge and automation to auditors and testers to ensure their activities reflect actual and potential attacks perpetrated the organization’s software.
AM3.1
Have a science team that develops new attack methods. The SSG has a science team that develops new attack methods. The team works to identify and defang new classes of attacks before real attackers even know they exist. This is not a penetration testing team finding new instances of known types of weaknesses—it is a research group innovating new types of attacks or new ways to exploit known weaknesses. A science team may include well-known security researchers who publish their findings at conferences like Blackhat.
AM3.2
Create and use automation to do what the attackers will do. The SSG arms testers and auditors with automation to do what the 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 tools to a firm’s particular technology stacks and potential attackers is a really good idea.