Please enable JavaScript.
Coggle requires JavaScript to display documents.
Threat Modeling
aims at finding the security problem
Model ->…
Threat Modeling
- aims at finding the security problem
- Model -> bigger picture, not just code
- Answering following questions -> What you build, How can it be wrong, how should you do, do you do a decent job for analysis?
Steps of Thread Modeling
- Build model system
- Find Threat
- Address threats
- Validate your works
- Rate threats
Build Model
- trust boundaries -> accounts, network interfaces, diff physical computers, virtual machines, organizational boundaries
- attack surface -> trust boundaries, can specify how an attack can be launched
What can go wrong -> STRIDE
- Spoofing -> pretend to be something that you are not
- Tampering -> modify sth that you should not do
- Repudiation -> claim you didn't do sth
- Denial of Service -> slow down system, fill storage or totally block the system
- Information disclosure
- Elevation of privilege
How to address threats
- mediate
- eliminate
- transfer
- accept the risk
Strategies -> Spoofing
- Spoof a person -> identification and authentification
- Spoof a file -> leverage OS -> cryptographic --> ACLs, digital signature
- Spoof network -> cryptographic
- Spoof program in memory -> many OSs have some application identifier
Strategies -> tempering
- File
-> ACLs (OS)
-> Digital signature, keyed MAC (Cryptographic)
- Network
-> cryptographic -> HTTPS/SSL, IPsec
-> Network isolation
Strategies -> repudiation
- No Log -> use log
- log comes under attack -> ACL, send over network
- log as an attack channel -> tightly specified logs
Strategies -> info disclosure
- network monitoring -> HTTP/SSL, IPsec
- Directory or filename -> ACLs, File encryption
- API information -> carefully design your API
Strategies -> DoS
- Network flooding
-> network ACLs
-> Work to ensure attacker resource consumption is
as high as or higher than yours, elastic network
- program resources
-> carefully design your program
-> Avoid multipliers
- System resources -> OS setting
Strategies -> elevation of privilege
- data/ code confusion -> use tool to separate data -> prepared statement or SQL, clear separator
- Control flow/ memory corruption attacks -> write a code with a safe type language, use memory protection facilities supplied by OS, sandbox
- common injection attack -> if it's wired, log and throw it
Validate your process
- ensure you build a good test
- extend the script to send a cookie with each request, and
then re-request with an admin cookie
- can your security expose failure on another software?
Type of Threats
- (To network) spoofed packets, port scanning, trace routing, broadcast...
- (To host) buffer overflows, illicit paths
- (To applications) SQL injection, XSS
Against Host
- Buffer overflow, directory traversal
- Malformed HTR request, virtualized UNC share vulnerability
- Unauthorized access
- Exploitation of open ports and protocals
Against Application
- SQL injection -> Drop table or something
- Cross-site scripting (XSS)
- Hidden-field tempering
- Eavesdropping
- Session hijacking
- Identity Spoofing -> stolen form authentication cookie and pretend as others
- Information disclosure
Against Network
- Information gathering
- Eavesdropping
- DoS
- Spoofing
Methodology of threats modeling -> focus on
- assets
- attackers
- software system
Model of assets
- Common assets that an attacker wants -> password or key, SSN or Identifier, Card number, confidential business data
- Things that you want to protect -> most of the time is intangible
- Stepping stone -> CPU can be used by attackers
How to apply ????
- List
- Consider how an attacker can threaten
- Connect all of them
Perspective
- common sense approach
- no direct line
- enumerate assets means you don't fix the threat itself
- generally, this idea come out naturally
Model of attackers
- seems a natural way
- but still less useful
- need to focus on lists of attackers to solve the security problem
- it's hard to know about their motivation....
-
Focus on software model
- Models can be documented by Architecture, UML diagrams, or APIs
- Making an explicit model of your software helps you look for threats without getting bogged down in the many details that are required to make the software function properly.
-
Rate your threats
- Risk = probability * damage potential (1-10 for each)
- DREAD model
-> Greater granularization of threat potential
-> Rates (prioritizes) each threat on scale of 1-15
-> Developed and widely used by Microsoft