a) Iron Triangle Constraint: the relationship between time, resources and budget. From management standpoint there's an absolute need for the resources (people) to have an appropriate skills to be able to implement the software business problem, however resources are not always available and are expensive factor to consider. Additionally the time required to produce a quality software that solves the business problem is always an intensive challenge, not to mention that constraints in the budget seems to have always been a rigid requirement for any development team.
b) Security as an Afterthought: taking security for granted has an adverse effect on producing a successful piece of software. Software engineers and managers tend to focus on delivering the actual business requirements and closing the gap between when the business idea is born and when the software has actually hit the market. This creates a mind set that security does not add any business value and it can always be added on rather than built into the software.
c) Security vs Usability: another reason that believes to be a showstopper in a software delivery process seems to be viewed as security makes the software usability more complex and less intuitive e.g. security configuration is often too complicated to configure etc. It is absolutely true that the incorporation of security comes with the cost which could potentially be performance, so that is why if the concept of psychology acceptability does not factor in, questioning security implementation can more or less be true. This factor however doesn't seem to have much impact in terms delivering security as a part of software development life cycle and it's more focused on whether the added security functionality makes the usability harder for users to work with the software.
With a and b being the main factors for not adopting security into Software Development Life Cycle (SDLC), development without bringing security in the early stages turns out to have a disastrous consequences, many vulnerabilities have gone undetected allowing hackers to penetrate into the applications and causing damages and loosing reputations for the companies. So threat modeling in this context is an effective approach which should be integrated in the software design process. It is intended to identify the reasons and methods an attacker would use to figure out vulnerabilities in the software systems.
I. What is Threat Modeling?
Threat modeling is a systematic approach for developing a resilient software. It identifies the security objective of the software, threats to software and vulnerabilities in the application being developed. It will also provides insight into attacker's perspective by looking into some of the entry and exit points that attackers are looking for in order to exploit the software.A) Challenges
Although threat modeling appears to have proven useful elevating security vulnerabilities, however it seems to have added a little challenge to the overall process due to the gap between security engineers and software developers. Since security engineers are not the guys who design and build the software, it often becomes a time consuming effort to embark on a brain storming sessions with other engineers to understand the specific behavior and define all system components of the software specifically as the application gets complex.
B) Legacy Systems
While it is important to model threats to the software application in the project life cycle, it is particularly important to threat model legacy software because there's a high chance that the software was originally developed without thread models and security in mind. This however is a real challenge as legacy software tend to lack a detailed documentation and normally documentations are scattered. This specifically is the case with opensource projects where a lot of people contributing and adding notes and documentations which may not be organized and consequently makes thread modeling a difficult task.II. Threat Modeling Crash Course
So threat modeling can be drilled down to three steps: characterizing the software, identifying assets and access points, and identifying threats.A) Characterizing the Software
At the start of the process the system in question needs to be thoroughly understood, this includes reviewing the correlation of every single components as well as defining the usage scenarios and dependencies. This is a critical step to understand the underlying architecture and implementation details of the system. The information from this process is used to produce data flow diagram (DFD) which provides the best representation to identify different security zones where data will be transit or be stored.
Data Flow Diagram for a typical web application
B) Identifying Assets and Access Points
In the next phase in the threat modeling exercise, assets and access points to the system need to be clearly identified. System assets are the components that need to be protected against misuse by the attacker. Assets could be tangible such as configuration files, sensitive information, and processes or could potentially be an abstract concepts like data consistency. Access points or attack surfaces are the path adversaries are going to use to access to the targeted endpoint, for example ports and protocol used, file system read and write privileges or the authentication mechanism. So once we've identified assets and access points we use this information to generate the data access control matrix and define the access level privilege that each entities could have.| Roles | ||||
|---|---|---|---|---|
| Admin | Developer | External Process | ||
| Assets | Configuration files | Create, Read, Update, Delete | Read, Update | - |
| Audit logs | Create, Read, Update, Delete | Read | - | |
| Datastore | Create, Read, Update, Delete | Read, Update | Read | |
Data access control matrix
C) Identifying Threats
Given the first two phases are completed it's time to think about the specific threats to the system. There seems to be three systematic approaches towards threat identification process, attack tree based approach, stochastic model based approaches, and categorized threat lists. Stochastic based approach is outside the scope of this writing however if you are interested you can find more details here. Attack trees have also been used widely to identify threats however categorized lists seem to be more comprehensive and easier to used as it has already categorized threats which can be used to analyse against system components, example of such lists are Microsoft STRIDE, OWASP top 10 vulnerabilities, and CWE/SANS Top 25 Most Dangerous Software Errors.| Vulnerability List | Identified Threats |
|---|---|
| Injection | XML Schema Poisoning |
| Accessing/Intercepting/Modifying HTTP Cookies | |
| HTTP Response Splitting | |
| Broken Authentication and Session Management | JSON Hijacking (aka JavaScript Hijacking) |
| Read Sensitive Strings Within an Executable | |
| Cross Site Scripting (XSS) | Cross Site Scripting through Log Files |
| Cross-Site Scripting in Error Pages | |
| Insecure Direct Object Reference | Privilege Abuse |
| Relative Path Traversal | |
| Security Misconfiguration | Padding Oracle Crypto Attack |
| Target Programs with Elevated Privileges | |
| Sensitive Data Exposure | Interception |
| Encryption Brute Forcing | |
| Missing Fuction Level Access Control | Cross Zone Scripting |
| Directory Indexing | |
| Cross Site Request Forgery (CSRF) | Cross Site Request Forgery |
| Using Components with Known Vulnerabilities | Using commons-collection for Java Desrialization Vulnerability |
| Unvalidated Redirects and Forwards | Fake the Source of Data |
Threat identification using OWASP top 10 vulnerabilities - Vulnerability mappings Credit: Critical Watch [2]
A key to generating a successful and comprehensive threat lists against external attacks heavily relies on the accuracy of the system architecture model and the corresponding DFD that's been created earlier in the process. These are the means to identify the behavior of the system for each components and whether a threats is posed as a result. For example our data access control matrix created earlier can give us insight into the privileged operations for a particular asset which we use to associate threats that could elevate this privilege.
D) Risk Ranking
At this stage we calculate the risk of each relevant threat associated with the software. There are a number of different ways to calculate this risk however OWASP dedicated a full page explaining a methodology which can be used for threat prioritization. So the crux of this method is to determine the the severity of the risk associated with each threat and come up with a weighting factor to address each identified threat depending on the significance of the issue to the business. It is also important to understand that threat modeling has to be revisited occasionally to ensure that it's not getting outdated and it is constantly re-evaluates and prioritizes threats.E) Mitigation and Control
Threats selected from previous steps now need to be mitigated. This is where security engineers have to provide a series of countermeasures to ensure that all security aspects of the issue is addressed by developers during the development process. A critical point at this stage is to ensure that security implementation cost does not exceed the expected risk. So the mitigation scope has to be clearly defined to ensure that meaningful security effort aligns with organization's security vision.F) Threat Analysis/Verification
This phase focuses on the security delivery, after the code development and testing has started. This is a key step towards hardening the software against attacks and threat model that's been identified earlier. Usually a threat model owner is involved during the process to ensure relevant discussions are made on each remedy implementation and whether the priority of a specific threat can be re-evaluated.III. How Threat Modeling Integrates into SDLC
Up until now we've identified threats to the system and documented all the findings to make it available for engineering team to consider during software development life cycle. However with continuous integration and delivery being the key to agile development practices any extra paper work that is included in the process makes the DevOps team to suffer. Additionally this resurrects the blocking issues - Iron triangle constraint - that I mentioned earlier in the post which might delay the release as a result. So it is essential to automate the overall threat modeling process into the continuous delivery pipeline to ensure security is enforced on the early stages of product development. On the other hand there's no one size fits all approach to automating threat modeling into SDLC, and any threat modeling automation technique really has to address specific security integration problem to software delivery process. With that said however there seems to be various automation implementation [3][4][5] that could help integrating threat modeling into the software delivery process.IV. Should you use Threat Modeling anyway?
The answer is absolutely, threat modeling adds value to company's security direction for its products by providing a holistic security view of the system components. This is used as a security baseline where any development effort can have a clear vision of what needs to be done to ensure security requirements are met, the company can also benefit for this in the long term.V. References
[1] US-CERT[2] OWASP to WASC to CWE Mappings
[3] Threat Modeling with Architectural Risk Patterns - AppSec USA 2016.
[4] Developer-Driven Threat Modeling.
[5] Automated Threat Modeling through the Software Development Life-Cycle.
