Most software projects, especially those that are considered to be particularly valuable to attackers should go through the Threat Modeling and Security Architecture Review activities of the Secure Development Life cycle. Threat Modeling is a process by which potential threats can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view. Security architecture review involves the analysis of the architectural and design solutions that mitigate threats identifies in the Threat Model.
Good architecture diagrams are vital to effective threat modeling or security architecture. In the following sections we will outline elements of a good architecture diagram and present examples of unacceptable and acceptable software architectures.
Many thanks to my friend and colleague, Antonio Martin, for leading the development of this content… and doing nearly all the work.
Here are a few tips for presenting your architecture properly:
- Provide an overview of the product architecture: This serves as reference for later discussion of assets attack surface,threats, etc
- Diagram and present the system by doing the following:
- Clearly identify what’s in scope and out-of-scope for the review.
- Show the high level, software and hardware components.
- Show all interconnections and data flows between components.
- Label all communication lines and interconnections.
- Explain each software component and what it does.
- Show system and trust boundaries:
- e. use lines or boxes to depict where data goes from one system to another, and from one level of trust to another.
- Include externally available interfaces on boundaries depicted
- Other issues to address: Updates, system management, system, hardening.
Example of an Unacceptable Software Architecture Diagram
Example project had no encryption or authentication providing access to critical hardware.
- Scope not shown.
- Connectors not labeled.
- Secure LAN” does not mean no security.
- Unknown how it works.
- Does not describe SW Architecture.
- Not enough detail.
Example of an Unacceptable Software Architecture Diagram
Example Project: A “Brick” Diagram
- Scope not shown.
- No connections shown amongst the components. This makes it impossible to know how data traverses the system.
- Unknown boundaries and interfaces.
- Unknown attack surfaces.
- A “brick” diagram is not a software architecture.
Example of an Acceptable Software Architecture Diagram
- Scope shown (yellow).
- Interconnections shown.
- Connection types show.
- Authentication types shown.
- Brief explanation of OS, and Linux user privilege separation.
- Attack surfaces can be understood.
- System boundary shown, internal trust boundaries not show but described.
This representation explains the system; it still leaves lots of questions, but the reviewers have a decent understanding of the system.
Subscribe
If you enjoyed this article, you can subscribe to receive our weekly newsletter via email.
