Threat Modelling Web applications
Threat Modelling
Purpose
Identify threats and vulnerabilities Raise security awareness amongst developers Improve communication Identify areas of the architecture that require more research
What others can you think??
Threat Modelling
Brief overview
Identify relevant threats and vulnerabilities in your scenario to help shape your application's security design Input Use cases Data flow Data schemes Deployment Diagrams
Output Threats Vulnerabilities
Threat Modelling
Threat Modelling Steps
Step 1: Identify security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on subsequent steps. Step 2: Create an application overview. Itemizing your application's important characteristics to helps you identify relevant threats during step 4. Step 3: Decompose your application. A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant and more detailed threats.
Threat Modelling
Threat Modelling Steps (Cont.)
Step 4: Identify threats. Use details from steps 2 and 3 to identify threats relevant to your application scenario and context.
Step 5: Identify vulnerabilities. Review the layers of your application to identify weaknesses related to your threats. Use vulnerability categories to help you to focus on those areas where mistakes are most often made.
Threat Modelling
Step 1: Identify security objectives
Input Business requirements Corporate security policies Compliance requirements (SDP) Output Key security objectives Confidentiality Integrity Availability
Threat Modelling
Step 2: Create an application overview
Input Deployment diagrams Use cases for user types Functional Specifications Output Scenarios Roles (administration, anonymous browsing) Technologies Security mechanisms
Threat Modelling
Step 3: Decompose your application
Input Deployment diagrams Use cases Functional specifications Data flow diagrams Output • Trust boundaries • Entry points • Exit points • Data flows
Threat Modelling
Step 4: Identify threats
Input
Common threats
Output
• Threat list (the threats that apply to your situation)
Threat Modelling
Step 5: Identify vulnerabilities
Input
Common vulnerabilities
Output
• Vulnerability list relevant to your situation
Threat Modelling
Tips on how to use threat this model
To not get blocked: Continue to ask questions and if you get blocked then move on to step 4. Use scenarios: Identify your scope, be realistic. Use existing design documentation: Use cases, data flow diagrams, architecture diagrams and other documentation.
Use a whiteboard: I remember and learn things better when I can see them graphically
Host and network details: Use your network people to get information regarding this stuff, you will save time.
Threat Modelling
Threat model example Step 1
Application name and description Authors, owners Revision history Security objectives
Confidentiality of customer data Accessibility, up time of 99.99% Integrity: prevent unauthorised modification
Threat Modelling
Threat model example – Application overview Step 2
The application is an Internet-facing Web application with a SQL Server back end. The Web server is located in a perimeter network. Business and data access logic reside on the Web server itself. The application enables Internet users to browse and purchase products from the company's product catalog.
Threat Modelling
Threat model example – Whiteboard Step 2
Threat Modelling
Threat model example – Application roles Step 2
which role can a user have when using the application?
Internet user Catalog administrator
Threat Modelling
Threat model example – Possible scenarios Step 2
Anonymous user browse the catalog to view product details Anonymous user search to find specific products Anonymous user add an item to their shopping basket Anonymous user authenticates prior to placing an order Anonymous user creates an account prior to placing an order Authenticated user places an order
Threat Modelling
Threat model example – Technologies Step 2 Web server: IIS 6.0 Server side logic: ASP.NET (C#) Data access: ADO, TSQL, Stored Procedures Database server: MS SQL Server 2000
Threat Modelling
Threat model example – Security Mechanisms Step 2 Form based authentication DB authentication is trusted connection, not mixed No remote administration is permitted, the administrator must be logged onto the console
Threat Modelling
Threat model example – Trust boundries Step 3 CheckPoint FW The data access components trust the business components to pass fully validated data
Threat Modelling
Threat model example – Data flow Step 3 An anonymous user browses the product catalog. The catalog page calls the catalog business component, which calls the catalog data access component to request a catalog listing. The first page of product details are retrieved from the database and returned to the catalog business component. The data is bound to a data grid control and displayed on the catalog page.
Threat Modelling
Threat model example – Data flow Step 3 An anonymous user submits a search string. The home page accepts the search string and validates it by using a regular expression. The search string must be less than 50 characters in length and may include any combination of letters or numbers. The search string is passed to the data access component. The data access component calls a stored procedure and passes the search string as a single parameter.
Threat Modelling
Threat model example – Data flow Step 3 The user logs on. The user submits a name and password through the logon form. The user name and password are handled by the logon page and passed to the membership business logic component. This component passes the data to the data access component, which verifies the credentials with the database to determine their validity.
Threat Modelling
Threat model example – Data flow Step 3 A catalog administrator logs on and accesses the restricted catalog administration page. The catalog administration component checks the user role at the business layer. If the user is authorized, the business component interacts with the catalog data access component to view and amend product details.
Threat Modelling
Threat model example – Entry points Step 3 TCP:80 Permit TCP:443 Permit TCP & UDP:1-65536 Deny (except for above) Logon page Public browse pages
Threat Modelling
Threat model example – Exit points Step 3 Search results page, the users search string is written out Catalog page where product details are displayed
Threat Modelling
Threat model example – Threats Step 4 Brute force against form login Network sniffing XSS Injection flaws Cookie replaying attacks Error handling DB server Insecure storage Poor server management, static files
Threat Modelling
Threat model example – Vulnerabilities Step 5 User password storage. Lack of password complexity enforcement. Lack of password retry logic. Missing or weak input validation at the server.
Threat Modelling
Threat model example – Vulnerabilities Step 5 (cont.) Failure to validate cookie input. Failure to sanitize data read from a shared database. Failure to encode output leading to potential crosssite scripting issues. Exposing an administration function through the customer-facing Web application. Exposing exception details to the client.
?