PEARL XXII : Threat Modelling for Agile Applications

PEARL XXII :  The key to effectively incorporating threat modeling is to decide on the scope of the threat modeling that  will be performed during the various stages of  agile development project by incorporating Security Development Life cycle for Agile Development projects which includes Threat modelling.

Many software development organizations, including product organizations like Microsoft, use Agile software development and management methods to build their applications.
Historically, security has not been given the attention it needs when developing software with Agile  methods. Since Agile methods focus on rapidly creating features that satisfy customers’ direct needs, and  security is a customer need, it’s important that it not be overlooked. In today’s highly interconnected  world, where there are strong regulatory and privacy requirements to protect private data, security must  be treated as a high priority.
There is a perception today that Agile methods do not create secure code, and, on further analysis, the  perception is reality. There is very little “secure Agile” expertise available in the market today. This needs  to change. But the only way the perception and reality can change is by actively taking steps to integrate  security requirements into Agile development methods.

With Agile release cycles taking as little as one week, there simply isn’t enough time for teams to  complete SDL requirements for every release. On the other hand, there are serious security  issues that the SDL is designed to address, and these issues simply can’t be ignored for any release—no  matter how small.

A set of software development process improvements called the Security Development life-cycle (SDL) has been developed. The SDL has been shown to reduce the number of vulnerabilities in shipping software by more than 50 percent. However, from an Agile viewpoint, the SDL is heavyweight because it was designed primarily to help secure very large products, Agile practitioners in order to adopt the SDL, two changes must be made. First, SDL additions to Agile processes must be lean. This means that for each feature, the team does just enough SDL work for that feature before working on the next one. Second, the development phases (design, implementation, verification, and release) associated with the classic waterfall-style SDL do not apply to Agile and must be reorganized into a more Agile-friendly format.  A streamlined approach that melds agile methods and security—the Security Development life-cycle for Agile Development (SDL-Agile) has to be put into practice.

Let’s look at some basic examples of what threat modeling is and what it isn’t:

How to perform threat modeling

Threat modeling is largely a team activity. Does that mean an individual can’t threat model alone on a small project? Of course not, but will get the greatest benefit from the activity by including as many project members as possible. This is because each member will bring unique perspectives to the exercise, and that input is essential when trying to identify the various ways that an attacker might attempt to break your application or service.

The recommended approach is to use a whiteboard to sketch out each threat model, thereby facilitating team discussion around the diagram. The SDL is specific in recommending that threat models use the data flow diagram (DFD) as the foundational diagramming technique. Having a project member who is already familiar with data flow diagramming can be a big help, and that individual would be best suited to facilitate the first threat modeling session. So, the first step in threat modeling is to draw a DFD on the whiteboard that represents your envisioned application. Next, let’s look at the various threat modeling diagram types.

The highest-level diagram you can create is the context diagram. The context diagram is typically a simple diagram that captures the most basic interactions of your application with external actors. Figure 1 is an example of a context diagram. Following the context diagram, there are a variety of more detailed diagrams that can show more specific interactions of your application’s internal components and actors. The Diagram Levels table below lists the various levels of diagrams, along with descriptions of what each level typically contains.

Figure 1. Context diagram

Once you have created a few of these high-level diagrams with your team, the next step is to identify the trust boundaries that we discussed earlier. Trust boundaries are represented by drawing lines that separate the various zones of trust in your diagram. It is the action of applying the trust boundary that changes the DFD into a threat model. It’s critical that you get the trust boundaries correct because that is where your team will focus its attention when discussing threats to the application. Figure 2 shows a Level 0 threat model with trust boundaries included.

• Identify Trust Boundaries, Data Flow, Entry Point
• Privileged Code
• Modify Security Profile based on above

Figure 2. Level 0 diagram with trust boundaries

Once you’ve created the threat model, your team will be ready to start discussing the threats to the application as envisioned in deployment. In order to do this efficiently, the SDL has categorized potential threats along with the most common mitigations to those threats in order to simplify the process. For a more complete discussion on threat models, refer to the book Threat Modeling by Frank Swiderski and Window Snyder.

Let’s next examine the process you can follow to identify, classify, and mitigate threats to your application. We call this process STRIDE.

STRIDE

STRIDE is a framework for classifying threats during threat modeling. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation Privilege. The table below provides basic descriptions of the elements of STRIDE.

Notice how each of the definitions are described in terms of what an “attacker” can do to your application. This is an important point: When threat modeling, it’s crucial to convey to your project team that they should be more focused on what an attacker can do than what a legitimate user can do. What your users can do with your application should be captured in your user stories and not in the threat model.

Now that you’ve created the threat model and discussed the threats to the various components and interfaces, it’s time to determine how to help protect your application from those threats. We call these mitigations. the following table lists the mitigation categories with respect to each of the STRIDE elements.

 The basics of threat modeling, has been depicted above , the following section delves into how to incorporate threat modeling with agile methods.  Additionally, it’s important to note that once  threat models have been created on the whiteboard, it is essential to capture them as a drawing. Microsoft provides an excellent tool for this purpose: the Microsoft SDL Threat Modeling Tool. This tool allows you to easily create threat model diagrams, and provides a systematic approach to identifying threats based on trust boundaries and evaluating common mitigations to those threats.

At some point, the major SDL artifact—the threat model—must be used as a baseline for the product.  Whether this is a new product or a product already under development, a threat model must be built as  part of the sprint design work. Like many good Agile practices, the threat model process should be time-boxed and limited to only the parts of the product that now exist or are in development.
Once a threat model baseline is in place, any extra work updating the threat model will usually be small,  incremental changes.
A threat model is a critical part of securing a product because a good threat model helps to:

• Determine potential security design issues.
• Drive attack surface analysis and most “at-risk” components.
• Drive the fuzz-testing process.

During each sprint, the threat model should be updated to represent any new features or functionality  added during that sprint. The threat model should also be updated to represent any significant design  changes, even if the functionality stays the same.

A threat model needs to be built for the current product, but it is imperative that the team remains lean. A minimal, but useful, threat model can be built by analyzing high-risk entry points and data in the system. At a minimum, the following should be identified and threat models built around the entry
points and data:

• Anonymous and remote network endpoints
• Anonymous or authenticated local endpoints into high-privileged processes
• Sensitive, confidential, or personally identifiable data held in data stores used in the application

Integrated threat modeling

Integrated threat modeling ensures that the dedicated security architect liaises with the QA lead and development lead, and periodically identifies, documents, rates, and reviews the threats to the system. The key point to be noted is that threat modeling is not a one-time activity; rather, it is an iterative process that needs to be carried out in every sprint

• Modify the architecture diagram based on changes in – Sprint (if any)
• Periodic Review and ID of assets
• Update Threat Document with vulnerabilities.
• ID threat attributes such as Countermeasures, attack technique etc
• Use techniques such as DREAD to rate the threats
• Threats with High Rating must be fixed immediately in subsequent sprints

Training Development Team

Focusing on improving processes and giving staff better awareness training could reap huge rewards – cutting the time taken to spot breaches and even preventing many from happening in the first place. Therefore it is suggested that the development team be given sufficient training in secure code development at least covering the following

•  Cross-site scripting vulnerabilities
•  SQL injection vulnerabilities
•  Buffer/integer overflows
•  Input validation
• Language Specific issues

Also, it would help if developers periodically review the industry
standards, such as OWASP Top 10 vulnerabilities, and understand
how to develop code devoid of such vulnerabilities.

Continuing Threat Modeling
Threat modeling is one of the every-sprint SDL requirements for SDL-Agile. Unlike most of the other every-sprint requirements, threat modeling is not easily automated and can require significant team effort. However, in keeping with the spirit of agile development, only new features or changes being implemented in the current sprint need to be threat modeled in the current sprint. This helps to minimize the amount of developer time required while still providing all the benefits of threat modeling.
Fuzz Testing
Fuzz testing is a brutally effective security testing technique, especially if the team has never used fuzz testing on the product. The threat model should determine what portions of the application to fuzz test. If no threat model exists, the initial list should include high-risk items,
High-Risk Code.
After this list is complete, the relative exposure of each entry point should be determined, and this drives the order in which entry points are fuzzed. For example, remotely accessible or unauthenticated endpoints are higher risk than local-only or authenticated endpoints.
The beauty of fuzz testing is that once a computer or group of computers is configured to fuzz the application, it can be left running, and only crashes need to be analyzed. If there are no crashes from the outset of fuzz testing, the fuzz test is probably inadequate, and a new task should be created to analyze why the fuzz tests are failing and make the necessary adjustments.
Using a Spike to Analyze and Measure Unsecure Code in Bug Dense and “At-Risk”
Code
A critical indicator of potential security bug density is the age of the code. Based on the experiences of organizations like Microsoft developers and testers, the older the code, the higher the number of security bugs found in the code. If the project has a large amount of legacy code or risky code individual should locate as many vulnerabilities in this code as possible. This is achieved through a spike. A spike is a time-boxed “side project” with a well-defined goal (in this case, to find security bugs). It can be thought  of this spike as a mini security push. The goal of the security push in organizations like Microsoft is to bring risky code up to date in a short amount of time relative to the project duration.
Note that the security push doesn’t propose fixing the bugs yet but rather analyzing them to determine how bad they are. If a lot of security bugs are found in code with network connections or in code that handles sensitive data, these bugs should not only be fixed soon, but also another spike should be set up to comb the code more thoroughly for more security bugs.

The following defines the highest risk code  that should receive greater scrutiny if  the code is legacy code and should be written with the greatest care if the code is new code.

• Windows services and *nix daemons listening on network connections
• Windows services running as SYSTEM or *nix daemons running as root
• Code listening on unauthenticated network ports connections
• ActiveX controls
• Browser protocol handlers (for example, about: or mms:)
• setuid root applications on *nix
• Code that parses data from untrusted (non-admin or remote) files
• File parsers or MIME handlers

Examples of analysis performed during a spike include:

• All code. Search for input validation failures leading to buffer overruns and integer overruns. Also, search for insecure passwords and key handling, along with weak cryptographic algorithms.
• Web code. Search for vulnerabilities caused through improper validation of user input, such as CSS.
• Database code. Search for SQL injection vulnerabilities.
• Safe for scripting ActiveX controls. Review for C/C++ errors, information leakage, and dangerous operations.

All appropriate analysis tools available to the team should be run during the spike, and all bugs triaged and logged. Critical security bugs, such as a buffer overrun in a networked component or a SQL injection vulnerability, should be treated as high-priority unplanned items.
Exceptions
The SDL requirement exception workflow is somewhat different in SDL-Agile than in the classic SDL.
Exceptions in SDL-Classic are granted for the life of the release, but this won’t work for Agile projects. A “release” of an Agile project may only last for a few days until the next sprint is complete, and it would be a waste of time for project managers to keep renewing exceptions every week. To address this issue, project teams following SDL-Agile can choose to either apply for an exception for the duration of the sprint (which works well for longer sprints) or for a specific amount of time, not to exceed six months (which works well for shorter sprints). When reviewing the requirement exception, the security advisor can choose to increase or decrease the severity of the exception by one level (and thus
increase or decrease the seniority of the manager required to approve the exception) based on the requested exception duration.
For example, say a team requests an exception for a requirement normally classified as severity 3, which requires manager approval. If they request the exception only for a very short period of time, say two weeks, the security advisor may drop the severity to a 4, which requires only approval from the team’s security champion. On the other hand, if the team requests the full six months, the security advisor may increase the severity to a 2 and require signoff from senior management due to the increased risk. In addition to applying for exceptions for specific requirements, teams can also request an exception for an entire bucket. Normally teams must complete at least one requirement from each of the bucket categories during each sprint, but if a team cannot complete even one requirement from a bucket, the team requests an exception to cover that entire bucket. The team can request an exception for the duration of the sprint or for a specific time period, not to exceed six months, just like for single exceptions. However, due to the broad nature of the exception—basically stating that the team is going to skip an entire category of requirements—bucket exceptions are classified as severity 2 and require the
approval of at least a senior manager.
Final Security Review
A Final Security Review (FSR) similar to the FSR performed in the classic waterfall SDL is required at the end of every agile sprint. However, the SDL-Agile FSR is limited in scope—the security advisor only needsto review the following:

• All every-sprint requirements have been completed, or exceptions for those requirements have been granted.
• At least one requirement from each bucket requirement category has been completed (or an exception has been granted for that bucket).
• No bucket requirement has gone more than six months without being completed (or an exception  has been granted).
• No one-time requirements have exceeded their grace period deadline (or exceptions have been granted).
• No security bugs are open that fall above the designated severity threshold (that is, the security bug bar).

Some of these tasks may require manual effort from the security advisor to ensure that they have been  completed satisfactorily (for example, threat models should be reviewed), but in general, the SDL-Agile  FSR is considerably more lightweight than the SDL-Classic FSR.