Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Threat Modeling Gameplay with EoP

You're reading from   Threat Modeling Gameplay with EoP A reference manual for spotting threats in software architecture

Arrow left icon
Product type Paperback
Published in Aug 2024
Publisher Packt
ISBN-13 9781804618974
Length 256 pages
Edition 1st Edition
Arrow right icon
Author (1):
Arrow left icon
Brett Crawley Brett Crawley
Author Profile Icon Brett Crawley
Brett Crawley
Arrow right icon
View More author details
Toc

Table of Contents (18) Chapters Close

Preface 1. Chapter 1: Game Play 2. Chapter 2: Spoofing FREE CHAPTER 3. Chapter 3: Tampering 4. Chapter 4: Repudiation 5. Chapter 5: Information Disclosure 6. Chapter 6: Denial of Service 7. Chapter 7: Elevation of Privilege 8. Chapter 8: Privacy 9. Chapter 9: Transfer 10. Chapter 10: Retention/Removal 11. Chapter 11: Inference 12. Chapter 12: Minimization 13. Glossary
14. Further Reading 15. Licenses for third party content 16. Index 17. Other Books You May Enjoy

Who should participate?

Preferably, you want between four and six players, covering different roles in the project and not necessarily technical roles. For example, you should include the software architect, a frontend/UI engineer if there is a UI component to the system, a backend engineer, a quality engineer, someone from the product team, and perhaps someone from compliance with knowledge of your privacy policies. The reason you want people from these different roles is to have a broader context. The product team is usually customer facing and so will be able to add context from that side of things; compliance will know what customers have signed up for, and what regulations and certifications the company needs to maintain, which will give additional context. People in different roles usually think differently because there is a certain amount of neurodiversity, so something one person misses others might spot.

You might find that people from product and compliance don’t believe they will be useful because they may not feel they have the technical background. An analogy I like to use to make them more comfortable and feel more at ease is that you don’t have to be a locksmith to know that if your key breaks in your front door lock, there is nobody home, and you’ve not got a key for another door, then you have a problem.

Now that we have our resources and we’ve invited the team members, we need to play the game. Let’s see how the game is played.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime