What is Threat Modeling
A Quick Nod, and note of reference
I want to Start this entry by saying in NO way is Threat modeling my idea, nor are any of the concepts I present, this is just a model I have used professionally over the years that is basically a slight adaptation to the OWASP threat modeling guide with what I believe is an easier to understand example.
Summary
The goal is an understanding of the threat landscape, which is achieved by the designing of documentation and diagrams to understand an application attack surface and the strengths and weaknesses of each.
Why
The closest summary I can give to the idea behind threat modeling is that its used to help engineers and developers work together to think about threats, but the key word is think, this is not meant to be a simple type in some keys and the answer is done for you, it will require minds to deeply think about risks that threats.
Understanding the documentation creation.
For the documentation piece this is the documentation such as excel/ google sheets that call out strengths and weaknesses of an application, and the word docs that give an overview of the application. These documents should call out entry points where attackers may interact, identifying the assets that are involved. Also during this phase you should be calling out the trust level and the access rights.
Determine threats
Use of the STRIDE model for determining risk.
|
Spoofing |
Pretending to be something or someone you are not |
|
Tampering |
Modifying something on disk, network, memory or elsewhere |
|
Repudiation |
Claiming you didn’t do something, need logs, be able to provide proof of integrity. |
|
Information Disclosure |
Obtaining information that isn’t authorized |
|
Denial of service |
Exhausting resources needed to provide service |
|
Elevation of privilege |
Allowing someone to do something they are not authorized to do |
Identify Countermeasures and Mitigations
Identifying countermeasures may include things like patching a system, possibly integrating a new application into a pipeline, etc. In this step you may ask, what the attack likelihood is, what would the effects of the attack be. Also in this phase you will need to decide what your plan of action for what the countermeasure may be. Courses of action may include:
- Accept- decide that the business impact is acceptable, and document who has chosen to accept the risk
- Eliminate- remove components that make the vulnerability possible
- Mitigate- add checks or controls that reduce the risk impact, or the chances of its occurrence
- Transfer- Transfer risk to an insurer or customer.
STRIDE Threat & Mitigation Techniques
|
Threat Type |
Mitigation Techniques |
|
Spoofing Identity |
1. Appropriate authentication 2. Protect secret data 3. Don’t store secrets |
|
Tampering with data |
1. Appropriate authorization 2. Hashes 3. MACs 4. Digital signatures 5. Tamper resistant protocols |
|
Repudiation |
1. Digital signatures 2. Timestamps 3. Audit trails |
|
Information Disclosure |
1. Authorization 2. Privacy-enhanced protocols 3. Encryption 4. Protect secrets 5. Don’t store secrets |
|
Denial of Service |
1. Appropriate authentication 2. Appropriate authorization 3. Filtering 4. Throttling 5. Quality of service |
|
Elevation of privilege |
1. Run with least privilege |
Briefing
Once threats and corresponding countermeasures are identified, it is possible to derive a threat profile with the following criteria:
- Non mitigated threats: Threats which have no countermeasures and represent vulnerabilities that can be fully exploited and cause an impact.
- Partially mitigated threats: Threats partially mitigated by one or more countermeasures and can only partially be exploited to cause a limited impact.
- Fully mitigated threats: These threats have appropriate countermeasures in place and do not expose vulnerabilities.
Example Model
Briefing
Let’s say we have built a small application, the purpose of this application is to connect to a internal company API, authenticate, extract a list of users with access and the level of access, then the application loads all that data into a AWS RDS instance, to later be ingested by a separate tool(not part of this scope). Lets build a sample Threat model doc
Threat Model Overview Document(Sample)
Description: The Security Department has developed a ELT application that gathers user access information from internal tooling for review and metrics. There are 3 user(s) with access to this application.
- Service account used to connect to api
- Anonymous user will be able to view api call results
- The administrator will be able to view, edit, update, and delete user data.
Application Name: HRconnect(intentionally bad name because that the norm.)
Document Owner: Brandon Williams
Participants: NA
Reviewer: The current Blog Reader
External Dependencies(sample)
External Dependencies refers to objects outside the control of the code that was written in house. This could be data pipelines, code frameworks, WAF implementations, etc.
|
KEY |
Description |
|
1 |
HRconnect connects to an internal API that is connected to the employee management tool for human resources |
|
2 |
HRconnect connects to an AWS RDS instance that is managed by the IT department. |
|
3 |
HRconnect uses Flask version 2.2.5 explicitly for compatibility with the opensource SAST tool |
Entry Points
Entry points are the interfaces that a user, or malicious actor can interact with the application, or input data(e.g. Input fields, methods, user login, API’s)
Entry Points
|
ID |
NAME |
Description |
Access level |
|
1 |
HTTPS port |
HRconnect only allows traffic via TLS |
(1)Service account, (2)anonymous user, (3)Administrator |
|
2 |
Admin portal |
The HRconnect admin portal allows the administrator to view, edit, create, and delete user data |
(1)Administrator |
|
3 |
The view portal |
HRconnect will have a view page with a search box |
(1)Anonymous, (2)service account, (3)Administrator |
Assets
Assets in the context of this document, are the valuable items that are possibly a target for attackers.
|
ID |
Name |
Description |
Access Level |
|
1 |
Account Credentials |
Usernames, emails, personal employee data |
|
|
1.1 |
Employee account data |
The usernames, emails, and country code of employees that will be gathered |
(1)Anonymous internal user, (2) Administrator, (3)Service account |
|
1.2 |
Personal data |
Employees country code, department, and phone numbers will be accessible |
(1)Administrator, (2)Service Account |
|
2 |
System |
System level exposures |
|
|
2.1 |
Ability to execute SQL DB calls |
The ability to select, insert, update, query, and delete database entries is available |
(1)Administrator, (2)Service Account |
|
2.2 |
Ability to query employee management tool |
Http requests to employee management tool is accessible |
(1)Administrator, (2)Service Account |
|
3 |
Web UI |
Web UI related assets |
|
|
3.1 |
Create, Delete , Edit users |
CRUD capabilities are available within the application |
(1)Administrator |
Access Levels
Access levels refers to the rights that the app will grant to the users that interface with it.
|
ID |
Name |
Description |
|
1 |
Administrator |
Application Administrator with full access to the system, is a single key stored in a department Vault. |
|
2 |
Service Account |
Application user, using a API key stored in department vault, and access via SDK |
|
3 |
Anonymous Internal User |
The application is available on the corporate network available via IP or DNS name on Intranet to anyone on network. |
DataFlow
|
HRconnect |
UI |
<-> |
App Backend |
||
|
strength |
weaknesses |
strength |
weaknesses |
||
|
Spoofing |
NA |
No identification of who is accessing ui |
only Administrator and Service account can access |
NA |
|
|
Tampering |
account credentials for Administrator and Service account are rotated monthly |
limited limitations on Service account |
account credentials for Administrator and Service account are rotated monthly |
limited limitations on Service account |
|
|
Repudiation |
NA |
no unique identification of users |
NA |
no unique identification of users |
|
|
Information Disclosure |
NA |
NA |
NA |
NA |
|
|
Denial of service |
NA |
NA |
NA |
NA |
|
|
Escalation of Privileges |
NA |
NA |
NA |
NA |
|
Risk Assessment and Mitigation
Based on the current state of HRconnect. The current Key Management solution is strong and reduces the risk of compromise since the keys are rotated and not stored anywhere other than in the key management vault. Unfortunately due to the fact that there are no required unique identifiers for inbound get requests to the HRconnect webui it is recommended that the webui implements user authentication in order to be able to view the dashboard, Also in order to reduce the risk of someone compromising the integrity of the Administrative account, it is recommended that a separate privileged role is created and given to users that will need privileged access and the administrative account only by used for system updates using a JIT(Just in Time) account vault for the administrative account. Adding unique identifiers will not only satisfy the requirements for being able to monitor for spoofing and tampering based attacks, it will also allow for reputable logging. Also a Vulnerability was discovered within the Python Framework, please patch to a version greater than or equal to Flask version 2.3.2 to patch for the vulnerabilities identified(CWE-2023-30861).
Next Steps
After the recommended mitigations have been placed the security team recommends a full application penetration test, and the implementation of the company SAST device, which will bring the application into alignment with policy. Upon completion of the application penetration test, the Security team would like to revisit this engagement and see where the Risk may have shifted.
For further reading on the subject:
https://owasp.org/www-community/Threat_Modeling_Process
https://en.wikipedia.org/wiki/Threat_model
Modeling tool
https://owasp.org/www-project-threat-dragon/
