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 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. The SSG must communicate attacker information to all interested parties. The business must create a data classification scheme that the SSG uses to inventory and prioritize applications.
Build and maintain a top N possible attacks list. The SSG helps the organization understand attack basics by maintaining a list of attacks most important to the firm. 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.
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. 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. For example, data may be classified according to protection of intellectual property, impact of disclosure, exposure to attack, relevance to SOX, or geographic boundaries.
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 and contextual attacker information is almost always more useful than generic information copied from someone else’s list.
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. 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 in order to counter a generic approach over-focused on top ten 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.
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. Regardless of its origin, attack information must be made actionable and useful for software builders and testers.
Build an internal forum to discuss attacks. The organization has an internal forum where the SSG, the satellite, and others discuss attacks. The forum serves to communicate the attacker perspective. The SSG could maintain an internal mailing list where subscribers share the latest information on publicly known incidents. Dissection of attacks and exploits that are relevant to a firm can be particularly helpful, especially if they spur discussion of development mitigations. Simply republishing items from public mailing lists does not achieve the same benefits as active discussion. Vigilance means never getting too comfortable. (See [SR1.2] Create a security portal.)
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.
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.
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 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. 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.
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 attacks perpetrated against the organization’s software as well as potential attacks.
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. 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. A science team may include well-known security researchers who publish their findings at conferences like Def Con.
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 tools to a firm’s particular technology stacks and potential attackers is a really good idea.