Threat Modeling: Applied on a Publish-Subscribe Architectural Style
Download as PPTX, PDF2 likes1,110 views
The document discusses threat modeling, particularly within a publish-subscribe architectural style, emphasizing the importance of identifying security issues early in the software development process. It provides an overview of threat modeling techniques and methodologies, such as creating data flow diagrams and leveraging the STRIDE framework to categorize potential threats. Additionally, it outlines mitigation strategies and highlights the need for systematic approaches to enhance security in software architectures.
Threat Modeling: Applied on a Publish-Subscribe Architectural Style
- 1. Threat Modeling: Applied on a Publish- Subscribe Architectural Style Dr. Dharma Ganesan, Ph.D., dharmalingam.ganesan11@gmail.com 1
- 2. Disclaimer The views expressed in the slides are my own and not of my employer 2
- 3. Context of the Slides • I was a Lecturer for “Secure Software Testing and Construction” course (Fall 2015) –at University of Maryland, College Park • Threat modeling was introduced to graduate students of this course –Hands-on approach to modeling and security 3
- 4. Agenda • Threat Modeling – Introduction –First 30 slides are from a threat modeling book –Got permission from the author of the book •https://threatmodelingbook.com/ • Applying it on a simplified real-world system –Publish-Subscribe architectural style –Software Enterprise Bus • Conclusion 4
- 5. Wouldn’t it be better to find security issues before we write a line of code? So how can we do that? 5
- 6. Ways to Find Security Issues • Static analysis of code • Fuzzing or other dynamic testing • Pen test/red team • Wait for bug reports after release • These issues are detected later in the process 6
- 7. Ways to Find Security Issues (2) • Threat modeling! – Think about security issues early – Understand our requirements better – Don’t write security bugs into the code 7
- 8. So…how do we threat model? 8
- 9. How to Threat Model (Summary) • What are we building? • What can go wrong? • What are we going to do about it? 9
- 10. What Are We Building? • Create a model of the software/system/technology • A model abstracts away the details so you can look at the whole – Diagraming is a key approach – Mathematical models rare in commercial environs • Software models for threat modeling usually focus on data flows and boundaries • DFDs, “swim lanes,” state machines can all help (next slides) 10
- 11. DFD (Data Flow Diagram) • Developed in the early 70s, and still useful – Simple: easy to learn, sketch – Threats often follow data • Abstracts programs into: – Processes: your code – Data stores: files, databases, shared memory – Data flows: connect processes to other elements – External entities: everything but your code & data. Includes people & cloud software – Trust boundaries now made explicit 11
- 12. Data Flow Diagram (Example) 12
- 13. Swim Lane Diagrams • Show two or more entities communicating, each “in a lane” • Useful for network communication • Lanes have implicit boundaries between them 13
- 14. State Machines • Helpful for considering what changes security state – For example, unauthenticated to authenticated – User to root/admin • Rarely shows boundaries 14
- 15. How to Threat Model (Summary) • What are we building? • What can go wrong? • What are we going to do about it? 15
- 16. What Can Go Wrong? • Fun to brainstorm • Mnemonics, trees or libraries of threats can all help structure thinking • Structure helps get you towards completeness and predictability • STRIDE is a mnemonic – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege – Easy, right? 16
- 17. Spoofing By Lego Envy, http://www.eurobricks.com/forum/index.php?showtopic=64532 17
- 19. RepudiationRepudiation By Seb H http://www.flickr.com/photos/88048956@N04/8531040850/ 19
- 21. Denial of Service Model by Nathan Sawaya http://brickartist.com/gallery/han-solo-in-carbonite/ 21
- 23. STRIDE Threat Property Violated Definition Example Spoofing Authentication Impersonating something or someone else. Pretending to be any of Bill Gates, Paypal.com or ntdll.dll Tampering Integrity Modifying data or code Modifying a DLL on disk or DVD, or a packet as it traverses the network Repudiation Non-repudiation Claiming to have not performed an action. “I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that web site, dear!” Information Disclosure Confidentiality Exposing information to someone not authorized to see it Allowing someone to read the Windows source code; publishing a list of customers to a web site. Denial of Service Availability Deny or degrade service to users Crashing Windows or a web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole. Elevation of Privilege Authorization Gain capabilities without proper authorization Allowing a remote internet user to run commands is the classic example, but going from a limited user to admin is also EoP. 23
- 24. Using STRIDE • Consider how each STRIDE threat could impact each part of the model – “How could a clever attacker spoof this part of the system?...tamper with?… etc.” • Easier with aids – Elevation of Privilege game – Attack trees (see Threat Modeling: Designing for Security, Appendix B) – Experience 24
- 25. What Can Go Wrong? • Track issues as we find them – “attacker could pretend to be a client & connect” • Track assumptions – “I think that connection is always over SSL” • Both lists are inputs to “what are we going to do about it” 25
- 26. How to Threat Model (Summary) • What are we building? • What can go wrong? • What are we going to do about it? 26
- 27. What Are You Going to Do About It? • For each threat: – Fix it! – Mitigate with standard or custom approaches – Accept it? – Transfer the risk? • For each assumption: – Check it – Wrong assumptions lead to reconsider what goes wrong 27
- 28. Fix It! • The best way to fix a security bug is to remove functionality – For example, if SSL doesn’t have a “heartbeat” message, the “heartbleed bug” couldn’t exist – You can only take this so far – Oftentimes end up making risk tradeoffs • Mitigate the risk in various ways (next slide) 28
- 29. Mitigate • Add/use technology to prevent attacks • For example, prevent tampering: – Network: Digital signatures, cryptographic integrity tools, crypto tunnels such as SSH or IPsec • Developers, sysadmins have different toolkits for mitigating problems • Standard approaches available which have been tested & worked through • Sometimes you need a custom approach 29
- 30. Some Technical Ways to Address Threat Mitigation Technology Developer Example Sysadmin Example Spoofing Authentication Digital signatures, Active directory, LDAP Passwords, crypto tunnels Tampering Integrity, permissions Digital signatures ACLs/permissions, crypto tunnels Repudiation Fraud prevention, logging, signatures Customer history risk management Logging Information disclosure Permissions, encryption Permissions (local), PGP, SSL Crypto tunnels Denial of service Availability Elastic cloud design Load balancers, more capacity Elevation of privilege Authorization, isolation Roles, privileges, input validation for purpose, (fuzzing*) Sandboxes, firewalls * Fuzzing/fault injection is not a mitigation, but a great testing technique See chapter 8, Threat Modeling for more 30
- 31. Agenda • Threat Modeling – Introduction • Applying it on a simplified real-world system • Conclusions 31
- 32. Can we identify threats of this sample architecture? 32 The system we analzed is quite similar to this architectural style
- 33. Threat modeling of a bus • A software bus for component/application communication • Ideal for developing distributed systems • Publish-subscribe architectural style –Components publish messages –The bus routes the messages to subscribers based on the message subject/topic •Let us enumerate STRIDE for this architecture 33
- 34. Input artifacts to our review • Software architecture • API documentation • Test cases • Source code 34
- 35. S - Spoofing (sample threats) • We reviewed the initial design and APIs • It turned out that is no method for verifying the authenticity of the bus, another system could impersonate the bus, responding to calls as if it were the bus. • This could be mitigated by using a system of authentication (e.g. public key cryptography) between the applications and the bus. 35
- 36. S - Spoofing (sample) •An unauthorized application could impersonate another application by publishing messages which would normally be published only by a particular application. •An attacker could unsubscribe legitimate applications from the bus. •These issues could be mitigated by using authentication and authorization controls 36
- 37. T - Tampering (sample) • Because the messages are not encrypted, messages can be intercepted and modified. • For example, while a legitimate application tries to subscribe to a particular topic the message is intercepted and the subscriber is subscribed to a different topic. • This could be mitigated by encrypting messages between the applications and the bus. 37
- 38. R - Repudiation (sample) • There does not appear to be any method to enforce non-repudiation in the system. • For example, there does not appear to be any logging of published messages, or tracking of who originally sent messages • It would be possible for someone to create a fake message and say that it was a published message received from the bus. 38
- 39. R - Repudiation (sample) • An application could also claim that it published a message when in fact it did not do so. • Alternatively (or in addition), messages could be digitally signed and timestamped so as to guarantee the sender and recipient of the data, and the time of the occurrence. 39
- 40. I - Information Disclosure (sample) • The APIs show no evidence of encryption of data- in-transit • Because messages are not encrypted, it is possible to eavesdrop on the messages sent between the bus and the applications. • This could be mitigated through encryption. 40
- 41. I - Information Disclosure (sample) •An application could subscribe to the topic “.*” (a regular expression for “everything”), thereby matching all messages destined for all applications. •This would be a way for an evil application to view all messages without even knowing the available topics. •Since XML is the messaging format, xml entity injection could be used to steal files 41
- 42. I - Information Disclosure (sample) •This could be mitigated by adding some restrictions to wildcard usage of message subjects •Or by limiting the set of message subjects to a pre- defined set rather than allowing regular expressions. 42
- 43. D - Denial of Service (sample) • An application could prevent other applications from accessing the bus by impersonating the bus and sending disconnect messages to other applications. • Similarly, an application could send unsubscribe messages to prevent the other applications from receiving data. 43
- 44. D - Denial of Service (sample) •Because messages are in XML, the system may be vulnerable XML bombs which may crash the bus –This could be mitigated by carefully ensuring proper parsing of inputs to the bus. •An application can make too many connections to the bus. –This could be mitigated by limiting the # of connections 44
- 45. E - Elevation of Privilege (sample) • It may be possible to craft a particular XML input which would be incorrectly parsed – For example, XML injection to run remote code • Large messages may trigger buffer overflows and remote code execution – This could be mitigated by introducing appropriate compiler flags • (e.g. DEP prevention, stack canaries, etc) – Of course, length check in the source code, too 45
- 46. Deriving security requirements using threat modeling - (sample) • Based on the threats described above, below are recommended high-level security requirements for the software bus: 1) All traffic between the bus and the applications must be encrypted using strong encryption. 2) There must be mutual authentication between the bus and each application. 46
- 47. Deriving security requirements using threat modeling - (sample) 3) Messages transmitted between the bus and the applications should be digitally signed and timestamped in order to prevent repudiation and spoofing. 4) The bus should contain a whitelist of applications which are allowed to subscribe to particular applications. This will prevent information disclosure by ensuring that messages are only seen by the proper applications. 47
- 48. Conclusion • Threat Modeling using STRIDE helps in identifying security requirements • STRIDE facilitates systematic enumeration of threats based on software architecture • For every architectural style, the list of threats and mitigation strategies can be reused! 48
- 49. Conclusion ... • An organization could build a library of threats for each architectural style • The identified threats become security bugs to address • 4 questions to remember –What are you building? – What can go wrong? – What are you going to do about it – Checking your work •Reference: https://threatmodelingbook.com 49
- 50. Acknowledgment • Mr. Caudill Nathan (Cyber Security Graduate) –For working out the details using STRIDE • Mr. Adam Shostack https://threatmodelingbook.com/ 50