CIS 6614 meeting -*- Outline -*-

* Threat Modeling

  Q: What is a threat?
  A possible attack and what an attacker might gain from it.

  Q: What is the difference between a threat and a vulnerability?
  A threat is a potential attack (an action that might happen)
  A vulnerability is a weakness (situation) that an attack might exploit

  Q: What is threat modeling?
     Analyzing the threats to the security and privacy of a system,
     ranking them, and planning to prevent (or mitigate) them.
     It's essentially planning.

  Q: What are the basic questions to ask about threat modeling?
     According to the "threat modeling manefisto":
 1. What are we working on?
 2. What can go wrong?
 3. What are we going to do about it?
 4. Did we do a good enough job?

  Q: Why do threat modeling?
     Costs less and is more effective than fixing vulnerabilities later.

** the Threat Modeling Manifesto
   Adapted from www.threatmodelingmanifesto.org

   Q: What kinds of values does the threat modeling manifesto advocate?
   (In general a thoughtful process of understanding and writing it down)

  - A culture of finding
    and fixing design issues
    (over checkbox compliance)
     
  - People and collaboration
    (over processes, methodologies, tools)

  - A journey of understanding
    (over a security or privacy snapshot)
    
  - Doing threat modeling
    (over talking about it)

  - Continuous refinement
    (over a single delivery)

*** principles
  Q: What is the goal of threat modeling?
    To improve security and privacy through early and frequent analysis.

  Q: Does a threat model need to keep up with the system's design?
    Yes, it must follow the design as it changes

  - Outcomes are meaningful
    when stakeholders value them
    
  - Dialog is key to understanding,
    documents record understandings
    and enable measurement

*** patterns

  Q: What approaches or attitudes are helpful in threat modeling?
     - being systematic, thorough, scientific (reproducible)
     - thinking creatively, like an attacker   

  Q: Is doing threat modeling in a team useful?
     - Yes, it's helpful to have many people who think differently
        and know different things.

*** anti-patterns
  Q: What is an anti-pattern?
     Something you shouldn't do

  Q: What shouldn't be done in threat modeling?
     - relying on just one person (the hero)
     - just analyzing the problem without looking for practical solutions
     - focus on just one part of the problem
          (e.g., adversaries, assets, or techniques)
     - using just one representation for modeling threats
          (they suggest multiple views and multiple representations are better)

** Process for Attack Simulation and Threat Analysis (PASTA)

   See https://youtu.be/8k-I3vn8C2A (for an overview video),
   https://versprite.com/blog/what-is-pasta-threat-modeling/
   (for an overview), and
   https://versprite.com/ebooks/leveraging-risk-centric-threat-models-for-integrated-risk-management/
   (for an ebook, free but requires registration)

   Q: What does PASTA stand for?
      "Process for Attack Simulations and Threat Analysis"
      
   Q: What are the stages of the PASTA approach?

   1. Define objectives
       What is app's purpose?
       What is the business impact?
       What requirements/compliance?
   
   2. Define technical scope/attack surface
       What is the high level arch./design?
       What tech. is involved?
         - protocols?
         - types of data?
         - s/w and tech. dependencies?
         - servers? services?
         - network devices?
   
   3. Decompose the app.
       What assets? What dataflows?
       What actors? Roles? Permissions?
       What trust levels? trust boundaries?
       Any implicit trust relationships?

      Q: What is "implicit trust"? What's an example?
         when one component trusts what another says,
            often inside a private network 
            e.g., about its the identity

      stage 3 produces: - a DFD and trust boundaries
                     - an access control matrix
                     - list of assets including
                        data, data sources and trust levels.

      implicit trust is a "good candidate for exploitation"

   4. Analyze threats
       What are the probable scenarios?
       What do logs or reports tell us?
   
   stage 4 produces: - attack-scenario landscape report
                     - list of threat agents and attack vectors
                     - report on what incidents/events are likely
                       and attack scenarios,
                         with evidence for how likely these are

   5. Vulnerability analysis
       How do existing vulnerabilities map
         to threats?
       How likely are these to be exploited?
   
   6. Attack analysis
       What is the app's attack surface?
       What attack vectors are likely?
   
   7. Risk and impact analysis
       What is the remaining risk?
       What is the business impact?

   stage 7 produces: - app risk profile
                     - risk report
                     - threat matrix with:
                          threats, attacks,
                          vulnerabilities, business impact
                     - risk mitigation strategy