Threat Analysis
WHY DO THREAT ANALYSIS
Well, why not? It can be that due to a lack of familiarity with or experience of doing threat analysis (aka threat modelling), there can be a certain reticence or fear of failing. But such reticence or fear of failing is unfounded. Firstly, you won’t be alone doing threat analysis as you’ll have the application domain experts with you; secondly, a rudimentary threat analysis is more useful than none at all; and thirdly, analysis competence will grow by following up on the rudimentary threat analysis in successive sessions.
The objective is secure-by-design (aka built-in security) and one of the ways to achieve that is to identify and mitigate design-related security vulnerabilities during the system or application design phase. The output from threat analysis will be a set of security requirements that must simply be fulfilled like all of the other requirements.
Note that security is one of the enablers of overall product and service quality, which customers and end users rate trust and reputation upon. Additionally, since the General Data Protection Regulation (GDPR) activated on the 25th of May, and since secure-by-design is an enabler of privacy-by-design, it is prudent to also query and scrutinise privacy risks and mitigations during threat analysis.
WHEN TO DO THREAT ANALYSIS
There is a timing element to threat analysis. Ideally, threat analysis is performed as soon as the architecture has been established and is sufficiently mature. It is critical to understand that, no matter how late in the development process threat analysis is performed, it is critical to understand weaknesses in the design’s defences.
The fiscal and temporal cost of addressing security issues will generally increase if the design phase misses security weaknesses, so it is much more useful (and more cost-effective) to begin the process of identifying potential attacks and associated mitigations as early as possible.
A threat model should begin when the major structures and major components or functions of the architecture are mature. Note that threat analysis is a useful exercise regardless of how close the system is to deployment or how long the system has been in use; but as said, the earlier, the better. Successive development cycles, as in the norm in Agile development, should include focused threat analyses when design changes are made and to gradually mitigate security risks that the system currently carries. Also note that there is a distinction between end of development and end of support, and even when active support has ceased, a proper threat model will bring clarity about the possible flaws in the system.
WHO DOES THREAT ANALYSIS
Optimally, the product owner, lead architect, lead developer, lead tester, and lead user experience designer should together perform threat analysis with advice and facilitation from a security advisor or consultant. For GDPR aspects there may also be involvement of the Data Protection Officer, who has formal responsibility for data protection compliance within an organisation. As well as having the various insights from each of these competence areas, it is a personal opinion that this cross-competence representation ensures a greater probability of broader security awareness exposure and sharing throughout the development team(s).
THE LINK TO REQUIREMENTS ENGINEERING
Threat analysis should be planned and applied in conjunction with requirements engineering; in this way, the security requirements can be derived as an integral part of the overall requirements derivation process. The security requirements derived from threat analysis should be linked to related business case epics, use cases and user stories so that they simply become “requirements amongst others”, which helps to dispel some of the unfounded reticence and mystery around security requirements.
HOW TO DO THREAT ANALYSIS
How do you want to do it? There’s no single perfect way to do threat analysis; open source and proprietary methods exist. But they all similarly strive to answer the following questions:
What assets require protecting?
Who and what are the threats and vulnerabilities?
What are the controls to mitigate the threats and vulnerabilities?
What are the implications of not securing assets?
What is the value to the organisation?
A good threat analysis methodology is one that identifies potential security vulnerabilities and threats, and as an exercise is time-optimised, manageable and repeatable. Project artefacts used for threat analysis include (and are not limited to):
Architectural diagrams (component and logical models)
Data-flow diagrams (DFDs)
User stories and use cases (and related misuse and abuse cases)
Mind maps
UI designs
IDENTIFY THREATS
Think like the attacker to understand the relevant threats to both security and to privacy. Use defined security questions to ensure sufficient threat landscape coverage. Use the following categories to understand who might attack the application:
Accidental Discovery
An ordinary user stumbles across a functional mistake in your application while using a web browser and gains access to privileged information or functionality.
Automated Malware
Programs or scripts that search for known vulnerabilities and then report back to a central collection site.
The Curious Attacker
A security researcher or ordinary user who notices something wrong with the application and decides to pursue further.
Script Kiddies
Rebellious types seeking to compromise or deface applications for notoriety or a political agenda.
The Motivated Attacker
A disgruntled employee or contractor with inside knowledge or a paid professional attacker.
Organised Crime
Criminals seeking high stake pay-outs by cracking high-value organisations for financial gain.
APPLY STRIDE TO CLASSIFY IDENTIFIED THREATS
STRIDE is a classification scheme for characterising known threats according to the kinds of exploit that are used (or motivation of the attacker). The STRIDE acronym is formed from the first letter of each of the following threat categories:
Spoofing Identity
Identity spoofing is a risk for applications that have many users but provide a single execution context at the application and database level. Users should not be able to become another user or assume the attributes of another user.
Tampering with Data
This is about how an application deals with untrusted data – treat all data as untrusted anyway! Examples of tampering are changing GET or POST variable values directly in the URL address bar, failing to check data integrity, and deficient client-side and server-side data validation. In the worst case, you can call it data sabotage. This relates to threats #1 and #7 in the Open Web Application Security Project (OWASP) Top 10 2017.
Repudiation
Users may dispute transactions if there is insufficient logging and auditing of user and system events, or if you cannot track user activities through the application or from the audit trail. A properly designed application will incorporate non-repudiation controls such as tamper-resistant logs; it should not be possible to alter logged events. A note of caution here: in terms of the GDPR, only the required data to facilitate audits should be logged; do not log personal data if there is no explicit requirement to do so. This relates to threat #10 Insufficient Logging and Monitoring in the OWASP Top 10 2017.
Information Disclosure
There are basically two types: a data leak, or a privacy breach. A data leak can be a flaw or be a malicious attack. The most common flaw is simply not using Transport Layer Security (TLS) and not enforcing HTTP Strict Transport Security (HSTS). This flaw provides entry points for attackers to steal keys, execute man-in-the-middle attacks, or steal clear text data from the user’s client (e.g. browser) and data in transit. Concerning privacy breaches, in the context of the GDPR due caution is required concerning the protection of personal data from accidental or unauthorised disclosure.
Denial of Service
The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.
Elevation of Privilege
Access control enforces policy such that users cannot act outside of their intended permissions. Flaws typically lead to unauthorised information disclosure, modification or destruction of all data, or performing actions outside of the bounds authorised by the administrator for the user. It is essential that the user cannot manipulate the human-computer interface (HCI) to elevate his/her role to higher privilege roles. This relates to threat #5i Broken Access Control in the OWASP Top 10 2017.
For further types of flaw-exploited attacks, you can refer to the OWASP Attack Categories.
APPLY DREAD TO QUANTIFY THREATS
DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.
DREAD modelling influences the thinking behind setting the risk rating and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.
DREAD_Risk = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5
The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk. Here is one way to quantify the DREAD categories:
Damage Potential
If a threat exploit occurs, how much damage will be caused?
0 = Nothing
5 = Individual user data is compromised or affected
10 = Complete system or data destruction
Reproducibility
How easy is it to reproduce the threat exploit?
0 = Very hard or impossible, even for administrators of the application
5 = One or two steps required, may need to be an authorised user
10 = Just a web browser and the address bar is sufficient, without authentication
Exploitability
What is needed to exploit this threat?
0 = Advanced programming and networking knowledge, with custom or advanced attack tools
5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools
10 = Just a web browser
Affected Users
How many users will be affected?
0 = None
5 = Some users, but not all
10 = All users
Discoverability
How easy is it to discover this threat?
0 = Very hard to impossible; requires source code or administrative access.
5 = Can figure it out by guessing or by monitoring network traces.
9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
10 = The information is visible in the web browser address bar or in a form.
IMPLEMENT THREAT MITIGATIONS
Fortunately, there already exists a body of industry-scrutinised application security requirements known as the Open Web Application Security Project Application Security Verification Standard (OWASP ASVS) that can be readily applied as security requirements for mitigating identified security weaknesses and threats.
VERIFY THREAT MITIGATIONS
An OWASP Testing Guide will help developers and testers to verify implemented security mitigations to the accepted risk level. By “accepted risk level” is meant that there may be residual risks that will be too expensive to mitigate beyond the value of the business case; project management or owners must be prepared to undersign residual risk acceptance.
Penetration testing should support verification and automated security testing should also be implemented to the Continuous Development/Continuous Integration pipeline using e.g. Checkmarx and Open Source Analysis security verification tools.
Also, verify with the Data Protection Officer that any identified privacy-associated risks have been sufficiently mitigated to the accepted risk level.
BE CURIOUS
I think this is the most important advice; without the curiosity, threat analysis might not happen. As said at the beginning, don’t postpone threat analysis; be curious, jump right in, and learn it by doing it.
REFERENCES
----------
ABOUT THE AUTHOR
Niall is a secure design best practices advocate, coach and promoter. His experience includes seeding the secure design mindset and best practices for private sector Internet of Things web applications and facilitating threat analysis workshops for public sector web application projects. Niall is also passionate about helping organisations to evolve their overall security maturity.
Do you want to read more?
