Difference between revisions of "Threat Model"
(→Complete Security) |
(→References) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 37: | Line 37: | ||
| Elevation of Privilege || Authorization | | Elevation of Privilege || Authorization | ||
|} | |} | ||
| + | |||
| + | See [[Native App Security]] for a comparison with a set of threat events from NIST NCCoE. | ||
| + | |||
===Mandatory Access Levels=== | ===Mandatory Access Levels=== | ||
| Line 55: | Line 58: | ||
Template | Template | ||
| − | # Spoofing: | + | # [[Identity Spoofing]]: The attacker is able to act as the user |
# Tampering: | # Tampering: | ||
# Repudiation: | # Repudiation: | ||
| Line 73: | Line 76: | ||
[[Category:Vulnerability]] | [[Category:Vulnerability]] | ||
[[Category:Profile]] | [[Category:Profile]] | ||
| − | + | [[Category: Risk]] | |
Latest revision as of 15:26, 13 December 2021
Contents
Full Title or Meme
A model of an information processing system that shows data flows around the system and which spots in the network that a susceptible to attack.
Context
Carnegie Mellon University Software Engineering Institute published a report on "Threat Modeling: 12 Available Methods" [1]
Loren Kohnfelder paper 'Threat Modeling Retrospective'[2]
Crispin Cowan on The Calculus of Threat Modeling [3]
Adam Shostack in 20 Years of STRIDE [4]
Problems
Solutions
A comprehensive Data Flow Diagram is the first step to creating a threat model.
STRIDE is an acronym for: Spoofing identity, Tampering data, Repudiation (denial of responsibility), Information disclosure (data breach), Denial of Service (DoS), and Elevation of privilege.[5]
Each threat is a violation of a desirable property for a system:
| Threat | Desired property |
|---|---|
| Spoofing | Authenticity |
| Tampering | Integrity |
| Repudiation | Non-repudiability |
| Information disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorization |
See Native App Security for a comparison with a set of threat events from NIST NCCoE.
Mandatory Access Levels
As expressed in the Bell-LaPadula Model there are two rules:
- The simple security policy that allows no read up to acquire data from a higher privilege process.
- The star (*) policy that allows no write down to send data to a lower prevailed process (or directory).
One example of a MAC treat export was and article by Joel Reardon on apps from related companies where an app with high privilege reads the device IMEI and writes it into a file that can be read by a app that does not have that privilege. They were discovered by looking at the data flowing from the less privilege app looking for data exfiltration.
Mandatory Integrity Levels
As expressed in the Bell-LaPadula Model there are two rules:
- no read down
- no write up
Complete Security
- From the about is should be clear that no access for read or rite is allowed to cross any level boundary.
- Since this does not allow for most purposes in computer science some sort of trust monitor is required for any level transition.
Template
- Identity Spoofing: The attacker is able to act as the user
- Tampering:
- Repudiation:
- Information Disclosure:
- Denial of Service: Making the system temporarily unavailable or unusable, such as those attacks that could force a reboot or restart of the user's machine. When an attacker can temporarily make the system resources (processing time, storage, etc.) unavailable or unusable, we have a denial of service threat. We must protect against certain types of D.o.S. threats for improved system availability and reliability. However, some types of D.o.S. threats are very hard to protect against, so at a minimum, we must identify and rationalize such threats.
- Elevation of Privilege:
References
- ↑ Nataliya Shevchenko, Threat Modeling: 12 Available Methods (2018-12-03) https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
- ↑ Loren Kohnfelder, Threat Modeling Retrospective Medium https://medium.com/@lorenkohnfelder/threat-modeling-retrospective-72910908533c
- ↑ https://www.leviathansecurity.com/blog/the-calculus-of-threat-modeling
- ↑ Adam Shostack, 20 Years of STRIDE: Looking Back, Looking Forward. Dark Reading https://www.darkreading.com/20-years-of-stride-looking-back-looking-forward/a/d-id/1334275
- ↑ Garg and Kohnfelder The threats to our Products. (1999) Microsoft https://adam.shostack.org/microsoft/The-Threats-To-Our-Products.docx
- Transforming Data Flow Diagrams for Privacy Compliance Privacy by Design, Data Flow Diagrams, GDPR.
Abstract: Most software design tools, as for instance Data Flow Diagrams (DFDs), are focused on functional aspects and cannot thus model non-functional aspects like privacy. In this paper, we provide an explicit algorithm and a proof-of-concept implementation to transform DFDs into so-called Privacy-Aware Data Flow Diagrams (PA-DFDs). Our tool systematically inserts privacy checks to a DFD, generating a PA-DFD. We apply our approach to two realistic applications from the construction and online retail sectors.
- Michael Howard, Praerit Garg Loren M. Kohnfelder, RAPID APPLICATION SECURITY THREAT ANALYSIS US Patent 7,243,374 B2 (2007-07-12) Abstract
The following Subject matter provides for modeling an application's potential security threats at a logical component level early in the design phase of the application. Specifically, in a computer system, multiple model components are defined to represent respective logical elements of the application. Each model component includes a corresponding set of security threats that could potentially be of import not only to the component but also to the application as a whole in its physical implementation. The model components are interconnected to form a logical model of the application. One or more potential security threats are then analyzed in terms of the model components in the logical model.
