Approach to Threat Modeling PDF

Approach to Threat Modeling The Process in a Nutshell Diagram Identify Validate Threats Mitigate The Process: Diagramming Diagram Identi...

Approach to Threat Modeling The Process in a Nutshell Diagram Identify Validate Threats Mitigate The Process: Diagramming Diagram Identify Validate Threats Mitigate How to Create Diagrams Go to the whiteboard Start with an overview which has: – A few external interactors – One or two processes – One or two data stores (maybe) – Data flows to connect them Check your work – Can you tell a story without edits? – Does it match reality? Diagramming Use DFDs (Data Flow Diagrams) – Include processes, data stores, data flows – Include trust boundaries – Diagrams per scenario may be helpful Update diagrams as product changes Enumerate assumptions, dependencies Number everything (if manual) Diagram Elements: Examples Externa Data Process Flow Data Store l Entity People DLLs Function call Database Other systems EXEs Network traffic File Microsoft.com COM object Remote Registry Components Procedure Call Shared Services (RPC) Memory Web Services Queue / Stack Assemblies Trust Boundary Process boundary File system Diagrams: Trust Boundaries Add trust boundaries that intersect data flows Points/surfaces where an attacker can interject – Machine boundaries, privilege boundaries, integrity boundaries are examples of trust boundaries – Threads in a native process are often inside a trust boundary, because they share the same privs, rights, identifiers and access Processes talking across a network always have a trust boundary – They make may create a secure channel, but they’re still distinct entities – Encrypting network traffic is an ‘instinctive’ mitigation But doesn’t address tampering or spoofing 7 Diagram Iteration Iterate over processes, data stores, and see where they need to be broken down How to know it “needs to be broken down?” – More detail is needed to explain security impact of the design – Object crosses a trust boundary – Words like “sometimes” and “also” indicate you have a combination of things that can be broken out “Sometimes this datastore is used for X”…probably add a second datastore to the diagram Context Diagram Resource integrity information iNTegrity App Administrator Analysis Instructions Level 1 Diagram Diagram layers Context Diagram – Very high-level; entire component / product / system Level 1 Diagram – High level; single feature / scenario Level 2 Diagram – Low level; detailed sub-components of features Level 3 Diagram – More detailed – Rare to need more layers, except in huge projects or when you’re drawing more trust boundaries Creating Diagrams: analysis or Top down synthesis? – Gives you the “context” in context diagram – Focuses on the system as a whole – More work at the start Bottom up – Feature crews know their features – Approach not designed for synthesis – More work overall Diagram Validation Rules of Thumb Diagram Validation Rules of Thumb Does data magically appear? Order Customer Web Server SQL Database Confirmation Data comes from external entities or data stores Diagram Validation Rules of Thumb Are there data sinks? Transaction Analytics Web Server SQL Server Database You write to a store for a reason: Someone uses it. Diagram Validation Rules of Thumb Data doesn’t flow magically Order Database Returns Database Diagram Validation Rules of Thumb It goes through a process Order Database RMA Returns Database Diagrams Should Not Resemble Flow charts Class diagrams Call graphs Real Context Diagram (“Castle”) Castle Config Castle Config Join/Leave Castle Local Castle Remote User Service Castle Feedback Feedback Castle Level 1 Diagram SSDP SSDP SSDP SSDP 10 Registry 8 8 10 7 Get version Get version info info Set version Set version Cache Castle Cache Castle info info Query other Query other info info Castle info Castle info Read Read Castle info Castle info Publish this Publish this Castle info Castle info Manage Manage Local Castle Castle Explorer Explorer Manage Manage User Local User (or rundl132) (or rundll32) Castle Castle Join, leave, Join, leave, Remote 11 Feedback 2 Castle Set Set users props users props Feedback 2 Castle Feedback Feedback Service Service Castle Query users props Service Service 38 Query users 9 props 9 Set Set acct info acct info Get machine Get machine Get acctinfo Get acct info password password Set psswd Set psswd Shacct Shacct 4 4 LSA 6 Setacct Set acct Get acct Get acct info Info info info SAM 5 The Process: Identifying Threats Diagram Identify Validate Threats Mitigate Identify Threats Experts can brainstorm How to do this without being an expert? – Use STRIDE to step through the diagram elements – Get specific about threat manifestation Threat Property we want Spoofing Authentication Tampering Integrity Repudiation Nonrepudiation Information Disclosure Confidentiality Denial of Service Availability Threat: Spoofing Threat Spoofing Property Authentication Definition Impersonating something or someone else Example Pretending to be any of billg, microsoft.com, or ntdll.dll Threat: Tampering Threat Tampering Property Integrity Definition Modifying data or code Example Modifying a DLL on disk or DVD, or a packet as it traverses the LAN Threat: Repudiation Threat Repudiation Property Non-Repudiation Definition Claiming to have not performed an action Example “I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that Web site, dear!” Threat: Information Disclosure Threat Information Disclosure Property Confidentiality Definition Exposing information to someone not authorized to see it Example Allowing someone to read the Windows source code; publishing a list of customers to a Web site Threat: Denial of Service Threat Denial of Service Property Availability Definition Deny or degrade service to users Example Crashing Windows or a Web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole Threat: Elevation of Privilege Threat Elevation of Privilege (EoP) Property Authorization Definition Gain capabilities without proper authorization Example Allowing a remote Internet user to run commands is the classic example, but going from a “Limited User” to “Admin” is also EoP Different Threats Affect Each Element Type ELEMENT S T R I D E External   Entity Process       Data Store  ?   Data Flow     Apply STRIDE Threats to Each Element For each item on the diagram: – Apply relevant parts of STRIDE – Process: STRIDE – Data store, data flow: TID Data stores that are logs: TID+R – External entity: SR – Data flow inside a process: Don’t worry about T, I, or D This is why you number things Use the Trust boundaries Trusted/ high code reading from untrusted/low – Validate everything for specific and defined uses High code writing to low – Make sure your errors don’t give away too much Threats and Distractions Don’t worry about these threats – The computer is infected with malware – Someone removed the hard drive and tampers – Admin is attacking user – A user is attacking himself You can’t address any of these (unless you’re the OS) The Process: Mitigation Diagram Identify Validate Threats Mitigate  Mitigation Is the Point of Threat Modeling Mitigation – To address or alleviate a problem Protect customers Design secure software Why bother if you: – Create a great model – Identify lots of threats – Stop So, find problems and fix them Mitigate Address each threat Four ways to address threats 1. Redesign to eliminate 2. Apply standard mitigations What have similar software packages done and how has that worked out for them? 3. Invent new mitigations (riskier) 4. Accept vulnerability in design SDL rules about what you can accept Address each threat Standard Mitigations Spoofing Authentication To authenticate principals: Cookie authentication Kerberos authentication PKI systems such as SSL/TLS and certificates To authenticate code or data: Digital signatures Windows Vista Mandatory Integrity Controls Tampering Integrity ACLs Digital signatures Secure logging and auditing Repudiation Non Repudiation Digital Signatures Encryption Information Confidentiality ACLS Disclosure ACLs Denial of Service Availability Filtering Quotas ACLs Elevation of Privilege Authorization Group or role membership Privilege ownership Input validation  Inventing Mitigations Is Hard: Don’t do it Mitigations are an area of expertise, such as networking, databases, or cryptography Amateurs make mistakes, but so do pros Mitigation failures will appear to work – Until an expert looks at them – We hope that expert will work for us When you need to invent mitigations, get expert help Sample Mitigation Mitigation #54, Rasterization Service performs the following mitigation strategies: 1. OM is validated and checked by (component) before being handed over to Rasterization Service 2. The resources are decoded and validated by interacting subsystems, such as [foo], [bar], and [boop] 3. Rasterization ensures that if there are any resource problems while loading and converting OM to raster data, it returns a proper error code 4. Rasterization Service will be thoroughly fuzz tested (Comment: Fuzzing isn’t a mitigation, but it’s a great thing to plan as part 4) Improving Sample Mitigation: Validated-For “OM is validated and checked by [component] before being handed over to Rasterization Service” Validated for what? Be specific! – “…validates that each element is unique.” – “…validates that the URL is RFC-1738 compliant, but note URL may be to http://evil.com/ownme.html” – (Also a great external security note) The Process: Validation Diagram Identify Validate Threats Mitigate Validating Threat Models Validate the whole threat model – Does diagram match final code? – Are threats enumerated? – Minimum: STRIDE per element that touches a trust boundary – Has Test / QA reviewed the model? Tester approach often finds issues with threat model or details – Is each threat mitigated? – Are mitigations done right? Did you check these before Final Security Review? – Shipping will be more predictable  Validate Quality of Threats and Mitigations Threats: Do they: – Describe the attack – Describe the context – Describe the impact Mitigations – Associate with a threat – Describe the mitigations – File a bug Fuzzing is a test tactic, not a mitigation Validate Information Captured Dependencies – What other code are you using? – What security functions are in that other code? – Are you sure? Assumptions – Things you note as you build the threat model “HTTP.sys will protect us against SQL Injection” “LPC will protect us from malformed messages” GenRandom will give us crypto-strong randomness More Sample Mitigations Mitigation #3: The Publish License is created by RMS, and we've been advised that it's only OK to include an unencrypted e-mail address if it's required for the service to work. Even if it is required, it seems like a bad idea due to easy e-mail harvesting. Primary Mitigation: Bug #123456 has been filed against the RMS team to investigate removing the e-mail address from this element. If that's possible, this would be the best solution to our threat. Backup Mitigation: It's acceptable to mitigate this by warning the document author that their e-mail address may be included in the document. If we have to ship it, the user interface will be updated to give clear disclosure to the author when they are protecting a document. Effective Threat Modeling Meetings Develop draft threat model before the meeting – Use the meeting to discuss Start with a DFD walkthrough Identify most interesting elements – Assets (if you identify any) – Entry points/trust boundaries Walk through STRIDE against those elements Threats that cross elements/recur – Consider library, redesigns Exercise Handout Work in teams to: – Identify all diagram elements – Identify threat types to each element – Identify at least three threats – Identify first order mitigations Extra credit: Improve the diagram Identify All Elements (16 Elements) Registry 7 7.0 …and two trust Raw boundaries, which don’t Registry 8 Data 3 have threats against them iNTegrity Host 10 Raw Software 3.0 9 FS Data Commands File System 6 6.0 11 Resource Integrity Data 16 1 Instructions 2 iNTegrity Admin Admin Console 1.0 Integrity 2.0 Change Information Read Settings 13 15 12 Read Update 14 Config Data Integrity Files 4.0 5.0 4 5 Identify Threat Types to Each Element Identify STRIDE threats by element type Threats Elements ELEMENT S T R I D E   Administrator (1) External Entity Process       Admin console (2) , Host SW (3) Config data (4), Integrity data (5), Data Store     Filesystem data (6), registry (7) Data Flow    8. 9. raw reg data raw filesystem data 10. commands.... 16 Identify Threats! Be specific Understand threat and impact Identify first order mitigations Standard Mitigations STRIDE Threat Property we want Spoofing Authentication Tampering Integrity Repudiation Nonrepudiation Information Disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization Standard Mitigations STRIDE Threat Property Spoofing Authenticatio To authenticate principals: n Basic authentication Digest authentication Cookie authentication Windows authentication (NTLM) Kerberos authentication PKI systems, such as SSL or TLS and certificates IPSec Digitally signed packets To authenticate code or data: Digital signatures Message authentication codes Hashes Standard Mitigations STRIDE Threat Property Tampering Integrity Windows Vista mandatory integrity controls ACLs Digital signatures Message authentication codes Standard Mitigations STRIDE Threat Property Repudiatio Nonrepudiatio Strong authentication n n Secure logging and auditing Digital signatures Secure time stamps Trusted third parties Standard Mitigations STRIDE Threat Property Informatio Confidentiality Encryption n ACLs Disclosure Standard Mitigations STRIDE Threat Property Denial of Availability ACLs Service Filtering Quotas Authorization High-availability designs Standard Mitigations STRIDE Threat Property Elevation Authorization ACLs of Privilege Group or role membership Privilege ownership Permissions Input validation