Threat Modelling and Risk Assessment I - CYBR 271 T2 2021 Jennifer Ferreira Ian Welch, Harith Al-Sahaf - ECS Web Hosting
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Threat Modelling and Risk Assessment I CYBR 271 T2 2021 Jennifer Ferreira Ian Welch, Harith Al-Sahaf Slides based upon these ones: https://www.cs.montana.edu/courses/csci476/topics/secure_coding_principles.pdf
Book Threat Modeling: Designing for Security by Adam Shostack Publisher: Wiley Release Date: February 2014 https://learning.oreilly.com/library/ view/threat-modeling- designing/9781118810057/
Goal Start thinking about the threats that might impact the applications or systems that you build and how you might protect against them. CYBR 271: Secure Programming Slide 3
Definitions Asset Vulnerability Threat Security Controls aka “mitigations” Something that Weakness or Something that Protect against should be lack of could negatively threats, reduce protected protections impact an asset vulnerability Risk The possibility that a threat will exploit a vulnerability to harm an asset Risk = Threat * Vulnerability More detail at: https://csrc.nist.gov/glossary/ CYBR 271: Secure Programming Slide 4
Why? Non- Data Loss Monetary Cost Reputation compliance Weight/Cost of Weight/Cost of Risk Realisation Countermeasures CYBR 271: Secure Programming Slide 5
Question • Do you know any examples of standards or laws that you need to comply with? CYBR 271: Secure Programming Slide 6
Question • Do you know any examples of standards or laws that you need to comply with? • NZ Information Security Manual (NZISM) https://www.gcsb.govt.nz/publications/the-nz-information-security-manual/) • NZ Privacy Act https://www.privacy.org.nz/the-privacy-act-and-codes/privacy-act- and-codes-introduction/ • EU General Data Protection Regulation (GDPR) https://gdpr-info.eu/ • US Health Information Portability and Accountability Act HIPAA https://www.hhs.gov/hipaa/index.html • Payment Card Industry Data Security Standard PCI DSS https://www.pcisecuritystandards.org/pci_security/ CYBR 271: Secure Programming Slide 7
When? After Implementation During Development • High cost to fix issues • Consider security during system design and development to reduce vulnerabilities • More vulnerabilities = more risk • Ongoing CYBR 271: Secure Programming Slide 8
Question • Why is it ideal for the application of the risk management process to be ongoing? CYBR 271: Secure Programming Slide 9
Question • Why is it ideal for the application of the risk management process to be ongoing? • New attack tools developed • New vulnerabilities discovered • Maintenance of the system introduces new vulnerabilities • System is deployed into a different environment changing assumptions about potential threats CYBR 271: Secure Programming Slide 10
How? Threat Modelling Analysing the Determining Addressing Application/System Threats Threats What does the What could go What can you do? system do? wrong? CYBR 271: Secure Programming Slide 11
Question • Why is it ideal for the application of the process to be ongoing? • New attack tools developed • New vulnerabilities discovered • Maintenance of the system introduces new vulnerabilities • System is deployed into a different environment changing assumptions about potential threats CYBR 271: Secure Programming Slide 12
Threat Modelling techniques Unstructured Structured 1. Persona non Grata 1. STRIDE 2. Misuse cases 2. DREAD 3. Security cards 3. Attack trees 4. Privilege escalation game 4. Attack libraries 5. PASTA 6. VAST 7. Trike 8. OCTAVE 9. NIST SOME TECHNIQUES CAN BE COMBINED TOGETHER CYBR 271: Secure Programming Slide 13
Threat Modelling techniques Unstructured Structured 1. Persona non Grata 1. STRIDE 2. Misuse cases 2. DREAD 3. Security cards 3. Attack trees 4. Privilege escalation game 4. Attack libraries 5. PASTA 6. VAST 7. Trike 8. OCTAVE 9. NIST CYBR 271: Secure Programming Slide 14
Why follow a particular technique? Key benefit is it makes developers and implementers answer the question: what is your threat model? Clarifies assumptions. Security always costs in terms of time, $$$ or performance. Avoid wasting effort on necessary defences. Focuses effort on actual defences. CYBR 271: Secure Programming Slide 15
Example – getting it wrong https://en.wikipedia.org/wiki/Maginot_Line 450 km CYBR 271: Secure Programming Slide 16
Example – getting it wrong CYBR 271: Secure Programming Slide 17
Example – getting it wrong CYBR 271: Secure Programming Slide 18
How? Threat Modelling Analysing the Determining Addressing Application/System Threats Threats What does the What could go What can you do? system do? wrong? CYBR 271: Secure Programming Slide 19
System Analysis Functions? Data? CIA? Users? Technology used? Interfaces? Connected systems? User requirements? Non-functional requirements?
System Models UML – Swimlanes UML – Use cases State machines Data flow diagrams (1970s)
How? Threat Modelling Analysing the Determining Addressing Application/System Threats Threats What does the What could go What can you do? system do? wrong? CYBR 271: Secure Programming Slide 22
Unstructured: Brainstorming Experienced experts in a room. Whiteboard, papers …. Number parts of the diagram so it is easier to refer to the same part in discussions, e.g. boxes and data flows for a web application Add trust boundaries to show who controls what and identify the attack surface.
Unstructured: Brainstorming Now consider what can go wrong with security. eg. For the system below: - What is the web browser is being used by the person you expect? - What happens if someone modifies data in the database? - Is it OK for data to move from one box to another without being encrypted?
Unstructured: Brainstorming Now consider what can go wrong with security. Techniques: - Persona non grata - Use cases - Security cards
Unstructured: Brainstorming Now consider what can go wrong with security. Techniques: - Persona non grata - Use cases - Security cards
Personas Developing systems is hard if you don’t know for whom you are developing. Personas are fictional characters, which you create based upon your research in order to represent the different user types that might use your service, product, site, or brand in a similar way. Creating personas will help you to understand your users’ needs, experiences, behaviours and goals. https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them
Personas – typical example Fictional biography: - user’s education, lifestyle, interests, values, goals, needs, limitations, desires, attitudes, and patterns of behaviour. - a few fictional personal details to make the persona a realistic character. Persona needs a name and a photo to personalise them. Persona isn’t an ideal person, they can be https://xtensio.com/user-persona/ flawed like real people. A rule of thumb is that a project will Create 1–2-pages of descriptions for each typically have 5-8 personas. persona.
Persona non grata (PnG) Latin for “an unwelcome person” Article 9 of the 1961 Vienna Convention for Diplomatic Relations. A country can declare a member of a diplomatic staff persona non grata “at any time and without having to explain its decision”. Must leave and never re-enter. https://www.dw.com/cda/en/what-does-it-mean-to-be-declared-persona-non-grata/a-47800884 Examples: German ambassador to Applied to security to help people develop Venezuela (2019) misuse cases.
Persona non grata (PnG) J. Cleland-Huang. How Well Do You Know Your Personae Non Gratae? IEEE Software, 31(4):28– 31, July 2014. Focus on atypical users who act in unwanted, possibly nefarious ways. Background gives us their motivations and abilities. Goals that they want to achieve. http://www.propublica.org/images/ngen/gypsy_big_image/gt-anonymous-hacker- mask-147972008-630.png Help us develop misuse cases that may achieve these goals using their abilities.
Persona non grata – Example (ICDs) Implantable cardioverter-defibrillators (ICDs) A Hybrid Threat Modeling Method Nancy R. Mead Forrest Shull Krishnamurthy Vemuru, University of Virginia Ole Villadsen, Carnegie Mellon University March 2018 TECHNICAL NOTE CMU/SEI-2018-TN-002 https://resources.sei.cmu.edu/asset_files/TechnicalNote/2018_004_001_516627.pdf
Persona non grata – personas
Unstructured: Brainstorming Now consider what can go wrong with security. Techniques: - Persona non grata - Use cases - Security cards
Use cases Use case – sequence of actions providing value to an actor (horizontal ellipse). Actors – an actor is a person, organization or external system that plays a role in one or more interactions. Usually a stick figure. Associations – between actors and use cases represented by solid lines. Optional arrowhead indicates direction of the initial invocation. Roles – in > marks – extend, include Unified Modelling Language (UML) use cases
Misuse case Evil twin of a use case: “special kind of use case, describing behavior that the system/entity owner does not want to occur” (Sindre & Opdahl, 2000). A misuser is a bad actor: “an actor that initiates misuse cases, either intentionally or inadvertently” (Alexander, 2002)
Misuse case Misuse cases and use cases shown together. The association between a misuse case and a use case can either be a “threatens” or a “mitigates” relationship. https://www.cs.auckland.ac.nz/courses/compsci725s2c/archive/termpapers/csia.pdf
Persona non grata – add misuse cases
Unstructured: Brainstorming Now consider what can go wrong with security. Techniques: - Persona non grata - Use cases - Security cards
Security cards Emphasis of creativity and brainstorming. Useful for fundamental learning to aiding professional threat modelers. Answer four main questions: - If your system were compromised what human assets could be impacted? - Who might attack your system and why? - What resources might the adversary have? - How might the adversary attack your system? AMARA DENNING, BATYA FRIEDMAN, AND TADAYOSHI KOHNO (2013) https://securitycards.cs.washington.edu/
Unstructured: Brainstorming - features 1. Quality of the exercise is bounded by experience of brainstormers and amount of time spent brainstorming. 2. Inconsistent results when repeated due to influence of prior experience – more consistency if misuse cases and PnG developed. 3. Misuse cases & PnG used together: 1. Bringing the attacker into the system model 2. Use natural language to communicate the results to the customer or users. 3. Helps identify mitigations. 4. Easier to assess relative risk of threats based upon attacker motivations and abilities 4. Improved technique: security cards to give prompts and allow less experienced security people or non-security people to become involved in the threat modeling process.
Threat Modelling techniques Unstructured Structured 1. Persona non Grata 1. STRIDE 2. Misuse cases 2. DREAD 3. Security cards 3. Attack trees 4. Privilege escalation game 4. Attack libraries 5. PASTA 6. VAST 7. Trike 8. OCTAVE 9. NIST CYBR 271: Secure Programming Slide 42
You can also read