The document outlines the agenda for a threat modeling workshop. The workshop includes three sessions: (1) BYOTM where attendees bring their own threat models to work on together, (2) an advanced threat modeling session on applying rapid techniques in a DevOps environment, and (3) an introductory threat modeling primer. The document then provides more details on topics covered in each session, including customizing approaches to organizational needs, key threat modeling terms, and frameworks that can be used. It emphasizes the importance of focusing threat modeling efforts on adding value and keeping practices sustainable.
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Threat modeling (Hacker Stories) workshop
1. Threat Modeling Workshop Agenda
BYOTM (Bring Your Own Threat Model)301
● Let’s threat model together!
● Bring your own threat model scenarios
Advanced threat modeling in a DevOps
world (aka Hacker Stories)
201
● Rapid Threat Modeling
● Applying a business oriented process
● Customize to your need
Overview of Threat Modeling101
● Threat Modeling Primer
● Threat Modeling Approaches (Pros vs. Cons)
2. Whoami
Education
● Penn State University - B.S. Information Science and Technology
● Norwich University - Masters of Science Information Assurance
Certifications
● CISSP, SSCP, CEH, CCSK, CPT
3. Independent, personal opinion, not a
representation of my current employer or
specifically of any past employees
Disclaimer
“A man person convinced against his their will, is of the same opinion
still” - Ben Franklin
7. 1. Actor - The subject, but can be a hacker, malware, employee, etc.
2. Threat - An actor who is regarding as a danger or a menace
3. Vulnerability - A specific weakness in protections or controls
4. Impact - How bad could it be
5. Likelihood - What is the probability of it occurring
Threat Modeling Key Terms
8. When do I threat model?
1. Scope Defined
a. Significant Changes
b. New Features
c. Business Critical Feature Enhancements
2. Time Defined
a. Align with SDLC
b. Project timing, resource availability
Anytime
9. When do I stop?
1. Lacks value or actionable outputs
2. Resource constraints
3. ...People stop caring or doesn’t add value
Risks have been mitigated or goals have been achieved
10. Who do I involve?
1. Product Owners
2. Architects
3. Business Leaders
4. Developers
5. Testers
6. Etc.
It depends on the scope of the threat model and your goals
11. What framework should I use?
NAME PROS CONS
STRIDE / DREAD Business Oriented
Simple (Impact vs. likelihood)
Usability
Adoption
OCTAVE, OCTAVE-Allegro Organization / Practice focused
Flexible (large vs. small org)
Time Consuming
Not for ad-hoc
TRIKE Tool driven
Flexibility
Time Consuming
Maintenance?
PASTA Risk Centric
Incorporates other security activities
Time Consuming
Scalability
FMEA Business focused
Simple business engagement
Time Consuming
Limited validity in Isolation
Pick any, just try to start smart
12. Can’t I just use tools?
1. Can require Data Flow Diagrams
a. You create Data Flow or Architecture Diagrams
2. Cost (Direct vs. Indirect)
a. Tools can be free and open source
b. Windows only!? (e.g. Microsoft Threat Modeling tool 2016)
3. Potential for missing the business intelligence
You can always partner or purchase tools to assist, but don’t forget
about the culture
13. Threat Modeling Thematics
1. Data Driven
a. Architecture / Data Flow Diagram
2. SME Involvement
3. Actionable Artifact
4. Taxonomy
Determine how to add maximum value with minimal overhead
14. Threat Modeling 101 Takeaways
1. Threat Modeling is valuable in communicating risk
a. Be focused and “Don’t try to boil the ocean”
2. Find what works for your organization
a. Culture is key
3. Don’t try to over engineer or make it too complex
a. Keep in mind sustainability
17. What is In-Scope?
1. High Risk changes (contextual to the business)
2. New Tech, New Supplier, New API
3. Architect doesn’t have a “trusted” blueprint
4. Authentication Changes
Out of Scope
1. Repeat changes using existing controls
2. Content Changes
3. Threat model already exists and are nominal changes
HACKER STORIES are Product Management and Engineering friendly
18. How do I understand the business?
1. Assets
a. Keys to the Kingdom (Credentials, Information, People)
b. Data Processing Systems (Financial, Intelligence, Movement)
c. Physical (Currency, Goods, People)
2. What are the goals of the organization
a. Overall Mission
b. Annual / Quarterly Goals
Understand how your company makes profit
19. What about existing security controls?
1. Capabilities / Services Matrix
a. What already in place?
i. Secure SDLC
ii. IDS/IPS
iii. FIM
iv. Authentication/Authorization
b. What is in the pipeline?
i. RASP / Next Gen Firewalls
ii. vSOC
Focus on actionable risks, not capabilities already established
20. High Level Post-It Completion
Who - Well defined persona
○ Malicious Hacker
○ Casual Security
Researcher
○ Internal Threat
What/How - Attack Pattern /Goal
○ Steal Money/Data
○ Upload Malware
Any
Where - Location of opportunity
○ Environment
○ Internal/External
○ Cloud vs Data Center
When - Likelihood
○ Timing
○ Environment
21. Hacker Persona
1. How can I impact the business?
2. What do I have to do, to cause damage?
3. What are the benefits for me? Hacker GOALS.
4. How easy it to exploit the vulnerability?
Put on your HACKER GOGGLES and think about what you could do, but
keep it grounded.
22. Definition of done?
1. Controls get built-in
a. Code/Feature delivered
2. Manual or automated code review to validate
3. Manual or automated dynamic testing to validate
4. Introduce Test Cases within QA
Trust, but verify
23. Downsides to Hacker Stories?
1. Not as comprehensive as traditional threat
modeling
2. Lacks visual documentation, but doesn’t have
to
3. Quick pivots
4. Experience/Knowledge/Wisdom
Internally you need to be processing other frameworks for Hacker
Stories to work
25. Threat Modeling 201 Hacker Stories Takeaways
1. Extremely customizable and meets the intent of threat modeling
2. Threat Modeling doesn’t have to be exhaustive
a. Don’t start with the “Doomsday” conversation
3. Add significant value with low overhead
a. You business may appreciate your efforts
“Absorb what is useful, discard what is useless and add what is specifically
your own” - Bruce Lee
26. Continuing Education
● http://safecode.org
○ A non-profit organization exclusively dedicated to increasing trust in information and communications technology
products and services through the advancement of effective software assurance methods.
● https://www.owasp.org
○ A worldwide not-for-profit charitable organization focused on improving the security of software.
● https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx
○ Microsoft has been a pioneer in the Secure SDL and Threat Modeling space.
“Absorb what is useful, discard what is useless and add what is specifically
your own” - Bruce Lee
28. Example Breakdown - What is the project/feature?
Set CONTEXT
1. Ask Simple Questions
a. Who
b. What
c. Where
d. When
e. Why
Security CONTEXT
1. What is at risk
a. Who
b. What
c. Where
d. When
e. Why
Let’s whiteboard together!
29. Contact Me
1. Twitter - @tysbano
2. Linkedin - https://www.linkedin.com/in/tysbano/
3. Articles - https://techbeacon.com/contributors/ty-sbano
4. Website - http://www.tysbano.com
1. Instagram - https://www.instagram.com/takoyakity/
a. Nothing to do with security, I just enjoy photography
Confidentiality - Is about if they are authorized, (Need to Know / Least Privilege) (e.g. Email being sent to you with no digital signature nor encrypted)
Availability - Is about who can access and how they can access (e.g. Email sent from me to you)
Integrity - is the data tamper resistant (e.g. Email forwarding a message, but modifying the body)
Reputation - Also known as the business risk
STRIDE - Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, Elevation of Privilege
DREAD - Damage Reproducibility Exploitability Affected Users, Discoverability
OCTAVE - Operationally Critical Threat, Asset, and Vulnerability Evaluation
PASTA - Process for Attack Simulation and Threat AnalysisVAST - Visual, Agile and Simple Threat Modeling
FMEA - Failure Mode Effective Anlaysis