Welcome to the 19th edition of the JW Secure Informer, our bi-monthly newsletter. This is an opportunity to share what’s on our radar, specifically with respect to enterprise network security, but also regarding IT and business more generally.
The Informer is intended to be useful content and good for a quick read. So if it’s just clutter in your inbox, we’ve failed, and I hope you’ll let us know.
How do you know What’s Secure?
Our customers often ask us to provide assurance for the security of the solutions we implement. It is satisfying for us that we have methods in place to give those assurances. We always recommend that the project budget include a threat model and an analysis of the final deliverable against the findings of that threat analysis.
Managing risk in the enterprise is of utmost importance. In this newsletter, we detail methods that can be used to identify and mitigate risk. Our objective is to consider the potential impact of external attacks against sensitive data, as well as the risk posed by insider and advanced persistent threats.
The JW Secure threat modeling process evolved from two resources. The first is Threat Modeling, the book by Swiderski and Snyder. The second is the SDL Threat Modeling Tool from Microsoft. After thoroughly investigating the concepts, we evolved them to work well in simpler projects that target a single point solution.
The first step in modeling any system is identification of the data assets that need to be protected. Once you know what you need to protect, it is necessary to track the flow of that data throughout its lifecycle. The next step is to focus on the part of the data flows that will be impacted by the project. The best representation of the model is a data flow diagram (DFD) than can be used to identify the different security zones where the data will transit or be stored.
The preceding figure is a DFD representing a typical cloud-based, three-tier line of business application (for example, the kind that is created with Ruby on Rails or ASP.NET MVC). There are three trust zones in this DFD and the boundaries between them are represented as dashed red lines. In this example, each trust zone has a single entity with bilateral communications links to the next. The goal of the DFD is to enumerate the places where sensitive data is accessible and where it is vulnerable to attack. More complete diagrams would include entities that authenticate users and authorize access to the data.
Once the DFD exists, the project team uses it to enumerate the threats. The DFD and threat list are then used as guidance by the project architects. One advantage of having the threat model at this early stage is that it can be used to system architecture and implementation decisions when changes are relatively inexpensive to make.
The Threat Analysis phase begins after the code development and testing has started. A key to hardening any software project against external attacks is an analysis of the deliverables of the project against a threat model as described above. The developers and testers of a software component are the subject matter experts and it is precisely those individuals that need to be involved in the analysis of the threats. Typically, a technical program manager takes ownership of the threat model and schedules the analysis session. The architect, developer, and tester should be present and each threat should be discussed in turn. Some threats will be determined to have little impact on the security of the data, while others will be mitigated by changes to be implemented by the development team. Any residual risks should be escalated for management review to determine if an unmitigated threat is acceptable to the project as a whole.
The entire development team benefits by engaging in the threat modeling process. This involvement leads to heightened awareness of the security ramifications of design and implementation decisions. Additional benefits, often overlooked, include higher overall code quality as well as greater management visibility into the benefits of instituting security processes that can otherwise be difficult to quantify.
Call to Action
In summary a security review should be enabled using the following steps:
- Create a data flow diagram for the project.
- Enumerate the threats using the templates provided in the references at the end of this overview.
- Review the design with the project architects.
- Enumerate potential threat mitigations.
- Make what changes are necessary to design, implementation, configuration, or documentation.
- Ensure that management is comfortable with any residual risk.
JW Secure personnel participated in the first effort to create a systemized security process for Windows XP SP2, the most widely deployed secure operating system yet. This pioneering effort forged the development methods that are now widely adopted by developers of secure software everywhere. Let us bring our security experience to your next project.
Contact JW Secure at firstname.lastname@example.org to learn more about our extensive experience in Threat Modeling and Analysis
Practical Risk Analysis and Threat Modeling Spreadsheet from the SANS institute
The Open Web Application Security Project – OWASP
Cyber Threat Metrics – A Sandia Report – March 2012
Security Development Lifecycle Process Training – Microsoft
Threat Modeling Tool – Microsoft SDL