02. Threat Modeling

‘Classic’ plan-based process:

• Sequential process:
  • Requirements
  • Design
  • Test plans
  • Coding
  • Testing
  • Deployment/maintenance
• 90s: the internet becomes a thing. Hacking also became a thing.
• Security-related activities jammed into the process
  • User risk analysis
  • Design risk analysis
  • Static code analysis
  • Developer training
  • Coding standards development
  • Security metrics development
  • Penetration tests
    • Breaking into real systems

Secure development lifecycle (SDLC):

• Requirement: security and privacy assessment, project plan
• Architecture: poly assessment, architecture choices
• Design: security test plan, threat modeling
• Development: code quality assurance (e.g. static analysis, fuzzing)
• Release: policy-compliance analysis, vulnerability scan, penetration testing

It is wrong to assume that if you can’t measure it, you can’t manage it - a costly myth

W. Edwards Deming

e.g. how well-trained are users in detecting phishing attempts? Even if you can’t measure it, you can still implement training.

Security assessment:

• Early-stage planning
• Discover and document relevant security aspects and turn them into functional requirements:
  • Identify key persons, laws, standards, infrastructure, third-parties
  • Plan security-related processes (e.g. coding, testing, review, certificating)
  • Define reporting and monitoring objectives
    • React in real-time to anomalous conditions (e.g. system overload, DDOS attacks)
• Privacy impact assessment
  • Exhaustive list of collected data
  • Understanding of legislating
  • Education on data retention, manipulation
  • Least-privilege as a core driver

Architecture:

• Policy assessment and scoping:
  • Define security objectives (e.g. expected level of security, accepted risk)
  • Refine definitions of assets (e.g. new entry point, dependencies)
  • Decompose software in subsystems: for all subsystems, identify threats
  • Threat space:
    • STRIDE
      • Spoofing
        • Accessing/using another user’s credentials
      • Tampering
        • Maliciously changing or modifying persistent data or data in-transit
      • Repudiation
      • Information disclosure
        • Accessing data that they should not have access to
      • Denial of service
        • Denying access to valid users
      • Elevation of privilege
        • Gaining access to previleged resources to access information or compromise a system

Modelling data flows:

                                       Trusted Space
                                     |
                         _____       
---------    data      /       \     | sanitized     ----------
| Actor |  ------->   | Process | ----------------->  Database
---------              \       /     |   data        ----------
                         -----  
                                     |

• Need to specify the semantics of the data flow: is it payment data? the weather?
• The diagram should model process and data flow, not sub-systems

Software detailed design:

• Security testing plan:
  • Dedicated test scripts for security aspects (i.e. test STRIDE threats)
  • Identify key stakeholders and resources (including knowledge gaps)
  • ‘Misuse cases’: how can a hacker misuse something (i.e. hacker’s user stories with ACs)
    • e.g. signing up for an account with someone else’s email: confirmation emails required to prevent spoofing
    • Microsoft DREAD:
      • D: How big is the damage
      • R: How easy is it to reproduce
      • E: How easy is it to exploit? How much time, effort, and expertise is needed?
      • A: How many users are affected
      • D: How easy is it to discover?
  • Define black-box testing strategy (e.g. penetration testing)
    • Sending random requests and seeing what comes back (always return uniform error responses!)
• Review your threat model
  • Is new design bringing new threats or assets?
  • Is the design still in line with legislation and policies
  • Can we ensure a fail-safe state
  • What level of risk can you tolerate? $\text{risk} = {threat} \times \text{vulnerability} \times \text{cost}$

Development and coding:

• Methods and tools:
  • Linters, static code analysis
  • Dynamic code analysis (execution monitoring)
  • Secure coding practices (e.g. sanitation, encapsulation, least-privilege)
  • Fuzzing
  • Code reviews (with checklists)
• Detailed data flow analysis

Release and deployment:

• Policy compliance:
  • Specify, report on results of security activities
  • Update, review deployment infrastructure
  • Discuss with stakeholders and document
• Vulnerability scanning, continuous testing
  • Tool-supported monitoring
  • Chaos engineering: test fail-safe states
• Reporting infrastructure
  • Reporting of issues must be part of security policy
  • Reporting workflow must be clear and communicated
  • System must be monitored

OWASP Threat Modeling Process:

• Decompose the application: identify use cases, users, external dependencies etc.
• Determine, rank threats
• Determine countermeasures or mitigations
  • Accept, eliminate or mitigate risks
• Entry points act as trust boundaries
  • For each entry point, note down the different trust levels (e.g. anonymous, logged in) that can access it
• Exit points: can be used in XSS, information extraction (e.g. SQL injection)
• Assets:
  • For each asset, note down trust levels (e.g. admin, web server process, DB user)
    • Assets could be things such as login sessions (e.g. cookies)
• Threat tree:
  • Root is attack on an asset
  • Children are possible attack vectors (e.g. user did not log out)
  • Grandchildren are possible mitigations for that vector

Uber Eats Scenario:

• End-user app:
  • Contains private details, contact details, address, and bank / PayPal account
  • Order food to, review restaurants, pay via Uber Eats, can tip, and review driver
• Restaurant app:
  • Contains bank account, and business details
  • Food safety information on menu items (e.g., allergen)
  • Negotiated margin, and service fee (private to a restaurant)
  • Receive orders from end-users, authenticate, match driver and ordered food
• Driver app:
  • Receive delivery requests, can combine multiple from same restaurant
  • Can communicate to the end-users through the app