Note: This page is part of the archive.

This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact if you have any questions about the US-CERT website archive.

Attack Patterns

Building software with an adequate level of security assurance for its mission becomes more and more challenging every day as the size, complexity, and tempo of software creation increases and the number and the skill level of attackers continues to grow. These factors each exacerbate the issue that, to build secure software, builders must ensure that they have protected every relevant potential vulnerability; yet, to attack software, attackers often have to find and exploit only a single exposed vulnerability. To identify and mitigate relevant vulnerabilities in software, the development community needs more than just good software engineering and analytical practices, a solid grasp of software security features, and a powerful set of tools. All of these things are necessary but not sufficient. To be effective, the community needs to think outside of the box and to have a firm grasp of the attacker’s perspective and the approaches used to exploit software [Hoglund 04, Koizol 04].

These articles discuss the concept of attack patterns as a mechanism to capture and communicate the attacker’s perspective. Attack patterns are descriptions of common methods for exploiting software. They derive from the concept of design patterns [Gamma 95] applied in a destructive rather than constructive context and are generated from in-depth analysis of specific real-world exploit examples. Through analysis of observed exploits, the following typical information is captured for each attack pattern:

  • Pattern name and classification
  • Attack prerequisites
  • Description
  • Targeted vulnerabilities or weaknesses
  • Method of attack
  • Attacker goal
  • Attacker skill level required
  • Resources required
  • Blocking solutions
  • Context description
  • References

This information can bring considerable value for software security considerations through all phases of the software development lifecycle (SDLC) and other security-related activities, including:

  • Requirements gathering
  • Architecture and design
  • Implementation and coding
  • Software testing and quality assurance
  • Systems operation
  • Policy and standard generation