|
|
| (104 intermediate revisions by 15 users not shown) |
| Line 1: |
Line 1: |
| − | ''[[OWASP Code Review Guide Table of Contents]]__TOC__
| + | __TOC__ |
| | | | |
| | + | Threat modelling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value. |
| | | | |
| − | <br>
| + | Threat modelling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the internet of things, business processes, etc. There are very few technical products which cannot be threat modelled; more or less rewarding, depending on how much it communicates, or interacts, with the world. Threat modelling can be done at any stage of development, preferably early - so that the findings can inform the design. |
| | | | |
| − | ----
| + | == What == |
| | + | Most of the time, a threat model includes: |
| | + | * A description / design / model of what you’re worried about |
| | + | * A list of assumptions that can be checked or challenged in the future as the threat landscape changes |
| | + | * A list of potential threats to the system |
| | + | * A list of actions to be taken for each threat |
| | + | * A way of validating the model and threats, and verification of success of actions taken |
| | + | Our motto is: Threat modelling: the sooner the better, but never too late. |
| | | | |
| − | ===Introduction=== | + | == Why == |
| − | Threat modeling is an approach for analysing the security of an application. It is a structured approach that enables you to identify, quantify and address the security risks associated with an application. Threat modeling is not an approach to reviewing code but it does compliment the secure code review process. The inclusion of threat modeling in the SDL can help to ensure that applications are being developed with security built in from the very beginning. This combined with the documentation produced as part of the threat modeling process can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point. The concept of threat modeling is not new but there has been a clear mindset change in recent years. Modern threat modeling looks at a system from a potential attackers perspective as opposed to a defenders view point. Microsoft have been strong advocates of the process over the past number of years. Microsoft have made threat modeling a core component of their SDL which they claim to be one of the reasons for the increased security of their products in recent years. The threat modeling process can be decomposed into 3 high level steps:
| + | [[Category:FIXME|the list above includes an Application name, but the example does not have one]] |
| | | | |
| − | '''Decompose the Application.'''
| + | The inclusion of threat modelling in the SDLC can help |
| | + | * Build a secure design |
| | + | * Efficient investment of resources; appropriately prioritize security, development, and other tasks |
| | + | * Bring Security and Development together to collaborate on a shared understanding, informing development of the system |
| | + | * Identify threats and compliance requirements, and evaluate their risk |
| | + | * Define and build required controls. |
| | + | * Balance risks, controls, and usability |
| | + | * Identify where building a control is unnecessary, based on acceptable risk |
| | + | * Document threats and mitigation |
| | + | * Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact |
| | + | * Identification of security test cases / security test scenarios to test the security requirements |
| | | | |
| − | The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves creating use cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets i.e. items/areas that the attacker would be interested in and trust levels which represent the access rights that the application will grant to external entities. This information is documented in the Threat Model document and it is also used to produce data flow diagrams (DFD) for the application. The DFDs show the different paths through the system highlighting the privilege boundaries.
| + | == 4 Questions == |
| | + | Most threat model methodologies answer one or more of the following questions in the technical steps which they follow: |
| | | | |
| − | '''Determine and rank threats.'''
| + | === 1. What are we building? === |
| | + | As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are: |
| | + | * Architecture diagrams |
| | + | * Dataflow transitions |
| | + | * Data classifications |
| | + | * You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat Modelling exercise. |
| | | | |
| | + | === 2. What can go wrong? === |
| | + | This is a "research" activity in which you want to find the main threats that apply to your application. There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others. |
| | | | |
| | + | === 3. What are we going to do about that? === |
| | + | In this phase you turn your findings into specific actions. See [[Threat_Modeling_Outputs]] |
| | | | |
| | + | === 4. Did we do a good enough job? === |
| | + | Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning. |
| | | | |
| − | '''Determine vulnerabilities and mitigation.'''
| + | == Process == |
| | + | The technical steps in threat modelling involve answering questions: - What are we working on - What can go wrong - What will we do with the findings - Did we do a good job? The work to answer these questions is embedded in some sort of process, ranging from incredibly informal Kanban with Post-its on the wall to strictly structured waterfalls. |
| | | | |
| | + | The effort, work, and timeframes spent on threat modelling relate to the process in which engineering is happening and products/services are delivered. The idea that threat modelling is waterfall or ‘heavyweight’ is based on threat modelling approaches from the early 2000s. Modern threat modelling building blocks fit well into agile and are in wide use. |
| | | | |
| | + | ==== When to threat model ==== |
| | + | When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious. |
| | | | |
| | + | Threat modelling integrates into Agile by asking “what are we working on, now, in this sprint/spike/feature?”; trying to answer this can be an important aspect of managing security debt, but trying to address it per-sprint is overwhelming. When the answer is that the system’s architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being transmitted, then it is unlikely that the answers to ‘what can go wrong’ will change. When one or more of those changes, then it’s useful to examine what can go wrong as part of the current work package, and to understand designs trade-offs you can make, and to understand what you’re going to address in this sprint and in the next one. The question of did we do a good job is split: the “did we address these threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task. |
| | | | |
| | + | After a security incident, going back and checking the threat models can be an important process. |
| | | | |
| − | Each of the above steps are documented as they are carried out. The resulting document is the threat model for the application. This guide will use an example to help explain the concepts behind threat modeling. The same example will be used throughout each of the 3 steps as a learning aid. The example that will be used is a college library website. At the end of the guide we will have produced the threat model for the college library website. Each of the steps in the threat modeling process are described in detail below.
| + | ==== Threat modelling: engagement versus review ==== |
| | + | Threat modelling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modelling, yet quite different. |
| | | | |
| | + | ==== Validating assumptions ==== |
| | | | |
| − | == Decompose the Application == | + | == Learning More == |
| − | The goal of this step is to gain an understanding of the application and how it interacts with external entities. This goal is achieved by information gathering and documentation. The information gathering process is carried out using a clearly defined structure, this ensures the correct information is collected. This structure also defines how the information should be documented to produce the Threat Model.
| |
| | | | |
| − | ===Threat Model Information=== | + | ==== Agile approaches ==== |
| − | The first item in the threat model is the information relating to the threat model.
| + | * Main agile threat modelling page |
| − | This must include the the following:
| + | * Specific agile approach1 TM page |
| | + | * Specific agile approach2 TM page |
| | | | |
| − | # '''Application Name''' - The name of the application.
| + | ==== Waterfall approaches ==== |
| − | # '''Application Version''' - The version of the application.
| + | * Main waterfall TM page |
| − | # '''Description''' - A high level description of the application.
| |
| − | # '''Document Owner''' - The owner of the threat modeling document.
| |
| − | # '''Participants''' - The participants involved in the threat modeling process for this application.
| |
| − | # '''Reviewer''' - The reviewer(s) of the threat model.<br/>
| |
| − | Example:<br/>
| |
| | | | |
| − | | + | == Additional/External references == |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="2" align="center">Threat Model Information</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th align="left">Application Version:</th>
| |
| − | <td>1.0</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <th align="left"> Description:</th>
| |
| − | <td>The college library website is the first implementation of a website to provide librarians and library patrons (students and college staff) with online services.
| |
| − | As this is the first implementation of the website the functionality will be limited. There will be three users of the application: <br/>
| |
| − | 1. Students<br/>
| |
| − | 2. Staff<br/>
| |
| − | 3. Librarians<br/>
| |
| − | Staff and students will be able to login and search for books. Librarians will be able to login, add books, add users and search for books.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th align="left">Document Owner:</th>
| |
| − | <td>David Lowry</td>
| |
| − | </tr>
| |
| − | | |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <th align="left">Participants:</th>
| |
| − | <td>David Rook</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th align="left">Reviewer:</th>
| |
| − | <td>Eoin Keary</td>
| |
| − | </tr>
| |
| − | | |
| − | </table>
| |
| − | <br/>
| |
| − | | |
| − | ===Use Cases===
| |
| − | Use cases are an important step in gaining an understanding of the applications structure and its use. Use cases capture the functional requirements of an application. They describe the interaction between the actor, i.e. the user of the application and the application to achieve a specific goal. The user cases help define the scope for the threat model as they are essentially documenting the requirements of the application.
| |
| − | | |
| − | Example:<br/>
| |
| − | The use case below shows the student actor interacting with the application. A student can carry out two tasks with the application - login and search for books.<br/><br/>
| |
| − | [[Image:Student_use_case.gif]]
| |
| − | <br/><br/>
| |
| − | The use case below shows the college faculty actor interacting with the application. A faculty member can carry out three tasks with the application - login, request books and search for books.<br/><br/>
| |
| − | [[Image:Faculty_use_case.gif]]
| |
| − | <br/><br/>
| |
| − | The use case below shows the librarian actor interacting with the application. A librarian can carry out four tasks with the application - login, search for books, add a book and add a user.<br/><br/>
| |
| − | [[Image:Librarian_use_case.gif]]
| |
| − | | |
| − | | |
| − | ===External Dependencies===
| |
| − | External dependencies are items external to the code of the application that may pose a threat to the application. These items are typically still within the control of the organisation but possibly not within the control of the development team. The first area to look at when investigating external dependencies is how will the application be deployed in a production environment and what are the requirements surrounding this. This involves looking at how the application is or is not intended to be run. For example if the application is expected to be run on a server that has been hardened to the organisations hardening standard and it is expected to sit behind a firewall then this information should be documented in the external dependencies section. External dependencies should be documented as follows:<br/> | |
| − | | |
| − | # '''ID''' - A unique ID assigned to the external dependency.
| |
| − | # '''Description''' - A textual description of the external dependency.
| |
| − | <br/>
| |
| − | Example:
| |
| − | <br/>
| |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="2" align="center">External Dependencies</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th>ID</th>
| |
| − | <th>Description</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1</td>
| |
| − | <td>The college library website will run on a Linux server running apache. This server will be hardened as per the colleges server hardening standard. This includes the application of the latest operating system and application security patches.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>2</td>
| |
| − | <td>The database server will be mysql and it will run on a Linux server. This server will be hardened as per the colleges server hardening standard. This will include the application of the lastest operating system and application security patches.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>3</td>
| |
| − | <td>The connection between the Web Server and the database server will be over a private network.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>4</td>
| |
| − | <td>The Web Server is behind a firewall and the only communication available is TLS.</td>
| |
| − | </tr>
| |
| − | | |
| − | | |
| − | </table>
| |
| − | <br/>
| |
| − | | |
| − | ===Entry Points===
| |
| − | Entry points define the interfaces through which potential attackers can interact with the application or supply it with data. In order for potential attacker to attack an application entry points must exist. Entry points in an application can be layered, for example each web page in a web application may contain multiple entry points. Entry points should be documented as follows:
| |
| − | | |
| − | # '''ID''' - A unique ID assigned to the entry point. This will be used to cross reference the entry point with any threats or vulnerabilities that are identified. In the case of layer entry points a major.minor notation should be used.
| |
| − | # '''Name''' - A descriptive name identifying the entry point and its purpose.
| |
| − | # '''Description''' - A textual description detailing the interaction or processing that occurs at the entry point.
| |
| − | # '''Trust Levels''' - The level of access required at the entry point is documented here. These will be cross referenced with the trusts levels defined later in the document.
| |
| − | <br/>
| |
| − | Example:
| |
| − | <br/>
| |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="4" align="center">Entry Points</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th width="5%">ID</th>
| |
| − | <th width="15%">Name</th>
| |
| − | <th width="45%">Description</th>
| |
| − | <th width="25%">Trust Levels</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1</td>
| |
| − | <td>HTTPS Port</td>
| |
| − | <td>The college library website will be only be accessable via TLS. All pages within the college library website are layered on this entry point.</td>
| |
| − | <td>(1) Anonymous Web User<br/>
| |
| − | (2) User with Valid Login Credentials<br/>
| |
| − | (3) User with Invalid Login Credentials<br/>
| |
| − | (4) Librarian<br/>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>1.1</td>
| |
| − | <td>Library Main Page</td>
| |
| − | <td>The splash page for the college library website is the entry point for all users.</td>
| |
| − | <td>(1) Anonymous Web User<br/>
| |
| − | (2) User with Valid Login Credentials<br/>
| |
| − | (3) User with Invalid Login Credentials<br/>
| |
| − | (4) Librarian<br/>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1.2</td>
| |
| − | <td>Login Page</td>
| |
| − | <td>Students, faculty members and librarians must login to the college library website before they can carry out any of the use cases.</td>
| |
| − | <td>(1) Anonymous Web User<br/>
| |
| − | (2) User with Login Credentials<br/>
| |
| − | (3) User with Invalid Login Credentials<br/>
| |
| − | (4) Librarian<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>1.2.1</td>
| |
| − | <td>Login Function</td>
| |
| − | <td>The login function accepts user supplied credentials and compares them with those in the database.</td>
| |
| − | <td>
| |
| − | (2) User with Valid Login Credentials<br/>
| |
| − | (3) User with Invalid Login Credentials<br/>
| |
| − | (4) Librarian</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1.3</td>
| |
| − | <td>Search Entry Page</td>
| |
| − | <td>The page used to enter a search query.</td>
| |
| − | <td>
| |
| − | (2) User with Valid Login Credentials<br/>
| |
| − | (4) Librarian</td>
| |
| − | </tr>
| |
| − | | |
| − | </table>
| |
| − | <br/>
| |
| − | | |
| − | ===Assets===
| |
| − | The system must have something that the attacker is interested in, these items/areas of interest are defined as assets. Assets are essentially threat targets, i.e. they are the reason threats will exist. Assets can be both physical assets and abstract assets. For example an asset of an application might be a list of clients and their personal information, this is a physical asset. An abstract asset might be the reputation of an organsation. Assets are documented in the threat model as follows:
| |
| − | | |
| − | # '''ID''' - A unique ID is assigned to identify each asset. This will be used to cross reference the asset with any threats or vulnerabilities that are identified.
| |
| − | # '''Name''' - A descriptive name that clearly identifies the asset.
| |
| − | # '''Description''' - A textual description of what the asset is and why it needs to be protected.
| |
| − | # '''Trust Levels''' - The level of access required to access the entry point is documented here. These will be cross referenced with the trust levels defined in the next step.
| |
| − | <br/>
| |
| − | Example:
| |
| − | <br/>
| |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="4" align="center">Assets</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th width="5%">ID</th>
| |
| − | <th width="15%">Name</th>
| |
| − | <th width="55%">Description</th>
| |
| − | <th width="25%">Trust Levels</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>1</td>
| |
| − | <td>Library Users and Librarian</td>
| |
| − | <td>Assets relating to students, faculty members and librarians.</td>
| |
| − | <td></td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1.1</td>
| |
| − | <td>Users Login Details</td>
| |
| − | <td>The login credentials that a student or a faculty member will use to log into the College Library website.</td>
| |
| − | <td>
| |
| − | (2) User with Valid Login Credentials<br/>
| |
| − | (4) Librarian <br/>
| |
| − | (5) Database Server Administrator <br/>
| |
| − | (7) Web Server User Process<br/>
| |
| − | (8) Database Read User<br/>
| |
| − | (9) Database Read/Write User
| |
| − | </td></tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1.2</td>
| |
| − | <td>Librarian Login Details</td>
| |
| − | <td>The login credentials that a Librarian will use to log into the College Library website.</td>
| |
| − | <td>
| |
| − | (4) Librarian <br/>
| |
| − | (5) Database Server Administrator <br/>
| |
| − | (7) Web Server User Process<br/>
| |
| − | (8) Database Read User<br/>
| |
| − | (9) Database Read/Write User
| |
| − | </td></tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1.3</td>
| |
| − | <td>Personal Data</td>
| |
| − | <td>The College Library website will store personal information relating to the students, faculty members and librarians.</td>
| |
| − | <td>
| |
| − | (4) Librarian <br/>
| |
| − | (5) Database Server Administrator <br/>
| |
| − | (6) Website Administrator <br/>
| |
| − | (7) Web Server User Process<br/>
| |
| − | (8) Database Read User<br/>
| |
| − | (9) Database Read/Write User
| |
| − | | |
| − | </td></tr>
| |
| − | | |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>2</td>
| |
| − | <td>System</td>
| |
| − | <td>Assets relating to the underlying system.</td>
| |
| − | <td></td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>2.1</td>
| |
| − | <td>Availability of College Library Website</td>
| |
| − | <td>The College Library website should be available 24 hours a day and can be accessed by all students, college faculty members and librarians.</td>
| |
| − | <td>
| |
| − | (5) Database Server Administrator <br/>
| |
| − | (6) Website Administrator <br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>2.2</td>
| |
| − | <td>Ability to Execute Code as a Web Server User</td>
| |
| − | <td>This is the ability to execute source code on the web server as a web server user.</td>
| |
| − | <td>
| |
| − | (6) Website Administrator <br/>
| |
| − | (7) Web Server User Process <br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>2.3</td>
| |
| − | <td>Ability to Execute SQL as a Database Read User</td>
| |
| − | <td>This is the ability to execute SQL select queries on the database and thus retrieve any information stored within the College Library database.</td>
| |
| − | <td>
| |
| − | (5) Database Server Administrator<br/>
| |
| − | (8) Database Read User<br/>
| |
| − | (9) Database Read/Write User<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>2.4</td>
| |
| − | <td>Ability to Execute SQL as a Database Read/Write User</td>
| |
| − | <td>This is the ability to execute SQL select, insert and update queries on the database and thus have read and write access to any information stored within the College Library database.</td>
| |
| − | <td>
| |
| − | (5) Database Server Administrator<br/>
| |
| − | (9) Database Read/Write User<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>3</td>
| |
| − | <td>Website</td>
| |
| − | <td>Assets relating to the College Library website.</td>
| |
| − | <td></td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>3.1</td>
| |
| − | <td>Login Session</td>
| |
| − | <td>This is the login session of a user to the College Library website. This user could be a student, a member of the college faculty or a Librarian.</td>
| |
| − | <td>
| |
| − | (2) User with Valid Login Credentials<br/>
| |
| − | (4) Librarian<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>3.2</td>
| |
| − | <td>Access to the Database Server</td>
| |
| − | <td>Access to the database server allows you to administer the database giving you full access to the database users and all data contained within the database.</td>
| |
| − | <td>
| |
| − | (5) Database Server Administrator<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>3.3</td>
| |
| − | <td>Ability to Create Users.</td>
| |
| − | <td>The ability to create users would allow an individual to create new users on the system. These could be student users, faculty member users and librarian users.</td>
| |
| − | <td>
| |
| − | (4) Librarian<br/>
| |
| − | (6) Website Administrator<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>3.3</td>
| |
| − | <td>Access to Audit Data</td>
| |
| − | <td>The audit data shows all audit-able events that occurred within the College Library application by students, staff and librarians.</td>
| |
| − | <td>
| |
| − | (6) Website Administrator<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | </table>
| |
| − | | |
| − | <br/>
| |
| − | | |
| − | ===Trust Levels===
| |
| − | Trust levels represent the access rights that the application will grant to external entities. The trust levels are cross referenced with the entry points and assets. This allows us to defined the access rights or privileges required at each entry point and those required to interact with each asset. Trust levels are documented in the threat model as follows:
| |
| − | | |
| − | # '''ID''' - A unique number is assigned to each trust level. This is used to cross reference the trust level with the entry points and assets.
| |
| − | # '''Name''' - A descriptive name that allows you to identify the external entities that have been granted this trust level.
| |
| − | # '''Description''' - A textual description of the trust level detailing the external entity who has been granted the trust level.
| |
| − | <br/>
| |
| − | Example:
| |
| − | <br/>
| |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="4" align="center">Trust Levels</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th width="5%">ID</th>
| |
| − | <th width="25%">Name</th>
| |
| − | <th width="70%">Description</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>1</td>
| |
| − | <td>Anonymous Web User</td>
| |
| − | <td>A user who has connected to the college library website but has not provided valid credentials.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>2</td>
| |
| − | <td>User with Valid Login Credentials</td>
| |
| − | <td>A user who has connected to the college library website and has logged in using valid login credentials.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>3</td>
| |
| − | <td>User with Invalid Login Credentials</td>
| |
| − | <td>A user who has connected to the college library website and is attempting to login in using invalid login credentials.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>4</td>
| |
| − | <td>Librarian</td>
| |
| − | <td>The librarian can create users on the library website and view their personal information.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>5</td>
| |
| − | <td>Database Server Administrator</td>
| |
| − | <td>The database server administrator has read and write access to the database that is used by the college library website.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>6</td>
| |
| − | <td>Website Administrator</td>
| |
| − | <td>The Website administrator can configure the college library website.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>7</td>
| |
| − | <td>Web Server User Process</td>
| |
| − | <td>This is the process/user that the web server executes code as and authenticates itself against the database server as.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>8</td>
| |
| − | <td>Database Read User</td>
| |
| − | <td>The database user account used to access the database for read access.</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>9</td>
| |
| − | <td>Database Read/Write User</td>
| |
| − | <td>The database user account used to access the database for read and write access.</td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | <br/>
| |
| − | | |
| − | ===Data Flow Diagrams===
| |
| − | All of the information collected allows us to accurately model the application through the use of Data Flow Diagrams (DFDs). The DFDs will allow us to gain a better understanding of the application by providing a visual representation of how the application processes data. The focus of the DFDs is on how data moves through the application and what happens to the data as it moves. DFDs are hierarchical in structure so they can be used to decompose the application into subsystems and lower-level subsystems. The high level DFD will allow us to clarify the scope of the application being modeled. The lower level iterations will allow us to focus on the specific processes involved when processing specific data. There are a number of symbols that are used in DFDs for threat modeling. These are described below:
| |
| − | | |
| − | '''External Entity'''<br/>
| |
| − | The external entity shape is used to represent any entity outside the application that interacts with the application via an entry point.<br/><br/>
| |
| − | [[Image:DFD_external_entity.gif]]
| |
| − | <br/><br/>
| |
| − | | |
| − | '''Process'''<br/>
| |
| − | The process shape represents a task that handles data within the application. The task may process the data or perform an action based on the data.<br/><br/>
| |
| − | [[Image:DFD_process.gif]]
| |
| − | <br/><br/>
| |
| − | | |
| − | '''Multiple Process'''<br/>
| |
| − | The multiple process shape is used to present a collection of subprocesses. The multiple process can be broken down into its subprocesses in another DFD.<br/><br/>
| |
| − | [[Image:DFD_multiple_process.gif]]
| |
| − | <br/><br/>
| |
| − | | |
| − | '''Data Store'''<br/>
| |
| − | The data store shape is used to represent locations where data is stored. Data stores do not modify the data they only store data.<br/><br/>
| |
| − | [[Image:DFD_data_store.gif]]
| |
| − | <br/><br/>
| |
| − | | |
| − | | |
| − | '''Data Flow'''<br/>
| |
| − | The data flow shape represents data movement within the application. The direction of the data movement is represented by the arrow.<br/><br/>
| |
| − | [[Image:DFD_data_flow.gif]]
| |
| − | <br/><br/>
| |
| − | '''Privilege Boundary'''<br/>
| |
| − | The privilege boundary shape is used to represent the change of privilege levels as the data flows through the application.<br/><br/>
| |
| − | [[Image:DFD_privilge_boundary.gif]]
| |
| − | <br/><br/>
| |
| − | | |
| − | | |
| − | | |
| − | Example:
| |
| − | <br/> Data Flow Diagram for the College Library Website.
| |
| − | <br/><br/>
| |
| − | [[Image:Data flow1.jpg]]
| |
| − | <br/><br/>
| |
| − | User Login Data Flow Diagram for the College Library Website.
| |
| − | <br/><br/>
| |
| − | [[Image:Data flow2.jpg]]
| |
| − | <br/><br/>
| |
| − | | |
| − | == Determine and rank threats ==
| |
| − | ===Threat Categorization===
| |
| − | The first step in the determination of threats is adopting a threat categorization. A threat categorization provides a set of threat categories with corresponding examples so that threats can be systematically identified in the application in a structured and repeatable manner.
| |
| − | | |
| − | ====STRIDE====
| |
| − | A threat categorization such as STRIDE is useful in the identification of threats by classifying attacker goals such as:
| |
| − | *Spoofing
| |
| − | *Tampering
| |
| − | *Repudiation
| |
| − | *Information Disclosure
| |
| − | *Denial of Service
| |
| − | *Elevation of Privilege.
| |
| − | | |
| − | A threat list of generic threats organized in these categories with examples and the affected security controls is provided in the following table:
| |
| − | | |
| − | <br/>
| |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="4" align="center">STRIDE Threat List</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th>Type</th>
| |
| − | <th>Examples</th>
| |
| − | <th>Security Control</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Spoofing</td>
| |
| − | <td>Threat action aimed to illegally access and use another user's credentials, such as username and password</td>
| |
| − | <td>Authentication</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Tampering</td>
| |
| − | <td>Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet</td>
| |
| − | <td>Integrity</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>Repudiation</td>
| |
| − | <td>Threat action aimed to perform illegal operation in a system that lacks the ability to trace the prohibited operations.</td>
| |
| − | <td>Non-Repudiation</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Information disclosure.</td>
| |
| − | <td>Threat action to read a file that they were not granted access to, or to read data in transit. </td>
| |
| − | <td>Confidentiality</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>Denial of service.</td>
| |
| − | <td>Threat aimed to deny access to valid users such as by making a web server temporarily unavailable or unusable.
| |
| − | </td>
| |
| − | <td>Availability</td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Elevation of privilege.</td>
| |
| − | <td>Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system.</td>
| |
| − | <td>Authorization</td>
| |
| − | | |
| − | </table>
| |
| − | <br/>
| |
| − | | |
| − | ====ASF====
| |
| − | The Application Security Frame (ASF) defines threat categories in terms of defensive controls such as:
| |
| − | *Auditing & Logging
| |
| − | *Authentication
| |
| − | *Authorization
| |
| − | *Configuration Management
| |
| − | *Data Protection in Storage and Transit
| |
| − | *Data Validation
| |
| − | *Exception Management
| |
| − | *User and Session Management
| |
| − | | |
| − | Descriptions and examples of generic threats organized in these categories is provided in the following threat list:
| |
| − | | |
| − | <br/>
| |
| − | <table align="center" cellspacing="1" CELLPADDING="7">
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th colspan="3" align="center">ASF Threat List</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <th width="15%">Type</th>
| |
| − | <th width="60%">Description</th>
| |
| − | <th width="25%">Attack Examples</th>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>Auditing & Logging</td>
| |
| − | <td>Threats caused by failure to maintain detailed and accurate application logs that can allow for traceability and non-repudiation and provide enough information for administrators to identify security issues and for incident response specialists to trace an attack. An attacker can use logs to obtain critical information about the system as well as tamper them to clear his traces after an attack.</td>
| |
| − | <td>
| |
| − | 1. Non repudiation<br/>
| |
| − | 2. Cleaning the logs to remove evidence<br/>
| |
| − | 3. Inserting of faked logging entries<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Authentication</td>
| |
| − | <td>Threats caused by lack of strong protocols to validate the identity of a user to access a system or component outside the trust boundary. An attacker can obtain illegitimate access to the system or its individual components.</td>
| |
| − | <td>
| |
| − | 1. Impersonation <br/>
| |
| − | 2. Spoofing attacks <br/>
| |
| − | 3. Brute force attacks <br/>
| |
| − | 4. Dictionary attacks <br/>
| |
| − | 5. Token/Cookie Reply attacks <br/>
| |
| − | 6. Man in The Middle attacks(MiTM) <br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>Authorization</td>
| |
| − | <td>Threats caused by lack of a mechanisms to enforce access control on protected resources within the system. An attacker can get access to resources that should not have privileges to access to.</td>
| |
| − | <td>
| |
| − | 1. Escalation of privileges<br/>
| |
| − | 2. Luring attacks <br/>
| |
| − | 3. Forceful browsing <br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Configuration Management</td>
| |
| − | <td>Threats caused by insecure deployment and administration. An attacker can get access to system/user data and gain unauthorized access to system functionality</td>
| |
| − | <td>
| |
| − | 1. Elevation of privileges <br/>
| |
| − | 2. Unauthorized access to configuration data <br/>
| |
| − | 3. Unauthorized access to administration interfaces <br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>Data Protection in Storage and Transit</td>
| |
| − | <td>Threats caused by the implementation of encryption and lack of adequate protection for secrets and other data in storage or transit. An attacker can compromise user/system confidentiality and data integrity by bypassing the cryptographic mechanisms used by the system</td>
| |
| − | <td>
| |
| − | 1. Access to sensitive data in storage <br/>
| |
| − | 2. Access to secrets (e.g. encryption keys)<br/>
| |
| − | 3. Eavesdropping of data during transmission <br/>
| |
| − | 4. Data tampering<br/>
| |
| − | 5. Brute force attacks to crack encryption<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>Data Validation</td>
| |
| − | <td>Threats due to lack of input validation and output validation whenever data crosses system or trust boundaries. An attacker can use data as a vector to carry the payload for attacks such as SQL injection, cross site scripting, or buffer overflows that lead to arbitrary code execution, denial of service, information disclosure and elevation of privileges attacks.</td>
| |
| − | <td>
| |
| − | 1. Cross Site Scripting<br/>
| |
| − | 2. SQL injection<br/>
| |
| − | 3. Buffer overflow<br/>
| |
| − | 4. Query string manipulation<br/>
| |
| − | 5. Form field manipulation<br/>
| |
| − | 6. Cookie manipulation<br/>
| |
| − | 7. HTTP header manipulation<br/>
| |
| − | 8. Denial of Service<br/>
| |
| − | 9. Sensitive information gathering<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#dddddd">
| |
| − | <td>Exception Management</td>
| |
| − | <td>Threats caused by failure to handle exceptions effectively and in a secure manner and any resulting unauthorized disclosure of information. An attacker can use exceptions to crash the application or to obtain other information regarding the system such as the database schema that he or she can then use to launch an attack.</td>
| |
| − | <td>
| |
| − | 1. Denial of Service<br/>
| |
| − | 2. Information disclosure<br/>
| |
| − | 3. Elevation of privileges<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | | |
| − | <tr bgcolor="#cccccc">
| |
| − | <td>User and Session Management</td>
| |
| − | <td>Threats caused by the lack of mechanisms to maintain session independence between multiple logged on users and the lack of adequate and secure management of authenticated sessions. An attacker can gain access to another user’s data and for unauthorized access to system resources and data</td>
| |
| − | <td>
| |
| − | 1. Session hijacking<br/>
| |
| − | 2. Session replay<br/>
| |
| − | 3. Session re-use <br/>
| |
| − | 4. Session fixation<br/>
| |
| − | 5. Session riding (CSRF)<br/>
| |
| − | 6. Elevation of privileges<br/>
| |
| − | </td>
| |
| − | </tr>
| |
| − | </table>
| |
| − | <br/>
| |
| − | | |
| − | ===Threat Analysis===
| |
| − | The prerequisite in the analysis of threats is the understanding of the generic definition of risk that is the probability that a threat agent will exploit a vulnerability to cause an impact to the application. From the perspective of risk management, threat modeling is the systematic & strategic approach for identifying and enumerating threats to an application environment with the objective of minimizing risk and the associated impacts.
| |
| − | | |
| − | Threat analysis as such is the identification of the threats to the application and involves the analysis of each aspect of the application functionality and architecture and design to identify and classify potential weaknesses that could lead to an exploit.
| |
| − | | |
| − | In the step 1 of TM we have modeled the system showing data flows, trust boundaries, process components and entry and exit points. An example of such modeling is shown in the Example: Data Flow Diagram for the College Library Website.
| |
| − | | |
| − | Data flows show how data flows logically through the end to end and allow the identification of affected components through critical points (i.e. data entering or leaving the system, storage of data) and the flow of control through these components. Trust boundaries show any location where the level of trust changes. Process components show where data is processed such as web servers, application servers and database servers. Entry points show where data enters the system (i.e. input fields, methods) and exit points are where it leaves the system (i.e. dynamic output, methods), respectively. Entry and exit points define a trust boundary.
| |
| − | | |
| − | Threat lists based on STRIDE model are useful in the identification of threats with regards to the attacker goals. For example, if the threat scenario is attacking the login, would the attacker brute force the password to break the authentication? If the threat scenario is to try to elevate privileges to gain another user privileges, would the attacker try to perform forceful browsing?
| |
| − | | |
| − | From the attacker's point of view and hence it is vital that all possible attack vectors are evaluated. For this reason, it is also important to consider entry and exit points, since they could also allow the realization of certain kinds of threats. For example the login page allows sending authentication credentials and the input data accepted by an entry point has to validate for potential malicious input to exploit vulnerabilities such as SQL injection, cross site scripting and buffer overflows. Additionally, the data flow passing through that point has to be used to determine the threats to the entry points to the next components along the flow, If the following components can be regarded critical (e.g. the hold sensitive data) that entry point can be regarded more critical as well. In an end to end data flow for example the input data (i.e. username and password) from a login page passed on without validation it could be exploited for a SQL injection attack to manipulate a query for breaking the authentication or to modify a table in the database.
| |
| − | | |
| − | Exit points might serve as attack points to the client (e.g. XSS vulnerabilities) as well for the realization of information disclosure vulnerabilities. For example, in the case of exit points from components handling confidential data (e.g. data access components), exit points lacking security controls to protect the confidentiality and integrity can lead to disclosure of such confidential information to an unauthorized user.
| |
| − | | |
| − | In many cases threats enabled by exit points are related to the threats of the corresponding entry point. In the login example, error messages returned to the user via the exit point might allow for entry point attacks such as account harvesting (e.g. username not found), or SQL injection (e.g. SQL exception errors).
| |
| − | | |
| − | From the defensive perspective, the identification of threats driven by security control categorization such as ASF, allows a threat analyst to focus on specific issues related to weaknesses (e.g. vulnerabilities) in security controls. Typically the process of threat identification involves going through iterative cycles where initially all the possible threats in the threat list that apply to each component are evaluated.
| |
| − | | |
| − | At the next iteration threats are further analyzed by exploring the attack paths, the root causes (e.g. vulnerabilities, depicted as orange blocks) for the threat to be exploited and the necessary mitigation controls (e.g. countermeasures, depicted as green blocks). A threat tree as shown in figure 2 is useful to perform such threat analysis
| |
| − | | |
| − | [[Image:Threat_Graph.gif|Figure 2: Threat Graph]]
| |
| − | | |
| − | Once common threats, vulnerabilities and attacks are assessed, a more focused threat analysis should take in consideration use and abuse cases. By thoroughly analyzing the use scenarios, weaknesses can be identified that could lead to the realization of a threat. Abuse cases should be identified as part of the security requirement engineering activity. These abuse cases can illustrate how existing protective measures could be bypassed, or were a lack of such protection exists. A use and misuse case graph for authentication is shown in figure 3[[Image:UseAndMisuseCase.jpg|Figure 3: Use and Misuse Case]]
| |
| − | | |
| − | Finally it is possible to bring all of this together by determining the types of threat to each component of the decomposed system. This can be done by using a threat categorization such as STRIDE or ASF, the use of threat trees to determine how the threat can be exposed by a vulnerability and use and misuse cases to further validate the lack of a countermeasure to mitigate the threat.
| |
| − | | |
| − | To apply STRIDE to the data flow diagram items the following table can be used:
| |
| − | [[Image:DFDStride.JPG|Figure 3: DFD and STRIDE]]
| |
| − | | |
| − | ===Ranking of Threats===
| |
| − | | |
| − | Threats can be ranked from the perspective of risk factors. By determing the risk factor posed by the various identified threats it is possible to create a prioritized list of threats support os a risk mitigation startegy such as decicing on which threats have to be mitigated first. Different risk factors can be used to determine with threats can be ranked as High, Medium or Low risk. In general threat-risk models use different factors to model risks such as shown in figure 3
| |
| − | | |
| − | | |
| − | [[Image:Riskfactors.JPG|Figure 3: Risk Model Factors]]
| |
| − | ===DREAD===
| |
| − | The Microsoft DREAD threat-risk ranking model the technical risk factors for impact are Damage and Affected Users while the ease of exploitation factors are Reproducibility, Exploitability and Discoverability. This risk factorization allows the assignment of values to the different influencing factors of a threat. The determine the ranking of a threat the threat analyst has to answer where basic questions for each factor of risk for example:
| |
| − | | |
| − | *For Damage: How big the damage can be?
| |
| − | *For Reproducibility: How easy is it to reproduce an attack to work?
| |
| − | *For Exploitability: How much time, effort and expertise is needed to exploit the threat?
| |
| − | *For Affected Users: If a threat were exploited, what percentage of users would be affected?
| |
| − | *For Discoverability: How easy is it for an attacker to discover this threat?
| |
| − | | |
| − | By referring to the college library website it is possible to document sample threats releated to the use cases such as:
| |
| − | | |
| − | '''Threat: Malicious user views confidential information of students, faculty members and librarians.'''
| |
| − | # '''Damage potential:''' Threat to reputation as well as financial and legal liability:8
| |
| − | # '''Reproducibility:''' Fully reproducible:10
| |
| − | # '''Exploitability:''' Require to be on the same subnet or have compromised a router:7
| |
| − | # '''Affected users:''' Affects all users:10
| |
| − | # '''Discoverability:''' Can be found out easily:10
| |
| − | | |
| − | Overall DREAD score: (8+10+7+10+10) / 5 = 9
| |
| − | | |
| − | In this case having 9 on a 10 point scale is certainly an high risk threat
| |
| − | ===Generic Risk Model===
| |
| − | A more generic risk model takes into consideration the Iikelihood (e.g. probability of an attack) and the Impact (e.g. damage potential):<b>''Risk = Likelihood x Impact''</b>
| |
| − | | |
| − | == Determine countermeasures and mitigations ==
| |
| − | ===Threat-Vulnerability Mapping===
| |
| − | | |
| − | ===Countermeasure Identification===
| |
| − | The purpose of the countermeasure identification is to determine if there is some kind of protective measure in place that can prevent each threat previosly identified via threat analysis from being realized. Since each of these threats has been categorized either with STRIDE ot ASF it is possible to find an appropriate countermeasure within the given category.
| |
| − | | |
| − | An example is provided in figure TBD.
| |
| − | | |
| − | ===Mitigation Strategies===
| |
| − | The objective or risk management is to reduce the impact that the exploitation of a threat can have to the application. This can be done by responding to a theat with a risk mitigation strategy. In general there are four options to mitigate threats
| |
| − | # '''Do nothing:''' for example hoping for the best
| |
| − | # '''Informing about the risk:''' for example warning user population about the risk
| |
| − | # '''Mitigate the risk:''' for example by putting countermeasures in place
| |
| − | # '''Accept the risk:''' for example after evaluating the impact of the exploitation (business impact)
| |
| − | # '''Transfer the risk:''' for example through contractual agreements and insurance
| |
| − | | |
| − | The decision which strategy is most appropriate depends on the impact an exploitation of a threat can have, the likelihood of its occurrence, and the costs for transferring (i.e. costs for insurance) or avoiding (i.e. costs or losses due redesign) it. That is, the decision is based on the risk a threat poses to the system. Therefore, the chosen strategy does not mitigate the threat itself but the risk it poses to the system.
| |
| | [[Category:OWASP Code Review Project]] | | [[Category:OWASP Code Review Project]] |
| | + | [[Category:Threat_Modeling]] |
| | + | [[Category:SAMM-TA-1]] |
Threat modelling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.
Threat modelling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the internet of things, business processes, etc. There are very few technical products which cannot be threat modelled; more or less rewarding, depending on how much it communicates, or interacts, with the world. Threat modelling can be done at any stage of development, preferably early - so that the findings can inform the design.
Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:
This is a "research" activity in which you want to find the main threats that apply to your application. There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning.
The technical steps in threat modelling involve answering questions: - What are we working on - What can go wrong - What will we do with the findings - Did we do a good job? The work to answer these questions is embedded in some sort of process, ranging from incredibly informal Kanban with Post-its on the wall to strictly structured waterfalls.
The effort, work, and timeframes spent on threat modelling relate to the process in which engineering is happening and products/services are delivered. The idea that threat modelling is waterfall or ‘heavyweight’ is based on threat modelling approaches from the early 2000s. Modern threat modelling building blocks fit well into agile and are in wide use.
When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious.
Threat modelling integrates into Agile by asking “what are we working on, now, in this sprint/spike/feature?”; trying to answer this can be an important aspect of managing security debt, but trying to address it per-sprint is overwhelming. When the answer is that the system’s architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being transmitted, then it is unlikely that the answers to ‘what can go wrong’ will change. When one or more of those changes, then it’s useful to examine what can go wrong as part of the current work package, and to understand designs trade-offs you can make, and to understand what you’re going to address in this sprint and in the next one. The question of did we do a good job is split: the “did we address these threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task.
After a security incident, going back and checking the threat models can be an important process.
Threat modelling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modelling, yet quite different.
