Threat Modeling. A workshop on how to create threat models by creating a hands-on example

Transcription

1 Threat Modeling A workshop on how to create threat models by creating a hands-on example

2 Introduction 2

3 Introduction 3

4 Part 1: Application- Layer Attacks A brief primer on some web application attacks

5 Authentication How can you break authentication? Brute-force Dictionary Birthday paradox Forgotten passwords (Paris Hilton attack) More advanced forms: Timing-based attacks Cryptanalysis Token replay attacks 5

6 Session Management Lots of potential attacks: Guess Session ID Modification attacks Content-caching Replay attacks / Session-hijacking Cookie attack DNS cache poisoning XSS (Input/Output validation) 6

7 Parameter Manipulation Free TVs for everyone! 7

8 SQL Injection DB can t differentiate between user-supplied values and computer generated values Classic 1 = 1 attack of course can get very severe xp_cmdshell 8

9 Part 2: Threat Model Case Study Intro to the case study for this class

10 Case Study Introduction You are consultants for Security Compass You have been contracted to perform a source code review and threat model on the False Secure Order web services site You will have 1 week to cover 7,500 out of over 145,000 lines of code You, as a group, have just over 2 hours to perform the threat model Prioritize which areas to cover in the threat model and identify which components are most critical You will review the architecture, interview the architect, determine data flows, determine and prioritize risk, and provide a list of countermeasures against high risk threats to look for in the review 10

11 Regular Users Read ACR Values Calls Caller Client Bro wser Apache Web Server My App Server Affected Roles Net Data Effect Threats and Risk Ratings Action Request data Send MQ Message Retrieve data from DB Regular, Administrative Users Read Mailing Options/ Mailing Options History Steps of Threat Modeling Gather Information Decompose App Brokerage Users Diagram User Type Regular User Admin User DFDs Identify Risk Use Cases Attack Trees 11

12 Gather Information Architect will walk you through the architecture of the application Please review the architecture documents provided Questions to ask Architect: Describe the application Who uses it? What is it used for? How often is it used? What kinds of data does it hold? Determine regulatory / legislative applicability Does it store/handle Personal data? Financial-reporting data? Cardholder data? Any others? What systems does it connect with? What are the entry points? Major app-sec domains: How does it handle access control, session management, logging, and input validation? Note that the architect is at too a high level to discuss issues such as error handling Remember the 5 Ws to determine business risk Who? What? When? Where? Why? How comes afterwards 12

13 Regular Users Read ACR Values Calls Caller Client Bro wser Apache Web Server My App Server Affected Roles Net Data Effect Threats and Risk Ratings Action Request data Send MQ Message Retrieve data from DB Regular, Administrative Users Read Mailing Options/ Mailing Options History Steps of Threat Modeling Gather Information Decompose App Brokerage Users Diagram User Type Regular User Admin User DFDs Identify Risk Use Cases Attack Trees 13

14 Decompose App Using the worksheets and stickers provided, break down: System Components Users Data Types Use Cases (don t do this now - complete this after the DFD) 14

15 Regular Users Read ACR Values Calls Caller Client Bro wser Apache Web Server My App Server Affected Roles Net Data Effect Threats and Risk Ratings Action Request data Send MQ Message Retrieve data from DB Regular, Administrative Users Read Mailing Options/ Mailing Options History Steps of Threat Modeling Gather Information Decompose App Brokerage Users Diagram User Type Regular User Admin User DFDs Identify Risk Use Cases Attack Trees 15

16 Data Flow Diagrams As a group, we re going to create a Level 1 DFD for a typical transaction flow based on the data we ve been given Identify components, data stores, and flow of data 5. Message returned to client Client Browser End User 1. Client sends request over web Determine trust boundaries are those trust boundaries legitimate? Web Server A Level 2 DFD would use the layers described in the presentation and middle tier design documents 4. Application server returns message to web server App Server 2. Web server forwards request to app server Allows us to drill in on those components we need to look at most 3. App server processes logic and updates DB Database 16

17 Interactive Time Our next steps will involve examining use cases and determining risk levels So what are the most pertinent use cases for this application? 17

18 Regular Users Read ACR Values Calls Caller Client Bro wser Apache Web Server My App Server Affected Roles Net Data Effect Threats and Risk Ratings Action Request data Send MQ Message Retrieve data from DB Regular, Administrative Users Read Mailing Options/ Mailing Options History Steps of Threat Modeling Gather Information Decompose App Brokerage Users Diagram User Type Regular User Admin User DFDs Identify Risk Use Cases Attack Trees 18

19 Create Use Case Using the worksheets and stickers provided to fill out use cases based on a single transaction flow from the DTD Example: User Updates Inventory in I-Tracker Client Browser 1. Sends inventory update HTTP form 2. Forwards HTTP Request 3. Update DB I-Tracker DB I-Tracker Web I-Tracker App 4. Notifies shipping team Notifications Description of Call Flow Call # Sender Receiver Description 1 Client I-Tracker Web Client sends an inventory request form submitted via the app along with JSESSION ID cookie 2 I-Tracker Web I-Tracker App Web server forwards request to app server 3 I-Tracker App I-Tracker DB App Server updates DB with new value for inventory 4 I-Tracker App Notifications Notification is sent to shipping if necessary 19

20 Find Risk for Threats This is the most difficult part of the threat model Starts with a solid base of knowledge of application security attacks (learned through your last class) What are the attack types? Do they affect C,I, or A? How likely are they? Enhanced by keeping up-to-date with other attacks. Reading the OWASP attacks section is a great resource: 20

21 Find Risk for Threats Common Weaknesses Enumeration is another great resource: May be too big to read all, but can do meaningful keyword searching (e.g. look for XML) 21

22 Find Risk for Threats For the purposes of this class we ll rely on the knowledge of the students Please use blank template provided Ignore Threat # for now Threats and Risk Ratings Attack Vector Data Types CIA Risk Threat # At client Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs From client to web server Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs From client to web server Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs From client to web server Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs 22

23 Use Cases Determining Risk We take the highest value from the data-types for each threat, and use that as our impact rating Threats and Risk Ratings Attack Vector At client At client At client Data Types Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs CIA Data Risk Data Type Description Inventory Levels L H M Amount of inventory for each product Customer IDs L H M Unique ID for each end customer Sales Order Numbers L H M Unique order # for each sales order Description of Orders L L L Description of sales order Product IDs L H M User is authenticated, User is authorized to perform functions Password H M M Password of system user User ID M M M ID of system user Session ID H M M Session ID value for user (JSession from Tomcat) 23

24 Find Risk for Threats Likliehood was determined from our knowledge of threats and by external resources. We assign a value of 1 for low, 2 for medium, and 3 for high for both likelihood and impact Risk = Likelihood X Impact Use the following chart from the resulting product to determine the risk level Likelihood X Impact = Risk Score Low Medium High 24

25 Fill in the Risk! Threats and Risk Ratings Attack Vector Data Types CIA Risk Threat # At client Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs H 1 At client Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs H 2 At client Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs N/A 3 From client to web server Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs H 4 From client to web server Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs H 5 From client to web server Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs N/A 6 25

26 Regular Users Read ACR Values Calls Caller Client Bro wser Apache Web Server My App Server Affected Roles Net Data Effect Threats and Risk Ratings Action Request data Send MQ Message Retrieve data from DB Regular, Administrative Users Read Mailing Options/ Mailing Options History Steps of Threat Modeling Gather Information Decompose App Brokerage Users Diagram User Type Regular User Admin User DFDs Identify Risk Use Cases Attack Trees 26

27 Attack Trees Determine how a threat may be exploited Confidentiality at client Plaintext data read during transmission Cross-site scripting in app Properly configured SSL Strong input validation 27

28 Attack Trees Can be very cumbersome and time-consuming Alternative notation is easier: Threat #1: Confidentiality at client Attack: Malware steals data Countermeasure: Set cache-control to no-cache for sensitive pages Attack: Sensitive data stored on client machine Countermeasure: Set cache-control to no-cache for sensitive pages Countermeasure: Prevent sensitive data from reaching client in error messages by providing a default, generic error page defined in Struts web.xml. Ensure all runtime and checked exceptions are caught and handled before reaching any JSP or Servlet. Attack: Session compromised Countermeasure: Use strong session identifiers use existing functionality to do this (e.g. JSESSION ID) Countermeasure: Expire sessions after 15 minutes of inactivity Countermeasure: Enforce hard time out after 8 hours regardless of amount of activity Countermeasure: Expire cookie at end of browsing session Countermeasure: Validate all user input using Apache Struts validators to prevent XSS Countermeasure: HTML encode all output using URLEncoder to prevent XSS Countermeasure: Use HTTP-Only tag to mitigate risk of XSS-stolen cookies 28

29 Determine Attacks For the three highest risk threats in your use case: Determine attacks Determine possible countermeasures (from your own knowledge, web resources, or by asking experts) Please fill out the attack tree sheets provided 29

30 Share Findings Which areas of code are most pertinent to review given our limited timelines? What suggestions would we make to the architect/management to improve the application s security in the next release? 30

31 Tools Unfortunately, not many tools out there Microsoft Threat Analysis & Modeling free tool is best bet Search for this at msdn.microsoft.com 31

32 Questions / Profile Our consultants have serviced large (Fortune 500) and medium sized companies across most major industries We have worked for major security players, including Foundstone and Deloitte We have co-authored or contributed to several security books, including: Hacking Exposed: Web Applications, 2nd Edition HackNotes: Network Security Buffer Overflow Attacks: Detect, Exploit & Prevent Windows XP Professional Security Writing Security Tools and Exploits We have presented at and continue to present at security conferences, including: Blackhat Amsterdam; Reverse Engineering Conference 2005 in Montreal; HackInTheBox 2005 in Malaysia; ISC2's Infosec Conferences in Las Vegas, NYC, Toronto & DC; CSI NetSec; DallasCon; ToorCon; and Freenix. We present and contribute to open source projects: Chair at OWASP Toronto, Presented at OWASP Toronto, Contributed to YASSP Project (Lead by SANS and Xerox). 32