├── LICENSE ├── README.md ├── img ├── TM_diagram.png ├── TM_stages.png └── ppt_iso27005.png └── playbook ├── 1. Introduction.md ├── 2. Get stakeholder buy-in.md ├── 3. Embed in your organization.md ├── 4. Train your people to threat model.md ├── 5. Strengthen your threat model proces.md ├── 6. Innovate with threat model technology.md ├── 7. Glossary of terms.md ├── 8. References.md └── test.md /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![CC BY 4.0][cc-by-shield]][cc-by] 2 | 3 | # Intro 4 | We aim to improve product and software security with our new threat modeling playbook. We consider threat modeling as a foundational activity to improve your software assurance. We are convinced that a good threat modeling practice will measurably decrease security issues of delivered products. 5 | 6 | As strong believers in open source, active OWASP collaborators and to increase our impact beyond our Toreon customers, we donate this threat modeling playbook to the community. 7 | 8 | We hope you will use this playbook to improve your threat modeling practice. We also encourage you to provide feedback to our [OWASP threat modeling](https://owasp.org/www-community/Threat_Modeling) community in order to make this playbook even better in our next release. 9 | 10 | I thank our collaborators (in alphabetic order): Jonas Muylaert, Joris Van den Broeck, Sebastien Deleersnyder, Steven Wierckx and Thomas Heyman to help us create this first release. I also thank Toreon for its decision to donate this work to the threat modeling community. 11 | 12 | Sebastien Deleersnyder 13 | 14 | CEO Toreon 15 | 16 | OWASP volunteer 17 | 18 | 10 September 2020 19 | 20 | # PDF version 21 | 22 | We released our threat modeling here in markdown. 23 | If you are interested in the PDF version, it is available for download on our [website](https://www.toreon.com/threat-modeling-playbook/). 24 | 25 | # Diagram 26 | 27 | ![alt text](img/TM_diagram.png) 28 | 29 | # Table of contents 30 | 31 | ### [1. Introduction](playbook/1.%20Introduction.md) 32 | ### [2. Get stakeholder buy-in](playbook/2.%20Get%20stakeholder%20buy-in.md) 33 | ### [3. Embed in your organization](playbook/3.%20Embed%20in%20your%20organization.md) 34 | ### [4. Train your people to threat model](playbook/4.%20Train%20your%20people%20to%20threat%20model.md) 35 | ### [5. Strengthen your threat model processes](playbook/5.%20Strengthen%20your%20threat%20model%20proces.md) 36 | ### [6. Innovate with threat model technology](playbook/6.%20Innovate%20with%20threat%20model%20technology.md) 37 | 38 | # Authors 39 | * ### Sebastien Deleersnyder 40 | * ### Steven Wierckx 41 | * ### Joris Van Den Broeck 42 | * ### Thomas Heyman 43 | * ### Jonas Muylaert 44 | 45 | # License 46 | 47 | 48 | This work is licensed under a 49 | [Creative Commons Attribution 4.0 International License][cc-by]. 50 | 51 | [![CC BY 4.0][cc-by-image]][cc-by] 52 | 53 | [cc-by]: http://creativecommons.org/licenses/by/4.0/ 54 | [cc-by-image]: https://i.creativecommons.org/l/by/4.0/88x31.png 55 | [cc-by-shield]: https://img.shields.io/badge/License-CC%20BY%204.0-lightgrey.svg 56 | -------------------------------------------------------------------------------- /img/TM_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/threat-modeling-playbook/a9ca8d1aaaea232da66d1d40b76034b76998b681/img/TM_diagram.png -------------------------------------------------------------------------------- /img/TM_stages.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/threat-modeling-playbook/a9ca8d1aaaea232da66d1d40b76034b76998b681/img/TM_stages.png -------------------------------------------------------------------------------- /img/ppt_iso27005.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/threat-modeling-playbook/a9ca8d1aaaea232da66d1d40b76034b76998b681/img/ppt_iso27005.png -------------------------------------------------------------------------------- /playbook/1. Introduction.md: -------------------------------------------------------------------------------- 1 | # 1. Introduction 2 | ## 1.1 Purpose 3 | 4 | The goal of a threat model is to provide an objective, risk-based evaluation of security problems within your system’s architecture. The information gathered, is provided to the stakeholders so they can make a well-informed decision on how to mitigate threats and lower risks to an acceptable level. 5 | 6 | Although this is the main focus of threat modeling, there are plenty of other reasons to utilize threat modeling [1]: 7 | 8 | * To get stakeholders to agree on a shared vision of your systems security 9 | * To increase awareness and knowledge of your system with stakeholders 10 | * To document your system design, document due diligence for certain legislative requirements such as privacy by design 11 | * To serve as input for other processes such as testing the implementation, validating requirements, etc. For example: A penetration test will be much more efficient if testers can fall back on a threat model which explains what needs to be protected and lists your system’s requirements 12 | * To spread knowledge on secure architecture in your organization. Lessons learned from a threat model can be useful in future designs of other systems 13 | 14 | Implementing and maturing the threat model process within an organization is hard. This playbook [2]will guide you through the process and will help you reach the level of maturity in threat modeling that you want to achieve within your organization. 15 | 16 | ## 1.2 Strategy 17 | This threat modeling playbook assumes you are creating or integrating software, hardware, or combining both using an agile methodology. We will measure the maturity level of the threat modeling practice based on three topics: people, processes, and tools or technology. 18 | 19 | If your organization is not using agile development methodologies, or this process is new and not yet optimized, this guide can still be used. Chapters 2.2, 4.4 and 4.6 will need some evaluation concerning tools and processes when development methodologies are not in place. Nevertheless, threat modeling is being done in many organizations that do not use agile development methodologies. 20 | 21 | To measure your maturity concerning the threat modeling process, several methodologies and frameworks are available. We are heavily influenced by the OWASP SAMM [3] project and will measure maturity at three levels. 22 | 23 | ## 1.3 How to use this playbook 24 | There are several strategies for using this playbook. The choice between strategies depends on the number of systems and the level of “thoroughness” needed for those threat models. 25 | 26 | There are several strategies you can use: 27 | 28 | 1. Start with one system and get to a very mature state of your threat modeling practice with a very mature threat model. After reaching the desired level of maturity, proceed to the next system. 29 | 2. Start with multiple systems in parallel. While you are maturing your threat modeling practice, come back to each threat model and improve it. 30 | 3. A combination of the above. Start with the top 10% of your (most important) applications in parallel if your organization has a large number of systems. 31 | 32 | For each existing system, you also need to decide a strategy: 33 | 34 | 1. Perform threat modeling of the *complete system* as it exists today. The rationale: this system is important, and the goal is to reduce the associated risks as much as possible. 35 | 36 | 2. Perform threat modeling on the *changes* being made on the system. The rationale: this system has been in use for a long time. If any major security problems existed, they would have been exploited by now so we can limit ourselves to new functionalities. 37 | 38 | 3. Perform threat modeling on the *most important use case(s)* of the system. The rationale: Creating a full-blown threat model takes too much time and effort to be economically viable. Nevertheless, we do still want to address the most important risks, which will generally be linked to the most important use cases. When in doubt, think about which use cases bring the most value and conversely which "doomsday scenarios" risk losing the most value. For some businesses this can be measured in money, while in others, reputational damage or physical harm can play a role. 39 | 40 | This threat model playbook contains several elements from which you can design your ‘playbook’ as you would in American football. Each subchapter can be considered a ‘play’ that you can use in a ‘playbook’ which is customized to your organization or situation. You should play for 'maximum forward progress' towards your end goal. 41 | 42 | 43 | [1]: 7.%20Glossary%20of%20terms.md 44 | [2]: 7.%20Glossary%20of%20terms.md 45 | [3]: 7.%20Glossary%20of%20terms.md 46 | 47 | 48 | [Main page](../README.md) | [Next page >>](./2.%20Get%20stakeholder%20buy-in.md) 49 | | --- | --- | 50 | -------------------------------------------------------------------------------- /playbook/2. Get stakeholder buy-in.md: -------------------------------------------------------------------------------- 1 | # 2. Get stakeholder buy-in 2 | 3 | A threat model can only achieve its goal, i.e., to reduce risk and increase security, if there is sufficient buy-in of all the stakeholders involved. Specifically, in order to implement the playbook, you will need the following resources: 4 | 5 | 1. Time of the people involved in creating the threat model 6 | 2. Threat modeling expertise (especially if you are just starting out) 7 | 3. Time, resources, and authority to address the resulting threats. 8 | 9 | As these are important to get management buy-in and commitment to manage your risks with threat modeling. Let us look at these in turn. 10 | 11 | ## 2.1 Involve people and allocate time 12 | 13 | It is easy to underestimate the number of people that are directly or indirectly involved in creating a threat model, but you will need to address their concerns in order to get them to collaborate. In order to do that, you first need to understand what it will cost them, and what they can potentially see as obstacles to investing time in the threat model. Note that we do not mention the threat modeling champion in this listing, as their motivation to do threat modeling is assumed. 14 |
15 | | Business stakeholder | Cost, obstacles for the stakeholder | 16 | | :--------------------------: | ----------------------------------- | 17 | | **Management** | | 18 | | **Application owner** | | 19 | | **Architect** | | 20 | | **Developer** | | 21 | | **Security and/or DevOps engineer** | | 22 | | **Project manager** | | 23 | 24 | 25 | In order to defuse some of these arguments and convince the stakeholders that threat modeling is also in their best interest, it is necessary to first listen to their concerns and acknowledge them. 26 | 27 | 28 | | Business stakeholder | Potential gains | 29 | | :--------------------------: | ----------------------------------- | 30 | | **Management** | | 31 | | **Application owner** | | 32 | | **Architect** | | 33 | | **Developer** | | 34 | | **Security and/or DevOps engineer** | | 35 | | **Project manager** | | 36 | 37 | ## 2.2 Inject threat modeling expertise 38 | 39 | A second ingredient you need to acquire in order to make threat modeling a success, is the relevant expertise. In Chapter 2, we mentioned the importance of finding a threat modeling specialist and to train your people. In order to obtain the relevant expertise, there are three approaches you can take. Let’s look at these in turn. 40 | 41 | #### **The do-it-yourself approach** 42 | 43 | In organizations that are just starting with dipping their toes into the proverbial threat modeling pond, one option is to start acquiring threat modeling expertise by reading books and accessing some freely available online resources. This is especially the case where there are no extensive security budgets, or if the current need is low. 44 | 45 | The advantages of this approach are that it can start right away and does not take a lot of preparation or budgeting. The downside, however, is that threat modeling can be tricky when you are just starting out, especially for people without prior security expertise. In that case, a failed first ad-hoc threat modeling attempt might undermine the goodwill of the rest of the stakeholders to invest further in setting up a threat modeling approach. This approach also does not scale for larger organizations. 46 | 47 | Therefore, the recommendation is to only start with and ad-hoc approach if the people involved have some prior security exposure, and there is a willingness to experiment (and possibly fail). For other cases, it might be better to start off by hiring an external expert. 48 | 49 | #### **Hiring an expert** 50 | 51 | A good, fairly lightweight way to start adopting a threat modeling approach, is to have a threat model done by an expert, in close collaboration with your team. In that way, the team gets to see hands-on how threat modeling is performed, and there is a larger guarantee that the first threat model will be a success. 52 | 53 | The advantages of this approach are that it is significantly lower risk than the ad-hoc approach and can create a lot of goodwill and willingness to adopt a broader threat modeling approach in a fairly short time. Furthermore, it scales reasonably well, as the same expert can be hired to perform follow-up threat models for other teams. The downsides of this approach are that it does require a larger budget than the ad-hoc approach, and it does not automatically scale to large organizations with dozens or hundreds of applications in their portfolio. 54 | 55 | Therefore, hiring an expert should be considered by organizations that are just starting out with threat modeling and want to get some experience, or small organizations with only a few applications in their portfolio. For larger organizations that want to systematically adopt threat modeling throughout various teams, external threat modeling training programs are more suitable. 56 | 57 | #### **Threat modeling training** 58 | 59 | With a threat modeling training program, a trainer is hired to train an initial core team of people to threat model. The trainees should be highly motivated people that can subsequently take up the role of threat modeling specialists (or even evangelists) within that organization. 60 | 61 | The advantages of this approach are that it scales extremely well and has the highest chance for success that your organization is able to fully adopt and internalize threat modeling. The downsides, however, is that it takes a while before results are produced, as the training should still be followed by actually creating initial threat models. It also requires a larger up-front investment, which might be a hurdle for organizations in which threat modeling has not proven its value yet. 62 | 63 | ## 2.3 Threat modeling return on investment 64 | 65 | Lastly, an extremely important aspect of setting up a sustainable threat modeling initiative within an organization, is to demonstrate return on investment (ROI) and get management commitment on this. A threat modeling approach is only able to show ROI if it results in a demonstrable improvement of the security of that organization, or its products. 66 | 67 | Some things that need to be considered, are: 68 | 69 | * To lead to security improvements, a threat modeling approach should result in recommendations that are clearly documented to the relevant stakeholders. A document on a file share which no one knows exists, will never lead to ROI. 70 | * To lead to change, the recommendations of a threat model should be realistic and implementable. If the recommendations exceed the timing, budget, expertise, or other constraints of a project, they will not effect change and not lead to ROI. It is crucial that the threat modeler has a good understanding of the project constraints before making recommendations! 71 | * To show that the change is effective with threat modeling, mitigations and recommendations made in a threat model should be clearly linked to development artefacts such as new user stories, bug fixes, JIRA tickets, and so on. If you can measure the number of projects, user stories, or tickets that are impacted by threat modeling, you can more easily track the level of adoption of threat modeling throughout your organization, and its effect. That, in turn, makes it easier to demonstrate ROI. 72 | 73 | Finally, to show that the change is positive, the changes effected by threat modeling should be linked to the number of security bugs or incidents that are reported after go-live of the system that was threat modeled. An important consideration is to distinguish between the number of security issues that are reported as a direct result of threat modeling (this number should be high!) and the number of security issues that are reported after the fact (this number should go down). By making it clear that threat modeling is responsible for detecting and fixing more security issues proactively, you can clearly show ROI. 74 | 75 | [<< Previous page](1.%20Introduction.md) | [Main page](../README.md) | [Next page >>](3.%20Embed%20in%20your%20organization.md) 76 | | --- | --- | --- | -------------------------------------------------------------------------------- /playbook/3. Embed in your organization.md: -------------------------------------------------------------------------------- 1 | # 3. Embed in your organization 2 | 3 | Threat modeling is a methodology to identify risks and hence should be integrated in your organizations’ risk management process. As a best practice we look at the risk management process described in ISO27005:2018 and map our threat modeling activities on this process. 4 | 5 | We visualized a simplified overview of the main stages, who are part of the risk management process in Figure 1. We can summarize the threat modeling activities in three categories: 6 | 7 | * People: who to involve how 8 | * Process: which processes need to exist or need to be adapted 9 | * Technology: which tools and technologies can help and facilitate threat modeling 10 | 11 | The risk management stages we consider for threat modeling are: 12 | 13 | * Context establishment 14 | * Communication 15 | * Risk assessment and treatment 16 | * Monitoring and review 17 | 18 | In each of these stages, we map related threat modeling activities. These threat modeling activities are grouped by people, process, or technology categories. 19 | 20 | ![alt text](../img/ppt_iso27005.png) 21 | 22 | ## 3.1 Context establishment 23 | 24 | First, you need to understand how your organization handles and manages risk. The same risk can have a totally different impact in different organizations. For threat modeling the following activities are important concerning context establishment: 25 | 26 | #### **Process**: 27 | * 5.1 Understand the current process: it is crucial to understand existing processes in your organization and how to integrate threat modeling in them. 28 | 29 | * 5.2 Introduce application security risk levels: by using application security risk levels and deciding when to apply threat modeling you can focus on the most important applications first. 30 | 31 | * 5.3 Define threat modeling methodology: there are many ways to define a threat model. You should select the methodology that fits your organization best. 32 | 33 | #### **Technology**: 34 | * 6.1 Identify current toolset: identify tools and technologies used in your organization. This will help to assess how to integrate threat modeling in the existing toolset. 35 | 36 | ## 3.2 Risk assessment and treatment 37 | 38 | Secondly, you execute the threat modeling activity as part of the risk assessment stage. Here you follow the selected threat modeling methodology. 39 | 40 | #### **Process**: 41 | * 5.4 Perform and persist threat model: you create and store your threat model. 42 | 43 | #### **Technology**: 44 | * 6.1 Whiteboards and flipcharts for modeling: most threat modeling methodologies are easy to start on a whiteboard or flipchart. 45 | 46 | * 6.2 Persisting models: tools and technology to store threat models. 47 | 48 | * 6.3 Integration with DevOps tooling: when working in a development environment, integrating with the development tooling is highly recommended. 49 | 50 | * 6.3 Use special threat modeling tooling: threat modeling tools exists that can support you to threat model. 51 | 52 | * 6.3 Threat modeling as code: following infrastructure as code – threat modeling as code also exists and can have several benefits. 53 | 54 | The identified risks should be handled according to the risk management policy/process in use in your organization. The first step is to consider different risk treatment options such as: risk reduction, risk retention, risk avoidance or risk transfer. Based on a cost / benefit calculation, you select your best options. 55 | 56 | ## 3.3 Monitoring & review 57 | 58 | Thirdly, risks are not static and will change over time. Exposure of the vulnerability leading to the risk may change, sensitivity of the information in the application may change, a risk may not be remediated in time, and so on. Hence it is important that your risks and their factors are regularly monitored and reviewed. For threat modeling this consists of the following activities: 59 | 60 | #### **Process**: 61 | * 5.6 Follow up on threat model actions: action should be taken on findings that come out of a threat model. 62 | 63 | * 5.7 Optimize methodology and risk calculation: to facilitate continuous improvement, you should monitor and optimize your threat modeling methodology. 64 | 65 | ## 3.4 Communication 66 | Finally, communication is key when creating a threat model. It is not possible to create a proper threat model without collaboration. 67 | 68 | ## **People**: 69 | * 4.1 Identify stakeholders: different stakeholders you involve in creating a threat model. 70 | 71 | * 4.2 Create a threat modeling specialist role: a threat model specialist role will facilitate threat modeling in your organization. 72 | 73 | * 4.3 Train your people: security awareness is critically important. Threat modeling training is a must when you start with threat modeling. 74 | 75 | * 4.4 Threat modeling culture: it is important to create a supporting culture for threat modeling. 76 | 77 | [<< Previous page](2.%20Get%20stakeholder%20buy-in.md) | [Main page](../README.md) | [Next page >>](4.%20Train%20your%20people%20to%20threat%20model.md) 78 | | --- | --- | --- | 79 | 80 | 81 | -------------------------------------------------------------------------------- /playbook/4. Train your people to threat model.md: -------------------------------------------------------------------------------- 1 | # 4 Train your people to threat model 2 | 3 | Before starting with the definition of an actual threat modeling process, care must be taken that the relevant people are identified, trained, and adopt the right mindset. In Chapter 4.1, we talk about identifying the relevant stakeholders for threat modeling. In Chapter 4.2, we focus on the creation of a threat model specialist role, who will serve as the focal point for threat model activities. In Chapter 4.3, we highlight the importance of appropriate training to support threat modeling. In Chapter 4.4, we end by talking on how to create and nurture a positive threat modeling culture in which threat modeling can flourish. 4 | 5 | ## 4.1 Identify stakeholders 6 | 7 | One of the strengths of threat modeling is that it brings together various stakeholders involved in the security of an IT system or project and ensures that they are aligned. Threat modeling helps this group of people to share a common understanding of the business value of the system or project. At the same time, it also helps those people share a view on the main threats and what mitigations can be put in place to address them. 8 | 9 | But who are those stakeholders? Involve too few, and the threat modeling exercise loses its main benefit as it does not create a shared understanding of business value and threats. Involve too many, and the exercise runs the risk of devolving into a costly set of meetings. You know the situation: most of the participants are too busy checking their e-mail and, in the end, nothing gets decided. In our experience, threat modeling is best performed within a core team of limited size. Ideally, at least the following roles are represented: 10 | 11 | | Role | Motivation | 12 | | :--------------------------: | ----------------------------------- | 13 | | **Business stakeholder** | Ensure that business value and potential business impact is clear. | 14 | | **Architect** | Provide a high-level overview of the application ecosystem and the underlying rationale. | 15 | | **Developer** | Provide details on used libraries, frameworks, and coding guidelines. | 16 | | **Security and/or DevOps engineer** | Provide details on existing security and/or infrastructure configuration.| 17 | | **Project manager** | Validate proposed mitigations in terms of timing and budget. | 18 | | **Threat model specialist** | Ensure proper execution of the threat model process. | 19 | 20 | This team composition can be very powerful, as it contains stakeholders with complementary views. First, it contains people with in-depth technical know-how, such as developers, security, and DevOps engineers. Second, it contains people that have a broader view, either technical such as architects, or non-technical such as business stakeholders and project managers. This is a proven recipe for productive discussions, as one might imagine. If managed well, this protects the threat modeling exercise from threats such as not representing reality, underestimating certain technical risks, or missing the point by failing to appropriately frame the uncovered risks with respect to their business impact. 21 | 22 | Of course, there is a drawback too. These people are usually extremely busy, and their time is a valuable resource. It is therefore not ideal to simply invite everyone for all threat modeling meetings. You must prepare the threat modeling workshops for them to be efficient and optimize the time spend by the participants, which we will revisit in Chapter 5 when we talk about processes. An important role who will achieve this is the threat model specialist. The specialist role will be explained next. 23 | 24 | ## 4.2 Create a threat modeling specialist role 25 | The primary purpose of a threat model specialist is to help incorporate threat model practices and a strong security culture into all aspects of an organization’s development processes. Threat model specialists are typically permanent staff that act more like floating specialists supporting the squads [4] as needed. They provide threat modeling advice, support squads, and occasionally drop in for a sprint or two. 26 | 27 | An example “job description” for a threat modeling specialist could look like this: 28 | 29 | #### **responsibilities**: 30 | * Act as a threat model point of contact for the squads and their security champions. 31 | * Responsible for leading threat model-related activities within the squad. 32 | * Act as a liaison between the stakeholders and squad members. 33 | 34 | #### **tasks**: 35 | 36 | * Raise the overall security awareness and threat modeling knowledge within the squads. 37 | * Organizes and facilitates threat modeling workshops for the squads. 38 | * Assures that lessons learned of threat modeling is communicated towards the squads. 39 | * Develops and improves your organization threat modeling methodology. 40 | * Selects, introduces, and maintains threat modeling tooling to support and automate your organization threat modeling practice. 41 | * Lead efforts in identification and remediation of weaknesses and vulnerabilities in the product design and development processes of the squads. 42 | * Develop security-focused user stories for squads using agile development strategies and designing unit and integration tests together with the squad’s test engineer. 43 | * Organize threat modeling education and training, advocate for security-focused culture changes, and recruit, mentor, and train additional threat model specialists and squad champions. 44 | 45 | #### **Required skills and experience**: 46 | * At least 2 years of experience in threat modeling. 47 | * Expert knowledge of threat model techniques and tools. 48 | * Excellent communication and meeting moderation skills. 49 | * Proven to be a team player. 50 | * Have an interest in security and willingness to learn and grow to meet the security needs of the squads. 51 | * Knowledge of security concepts, tools, and practices in development (automated security testing, dependency checking) are a plus. 52 | 53 | Once you have this role figured out for your organization, you second step is to find or hire candidate threat modeling specialists within your organization to help you start and improve your threat modeling practices. 54 | 55 | ## 4.3 Train your people 56 | 57 | As mentioned earlier, it is important to train the involved people on how to do practical threat modeling. Before anything else, the people in your threat modeling sessions need to understand the why and how of threat modeling. 58 | 59 | Start to gradually involve people from your different DevOps teams in lunch & learn sessions that explain and demonstrate what threat modeling is all about. 60 | 61 | Once people have a basic understanding, start with a role-based training program. People in the roles of architects, security champions, testing engineers and security specialists should follow thorough threat modeling training that covers at least the following topics: 62 | 63 | * Threat modeling as part of a secure development lifecycle 64 | * The threat modeling stages and process 65 | * Threat modeling methodologies (covering at least STRIDE [5] ) 66 | * Diagramming 67 | * Threat identification 68 | * Threat mitigation 69 | * Risk management concepts 70 | * Hands-on exercises, preferably based on your organization systems 71 | 72 | Ideally you include organization specific playbooks and templates, examples, and lessons learned. Also make sure to adapt the training to your technology stack and project governance. Assure that the learning objectives are clear and met, that you focus on outcome, techniques and that you perform hands-on exercises in group to mimic real live threat modeling workshops. 73 | 74 | Other people will be involved in threat modeling tangentially or are stakeholders or recipients of your threat modeling actions. Examples are developers, DevOps engineers, business analysts or product owners. For these roles you provide a high-level introduction training on threat modeling. 75 | 76 | ## 4.4 Create a positive threat modeling culture 77 | 78 | Create a positive culture around threat modeling to get the most out of threat modeling. Threat modeling is not an audit, but an activity to align the involved team on a shared vision on the security of the products that they are working on. 79 | 80 | When you start threat modeling as a practice, you should make it clear that a no-blame culture is the right starting point to do threat modeling. People make mistakes. During the workshops you will discover issues and design flaws. Take these as learning points to do it better next time, do not point fingers or blame the involved people for making errors. Look for root causes and learn from past mistakes to improve your product and DevOps processes. 81 | 82 | Likewise, when you do threat modeling, leave your ego at the door. Make sure you focus on the bigger picture of the threat model and not just your own vision and understanding. When doing threat modeling workshops, apply active listening and be open for the position of everyone involved. This means that you actively involve all the participants in your threat modeling session. By doing so, participants will get the full picture of your threat model which will result in support from your team. It also requires mutual respect, inclusivity, and the establishment of a space that is safe enough for the participants to speak their minds. 83 | 84 | As threat modeling is an activity where people with different backgrounds and skill levels will participate, you spend time to gain a good common understanding of the system in scope, including business and technical aspects. Make sure that everyone understands the terminology and concepts, if needed provide some reading materials before the workshops. 85 | 86 | Creating a threat model is fun. But do not forget the objective of your activity: aligning your stakeholders on the security vision you created, together with the people that were involved in the workshops. Make sure not to simply “toss your threat model over the cubicle wall” but take your time to go and explain it to the affected people or groups, ideally in-person. Translate your threat model outcome to the target audience. E.g. for senior management be prepared to map your technical findings to business risks and the involved budget impacts. Another example is to provide input for security testing towards your testing engineers in a way that they understand the technical implications of the discovered flaws in your threat model. 87 | 88 | Threat modeling is all about breaking your “tunnel vision” on the security aspects of your system. Tunnel vision originates from looking too far in the future, only looking at what is familiar in terms of security, and not being aware of external threats to your system. By involving other people and creating an open culture around threat modeling you will be able to break free from this tunnel vision trap and discover more and other security issues than you ever imagined. 89 | 90 | [<< Previous page](3.%20Embed%20in%20your%20organization.md) | [Main page](../README.md) | [Next page >>](5.%20Strengthen%20your%20threat%20model%20proces.md) 91 | | --- | --- | --- | 92 | 93 | [4]: 7.%20Glossary%20of%20terms.md 94 | [5]: 7.%20Glossary%20of%20terms.md -------------------------------------------------------------------------------- /playbook/5. Strengthen your threat model proces.md: -------------------------------------------------------------------------------- 1 | # 5 Strengthen your threat model processes 2 | 3 | Setting up the right processes is vital for increasing the maturity level of your threat model. This chapter of the playbook will guide you in setting up or updating these processes. When determining your process of threat modelling, you must first understand your current processes in place, as mentioned in chapter 5.1. You will need to determine the application risk level to see what threat model activities need to be performed and why, chapter 5.2 will guide you in doing this. Chapter 5.3 will assist you in choosing the correct methodology that must be used when developing a threat model. In chapter 5.4 we will discuss ways to persist your threat model according to their deliverables. The integration of your threat model with your risk management framework will be discussed in chapter 5.5. Chapter 5.6 will give you an insight on how to follow up on mitigations that were produced by your threat model. The last chapter 5.7, elaborates on different processes that already exist and how your threat model process can interact with these processes. 4 | 5 | ## 5.1 Understand your current process 6 | 7 | OWASP SAMM [6] describes threat modeling in the SAMM threat assessment practice. Basic threat modeling should include best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists. 8 | 9 | To determine where to introduce threat modeling in your organization, it is helpful to understand and document your current threat modeling processes. Make sure you have a basic understanding of what your teams are doing (if they do threat modeling at all). When do you carry out threat modeling? What kind of inputs and outputs do you have? What steps are taken? 10 | 11 | We recommend drawing a basic overview of your current threat modeling steps. Use this drawing as a map together with this playbook to see where you can improve your existing threat modeling based on the activities described in this playbook. 12 | 13 | ## 5.2 Introduce application risk levels 14 | 15 | As threat modeling can be a time-consuming activity you need to decide for what applications you are going to do this. Typically, applications will not all have the same risk level within your organization. We recommend ordering your applications in different risk “buckets” or risk profiles. Usually, you use three risk profiles: high, medium, and low risk. When you have application risk levels you can leverage other OWASP resources that rely on these levels, such as OWASP SAMM or OWASP ASVS [7]. 16 | 17 | But first you will need to define the application risk profile levels and a classification method that work for your organization. The level of risk for a system will determine the level of threat model activities that need to be performed to protect them. For more information on the risk related processes you can consult chapter 3. 18 | 19 | Use a simple method to evaluate the application risk per application, estimating the potential business impact that it poses for your organization in case of an attack. This is also explained in the Application Risk Profile activity of OWASP SAMM. An example and simple risk classification into three levels can use the following scheme: 20 | 21 | * Level 1 (low risk) is for systems that contain no critical data and complete loss, data theft etc. will have no impact on your organization. Examples: application to reserve a parking spot, application to order lunch … These applications do not need a full-blown threat model. 22 | * Level 2 (medium risk) contains all systems not in level 1 or level 3. In practice these are systems that are not critical but do contain sensitive data such as GDPR impacted data etc. These systems need a threat model that handles the use cases of this system. 23 | * Level 3 (high risk) systems are those systems that contain very sensitive data, large amounts of sensitive data or that control processes that, if compromised, threaten the existence of your organization. Examples: applications that process intellectual property, systems that result in actions in the physical world and could harm people (safety aspect). These systems need a threat model that goes into great detail and might go into very detailed systems aspects, up to inter-process communication on a CPU if that is part of your system scope. 24 | 25 | Data is considered sensitive if compromising the data would negatively impact your organization. 26 | 27 | ## 5.3 Choose a threat modeling methodology 28 | 29 | There is only one rule when it comes to choosing a threat model methodology. If it works for you, keep it. If not, change it. This is a very pragmatic approach but does not allow us to compare and evaluate different threat model methodologies. 30 | 31 | A threat model methodology should at least answer the following questions/steps: 32 | 33 | ![alt text](../img/TM_stages.png) 34 | 35 | These steps are: 36 | 37 | #### **Diagram the application.** 38 | A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant and more detailed threats. This includes the identification of security objectives. Clear objectives help you to focus on the threat modeling activity and determine how much effort to spend on subsequent steps. Itemizing your system's important characteristics and actors helps you to identify relevant threats during the next step. 39 | 40 | #### **Identify threats.** 41 | Use details from the previous step together with techniques to identify threats relevant to your system scenario and context. Examples of such techniques are attack trees [8], STRIDE [9], LINDDUN [10], etc. 42 | 43 | #### **Mitigate Identify vulnerabilities.** 44 | Review the layers of your system to identify weaknesses related to your threats. Use vulnerability categories to help you focus on those areas where mistakes are most often made. 45 | 46 | #### **Validate.** 47 | Validate the whole threat model. Is each threat mitigated? If not: is the residual risk clearly explained and tied into business risk. Scoping of security tests is typically done during this step. 48 | 49 | Evaluating a threat model methodology can be split in 2 distinct steps: 50 | 51 | 1. Evaluate the soundness of the methodology 52 | 2. Evaluate if the methodology works for you 53 | 54 | 55 | Academic research (Yskout, et al., 2020) shows us the elements, that should be present in an effective threat model methodology: 56 | 57 | * Model based 58 | * Traceable 59 | * Systematic 60 | * Business integration 61 | * Context aware 62 | * Scalable 63 | 64 | A recent overview of different threat model methodologies can be found in this [master’s thesis from Selin Juuso](https://www.theseus.fi/bitstream/handle/10024/220967/Selin_Juuso.pdf) (2019). Once you eliminated all threat model methodologies that do not have these elements you will have a list of potential candidates for your organization. You should also already have an idea of the requirements for the methodology. Are you looking for a pragmatic approach or rather a formal approach? Who will be the main stakeholders and users of the methodology? Do you have generic security and compliance requirements and can the methodology handle those? Do you have an established risk calculation methodology, and can the methodology apply this? 65 | 66 | Evaluating if a threat model methodology is going to work in your organization often requires you to have at least one try-out of the methodology. It is strongly advised to hire the help of a specialist in the methodology when doing this. 67 | 68 | In an ideal world the threat model methodology gives you sufficient tools and techniques to answer the 4 questions no matter what type of system/application of your organization is being assessed. In reality there might be such a diverse ecosystem of assets to threat model, that techniques of other methodologies might need to be applied. This should be a minority of the cases and we should keep the first and only rule in mind: if it works for you, keep it. If not, change it. 69 | 70 | ## 5.4 Perform and persist the threat model 71 | 72 | Once a threat model is created, you should persist or store your threat model for later reference, or if you want to update it. There are two types of deliverables that are created after each threat model - and for each of them different options are available to persist them. 73 | 74 | * Threat modeling supporting files: all artifacts created to perform the threat model e.g. data flow diagrams, architectural drawings, questionnaires, documentation, meeting minutes or STRIDE analysis. 75 | * These can be stored in the platform your squad is using, e.g. SharePoint [11], MS Teams [12], G Suite [13], Azure DevOps [14], JIRA [15], … 76 | * Risks identified in the threat model. 77 | * Stored in the risk register, stored in a bug/user-story system, ... 78 | * For each identified risk you should include a risk level and the agreed upon follow-up action. 79 | 80 | Whatever tool you use, we recommend storing your threat modeling artifacts as close as possible to your team documentation or source code repository. We also recommend using tools that the involved people can easily use. 81 | 82 | ## 5.5 Integrate with your risk management framework 83 | 84 | To ensure risks identified in the threat model are properly handled, a defined and management supported risk management framework is recommended. Without an agreed manner on how to handle risks – anything identified in the threat model will float around in empty spaces without actions or owners. You can have your own risk management framework, or you can derive one from the aforementioned ISO 27005 standard. 85 | 86 | The following components are essential to ensure action is taken upon risk identified during threat modeling: 87 | 88 | * Risk level:It should be possible to clearly identify the risk level for each risk to your organization. The risk level can depend on your business, type of application, data involved, or etc. The description of the risk level should include all the necessary components. When included, you can determine the specific risk level for a certain risk, that is representative for the risks posed to your organization. 89 | * Implications of the risk level: an agreement on which actions to take based upon the risk level. Based on the risk threshold of your organization, an agreement is necessary on what to do with each level of risk. E.g. will a critical risk be resolved in one week? What happens when the risk is not resolved within one week? 90 | * Risk escalation and acceptance: when a risk is not taken up and the risk level is sufficiently high, a risk escalation procedure must be followed. In addition, risk acceptance must be possible. 91 | * Risk review process: it is necessary to regularly review identified risk and whether appropriate action is taken. This can be done by reviewing a risk register or by reviewing user-stories or bugs in tools like JIRA or Azure DevOps. 92 | 93 | Make sure you identify these components in the risk management process in use at your organization and integrate your threat modeling methodology into these. If these are not present, your first step is to bootstrap a basic risk management process and agree on the essential components listed above with your key stakeholders. 94 | 95 | ## 5.6 Follow-up threat modeling action items 96 | 97 | One of the most important outcomes of a threat model is the list of mitigations and the order in which they need to be implemented. Many organizations struggle with this process. A perfect threat model is almost useless if the mitigations are not followed up upon. 98 | 99 | Start with creating a follow-up process. This process should ensure that every agreed upon action is implemented or executed by the assigned due date or handle any deviation from that plan. This process will certainly need to capture the following elements: 100 | 101 | * Who is accountable for the progress and due date? 102 | * What is the current status of the mitigation? 103 | * What is the risk of the mitigation? 104 | * Who is responsible for the execution / implementation? What are the actions that are needed? 105 | * What is the current state of each of the actions needed to finish this mitigation? 106 | 107 | Keep in mind that the risk level of threat modeling findings will change over time and might require new due dates and re-ordering of mitigations. 108 | 109 | ## 5.7 Optimize methodology and risk calculation 110 | 111 | Threat modeling might be new to your organization, but elements of the threat model process are probably already being produced. Examples are architecture diagrams, user stories, risk handling methodologies and risk calculation methodologies, security baselines like the CIS guide etc. 112 | 113 | Where possible you will want to re-use these since the process to gather them already exists and the effort to create the information is already done. It might be needed to adapt or enhance certain pieces of information to make them more applicable or more efficient for use in threat modeling. 114 | 115 | Several other activities can provide input for threat modeling. For example, the penetration test reports might hint to a structural problem in the architecture, risk assessment done in the beginning of the project (e.g. the business case) might provide valuable information on the expected return for the system and could point to associated threats. There might be the need for compliance to certain legislation coming from the DPO office or your legal team. They might also already have defined the requirements for the audit trails the system needs to provide. Your service delivery team might provide you with expectation on the quality of service that they will want to put in SLA’s together with the marketing/sales team etc. 116 | 117 | When you start the threat model process you need to have a good overview on all other processes in your organization in order to make the most efficient use of the limited resources available. In the same sense the threat model can be used as input for other activities such as test automation, penetration testing, training, awareness etc. 118 | 119 | And last but not least you might want to align or standardize on an organization wide risk calculation framework. This can be based on CVSS [16], the OWASP risk rating methodology [17] or any other methodology that makes sense for you teams. It does not really matter which calculation methodology you use, as long as you agree on a consistent way of implementing it within your organization. This way you can compare and manage the outcomes of your threat models across different teams. 120 | 121 | [<< Previous page](4.%20Train%20your%20people%20to%20threat%20model.md) | [Main page](../README.md) | [Next page >>](6.%20Innovate%20with%20threat%20model%20technology.md) 122 | | --- | --- | --- | 123 | 124 | 125 | [6]: 7.%20Glossary%20of%20terms.md 126 | [7]: 7.%20Glossary%20of%20terms.md 127 | [8]: 7.%20Glossary%20of%20terms.md 128 | [9]: 7.%20Glossary%20of%20terms.md 129 | [10]: 7.%20Glossary%20of%20terms.md 130 | [11]: 7.%20Glossary%20of%20terms.md 131 | [12]: 7.%20Glossary%20of%20terms.md 132 | [13]: 7.%20Glossary%20of%20terms.md 133 | [14]: 7.%20Glossary%20of%20terms.md 134 | [15]: 7.%20Glossary%20of%20terms.md 135 | [16]: 7.%20Glossary%20of%20terms.md 136 | [17]: 7.%20Glossary%20of%20terms.md 137 | -------------------------------------------------------------------------------- /playbook/6. Innovate with threat model technology.md: -------------------------------------------------------------------------------- 1 | # 6 Innovate with threat model technology 2 | 3 | At its core, threat modeling is a process that brings the right people together to think about (and hopefully improve) the security of an application or IT system. Technology should always be judged in its ability to support that process, and never as a goal in itself. 4 | 5 | In this section, we will talk about a number of guidelines that provide guidance on selecting the right technology and integrating it in your way of working so that the technology maximally supports the threat modeling process, and not the other way around. 6 | 7 | ## 6.1 Select the right tools 8 | 9 | Every threat modeler will make use of some technology. This can be very simple such as a piece of paper or more advanced such as specialist threat model tools. When deciding on a tool there is one core rule that should always be followed: a tool should support your process, never change your process to accommodate a tool. As a result of this rule you should first gather the requirements for your tool(s). 10 | 11 | Start with the tools already used within your organization for other purposes. Perhaps they can either partially or completely fulfill the requirements already. 12 | 13 | For example, the architects might already use a diagramming tool to create their diagrams. Each of the questions of the threat model process might have one or more tools being used. Typically, the models will be created in a drawing program such as MS Visio or Diagram.net (formerly Draw.io). The threat model itself is documented in a word processor whereas a spreadsheet is often used to calculate the risk scoring. 14 | 15 | Identifying the toolset currently in use will make it easier to incorporate the threat model practice in the existing toolset. This will create less friction and should help the adoption of threat model practices in your organization. Every organization is different, and each one implements the threat model practice and processes in a different way to fit the needs of that organization. This means there is no definitive list of tools that are ‘fixed’ for a certain level of maturity of the threat model process. 16 | 17 | Since the tools are supposed to fulfill the requirements, it is important that you document the use of tools when you use them during the threat model process. 18 | 19 | The tooling should be tailored to your organization. It should fit the size of the number of threat models needed. It should support the complexity of those threat models as well as the maturity of your threat model process. Of course, the tools should fit within the budget you have available. 20 | 21 | As an example, we will discuss one of the cheapest and readily available tools, the flipchart. There are several good reasons to use flipcharts, whiteboards or magic paper in an organization that is new to threat modeling. Creating models is cooperative work of different stakeholders. Standing around a whiteboard will enable all your stakeholders to take a marker and make changes to the model(s). It will force active participation of your stakeholders and will facilitate a consensus on the system scope. The same reasoning is valid for the other times during a threat model that the stakeholders work together. A threat model is a consensus between these stakeholders and as such there is a need for conversation to discuss the doomsday scenarios, scope, models, threats, mitigations, risks, etc. Flipcharts are a cheap tool that can be used to create initial threat models in any organization at the start of its threat model journey. It will stay a very relevant tool as your organization grows in maturity, but there will probably be a need for a tool that starts from a digital version of the model for updating the threat model. A flipchart is not the most ideal tool for that so it will be replaced in organizations that have created an initial threat model and are adding significant functionality that requires an update of the existing model. 22 | 23 | Creating a threat model using remote participation is certainly possible but this requires specific tools and some experience within the team to pull off in an efficient way. 24 | 25 | ## 6.2 Processing the outcome of tools 26 | 27 | The primary goal of a threat model is allowing the decision makers to use an objective, risk-based approach to mitigate threats against a system. 28 | 29 | However, there are many other reasons to do threat modeling. These reasons could be: 30 | 31 | * To create awareness with your stakeholders 32 | * To document due diligence 33 | * To serve as documentation on the system 34 | * To feed input into other practices, such as security reviews and penetration testing 35 | * Feedback lessons learned into other systems and threat models 36 | * To share threat modeling knowledge 37 | * … 38 | 39 | To cover all these requirements your threat model needs to be accessible by different groups of people, some of them needing only access to certain parts of the threat model. 40 | 41 | Once the first threat model creation has started you will need to persist the results of these sessions. Any tool(s) you select should therefore fulfill two requirements: 42 | 43 | 1. Allow / facilitate the conversations between your stakeholders that happen during threat modelling 44 | 2. Persist the threat model in such a way that it can be easily updated and is available to all stakeholders. The threat model contains the modelling artefacts as well as supporting evidence. 45 | 46 | When you evaluate tools to persist threat models, the operational security must also be guaranteed. A threat model will contain sensitive information in the form of unsolved security problems and the access should be limited as much as possible. This creates a field of friction between the operational security and the other requirements for threat modeling. A vision on how to handle both sets of requirements should be decided on and serve as a guideline during tool selection. 47 | 48 | Combining the two requirements from above with the operational security might lead you to have several places / tools where (partial) information can be shared with your different shareholders. 49 | 50 | ## 6.3 Integration in your threat modeling methodology 51 | 52 | Let`s first remind ourselves of the rule we stipulated in chapter 4.1: a tool should support your process, never change your process to accommodate a tool. As a result of this rule you should first gather the requirements for your tool(s). 53 | 54 | There can be several tools already in use in your organization. Where possible you should reuse these tools since this will limit the friction to implement the process, limit the costs (both in potential licensing and learning curve). 55 | 56 | While looking at the Dev(Sec)Ops [18] process and reviewing typical tools being used here, we can distinguish several possible things to harmonize: 57 | 58 | * Several architecture diagrams might already exist, they can potentially be re-used. These diagrams tend to need extensions for threat modeling. Most diagramming tools can handle this well. 59 | * A wiki like tool where developers put information on the sprints, stories etc. might already exist. This might be the most current version of the documentation of the system, a threat model could be considered part of that documentation. 60 | * To follow up the actions coming from a threat model (i.e. implementing approved mitigations) you should use the same ticket tracking tool used for other development activities. 61 | * The risk calculation methodology used to score security problems (for example from a penetration test) should be re-used during threat modeling so that different risks can easily be compared to each other. 62 | 63 | Make sure that the threat model tools fits within your Dev(Sec)Ops pipeline, either by re-using tools or by acquiring tools that support that process. The output of the threat model process can be viewed as development artefacts. The best example of this is to treat threat models as code. Threat modeling as code follows the trend to have everything ‘as code’. The different elements of a threat model are described, often in a text format that is both human and machine readable. From this, some of the frameworks can generate documentation, automate tests, automate the risk calculation etc. This style of threat modeling lends itself very well to continuous development practices. The threat model process will also be a continuous process with a heavy focus on tool support and integration in the development team. 64 | 65 | Treat modeling as code is not a mature field of expertise at the time of writing this document (2020). Additionally, not that many organizations are ready to do infrastructure as code, threat modeling as code etc. therefore we consider this to be an optional step in the playbook reserved for organizations with the highest level of maturity in both threat modeling practices as agile processes and tools. 66 | 67 | [<< Previous page](5.%20Strengthen%20your%20threat%20model%20proces.md) | [Main page](../README.md) | [Glossary of terms >>](7.%20Glossary%20of%20terms.md) 68 | | --- | --- | --- | 69 | 70 | [18]: 7.%20Glossary%20of%20terms.md 71 | -------------------------------------------------------------------------------- /playbook/7. Glossary of terms.md: -------------------------------------------------------------------------------- 1 | # 7 Glossary of Terms 2 | This glossary covers a list of words that are frequently used while threat modeling and their meaning. 3 | 4 | * **ASVS:** The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development. (OWASP Application Security Verification Standard, n.d.) 5 | * **Attack tree:** Attack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root node and different ways of achieving that goal as leaf nodes (Schneier, 1999) 6 | * **Azure DevOps:** Azure DevOps provides developer services to support teams to plan work, collaborate on code development, and build and deploy applications. Developers can work in the cloud using Azure DevOps Services or on-premises using Azure DevOps Server. Azure DevOps Server was formerly named Visual Studio Team Foundation Server (TFS). (What is Azure DevOps, n.d.) 7 | * **CVSS:** The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes (Common Vulnerability Scoring System SIG, n.d.) 8 | * **DevOps:** DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality 9 | * DevSecOps: DevSecOps means thinking about application and infrastructure security from the start. It also means automating some security gates to keep the DevOps workflow from slowing down. (What is DevSecOps, n.d.) 10 | * **G-suite:** G Suite—formerly known as Google Apps for Work—is a Software as a Service (SaaS) product that groups all the cloud-based productivity and collaboration tools developed by Google for businesses, institutes, and non-profits (Gavin, 2019) 11 | * **JIRA:** Jira Software is part of a family of products designed to help teams of all types manage work. Originally, Jira was designed as a bug and issue tracker. But today, Jira has evolved into a powerful work management tool for all kinds of use cases, from requirements and test case management to agile software development (What is Jira used for, n.d.) 12 | * **LINDDUN:** A privacy threat modeling methodology that supports analyst systematically eliciting and mitigating privacy threats in software architectures. LINDDUNN is a mnemonic for the privacy threat categories it supports: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance (LINDDUN privacy engineering, n.d.) 13 | * **MS teams:** Microsoft Teams is a communication and collaboration platform that combines workplace chat, video meetings, file storage, and application integration. The service integrates with the Office 365 subscription office productivity suite and features extensions that can integrate with non-Microsoft products (Microsoft Teams, 2020) 14 | * **OWASP risk rating methodology:** Risk rating methodology introduced by OWASP which approaches risk rating in six steps: Identifying a risk, factors for estimating likelihood, factors for estimating impact, determining severity of the risk, deciding what to fix, and customizing your risk rating model. 15 | * **Playbook:** A book containing a team's strategies and plays. A set of rules or suggestions that are suitable for a particular activity, industry, or job. 16 | * **SAMM:** OWASP SAMM stands for Software Assurance Maturity Model. This is an open source project from OWASP, more details are available on https://owaspsamm.org/about/ 17 | * **Security champion:** Security Champions are active members of a team that may help to make decisions about when to engage the Security Team. They act as a core element of security assurance process within the product or service and hold the role of the Single Point of Contact (SPOC) within the team. More details are available at: https://github.com/c0rdis/security-champions-playbook 18 | * Sharepoint: Organizations use Microsoft SharePoint to create websites. You can use it as a secure place to store, organize, share, and access information from different devices 19 | * **STRIDE:** a model of threats developed by Microsoft for identifying computer security threats. It provides a mnemonic for security threats in six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege 20 | * **Squad:** Similar to a scrum team, Squads are cross-functional, autonomous teams (typically 6-12 individuals) that focus on one feature area. Each Squad has a unique mission that guides the work they do, an agile coach for support, and a product owner for guidance. 21 | * **Threat Modeling:** Threat modeling is the activity of identifying and managing application risks. Also known as architectural risk analysis. 22 | 23 | 24 | [<< Previous page](6.%20Innovate%20with%20threat%20model%20technology.md) | [Main page](../README.md) | [Glossary of terms >>](8.%20References.md%20) 25 | | --- | --- | --- | 26 | -------------------------------------------------------------------------------- /playbook/8. References.md : -------------------------------------------------------------------------------- 1 | # 8. References 2 | 3 | * ABOUT US. (n.d.). Retrieved from OWASPP SAMM: https://owaspsamm.org/ 4 | * c0rdis. (2020, January 21). security champions playbook. Retrieved from https://github.com/c0rdis/security-champions-playbook 5 | * Common Vulnerability Scoring System SIG. (n.d.). Retrieved from First: https://www.first.org/cvss/ 6 | * Gavin, B. (2019, November 12). What is G Suite, Anyway? Retrieved from howtogeek: https://www.howtogeek.com/411808/what-is-g-suite-anyway/ 7 | * (2018). ISO/IEC 27005. ISO. Retrieved from Wikipedia: https://en.wikipedia.org/wiki/ISO/IEC_27005 8 | * Juuso, S. (2019, May). Evaluation of Threat Modeling. JAMK University of Applied Sciences. 9 | * LINDDUN privacy engineering. (n.d.). Retrieved from LINDDUN: https://www.linddun.org/ 10 | * Microsoft Teams. (2020, 9 8). Retrieved from Wikipedia: https://en.wikipedia.org/wiki/Microsoft_Teams 11 | * OWASP Application Security Verification Standard. (n.d.). Retrieved from OWASP: https://owasp.org/www-project-application-security-verification-standard/ 12 | * Schneier, B. (1999). Attack Trees. Dr. Dobb's Journal. 13 | * What is Azure DevOps. (n.d.). Retrieved from microsoft docs: https://docs.microsoft.com/nl-nl/azure/devops/user-guide/what-is-azure-devops?view=azure-devops 14 | * What is DevSecOps. (n.d.). Retrieved from redhat: https://www.redhat.com/en/topics/devops/what-is-devsecops 15 | * What is Jira used for. (n.d.). Retrieved from atlassian: https://www.atlassian.com/software/jira/guides/use-cases/what-is-jira-used-for 16 | * Yskout, K., Sion, L., Heyman, T., Wuyts, K., Van Landuyt, D., & Joosen, W. (2020, May 23). Threat modeling: from infancy to maturity. International Conference on Software Engineering. Seoul, South Korea: Institute of Electrical and Electronics Engineers. Retrieved from https://lirias.kuleuven.be/2947593 17 | 18 | [<< Previous page](7.%20Glossary%20of%20terms.md| [Main page](../README.md) 19 | | --- | --- | 20 | -------------------------------------------------------------------------------- /playbook/test.md: -------------------------------------------------------------------------------- 1 | # Keys to successful privacy threat modeling 2 | 3 | 4 | 5 | Privacy is important! This has been underlined by the GDPR and other data protection legislation that entered into force in the past years and that highlight the need for privacy integration in the software development lifecycle. 6 | 7 | The privacy-by-design principle requires privacy to be included early on in the development lifecycle. But how can this be done in practice? Threat modeling, a systematic approach to reason about what can go wrong in a system, has proven its value in security engineering, and is equally useful for privacy. To get the most out of your privacy threat modeling experience, there are however some simple, yet important, rules you should take into account. 8 | 9 | The key aspects listed below follow from our experiences with [LINDDUN](https://www.linddun.org), however they are applicable to privacy threat modeling in general, independent of the specific approach or knowledge base that you want to apply. 10 | 11 | > *[LINDDUN](https://www.linddun.org) provides a structured process for threat modeling enriched with an extensive privacy knowledge base. It was inspired by Microsoft’s STRIDE and therefore roughly shares the same steps yet focusing on the 7 privacy threat categories that are contained in its acronym (i.e. linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, non-compliance). [LINDDUN GO](https://www.linddun.org/go) is the recently launched light-weight variant.* 12 | 13 | 14 | 15 | 16 | 17 | ### 1 - Understand what privacy is about 18 | 19 | Privacy is not a synonym for confidentiality. Clearly, protecting access to data in general is an important aspect to ensure privacy, but in essence it remains a security property. Even a perfectly secure system (if that would even exist) could still violate the privacy of its users. Privacy is more concerned about what can be done with the data once someone has access to them (whether this was intentional or not) and what can be done to prevent this. 20 | 21 | [LINDDUN](https://www.linddun.org) encapsulates and supports 7 privacy threat categories: 22 | 23 | - **Linkability** - Two (or more) items of interest can be linked, even without knowing the identity of the data subject(s) involved. 24 | 25 | - **Identifiability** - A data subject can be identified from a set of data subjects through an item of interest. 26 | 27 | - **Non-repudiation** - The data subject is unable to deny a claim (e.g. having performed an action or sent a request). 28 | 29 | - **Detectability** - It is possible to distinguish whether an item of interest about a data subject exists or not, regardless of being able to read the contents itself. 30 | 31 | - **Disclosure of information** - An adversary is able to learn the content of an item of interest about a data subject. 32 | 33 | - **Unawareness** - The data subject is unaware of, or unable to intervene in, the collection, processing, storage, or sharing activities (and corresponding purposes) of the data subject’s personal data, and their own rights related to these data. 34 | 35 | - **Non-compliance** - The processing, storage, or handling of personal data is not compliant with legislation, regulation and/or policy. 36 | 37 | In addition to LINDDUN, you might find other privacy taxonomies useful, such as [Solove’s privacy taxonomy](https://www.law.upenn.edu/journals/lawreview/articles/volume154/issue3/Solove154U.Pa.L.Rev.477(2006).pdf), [Hansen et al.’s privacy goals](https://www.computer.org/csdl/pds/api/csdl/proceedings/download-article/17D45WXIkFp/pdf) (i.e. intervenability, transparency, linkability), and [NIST’s privacy engineering objectives](https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf) (i.e. predictability, manageability, disassociability). 38 | 39 | 40 | 41 | ### 2 - Get rid of your security mindset 42 | 43 | This is probably the most challenging one for those who are familiar with (security) threat modeling. While the essence of threat modeling (i.e. think about what can go wrong in a structured way) remains the same and there is a strong dependency between privacy and security, privacy threat modeling approaches the system from a different perspective. **Rather than protecting *your* assets, privacy is about protecting the data subjects’ data and their right to privacy.** Not only (external) attackers can bring harm, also the system itself can misbehave and violate a person’s privacy. Therefore, you need to think about it with the data subject in mind and also critically reflect on the actions the system is performing on the personal data. For instance, do we need *all* these data or is a subset sufficient? What are the consequences of storing or sharing this dataset and what will (other) people be able to ‘learn’ from it? 44 | 45 | 46 | 47 | ### 3 - Find the approach that suits your needs 48 | 49 | There are different ways to actually apply privacy threat modeling. Even within a single framework, method or knowledge base, execution can vary. 50 | 51 | LINDDUN has 3 main variants to elicit privacy threats: 52 | 53 | - **Full-fledged threat modeling** (‘*full’ [LINDDUN](https://www.linddun.org/linddun)*) - Inspired by STRIDE (as described by [Howard&Lipner](https://download.microsoft.com/download/8/1/6/816C597A-5592-4867-A0A6-A0181703CD59/Microsoft_Press_eBook_TheSecurityDevelopmentLifecycle_PDF.pdf)), LINDDUN provides systematic support to elicit and mitigate privacy threats. In summary, each system component (i.e. DFD element) needs to be examined with the LINDDUN threat categories in mind to determine whether threats apply. To help elicit these threats, LINDDUN provides privacy threat trees which describe the most common privacy threat types. *This variant is most suited for those looking for an extensive analysis with strong traceability of the process they executed.* 54 | 55 | * **Acronym-based brainstorming** (*LINDDUN as mnemonic*) – At the other end of the spectrum is a more freestyle type of exercise. In practice, people sometimes only use the LINDDUN categories as input for a brainstorming session. While this highly reduces the effort required, it also reduces the systematicity and traceability of the process. In addition, the output solely depends on the threat modeler’s (privacy) expertise. *This variant is therefore most suited for an experienced threat modeler who is looking for a quick, rather than an exhaustive, result.* 56 | * **Guided light-weight threat modeling** *([LINDDUN GO](https://www.linddun.org/go))* - LINDDUN GO aims to bridge the gap between the previous two variants by combining the best of both worlds. Inspired by the [Elevation of Privilege cards](https://www.microsoft.com/en-us/download/details.aspx?id=20303), LINDDUN GO provides light-weight support by reducing the complexity of both the threat modeling process and the provided privacy knowledge while still maintaining systematicity and extensive knowledge support. *This variant is thus suited for people who are relatively new to the field, as well as for those who prefer more light-weight support in general.* 57 | 58 | Overall, the less (privacy) expertise you have, the more you will need to find support in a threat modeling method and its corresponding knowledge base. 59 | 60 | 61 | 62 | **To conclude, remember that privacy isn’t the same as security, hence you should also approach it differently. LINDDUN provides you with different approaches, from informal to systematic, that can support you in doing so.** 63 | --------------------------------------------------------------------------------