Creating a threat model for a moderately complex application can take several weeks and requires a certain level of software security expertise. Just because you’re following an Agile development methodology doesn’t mean that you can ignore potential flaws in the design of the application. The way in which you look for those flaws may need a bit of adjusting in order to fit into your Agile SDLC, but thinking about design flaws cannot be ignored.
This post assumes that an application is already built and a threat model exists for the application.
Does the sprint affect your threat model?
As you work through the sprint, you are making changes to the functionality of the application. It’s a relatively straightforward exercise to see if the sprint affects your threat model. To find out, ask yourself the following questions:
- Has something regarding assets changed?
- Has something regarding security controls changed?
- Has something regarding the attack surface changed?
- Has something regarding threat agents changed?
If you answer ‘no’ to every one of these questions, you can get back to your sprint and you don’t need to worry about updating your threat model as part of this exercise. However, if you answer ‘yes’ to any of these questions, you need to see if the changes being made within the sprint affect your threat model. To be clear, there are other reasons you may need to update your threat model, but those reasons are not driven by your sprint.
Has something regarding assets or controls changed?
When an asset (data or functionality) is added to the application (or some attribute of an asset changed such as the data sensitivity being raised or access becoming more restrictive), you need to find out if it is similar to an existing asset. If it is similar enough, the existing control can be used to protect that asset. If no control exists, you need to add a control to your design and to your threat model to protect the new asset.
This is a good time to consider whether applying the design principle of defense in depth makes sense. For example, maybe the new asset could be protected by an existing control but the risk of some compromise is so great that adding a complementary control to protect the asset reduces your risk to an acceptable level.
When an asset is removed from the application, it likely changes your threat model in a number of ways. Wherever the asset was at rest, a security control that existed for the sole purpose of protecting that asset may no longer be needed. That asset may have flowed through one or more components. So, when it is removed, the risk profile of those components may now be different.
An asset might have already existed but is now used in another part of the application. Questions to consider in this scenario include:
- If the asset represents some functionality, are controls still in place to protect access to that functionality?
- If the asset represents a piece of data, where is that asset flowing through the application’s components?
- Does it need to be protected while in transit? If so, are there existing controls that can be used to provide that protection?
- Will that asset be stored in some new location? If so, are there existing controls to protect the asset in its new location?
Has something regarding the attack surface changed?
The attack surface represents the entry points into your application used by threat agents when launching their attacks. As entry points are added or removed, you should revisit your threat model to see how threats to your application have changed. If certain threat agents no longer have access to certain parts of the application, perhaps the risk associated with assets flowing through components has been reduced. This may negate the need to have certain types of security controls. If the application changes in such a way as to allow for threat agents to have access to assets they did not have before, consider if the existing controls will protect assets reachable by the added threat agent.
Has something regarding threat agents changed?
A threat agent can be categorized by capability, skill, or access (largely driven by attack surface). Perhaps the risk associated with a threat agent changes based on new intelligence brought to light in the development or security community. If the risk has increased, you should revisit the controls protecting assets reachable by that threat agent to see if the risk is still at an acceptable level. If the risk has decreased, perhaps the controls in place are now overkill and are creating unnecessary work for development, testing, and operational staff.
Remember: Agile isn’t an excuse or reason to ignore secure design principles.
Each of these points can be evaluated in a relatively short amount of time. Certainly, some of the work identified by this analysis could take considerable time to design and build. But that is a crucial point. Asking yourself these simple questions can help you realize that adding simple functionality to the system produces a lot of work in order to implement functionality in a secure way. Roll these questions into your Agile SDLC to take a big step toward not missing some really obvious security weaknesses you might otherwise introduce into your application.
Continue Reading
