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: 77] Create a data classification scheme and inventory.

Security stakeholders in an organization agree on a data classification scheme and use it to inventory software, delivery artifacts (e.g., containers), and associated persistent stores according to the kinds of data processed or services called, regardless of deployment model (e.g., 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, for example. Depending on the scheme and the software involved, it could be easiest to first classify data repositories (see [CP2.1 Build PII inventory]) and then derive classifications for applications according to the repositories they use. Other approaches to the problem include data classification according to protection of intellectual property, impact of disclosure, exposure to attack, relevance to GDPR, and geographic boundaries.

[AM1.3: 41] Identify potential attackers.

The SSG identifies potential attackers in order to understand their motivations and abilities. The outcome of this exercise could be a set of attacker profiles that includes outlines 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. Moreover, a list that simply divides the world into insiders and outsiders won’t drive useful results. Identification of attackers should account for the organization’s evolving software supply chain and attack surface.

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

The SSG ensures the organization stays ahead of the curve by learning about new types of attacks and vulnerabilities. Attending technical conferences and monitoring attacker forums, then correlating that information with what’s happening in the organization (perhaps by leveraging automation to mine operational logs and telemetry) helps the SSG learn more about emerging vulnerability exploitation. In many cases, a subscription to a commercial service can provide a reasonable way of gathering basic attack intelligence related to applications, APIs, containerization, orchestration, cloud environments, and so on. Regardless of its origin, attack information must be adapted to the organization’s needs and made actionable and useful for developers, testers, and DevOps and reliability engineers.

Attack Models Level 2

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

The SSG prepares the organization for SSDL activities by working with stakeholders to build attack patterns and abuse cases tied to potential attackers (see [AM1.3 Identify potential attackers]). However, these resources don’t have to be built from scratch for every application in order to be useful; rather, standard sets might exist for applications with similar profiles, and the SSG can add to the pile based on its own attack stories. For example, a story about an attack against a poorly designed cloud-native application could lead to a containerization attack pattern that drives a new type of testing. If a firm tracks the fraud and monetary costs associated with particular attacks, this information can in turn be used to prioritize the process of building attack patterns and abuse cases. Evolving software architectures (e.g., zero trust, serverless) might require organizations to evolve their attack pattern and abuse case creation approach and content.

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

The SSG facilitates technology-specific attack pattern creation by collecting and providing knowledge about attacks relevant to the organization’s technologies. For example, if the organization’s cloud software relies on a cloud vendor’s security apparatus (e.g., key and secrets management), the SSG can help catalog the quirks of the crypto package and how it might be exploited. Attack patterns directly related to the security frontier (e.g., serverless) can be useful here as well. It’s often easiest to start with existing generalized attack patterns to create the needed technology-specific attack patterns, but simply adding, for example, “for microservices” at the end won’t suffice.

[AM2.5: 13] Maintain and use a top N possible attacks list.

The SSG periodically digests the ever-growing list of attack types and focuses the organization on prevention efforts for a prioritized short list—the top N—and uses it to drive change. This initial list almost always combines input from multiple sources, both inside and outside the organization. Some organizations prioritize their list according to perception of potential business loss while others might prioritize according to successful attacks against their software. The top N list doesn’t need to be updated with great frequency, and attacks can be coarsely sorted. For example, the SSG might brainstorm twice a year to create lists of attacks the organization should be prepared to counter “now,” “soon,” and “someday.”

[AM2.6: 10] 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’s software. Both successful and unsuccessful attacks can be noteworthy, and discussing historical information about software attacks has the added effect of grounding software security in a firm’s reality. This is particularly useful in training classes to help counter a generic approach that might be overly focused on other organizations’ top 10 lists or outdated platform attacks (see [T2.8 Create and use material specific to company history]). Hiding or overly sanitizing information about attacks from people building new systems fails to garner any positive benefits from a negative happenstance.

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

The organization has an internal, interactive forum where the SSG, the satellite, incident response, and others discuss attacks and attack methods. The discussion serves to communicate the attacker perspective to everyone. The SSG can also maintain an internal mailing list that encourages subscribers to 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, infrastructure, and other 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 (see [SR1.2 Create a security portal]).

Attack Models Level 3

[AM3.1: 5] Have a research group that develops new attack methods.

A research group works to identify and defang new classes of attacks before attackers even know that they exist. Because the security implications of new technologies might not have been fully explored in the wild, doing it in-house 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 that innovates new types of attacks. Some firms provide researchers time to follow through on their discoveries using bug bounty programs or other means of coordinated disclosure. Others allow researchers to publish their findings at conferences like DEF CON to benefit everyone.

[AM3.2: 4] Create and use automation to mimic attackers.

The SSG arms engineers, testers, and incident response with automation to mimic what attackers are going to do. For example, a new attack method identified by an internal research group or a disclosing third party could require a new tool, so the SSG could package the tool and distribute it to testers. The idea here is to push attack capability past what typical commercial tools and offerings encompass, and then make that knowledge and technology easy for others to use. Tailoring these new tools to a firm’s particular technology stacks and potential attackers increases the overall benefit. When technology stacks and coding languages evolve faster than vendors can innovate, creating tools and automation in-house might be the best way forward. In the DevOps world, these tools might be created by engineering and embedded directly into toolchains and automation (see [ST3.6 Implement event-driven security testing in automation]).

[AM3.3: 6] Monitor automated asset creation.

The SSG guides the implementation of technology controls that provide a continuously updated view of the various network, machine, software, and related infrastructure assets being instantiated by engineering teams as part of their ALM processes. To help ensure proper coverage, the SSG works with engineering teams to understand orchestration, cloud configuration, and other self-service means of software delivery used to quickly stand-up servers, databases, networks, and entire clouds for software deployments. Monitoring the changes in application design (e.g., moving a monolithic application to microservices) is also part of this effort. This monitoring requires a specialized effort—normal system, network, and application logging and analysis won’t suffice. Success might require a multi-pronged approach, including consuming orchestration and virtualization metadata, querying cloud service provider APIs, and outside-in web crawling and scraping. As processes improve, the data will be helpful for threat modeling efforts (see [AA1.1 Perform security feature review]).