Personal Notes

• Threat: A potentially successful attack Risk: The potential for harm or damage, measured as the combination of the likelihood x impact
• Vulnerability: A weakness identified in the product for which an exploit does exist

Threat Modeling answers:

1. [Assets] What assets need to be protected
2. [Threats] What are the threats to these assets
3. [Risk] How important or likely is each threat?
4. [Fix] How can we mitigate the threats?

Decompose -> Identify Threats -> Analyze Risks -> Mitigate Risks -> Validate

• Decompose: What are we building? Identify assets and Actors, we use a graphical representation with Data Flow Diagram.

  

• Identify Threats: Get the Data Flow Diagram and ask what can go wrong, ask questions. Use STRIDE or Attack Trees for guidance.

  STRIDE:

  • **S**poofing
  • **T**ampering
  • **R**epudiation
  • **I**nformation Disclosure
  • **D**enial of Service
  • **E**levation of Privileges

  

  Attack Trees: Set the root node as the goal (obtaining root) and represent the attack as a tree, where the leaf nodes are different ways of achieving that goal.

  

  Other popular threat models:

  • OWASP IoT Vulnerabilities Projects
  • LINDDUN: Privacy Threat Analysis Methodology
    • Linkability: Being able to determine if two entities are linked
    • Identifiability: Being able to identify a subject
    • Non-Repudiation: Not being able to deny a claim
    • Detectability: Being able to determine wheter a item exists
    • Disclosure of Information
    • Unawareness: Being unaware of consequences of sharing information
    • Non-compliance: Not being compliant with legislation
• Risk Analysis: Determine wheter identified threat can be neglected or what mitigation should be applied.

There are some general Scoring Systems:

• CWSS (Common Weakness Scoring System)
• CVSS (Common Vulnerability Scoring System)
• CWRAF (Common Weakness Risk Analysis Framework)
• Select CWEs that are related
• DREAD:
  • Damage: Assess the damage result from the attack
  • Reproducibility: How easy an attack can be reproduced
  • Exploitability: Effort and expertise to mount the attack
  • Affected: How many users would be affected
  • Discoverability: Likelihood that a threat will be exploited

The trusted computing base is a collection of hardware, software and firmware components that provide some form of security and enforce the policy.

The security perimeter is a boundary that divides the trusted from the untrusted.

The security model specifies the operational and funcitonal behavior of a system for security. There are many security models:

• Graham-Denning Model: Formal system of protection rules
• Information-Flow Model: Demonstrates data flows, communications channels…
• State-Machine Model : Abstract Math model
• Non-Interference Model: Subset of information-flow model that prevents subjects operating in one domain from affecting each other in violation of security policy.
• …

Access is the flow of information between a subject and an object.

Access capability is what a subject can do to an object

Access control governs the information flow.

• Discretionary Access Control (DAC): is where the information owner determines the access capabilities of a subject to what objects
• Mandatory Access Control: Is where the access capabilities are predetermined by the security classification of a subject and the sensitivity of an object

Make security an integral part of design phase of product development.

• Design your product with the fact in mind that it will be attacked
• Integrate security controls from the beginning
• Make security tests a critical part of development process

Goals:

• Spell out threats to a system
• Provide system architecture mitigating as many threats as possible
• Employ design techniques, forcing developers to consider security with every line of code
• Enforce necessary authentication, authorization, confidentiality, data integrity..
• Design a robust security archivecture
• Take malicious practices for granted.

Design techniques: Minimize attack surface.

Principle of least privilege: SW processes and their authorized users shall be granted only those privileges required for them to carry out their specified function.

Principle of least functionality: Disable/Uninstall unused functionality, protocols, ports, services, etc. Limit the SW functionality to the strictly needed.

Defense in depth: Multiple layers of security controls in place. If one mechanism fails, another will be in place.

Ensure confidentiality: Encrypt sensitive data and use standarized algorithms.

Ensure integrity: Use secure boot, design secure update process, verify integrity.

Ensure authenticity and non-repudiation: Use standarized protocols and algorithms

Secure Communication: Never communicate over insecure channels, verify authenticity of data

Defensive Programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances.

• Source code should be readable & understandable
• Make SW behave predictable even in case of unexpected inputs/actions
• Assume that SW will be attacked, use safe functions.

Key principles:

• DRY (Don’t Repeat Yourself)
• SOLID:
  • S: Single Responsibility Principle
  • O: Open for extension, closed for modification
  • L: Liskov substitution principle
  • I: Interface segregation principle
  • D: Dependency Inversion Principle
• CQRS (Command Query Responsibility Segregation): Segregate operations reading data from operations updating data

• Cryptography
• Protocols: TLS, IPsec, Wireguard
• Privacy Techniques:
• Hardware Security: TPM, Hardware Security Modules, Secure Elements, Trusted Execution Zones, Root of Trust
• Authentication and Authorization
• Key Management

High: Review of technical documentation, testing to demonstrate the products have the security funcitonalities properly implemented, an assessment of the resistance of skilled attackers (big pentest).

Substantial: Review of technical documentation and medium pentest

Basic: Review of technical documentation or minimal pentest.

• EU Cybersecurity Act
• GDPR
• California Consumer Privacy Act
• Common Criteria

Functional Security: Demonstration that your security is correctly implemented. Done by functional testing. Robustness: Demonstration that the way how your security is implemented, cannot be bypassed. Done by penetration testing, fuzzying, etc

Common Criteria is an international set of guidelines and specifications developed for evaluating information security products, specifically to ensure they mett an agreed-upon security standard.

It consists of:

• CC Part 1: Introduction and General Model
• CC Part 2: Security Functional Requirements (SFRs)
• CC Part 3: Security Assurance Requirements (SARs). Also presents the evaluation criteria for PPs and STs and present seven pre-defined assurance levels.
• CEM (Common Evaluation Technology)

Wording:

• TOE: Target of Evaluation. The product.
• ST: Security Target. The security claims made for the product.
• PP: Protection Profile. Describes a type of TOE, for example firewalls, smartcards, etc.
  • Can be used as a template, then if the PP is certified, the ST can claim conformance to the security target.
  • Written by a community seeking consensus regarding a TOE
  • By a goverment specifyin its requirements as part of an acquisition process
• SFR: Set of Functional Components
• SAR: Set of Assurance Components
• EAL: Evaluation Assurance Levels

OWASP Top 10:

1. Injection: SQLi Injection for Example
2. Broken Authentication: Easy bruteforce, bad sessionID, bad sessID validation
3. Sensitive Data Exposure: Plaintext data transmission, weak crypto
4. XML External Entities: Sending malformed XML (w/ Javascript, etc.)
5. Broken Access Control: Bypass restrictions, modifying JWT, etc
6. Security Misconfiguration: Generalistic. Readable .htaccess, .git access
7. Cross-Site Scripting (XSS): Reflected (temporal), stored (permanent), DOM (dynamic)
8. Insecure Deserialization: Bad parsing
9. Using Components with Known Vulnerabilities:
10. Insufficient Logging and Monitoring:

CVEs: Database of known vulnerabilities for many products

CWEs: Comprehensive List of “bad practices” in implementation

We have to:

• Extract version/configuration that was tested
• Provides a detailed explanation of the tests performed
• States the results
• Points out the limitations of the test

Structure:

• Executive summary
• Introduction
• Results summary
• Testing Summary
• Detailed Results
• Recommendations

OWASP Mobile Application Security Verification Standard can be used by mobile software developers to develop secure mobile applications.

It’s like a list of requirements, for example:

• No sensitive data is written to application logs

It has the following chapters:

• V1: Architecture. Design and Threat Modeling Requirements
  • SDLC (Security Development Lifecycle)
  • Threat Modelling
• V2: Data Storage and Privacy Requirements
  • Use system storage facilities
  • No data stored outside app container
  • No data leakage via logs
• V3: Cryptography Requirements
  • Apply crypto properly
  • No hardcoded keys
• V4: Authentication and Session Management Requirements
  • Password policy
  • Login to remote services
  • Proper authorization/authentication
• V5: Network Communication Requirements
  • Use TLS
  • X.509 Certificate Validation
• V6: Enviromental Interaction Requirements
  • App folow best practices
  • Minimum set of permissions
  • User input validation
• V7: Code Quality and Build Setting Requirements
  • Use proper code practises, for example stack protection
  • No debug builds
  • No dead code
  • Proper exception handling
• V8: Resiliency Against Reverse Engineering Requirements
  • Sandbox detection
  • Obfuscation
  • App detects root on device

OWASP Mobile Security Testing Guide is a comprehensive manual for testing the security of mobile apps. It describes processes and techniques for verifying the requirements listed in the MASVS

It’s the test cases for the previous list of requirements.

It provides the following verification levels:

• MASVS-L1: Standard Security
  • Basic Applications
• MASVS-L2: Defense-in-Depth
  • Sensitive Applications
• MASVS-LR: Resiliency Against Reverse Engineering and Tampering

They can be combined, for example L1 + LR, L2 + LR.

1. Improper Platform Usage
   • Improper use of TouchID, Keychain, etc.
2. Insecure Data Storage
   • Insecure storage in filesystem
   • Unencrypted mysql
   • Log files
3. Insecure Communication
   • No usage of TLS
   • Traffic can be sniffed
4. Insecure Authentication
   • Bypass authentication
5. Insufficient Cryptography
   • Weak cryptography
   • Hardcoded keys
6. Insecure Authorization
   • Can execute higher privilege actions
7. Client Code Quality
   • Typical memory leaks, overflows
8. Code Tampering
   • Malware, security bypass, etc
   • Ensure code integrity
9. Reverse Engineering
   • Get information like strings
   • Reveal ciphers, keys, etc.
10. Extraneous Functionality
    • Misc. functionality like hidden switches

Root of Trust: Foundation for all security related functions

Bootloader relies on root of trust for loading firmware image

Secure Boot Flow:

1. Initialize Hardware
2. Initialize Flash
3. Copy from flash to SRAM
4. Verify copy in SRAM
5. Jump to SRAM or Fail

How to evaluate the bootlaoder? Change the firmware image, perform glitching attacks, etc.

TEE (Trusted Execution Enviroment) is multiple hardware and software components that protects the TEE from real world. Can run trusted applications (TA)

Security is never static, newly found vulnerabilities result in new attack vectors. Security must be considered throughout the whole product lifecycle.

We have to update the devices deployed on field, and yes, the field is an untrusted enviroment. We need a secure in-field update mechanism.

• Assets: FS/SW image
• Threats: Tampering of image, leakage of image, loading unauthorised image, etc.
• Attackers are targeting FS/SW image, device during update process, backend infrastructure.

Main security requirements of the update process:

• Authenticity
• Integrity
• Confidentiality
• Integrity

How can we guarantee that updates are distributed only to uncompromised devices? How can we obtain the SW version of a device?

• Secure Boot: Guarantees that only trusted SW components are loaded during startup
• Remote device attestation: Allows remote service to verify device security state
• Sealing: Locks keys to specific, secure device state

The platform integrity state is gathered during the secure boot by measuring SW components loaded during startup. These components are only loaded after successful integrity check.

Platform Configuration Registers (PCRs), can securely store measured hash values and results are compared to expected values. New PCR values are obtained by hash-chaining old values with the extension value. Then we report signed PCR state to remote service.

Direct Anonymous Attestation (DAA) is a privacy protocol designed for TPMs. Backend checks signature & PCR values against reference values, on success, it knows that it is interacting with valid uncompromised platform.

EU is regulating market surveillance

It allows to do spot checks of products

Device should support deletion of any stored sensitive data when end-of-life is reached.

For products intended to be part of a large system, decommissioning procedures shall be provided to allow for the product to be removed from the system.