Presentation is loading. Please wait.

Presentation is loading. Please wait.

Threat Modelling part 1 General introduction to Application and Infrastructure Threat Modelling Jon R. Wall Security / IA Microsoft Corp.

Similar presentations


Presentation on theme: "Threat Modelling part 1 General introduction to Application and Infrastructure Threat Modelling Jon R. Wall Security / IA Microsoft Corp."— Presentation transcript:

1 Threat Modelling part 1 General introduction to Application and Infrastructure Threat Modelling Jon R. Wall Security / IA Microsoft Corp.

2 Agenda Intro Overview of SDL SDL in detail Threat Modeling Applications Threat Modeling Networks

3 Light Reading Developer / Manager focused Security Books Pragmatic view Actionable Security vs. Security Theater

4 “An Inconvenient Truth!” All software has security defects! Yes, EVERYONE (yes, that includes YOU!) Present development models cannot deliver secure software Microsoft introduced the Security Development Lifecycle (SDL) to remedy this problem No-one else has changed their processes Yet they continue to have major security defects

5 Another “Inconvenient Truth!” Improving quality does not improve security You MUST focus on security to raise security

6 One More “Inconvenient Truth!” There is a lot of GREAT material available to help build more secure software However, the state of the art certainly isn’t the state of the practice

7 What is the SDL? A set of product-development process agnostic security and privacy-related process improvements that increase security and privacy It’s not about fixing bugs, it’s about reducing the number of bugs you enter into the system in the first place

8 What the SDL is NOT! A panacea or silver bullet Security is “human vs. human” There is ongoing security research There will always be vulnerabilities SDL is a long-term vision Over time we will reduce vulnerability count and severity SDL will not eliminate all vulnerabilities

9 “We actually consider Microsoft to be leading the software [industry] now in improvements in their security development life cycle [SDL].” John Pescatore Vice President and Distinguished Analyst Gartner, Inc (From CRN, Feb 13 th 2006) Security Development Lifecycle Demonstrating Results

10 The Book

11 Security Development Lifecycle

12 Education On-going security education required for all engineers Raise awareness, set expectations Learn to not make mistakes! Writing Secure Code 2nd is required reading 5

13 Education Example classes: Security Basics Reviewing Code for Security Bugs Implementing Threat Mitigations Classes of Defects Secure Design Principles Using Crypto Web-related Security Bugs Fuzzing Threat Modeling Many, many more… Have all staff review the ‘Basics’ on the SDL book CD. Train all your engineering staff. Read some good security books. 5

14 The Bigger Picture Quality Gates Security,Privacy, Reliability, etc… PREfast FxCop SAL Banned API check BO checks I/O checks Crypto Yearly Training Yearly Training Peer Review Central PREfix (etc) runs SWI & External Review Threat Model s Pentest Fuzz Tests

15 Threat Modeling Critical to building secure software Required for all SDL products to ship We’ve learned a great deal about making TMs easier to create TM Tool available for download on msdn.microsoft.com 9

16 THREAT MODELING

17 Why Threat Modeling? To find security design flaws!

18 Vision Define Scenarios & Background Define the most common and realistic use scenarios for the application Example from Windows Server 2003 and Internet Explorer “Think about an admin browsing the Internet from a Domain Controller” Example from Windows CE “The stolen device” Define your users

19 Model the Application with DFDs A Data Flow Diagram (DFD) is a graphical representation of how data enters, leaves, and traverses your component It is not a Class Diagram or Flow Chart! Shows all data sources and destinations Shows all relevant processes that data goes through Good DFDs are critical to the process This point can’t be emphasised enough! Building DFDs == understanding the system Analysing DFDs == understanding the threats

20 Model the Application with DFDs Most “whiteboard architectures” are DFD-like External Entity Process Complex-Process Data Store Dataflow PrivilegeBoundary

21 Privilege Boundaries Specific DFD addition to TMs Boundary between DFD elements with different privilege levels Machine boundary (data from the other machine could be anonymous) Integrity boundary (Low  Medium trust) Process boundary (e.g.; User process  SYSTEM process) Kernel  User mode

22 Types of DFDs Context Diagram Very high-level; entire component / product / system Level 0 Diagram High level; single feature / scenario Level 1 Diagram Low level; detailed sub-components of features Level n Diagram Even more detailed; unlikely to go beyond Level 2

23 A Real Context Diagram (Castle)

24 A Real Level-0 DFD (Castle)

25 DFD Element Threat Types Each DFD element (Asset) is susceptible to certain kinds of threats SpoofingTamperingRepudiation Information Disclosure Denial of Service Elevation of Privilege

26 What is Repudiation? Something you probably won’t need to worry too much about! Usually involves policies (read: you’ll need a lawyer) Mitigate with Non-repudiation techniques Non-repudiation services generate evidence which will help a disinterested party that a specific subject performed a specific action Evidence of Origination, Submission & Receipt

27 Every Asset is Subject to Attack How are each of these elements protected?

28 Determining Threats Prime Threat Based on DFD asset type Secondary Threat Based on threat trees Related issues

29 Prime Threats by Asset Type External Entity Process Data Store Dataflow STRIDESTRIDESTRIDESTRIDE        Asset 

30 Threat Trees A graphical representation of security-relevant pre-conditions in a system First outlined in Amoroso’s “Fundamentals of Computer Security Technology” Based on hardware fault trees There are many “threat tree patterns”

31 Threat Tree Pattern Example Spoofing Primary Threat Each leaf is a secondary threat to be evaluated

32 A Special Note about Information Disclosure threats All information disclosure threats are potential privacy issues. Raising the Risk. Is the data sensitive or PII?

33 Calculating Risk with Numbers DREAD etc. Very subjective Often requires the analyst be a security expert On a scale of 0.0 to 1.0, just how likely is it that an attacker could access a private key? Where do you draw the line? Do you fix everything above 0.4 risk and leave everything below as “Won’t Fix”?

34 Calculating Risk with Heuristics Simple rules of thumb Derived from the MSRC bulletin rankings

35 Security Risk Rankings (Examples) Critical Run malicious code Most ‘E’ vulns Important Denial of service against a server And now it’s dead Moderate Server DoS that stops once attack stops Low DoS against a client

36 Mitigating Threats Options: Leave as-is Remove from product Remedy with technology countermeasure Warn user

37 Mitigation Techniques Threat Mitigation Feature SpoofingAuthentication TamperingIntegrity RepudiationNonrepudiaton Information Disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization

38 An Example: Castle

39 Assumptions and Scenarios Home environment only, non-domain, 10 machines max Abby is the user Relying on the OS for most security technology

40 Castle Level-0 DFD

41 Castle DFD Elements External Entities (SR) 1

42 Castle DFD Elements Processes (STRIDE) 2, 3, 4 & 8

43 Castle DFD Elements Data Stores (TID and possibly R) 5, 6 & 7

44 Castle DFD Elements Data Flows (TID) [1  2, 2  1] [2  3, 3  2] etc

45 Spoofing “The other end” Threat Spoofing Remote Castle Service Example “I’m castle, honest!” Mitigation ??

46 Tamper with ‘Bits’ on disk Threat Tampering with Castle Service Example Replace bits on disk with rogue Mitigation Good ACL, Signature

47 Denial of Service against Castle Threat Castle no longer responds Example Flood RPC endpoint Mitigation Require authn

48 Priv Elev against Castle Threat Bug in design/code leads to EoP Example No need, you will have bugs! Mitigation Run in lower priv/drop privs

49 Info Disc of data flow Castle-Castle Threat View sensitive data on network Example Use network sniffer Mitigation RPC with encryption

50 Threat Modeling Learn to model your threats Pick a simple product you build Model it and learn to apply the process to other products

51 A Critical Lesson Defenses are as important as code and design quality Because you will never get the code and design 100% correct The Animated Cursor coding vulnerability we fixed in MS was in Vista But Vista customers were protected from real exploits because of operating system defenses

52 Why the DNS Zero-Day Did not Exploit Windows “Longhorn” Server beta 2 The coding vulnerability was in the code The attacker had to: Get passed the firewall Bypass /GS Bypass SafeSEH Bypass NX Bypass ASLR Bypass stack randomization Bypass service hardening And the attacker has only two attempts Because of service restart policy

53 Using Tools Tools DO NOT MAKE CODE SECURE! They help scale the process They help enforce policy Common tools: PREfastSALFxCopAppVerifCodeCoverage Constantly upgrading our compilers to add new defenses 21

54 Testing Fuzz all data formats you consume 100,000 malformed iterations per parser (clean!) Build a fuzzing layer into your network applications Malform outgoing data at random 12 “Microsoft is applying a lot of the technologies used by security researchers in house, making the third-party techniques not as effective.”, Pedram Amini, TippingPoint, Oct 2007

55 Fuzz Testing Random fuzzing Toggle high bits Flip adjacent bytes Write random data Search for ASCII/Unicode chars then set the training NULL to non-NULL Truncate data stream Smart fuzzing Make sizes and offsets huge, small, negative

56 Testing (cont) Inventory your file parsers Inventory your network end points Use a file fuzzer to fuzz the parsers with >100,000 malformed files Build a rogue layer into your network code Build protocol fuzzers CD

57 Final Security Review Mandatory ship requirement for products covered by SDL Can last up to 10 weeks for some products Process for the “big products” includes: External (non-Microsoft) review Code review Penetration work Architecture & Design review Threat model review Bug review Exit Criteria “Explicit signoff from SEC that the products have successfully completed the FSR and the product team has addressed any requirements derived from the results.” 14

58 Post-Bulletin Process Every defect in every bulletin is subject root cause analysis How finder found defect (if known) Code diff (if applicable) Design weakness statement (if applicable) What code, test or defense could have found and/or mitigated the defect How the defect affected different platforms Action items and recommendations 17 Learn from your mistakes Build unit tests when you find errors

59 Threat Modelling part 2 Application and Infrastructure Threat Modelling Jon R. Wall Security / IA Microsoft Corp.

60 “An Inconvenient Truth!” All software has security defects! Yes, EVERYONE (yes, that includes YOU!) Present development models cannot deliver secure software Microsoft introduced the Security Development Lifecycle (SDL) to remedy this problem No-one else has changed their processes Yet they continue to have major security defects

61 The Bigger Picture Quality Gates Security,Privacy, Reliability, etc… PREfast FxCop SAL Banned API check BO checks I/O checks Crypto Yearly Training Yearly Training Peer Review Central PREfix (etc) runs SWI & External Review Threat Model s Pentest Fuzz Tests

62 Final Security Review Mandatory ship requirement for products covered by SDL Can last up to 10 weeks for some products Process for the “big products” includes: External (non-Microsoft) review Code review Penetration work Architecture & Design review Threat model review Bug review Exit Criteria “Explicit signoff from SEC that the products have successfully completed the FSR and the product team has addressed any requirements derived from the results.” 14

63 Post-Bulletin Process Every defect in every bulletin is subject root cause analysis How finder found defect (if known) Code diff (if applicable) Design weakness statement (if applicable) What code, test or defense could have found and/or mitigated the defect How the defect affected different platforms Action items and recommendations 17 Learn from your mistakes Build unit tests when you find errors

64 © 2004, Microsoft Corporation, All Rights Reserved Defense in Depth Threat Modeling is one part of a Defense in Depth strategy Supplement it with other measures People, Policies, & Procedures OS hardening, patch management, authentication, HIDS Firewalls, VPN quarantine Guards, locks, tracking devices Network segments, IPSec, NIDS Application hardening, antivirus ACL, encryption User education Physical Security Perimeter Internal Network Host Application Data

65 © 2004, Microsoft Corporation, All Rights Reserved Lessons Learned From Experience Most security tweaks do not improve security Security changes without a threat model do not improve security Focus is often on the wrong thing Analysis of target environment is essential Threat model must correlate with security policy Group policy is a bonus Careful smoke-testing needed

66 © 2004, Microsoft Corporation, All Rights Reserved Applying the lessons - DSR Document Model applications and services Environment dependent SegmentApplications Security requirements Restrict Disable services Close ports Use IPSec or RRAS filters Use different passwords

67 © 2004, Microsoft Corporation, All Rights Reserved Document

68 Communicate The Design

69 © 2004, Microsoft Corporation, All Rights Reserved Network Segmentation Segment systems by application and security requirements Should you trust systems that are not part of your application? Which systems do they trust? What are their security requirements? Less sensitive systems may depend on more sensitive systems More sensitive systems MUST NEVER depend on less sensitive systems

70 © 2004, Microsoft Corporation, All Rights Reserved End Goal

71 © 2004, Microsoft Corporation, All Rights Reserved Documenting Segments

72 © 2004, Microsoft Corporation, All Rights Reserved Trust Boundaries Systems and entities you trust are included within your trust boundary Never share administration and accounts across boundaries Should your trust boundary include databases? It depends…

73 © 2004, Microsoft Corporation, All Rights Reserved Trust Boundaries

74 © 2004, Microsoft Corporation, All Rights Reserved Restrict

75 Restrict Policies allow nothing but… Disable unnecessary services Remove users Restrict privileges Turn on security tweaks Remove permissions Set very strong passwords Restrict communications IPSec RRAS filters

76 © 2004, Microsoft Corporation, All Rights Reserved Manage Administrative Dependencies An administrator on any given machine can run code as any user logging on to that machine What other machines do your admins log on to? Who administers those machines Administrative dependencies balloon – fast! Enumerating actual administrators is hard

77 © 2004, Microsoft Corporation, All Rights Reserved How Many Admins Do You Have?

78 © 2004, Microsoft Corporation, All Rights Reserved Limit Service Account Trust Environment Any admin can retrieve service account credentials Service accounts frequently have Administrative privileges… …on several machines Implements the “least common security denominator” Consider security needs NetworkService and LocalService are useful, to a point

79 © 2004, Microsoft Corporation, All Rights Reserved Consider your needs first

80 Remote Exchange Access: IT Perspective 1. Client enters OWA URL in IE 2. Smartcard logon to ISA 3. ISA requests a Kerberos ticket 4. ISA uses ticket to impersonate client 7. BE Exchange validates ticket 6. FE Exchange uses ticked to request mail 8. Client mail sent to FE Exchange 10. ISA proxies OWA to client 9. OWA page sent to ISA 5. FE Exchange validates ticket Remote client with smartcard ISA 2006 Front-End Exchange w/ Forefront for Exchange Back-End Exchange w/ Forefront for Exchange Domain Controller

81 Threat Types - STRIDE Each DFD element (Asset) is susceptible to certain kinds of threats SpoofingTamperingRepudiation Information Disclosure Denial of Service Elevation of Privilege

82 What is Repudiation? Something you probably won’t need to worry too much about! Usually involves policies (read: you’ll need a lawyer) Mitigate with Non-repudiation techniques Non-repudiation services generate evidence which will help a disinterested party that a specific subject performed a specific action Evidence of Origination, Submission & Receipt

83 Prime Threats by Asset Type External Entity Process Data Store Dataflow STRIDESTRIDESTRIDESTRIDE        Asset 

84 Put The Right Things In The Right Place

85

86

87 QUESTIONS?


Download ppt "Threat Modelling part 1 General introduction to Application and Infrastructure Threat Modelling Jon R. Wall Security / IA Microsoft Corp."

Similar presentations


Ads by Google