[Hungary] I play Jack of Information Disclosure
•Download as PPTX, PDF•
0 likes•510 views
I play Jack of Information Disclosure. Mark Vinkovits.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to [Hungary] I play Jack of Information Disclosure
Similar to [Hungary] I play Jack of Information Disclosure (20)
More from OWASP EEE
More from OWASP EEE (20)
Recently uploaded
Recently uploaded (20)
[Hungary] I play Jack of Information Disclosure
- 1. I play Jack of Information Disclosure HOW TO DO THREAT MODELING VIA PLAYING CARDS MARK VINKOVITS@HACKTIVITY 2015
- 2. 2
- 3. 3 Speaker Introduction Mark Vinkovits Security Engineer @ LogMeIn
- 4. Disclaimer
- 5. I. I’m a prophet! But you decide what fits you best
- 6. II. The world will not end!
- 9. Threat Modeling But Wait! What is a threat?
- 10. 10Images from http://intelmsl.com/ yandy.com Threat modeling
- 11. ENISA definition Threat: Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
- 12. Threat: Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
- 13. Threat: Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
- 14. Threat: Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
- 15. Threat: Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
- 16. Threat: Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
- 17. Threat Modeling
- 18. Modeling Guidelines By Norman Daoust “The most important advice I can give is to always keep in mind the following three aspects of your modeling situation: • Target Audience • Purpose • Scope“
- 19. Target Audience
- 21. Developer: Ken Skills: • Web applications: JavaScript, JSP, HTML • JavaEE bean development • Web architectures Hobbies: • Wearing He-Man wigs
- 22. Modeling Guidelines By Norman Daoust “The most important advice I can give is to always keep in mind the following three aspects of your modeling situation: • Target Audience • Purpose • Scope“
- 23. Threat Modeling VIA AN EXAMPLE
- 24. Steps of Threat Modeling 1.Identify Security Objectives 2.Survey the Application 3.Decompose it 4.Identify Threats 5.Document the Threats 6.Rate the Threats
- 26. 1. Identify Security Objectives • Infrastructure • Customer data • Employee accounts • Reputation
- 27. Configuration Backend Website Mail server Database 2. Survey the Application 3. Decompose it
- 28. 4. Identify Threats 5. Document Threats 6. Rate Threats
- 29. 4. Identify Threats 5. Document Threats 6. Rate Threats CLASSICAL APPROACH
- 30. “Methodology” ”bring members of the development and test teams together to conduct an informed brainstorming session in front of a whiteboard.” ”You get a set of experienced experts in a room, give them a way to take notes and let them go. The quality of the brainstorm is bounded by the experience of the brainstormers and the amount of time spent.” ”the thought process that you are going to go through is: what are all the different types of attacks that could make sense for the threat agent to get to the assets.” ”Most security professionals can just think and know what bad outcomes there are.” Common Weakness Enumeration: 1-1002 Image from screenrant.com informedbrainstorming infrontofawhiteboard experience timespent let them go all
- 31. 5. Document Threats 6. Rate Threats
- 33. 4. Identify Threats 5. Document Threats 6. Rate Threats GAMIFIED APPROACH
- 35. Suite Rank Threat References: - Secure Coding Practices - Application Security Verification Standard - AppSensor project - Common Attack Pattern Enumeration and Classification - Software Assurance Forum for Excellence in Code
- 36. Play the game!
- 47. What have we learned? Image from https://goodybagsblog.files.wordpress.com
- 48. Thank you.
Editor's Notes
- This is my picture in big– or today called a selfie for those who sit in the back and cannot see Or who just came in after lunch without knowing what this is
- It is true If you google prophet you will find my picture I will tell the truth in its raw beauty But as with every good prophet: If it does not work for you, do not blame me It worked in my environment
- Have you known it was supposed to end? That at every conference you hear that security is broken for good? No hope I am here to say: there is hope And I will give you the solution to all your problems I will even make your marriage better Your kids more happy Your car consume less
- And no: it is not magic It is not even difficult If you have no scar on your forehead Or no wizard hat Or the force is not strong within you this talk is for you If you are a security Voldemort, always saying not possible Harry Potter will come and take you away
- Before we start playing cards Let us do a recap what threat modeling is Why do you do it? When do you do it? And why in pratice no one does it? It is like unit testing Iterative development Paying taxes
- This is where problems begin
- When you search for clarification on the internet You find this picture Easy, isn’t it? Hell no If a crocodile is a threat This is threat modeling
- A good definition is this one Any circumstance or event with the potential to adversely impact an asset through unauthorized access, destruction, disclosure, modification of data, and/or denial of service. The picture for this is not so nice, but let me try But let me describe it via a picture
- This picture shows what a threat is Let take it in piece by piece
- A threat comes from someone or something
- It impacts something: an asset
- Something important That has business value Stealing your company’s snacks at the booth is no threat
- Threat comes through an adverse effect Like: Unauthorized access Destruction Disclosure Tampering DoS
- Trying again: What is threat modeling? Instead of describing it, I will show you what it is
- When doing it, let’s do it correctly As Norman Daoust says: Keep in mind target audience, purpose, scope I will go from the back, it is easier: 1. Scope: easy – my software 2. Purpose: I want to make it secure Stop here: if your scope is something else You will be taken away by Harry Potter: No creating reports, paper towels, beer mat, paper planes, impressing your boss It is for making stuff secure 3. Target Audience
- Synonyms: Spam filter My mail is not working I have a new laptop If this is where your threat model goes to Do not do it More importantly: go stand in the corner, and think what you have done It is your fault! You started an epic battle
- The battle between developers and security engineers No, please don’t laugh, this is no joke, this is serious There is a battle I am allowed to say this, I have been on both sides And obviously the mortal kombat side is much cooler With threat modeling, security engineers are always unhappy Documentation is not good, design is unclear, I have stomach ache, they make it wrong Developers are unhappy: It is long, it is irrelevant, we changed it since, I do not understand it Look at that guy! He must have been forced. This must be the sign: please help, I have 2 days left to live Yesterday I was still dressed as he-man
- Probably no one understood his cry for help Let us remember him by using him as an example Think of your target audience: Skilled developer Knows the system Understands plain and technical English Wants to fix things: yes, most developers are proud of their craftsmanship They want to deliver good software if possible
- Now we now what we are modeling for
- Let’s do the example
- Steps are: Identify Security Objectives Survey the Application Decompose it Identify Threats Document the Threats Rate the Threats
- This is the example: Simple webshop as you would imagine it There is a website Server Products E-mail newsletter If there is anything else to a webshop: Imagine it is there
- Identify Security Objectives Easy: We have infrastructure Customer data Employee accounts Company reputation Remember our target audience: Will Ken understand this? Yes Great, 2. step
- Survey the application and decompose it Important part, because your developers never did this before Literally, I had senior developers saying: Poo, this is how this works? Yes, I said poo We usually create a data flow diagram After you have an overview, look at the datastreams What data travels where, where is the trust boundary, Where do you accept or send out data Here rely on the developers They know the system More importantly, you too learn about the system
- Identify threats There are a number of approaches here I will call them classical and gamified
- Open the stage for: The Classical approach Here I must say, it is disappointing When I first had to do threat modeling, I did a lot of research How do you do it? What is the best method? How do you find threats? This is what I found
- ”bring members of the development and test teams together to conduct an informed brainstorming session in front of a whiteboard.” I don’t know what an informed brainstorm is. And how does a whiteboard help in methodically finding threats? ”You get a set of experienced experts in a room, give them a way to take notes and let them go. The quality of the brainstorm is bounded by the experience of the brainstormers and the amount of time spent.” Quality is bound by experience and time? Ok, but how much? No clue – well, there is Something strange about the sentence: you have to let them go Security engineers like this make me sad ”the thought process that you are going to go through is: what are all the different types of attacks that could make sense for the threat agent to get to the assets.” Think of all attacks. Really: all? I don’t know whether you are familiar with the common weakness enumeration It contains 1000 attacks; 1000 for each asset and threat agent combination – and that as a thought process ”Most security professionals can just think and know what bad outcomes there are.” Next one says security engineers can simply do this. Just think – and you know. So next time this guy comes along, hire him as a security engineer – because he is the only one who can do everything by thinking. Well, this is what you can find on methodology. No wonder that we have problems with making it right.
- Document and rate threats Classical approach does this together In a report (this is taken from a voting system threat model) Nice, right? – Let’s just look at it Seriously, who thought this can work? This is what you give your developer? He will kill you. No really, he will cause you intolerable pain and death He will use those two fingers and cause agony Look at this sentence: Voter ballot selections are accessed off election information systems by individuals with authorized access to these machines, resulting in loss of voter privacy. WHAT? If this were a threat model for buildings: this is what you get
- An attacker may get unauthorized access to a car An attacker causes larger weight on overhead cable, causing a larger force on post Best western guest might be insulted by the word straight If this was how you did threat modeling Forget it No one reads it, everyone hates security engineering The world will end
- How does the gamified approach look like?
- There are two card games available: OWASP cornucopia, Microsoft Elevation of privilege Rules are almost identical Cornucopia is currently more focused on web applications Explain rules
- Explain card: Suite: authentication, data validation, session mgmt., cryptography, all the rest Rank Threat Cross references: Secure coding practices Application Security Verification Standard Common attack pattern enumeration
- Explain how we play here
- 5. Document the threats I usually have a developer document Mainly because I do not know the name of the developers You write down which card Who said it What the exact description is Here you will have actionable items Where developer know which functionality and how affected For Ken it is clear what is happening here
- 6. Rate the threats Add them to your ticketing system Because you can, they are immediate stories Organize a meeting with developers There you discuss what the vulnerability was You can ask them about its functionality Provide an estimation of the risk
- The talk presented you the difference between Classical and gamified threat modeling
- Let me recap what we learned today
- Making pictures of a women in a crocodile dress is not threat modeling
- Classical security engineers have no real methodology for threat modeling No time limit, no guarantees regarding quality Your best chances to get results is by hiring X-men
- Classically security engineers are weirdos, who are constantly fighting with development They come up with irrelevant world problems, therefore are little effective in improving security
- If your threat models only describe what not to do, they are as effective as a hammer You can use it for everything, but eventually you are going to make more damage until get a screw in
- Gamified threat modeling brings us together Includes all stakeholders Raises awareness for both developers and security engineers And will make a stormtrooper strip by the end
- Gamified approaches make security actionable Provides clear items obvious for developers to work on
- With cards items might remain hidden Developers might dive in too deep