1 / 54

Threat Modeling

Threat Modeling. Terminology. Protected Resources / Asset: Things to protect (tangible or intangible) Entry/Exit Points: Ways to get at an asset Threat: Risks to an asset Attack / exploit : An action taken that harms an asset Vulnerability : Specific ways to execute the attack

amora
Download Presentation

Threat Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Threat Modeling

  2. Terminology • Protected Resources / Asset: Things to protect (tangible or intangible) • Entry/Exit Points: Ways to get at an asset • Threat: Risks to an asset • Attack / exploit: An action taken that harms an asset • Vulnerability: Specific ways to execute the attack • Risk: Likelihood that vulnerability could be exploited • Mitigation / Countermeasure: Something that addresses a specific vulnerability We can mitigate vulnerabilities… …but the threat still exists!!!

  3. Terminology Example • Entry/Exit Points: • Front & Side Doors • Windows (guest bedroom & elsewhere in residence • Note vulnerability can be shared across attacks(!) • Asset(s): • $5,000,000 under the mattress in guest bedroom • Threat(s): • Loosing the $5,000,000

  4. QUESTION… • ASSUMING you could engage in repeated (destructive) testing… • How would you test the mitigation of each of the vulnerabilities? • During Development? At deployment? Over time?

  5. Terminology Example (Cont’d) • Lets apply some mitigations to our vulnerabilities • QUESTION: How would you test the effectiveness of each mitigation? • BIGGER QUESTION: How would verify the mitigation effectiveness beyond initial deployment???

  6. KEY POINT: The threat doesn’t go away!!! • Ways I can defeat each of those mitigations: • User Invites Tracy Monteith into home, Tracy sees the lumpy mattress, investigates, leaves abruptly and is last seen heading to the Bahamas to “retire” • That is… I bypass all of the security measures explicitly with someone I “trust” (its’ Tracy, big mistake there, eh? ) • User forgets to lock the door / windows (nobody notices)Smoke detector batteries expire (nobody notices) • That is… Is your mitigation still turned on past deployment? (A: Auditing / Logging / Ongoing Verification Testing) • What about a meteor (vaporizing house and asset!) • That is… there will always be “new” attacks around the corner!

  7. Your Threat Model / Test Plan is a living document! • Testing during development / deployment isn’t enough • Mitigations may have vulnerabilities themselves • Although you should probably take this into account when calculating the initial risk reduction for the mitigation

  8. Sometimes, though, the mitigation may not map 1:1 to a vulnerability or an attack… but applies to the THREAT • Consider… • Depositing $5,000,000 in a bank account • Cost: Not good, have to pay Uncle Sam $38% • Risk: FICA only insures up to ~ $100,000 (???) • Mitigate: by depositing $100,000 in ~30 banks (after tax) • Try a safe deposit box! • Cost: Better, and Uncle Sam doesn’t know what’s in the box! • Risk: Could still be robbed (harder though, requires random luck that the burglar opens your box) • Mitigate: Take out insurance to cover risk (compensates for loss of asset)

  9. One more term to define… • Trust Boundaries: Boundaries that surround the asset and require a specified degree of trust to access • GREAT PLACE TO TEST! Code Red, SQL Slammer, Blaster, etc. were all cases of allowing un-validated user input to cross into privileged trust boundaries

  10. Two types of Security Issues (to model / test) • And before we begin on threat modeling itself: • Input trust issues • Everything else!

  11. Threat Modeling Methodologies • All basically saying the same thing • Some differences in terminology • Some differences reflect evolution over last 2 years)2 Years Old 1 year old +/- 2 weeks old

  12. 3 Phases of Threat Modeling • Define: The first phase defines security centric information which is used later to model threats • Model: The second phase constructs Threat Events • Analyzing and prioritizing decomposition • Measure Threats: The third phase assesses probability, impact, risk, and cost and value of mitigation • Measuring Risk (DREAD) value before and after Mitigation • Documenting estimated costs of Mitigation • Allows DREAD delta comparison to Mitigation cost

  13. Entry Points Roles and Identities Assets Threat Modeling Process(Writing Secure Code + Threat Modeling) Collect Model the Determine Background System Threats Information Use Scenarios External Identify Threats Dependencies Implementation Assumptions Analyze Threats / Determine Trust Levels External Security Vulnerabilities Notes Data Flow Diagrams / Process Internal Security Models Notes

  14. USE SCENERIOS Actor User, Admin, Hacker, Someone Interaction Authenticates, Requests, Writes, Reads Service IIS, SQL, WS, etc. EXTERNAL DEPENDENCIES Feeds Inbound (Pull) <implies trust> Outbound (Push) Feedstore vs. External Vendor? Applications Who consumes your service Environments Extranet vs. Intranet vs. Internet Defining the System

  15. IMPLEMENTATION ASSUMPTIONS Platform W2K vs. W2K3 vs. ??? Technologies SQL 2000 vs. ??? Protocols SSL vs. IPSec Standards Known mitigating factors from Design Time EXTERNAL SECURITY NOTES What do external entities need to be aware of in the context of security with regards to your application? Who depends on your application? Can they trust your outbound feed(s)? Who do they need to contact re: security? INTERNAL SECURITY NOTES Document security strategy notes Priorities Challenges Exceptions Constraints Defining the System (Cont’d)

  16. Entry Points Roles and Identities Assets Threat Modeling Process(Writing Secure Code + Threat Modeling) Collect Model the Determine Background System Threats Information Use Scenarios External Identify Threats Dependencies Implementation Assumptions Analyze Threats / Determine Trust Levels External Security Vulnerabilities Notes Data Flow Diagrams / Process Internal Security Models Notes

  17. ENTRY POINTS Services IIS, SQL, MSMQ, File, WS Object or Classes DLLs, Tables, Views, etc Methods Procedures, Routines etc ASSETS Both concrete and abstract, that could be targets of an attack A concrete example might be corporate data stored in a database. A more abstract example might be network coherency in a peer to peer application. Assets should be nouns. Modeling the System

  18. ROLES AND IDENTITIES This allows the ability to define what roles exist in the application Allow identification of what authentication mechanism is used Also allow weighting of groups to assess impact and opportunity due to size of population TRUST LEVELS Trust levels characterize either entry points or assets. Entry points describe the external entity that can interface with the entry point. Assets indicate what privilege level would normally be able to access the resource. The type of trust level is specific to the entry point or protected resource Modeling the System (Cont’d)

  19. Modeling the System (Cont’d) DATA FLOW / DECOMPISITION • Time to break down the application • During initial design we don’t know much detail so we typically only go to the service level and partially identify ‘logical’ objects • We record this decomposition as “Entry Points”; components where an entity interfaces within the application

  20. IIS6 Context Diagram

  21. IIS6 Level-0 DFD

  22. Entry Points Roles and Identities Assets Threat Modeling Process(Writing Secure Code + Threat Modeling) Collect Model the Determine Background System Threats Information Use Scenarios External Identify Threats Dependencies Implementation Assumptions Analyze Threats / Determine Trust Levels External Security Vulnerabilities Notes Data Flow Diagrams / Process Internal Security Models Notes

  23. Threat Profile • Where to BEGIN? • By Network / Server / Application • Document your assumptions / Service Level Agreements(!) • By Technology / Service • By type of threat (CIA)

  24. Threat Profile (Alternate View)From: Improving Web Application Security—Threats and Countermeasures

  25. For each threat… • What are the conditions that allow the threat to take place (THREAT TREES) • What are the attacks? • How would you classify the attack (STRIDE) • What are the ENTRY / EXIT Points? • What protected resources / assets are exposed? • Enumerate vulnerabilities that allow the attack • Evaluate RISK before mitigation… …evaluate risk after mitigation …how would you verify / test the mitigation?

  26. Threat Trees

  27. Threat Modeling Tool

  28. Summary • Threat Modeling Toolhttp://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx • A quality threat model should feed directly into your test plans • Validating the mitigation (as intended) • Testing the mitigation (in ways not intended) • No matter what mitigation you choose, the threat to the asset doesn’t go away!!!

  29. Questions?

  30. Boneyard (Risk Analysis/DREAD)

  31. Calculation of Risk(How does DREAD do this?) • Risk = Impact * Probability • Impact = (DREAD) • Damage • Note that Damage needs to be assessed in terms of Confidentiality, Integrity and Availability • Affected Users (how large is the user base affected? • Probability = (DREAD) • Reproducibility (how difficult to reproduce? Is it scriptable?) • Exploitability (how difficult to use the vulnerability to effect the attack?) • Discoverability (how difficult to find?)

  32. Calculation of Risk (Cont’d) • Let’s establish a few assumptions • In the Risk equation; Damage and Probability are equally important • The factors, as well as the result should have mathematical value (in order to assist in easily determining priorities) • Therefore in any formula giving each factor equal weight an imbalance occurs giving Probability a 3:2 representation over Damage • To mitigate: • e.g. Risk = Impact(D+A) * Probability(R+E+D) • while ensuring the summary of qualitative scales for Risk and Probability are equal (e.g. D+A=(1-10) & R+E+D=(1-10) which results in a scale of 6-100 when the summation of factors are multiplied

  33. Damage • Damage has 3 categories and each has been given it’s own value ranking • Confidentiality (Read) • Vulnerability or exposure of sensitive data or process (e.g. application or business logic) • Integrity (Write) • Compromise of application or system data integrity (e.g. log tampering, data modification) • Availability • Degradation or denial of service

  34. Damage

  35. Affected Users

  36. Reproducibility

  37. Exploitability

  38. Discoverability

  39. A new spin on DREAD • Use DREAD to calculate • The risk before mitigation • The risk after mitigation • The cost of implementing the mitigation AND the cost to maintain the mitigation • NOW you can make an accurate assessment of the best mitigation for a given vulnerability!!! • Example: Using SSL or IPSec to secure IIS – SQL Server • SSL: Low cost to turn on, but can easily be turned off (what is the cost to validate the mitigation over time? • IPSec: High cost to turn on initially, but low maintenance cost + INCREASED SECURITY • Perf impact on both machines, but Accelerator cards can easily mitigate this

  40. Boneyard (Misc)

  41. S Spoofing identity T Tampering with data R Repudiability I Information disclosure D Denial of service E Elevation of privilege STRIDE • Use STRIDE in several scenarios to identify the categories of threat

  42. An alternate taxonomy(Patterns and Practices group)

  43. Big Issues • There are two types of security issues • Input trust issues • Everything else! • Buffer Overruns • Integer Overflow Attacks • Non-admin issues

  44. How common are BOs? Approx 33% of bulletins remedy BOs Source: Vendor Web sites, 01Jan03 –31Dec03

  45. Healthy stack Pass big buffer buff SFP ret szData Hand-crafted code Pointer to start of buffer Stack after attack Execute from here on function return!  Exploiting the overrun

  46. CIA (Defensive Goals) Confidentiality (who can read what) Integrity (who can write what) Availability (who can access what) Breaking Apart the System Secure the Network Secure the Host/Server Secure the Application DREAD (Measure of Risk) Damage (Impact) Reproducibility (Probability) Exploitability (Probability) Affected Users (Impact) Discoverability (Probability) Terms

  47. Buffer overrun example: Index Server ISAPI (Code Red) // cchAttribute is the character count of user input WCHAR wcsAttribute[200]; if ( cchAttribute >= sizeof wcsAttribute) THROW( CException( DB_E_ERRORSINCOMMAND ) ); DecodeURLEscapes( (BYTE *) pszAttribute, cchAttribute, wcsAttribute,webServer.CodePage()); ... void DecodeURLEscapes( BYTE * pIn, ULONG & l, WCHAR * pOut, ULONG ulCodePage ) { WCHAR * p2 = pOut; ULONG l2 = l; ... for( ; l2; l2-- ) { // write to p2 based on pIn, up to 12 bytes

  48. Buffer overrun example: Code Red // cchAttribute is the character count of user input WCHAR wcsAttribute[200]; if ( cchAttribute >= sizeof wcsAttribute / sizeof WCHAR) THROW( CException( DB_E_ERRORSINCOMMAND ) ); DecodeURLEscapes( (BYTE *) pszAttribute, cchAttribute, wcsAttribute,webServer.CodePage()); ... void DecodeURLEscapes( BYTE * pIn, ULONG & l, WCHAR * pOut, ULONG ulCodePage ) { WCHAR * p2 = pOut; ULONG l2 = l; ... for( ; l2; l2-- ) { // write to p2 based on pIn, up to 12 bytes FIXED!

  49. Copies buffer from the network until ‘\’ char found Sitting on port 135 – The Internet Buffer Overrun ExamplesDCOM Remote Activation (MS03-026) error_status_t _RemoteActivation(..., WCHAR *pwszObjectName, ... ) { *phr = GetServerPath( pwszObjectName, &pwszObjectName); ... } HRESULT GetServerPath(WCHAR *pwszPath, WCHAR **pwszServerPath ){ WCHAR * pwszFinalPath = pwszPath; WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]; hr = GetMachineName(pwszPath, wszMachineName); *pwszServerPath = pwszFinalPath; } HRESULT GetMachineName( WCHAR * pwszPath, WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]) { pwszServerName = wszMachineName; LPWSTR pwszTemp = pwszPath + 2; while ( *pwszTemp != L'\\' ) *pwszServerName++ = *pwszTemp++;... }

More Related