Difference between revisions of "Threat Model"
(→Banking) |
(→With a Model) |
||
| Line 83: | Line 83: | ||
* [https://arxiv.org/pdf/2411.17058v1 ThreatModeling-LLM: Automating Threat Modeling using Large Language Models for Banking System] | * [https://arxiv.org/pdf/2411.17058v1 ThreatModeling-LLM: Automating Threat Modeling using Large Language Models for Banking System] | ||
===With a Model=== | ===With a Model=== | ||
| − | A security model can be constructed without having a model of the object, but it requires a different approach than traditional object-based security frameworks. Instead of designing protections around a specific object, you focus on contextual, behavioral, or environmental security principles. | + | A security model can be constructed without having a model of the object, but it requires a different approach than traditional object-based security frameworks. Instead of designing protections around a specific object, you focus on contextual, behavioral, or environmental security principles. The Alternative to a Object Model include: |
| − | + | ====Zero-Trust Architecture (ZTA)==== | |
| − | Zero-Trust Architecture (ZTA) | ||
Security is enforced without assuming trust in any object, identity, or system. | Security is enforced without assuming trust in any object, identity, or system. | ||
| Line 94: | Line 93: | ||
Example: A user’s authentication isn’t based solely on a device but on behavioral patterns (location, access history, anomalies). | Example: A user’s authentication isn’t based solely on a device but on behavioral patterns (location, access history, anomalies). | ||
| − | Threat-Based Modeling | + | ====Threat-Based Modeling==== |
Defines security parameters based on potential threats, not an object’s attributes. | Defines security parameters based on potential threats, not an object’s attributes. | ||
| Line 102: | Line 101: | ||
Example: DDoS mitigation strategies target patterns of excessive traffic rather than a specific resource. | Example: DDoS mitigation strategies target patterns of excessive traffic rather than a specific resource. | ||
| − | Policy-Based Security | + | ====Policy-Based Security==== |
Security decisions rely on defined policies rather than object properties. | Security decisions rely on defined policies rather than object properties. | ||
| Line 110: | Line 109: | ||
Example: Adaptive encryption rules based on network trust levels, not specific device types. | Example: Adaptive encryption rules based on network trust levels, not specific device types. | ||
| − | Behavioral & Anomaly Detection Models | + | ====Behavioral & Anomaly Detection Models==== |
AI-driven detection focuses on abnormal behavior rather than predefined object characteristics. | AI-driven detection focuses on abnormal behavior rather than predefined object characteristics. | ||
| Line 118: | Line 117: | ||
Example: Fraud detection in banking relies on transaction anomalies instead of predefined customer risk profiles. | Example: Fraud detection in banking relies on transaction anomalies instead of predefined customer risk profiles. | ||
| − | Decentralized Identity & Cryptography | + | ====Decentralized Identity & Cryptography==== |
Security models shift from centralized object validation to cryptographic guarantees. | Security models shift from centralized object validation to cryptographic guarantees. | ||
| Line 126: | Line 125: | ||
Example: Zero-Knowledge Proofs (ZKP) allow verification without exposing actual identity data. | Example: Zero-Knowledge Proofs (ZKP) allow verification without exposing actual identity data. | ||
| − | Implications of Object-Free Security Models | + | ====Implications of Object-Free Security Models==== |
Flexibility: Can adapt to unknown objects or changing environments. | Flexibility: Can adapt to unknown objects or changing environments. | ||
Revision as of 15:02, 2 June 2025
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 are 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]
Loren Kohnfelder paper 'Threat Modeling threat modeling'[3]Anytime an endeavor experiences a setback that takes the team by surprise, threat modeling could probably have averted the problem or at least provided an opportunity to plan ahead and take action proactively. Since trouble has a way of surprising us, it’s incredible what a wide range of things this applies to: buying goods or services, crafting legislation, military planning, starting a business, investing, choosing a college and degree program, getting married, you name it. If you don’t consider what could possibly go wrong up front, you can easily make a bad decision or act unprepared.
Crispin Cowan on The Calculus of Threat Modeling [4]
Adam Shostack in 20 Years of STRIDE [5]
Problems
- There are many different Threat Modeling Paradigms. - 12 at this link. This page focuses on the STRIDE method.
- Another model that has been promoted by MITRE is the Attack mode. (qv)
Solutions
From LK book.[6]
- Work from a comprehensive model of the system to be sure to consider everything that is scope.
- Identify assets (valuable data and resources) within the system that need protection.
- Scour the system model for potential threats, component by component, identifying attack surfaces (places where an attack could originate); trust boundaries (interfaces bridging more-trusted parts of the system with the less-trusted parts), and different types of threats.
- Analyze these potential threats, from the most concrete to the hypothetical.
- Rank the threats, working from the most to least critical.
- Propose mitigations to reduce risk for the most critical threats.
- Add mitigations, starting from the most impactful and easiest, and working up to the point of diminishing returns.
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.[7]
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.
Design Models
Traditionally threat modeling has been done based on a data low diagram of the system or application to be analyzed. Other models, like UMF have also been used.[6]
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:
Banking
With a Model
A security model can be constructed without having a model of the object, but it requires a different approach than traditional object-based security frameworks. Instead of designing protections around a specific object, you focus on contextual, behavioral, or environmental security principles. The Alternative to a Object Model include:
Zero-Trust Architecture (ZTA)
Security is enforced without assuming trust in any object, identity, or system.
Access is continuously verified based on dynamic risk factors.
Example: A user’s authentication isn’t based solely on a device but on behavioral patterns (location, access history, anomalies).
Threat-Based Modeling
Defines security parameters based on potential threats, not an object’s attributes.
Uses attack vectors, adversary behavior, and real-time risk assessments.
Example: DDoS mitigation strategies target patterns of excessive traffic rather than a specific resource.
Policy-Based Security
Security decisions rely on defined policies rather than object properties.
Policies adapt to environmental context, ensuring resilience even without full object modeling.
Example: Adaptive encryption rules based on network trust levels, not specific device types.
Behavioral & Anomaly Detection Models
AI-driven detection focuses on abnormal behavior rather than predefined object characteristics.
Security responses adjust dynamically, making object-modeling unnecessary.
Example: Fraud detection in banking relies on transaction anomalies instead of predefined customer risk profiles.
Decentralized Identity & Cryptography
Security models shift from centralized object validation to cryptographic guarantees.
Proof-based security ensures trust without requiring a persistent object model.
Example: Zero-Knowledge Proofs (ZKP) allow verification without exposing actual identity data.
Implications of Object-Free Security Models
Flexibility: Can adapt to unknown objects or changing environments.
Privacy-Preserving: Reduces reliance on static identity tracking.
Resilience: Protects against threats without requiring predefined entity characteristics.
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
- ↑ Loren Kohnfelder, Threat Modeling threat modeling (2023-08) https://designingsecuresoftware.com/writings/threat_modeling_itself/
- ↑ Crispin Cowan The Calculus of Threat Modeling 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
- ↑ 6.0 6.1 Loren Kohnfelder, Designing Secure Software No Starch Press 2022 ISBN 9781718501928
- ↑ 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.
