Jon R. Wall Security / IA Microsoft Corp.

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

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

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

“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

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

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

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

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

Security Development Lifecycle Demonstrating Results
“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 13th 2006)

The Book

Security Development Lifecycle
Security Training Use Security Development Tools and Security Best Dev and Test Practices Create Security Docs and Tools For Product Security Push Prepare Security Response Plan Final Security Review Security Servicing and Response Execution Security Kickoff and Register with SWI Security Arch and Attack Surface Review Security Design Best Practices Pen Testing Threat Modeling Traditional Microsoft Software Product Development Lifecycle Tasks and Processes Testing and Verification Feature Lists Quality Guidelines Arch Docs Schedules Design Specifications Code Signing A Checkpoint Express Signoff RTM Product Support Service Packs/ QFEs Security Updates Functional Specifications Development of New Code Bug Fixes Design Implementation Verification Release Requirements Support and Servicing

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

Education 5 Example classes: Secure Design Principles 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.

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

Threat Modeling 9 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

Threat Modeling

To find security design flaws!
Why Threat Modeling? To find security design flaws!

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

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 DFDs should be completed before the threat modelling meeting. The PM and the dev should work together to get it into good shape and distribute it to the team in advance of the meeting. Data flows across trust boundaries are where the bad stuff gets in and causes the really nasty bugs (elevation of privilege, denial of service, etc.) and where the good stuff leaks out (information disclosure / privacy). Flows across other kinds of boundaries (eg machine boundaries) are also interesting if the communication channel is not secure Once inside the trusted system, look for defence-in-depth measures (sanity checking, verification, auditing, etc) to help reduce the impact of bugs in other parts of the system

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

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

Types of DFDs Context Diagram Level 0 Diagram Level 1 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

A Real Context Diagram (Castle)

A Real Level-0 DFD (Castle)

DFD Element Threat Types
Each DFD element (Asset) is susceptible to certain kinds of threats Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege CIA is Confidentiality, Integrity & Availability Spoofing identity Spoofing threats allow an attacker to pose as another user or allow a rogue server to pose as a valid server. An example of user identity spoofing is illegally accessing and then using another user's authentication information, such as username and password. A good real-life example is an insecure authentication technique, such as HTTP Authentication: Basic and Digest Access Authentication (RFC2617). If Fletcher can view Blake's username and password in the HTTP Authorization header, he can replay the username and password to access secured data as if he were Blake. Examples of server spoofing include DNS spoofing and DNS cache poisoning. A good example of this is a reported vulnerability in Apple Computer's SoftwareUpdate software. Read about the vulnerability at news.com.com/ html if you're unfamiliar with the concepts of attacking DNS servers; the article includes a useful overview of DNS spoofing and DNS cache poisoning. Tampering with data Data tampering involves malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet. A real-life example includes changing data in a file protected with a weak ACL, such as Everyone (Full Control), on the target computer. Repudiation Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performing an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation is the ability of a system to counter repudiation threats. For example, if a user purchases an item, he might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package. As you can imagine, nonrepudiation is important for e-commerce applications. Information disclosure Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, a user's ability to read a file that she was not granted access to and an intruder's ability to read data in transit between two computers. The spoofing example shown earlier is also an example of an information disclosure threat because to replay Blake's credentials, Fletcher must view the credentials first. Denial of service Denial of service (DoS) attacks deny service to valid users— for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability. A very real example of this includes the various distributed denial of service attacks (DDoS), such as Trinoo and Stacheldraht. You can learn more about these attacks at staff.washington.edu/dittrich/misc/ddos/. Elevation of privilege In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed. An example is a vulnerable computer system that allows an attacker to place an executable on the disk and then to wait for the next person to log on to the system. If the next user is an administrator, the malicious code also runs as an administrator.

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

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

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

Prime Threats by Asset Type
S T R I D E External Entity         Process     Data Store    Dataflow

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”

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

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

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”?

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

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

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

Mitigation Techniques
Threat Mitigation Feature Spoofing Authentication Tampering Integrity Repudiation Nonrepudiaton Information Disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization

An Example: Castle

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

Castle Level-0 DFD

Castle DFD Elements External Entities (SR)
1

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

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

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

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

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

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

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

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

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

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

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

Using Tools 21 Tools DO NOT MAKE CODE SECURE!
They help scale the process They help enforce policy Common tools: PREfast SAL FxCop AppVerif CodeCoverage Constantly upgrading our compilers to add new defenses

Testing 12 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 “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

Fuzz Testing Random fuzzing Smart 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

Testing (cont) CD 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

Final Security Review 14 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.”

Post-Bulletin Process
17 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 Learn from your mistakes Build unit tests when you find errors

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

“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

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

Final Security Review 14 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.”

Post-Bulletin Process
17 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 Learn from your mistakes Build unit tests when you find errors

People, Policies, & Procedures
Defense in Depth Threat Modeling is one part of a Defense in Depth strategy Supplement it with other measures People, Policies, & Procedures Physical Security A security strategy for an organization is most effective when data is protected by more than one layer of security. A defense in depth security strategy utilizes multiple layers of defense so that if one layer is compromised, it does not necessarily follow that your entire organization will be compromised. A defense in depth strategy increases an attacker’s risk of detection and reduces an attacker’s chance of success. To minimize the possibility of a successful attack against your organization’s servers, you need to implement the appropriate level of defense at each layer. There are many ways to protect each individual layer by using tools, technologies, policies, and best practices. For example: Policies, Procedures, and Awareness layer – Security education programs for users Physical Security layer – Security guards, locks, and tracking devices Perimeter layer – Hardware and/or software firewalls, and virtual private networks with quarantine procedures Internet Network layer – Network segmentation, IP Security (IPSec), and network intrusion detection systems Host layer – Server and client hardening practices, patch management tools, strong authentication methods, and host-based intrusion detection systems Application layer – Application hardening practices and antivirus software Data layer – Access Control Lists and encryption This session focuses on securing your Windows-based servers. Security methods and practices discussed in this session relate primarily to the Application, Host, and Internal Network layers. However, it is important to keep in mind that server security should form only part of the overall security strategy of your organization. Data ACL, encryption Application Application hardening, antivirus OS hardening, patch management, authentication, HIDS Host Internal Network Network segments, IPSec, NIDS Perimeter Firewalls, VPN quarantine Guards, locks, tracking devices User education © 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 © 2004, Microsoft Corporation, All Rights Reserved

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

Communicate The Design
Purpose is to communicate what the environment looks like Use well understood modeling techniques Modified Data flow diagrams Threat trees Verbose documentation © 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 © 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… © 2004, Microsoft Corporation, All Rights Reserved

Restrict Policies allow nothing but… Restrict communications
Disable unnecessary services Remove users Restrict privileges Turn on security tweaks Remove permissions Set very strong passwords Restrict communications IPSec RRAS filters © 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 © 2004, Microsoft Corporation, All Rights Reserved

How Many Admins Do You Have?

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 © 2004, Microsoft Corporation, All Rights Reserved

Consider your needs first

Remote Exchange Access: IT Perspective
Domain Controller 3. ISA requests a Kerberos ticket 7. BE Exchange validates ticket 5. FE Exchange validates ticket Back-End Exchange w/ Forefront for Exchange This is a build slide that requires 10 clicks to progress through the solution. Start by pointing out each of the elements (remote client, ISA 2006 cluster, front-end and back-end Exchange, Forefront for Exchange, and domain controllers) then walk through the build: Client enters the OWA URL into Internet Explorer, this URL resolves to the IP address of the ISA 2006 cluster (ISA is scaled out using Network Load Balancing) ISA requests the client’s SSL certificate, which has been stored on their smartcard. The user enters their smartcard’s PIN so that IE can forward the certificate to the ISA server ISA contacts the domain controller in order to verify that the certificate is valid for that user account. Once verified the DC sends the ISA server a Kerberos ticket for accessing the front-end Exchange server in the user’s name. ISA uses Kerberos Constrained Delegation to impersonate the user while presenting the user’s Kerberos ticket to the front-end Exchange server. The front-end server validates the user’s Kerberos ticket and requests a new ticket for the user to use with the back-end Exchange server. The front-end Exchange server asks the back-end server for access to the user’s mailbox using the second Kerberos ticket. The back-end server validates the second Kerberos ticket by contacting the domain controller. The back-end Exchange server sends the user’s mail to the front-end server. The front-end server renders the OWA HTML page containing the user’s mail and send it to the ISA 2006 server. The ISA server proxies OWA by forwarding the OWA HTML page to the user’s remote PC. 4. ISA uses ticket to impersonate client 6. FE Exchange uses ticked to request mail 1. Client enters OWA URL in IE 2. Smartcard logon to ISA Remote client with smartcard Front-End Exchange w/ Forefront for Exchange 8. Client mail sent to FE Exchange 10. ISA proxies OWA to client 9. OWA page sent to ISA ISA 2006

Threat Types - STRIDE Each DFD element (Asset) is susceptible to certain kinds of threats Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege CIA is Confidentiality, Integrity & Availability Spoofing identity Spoofing threats allow an attacker to pose as another user or allow a rogue server to pose as a valid server. An example of user identity spoofing is illegally accessing and then using another user's authentication information, such as username and password. A good real-life example is an insecure authentication technique, such as HTTP Authentication: Basic and Digest Access Authentication (RFC2617). If Fletcher can view Blake's username and password in the HTTP Authorization header, he can replay the username and password to access secured data as if he were Blake. Examples of server spoofing include DNS spoofing and DNS cache poisoning. A good example of this is a reported vulnerability in Apple Computer's SoftwareUpdate software. Read about the vulnerability at news.com.com/ html if you're unfamiliar with the concepts of attacking DNS servers; the article includes a useful overview of DNS spoofing and DNS cache poisoning. Tampering with data Data tampering involves malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet. A real-life example includes changing data in a file protected with a weak ACL, such as Everyone (Full Control), on the target computer. Repudiation Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performing an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation is the ability of a system to counter repudiation threats. For example, if a user purchases an item, he might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package. As you can imagine, nonrepudiation is important for e-commerce applications. Information disclosure Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, a user's ability to read a file that she was not granted access to and an intruder's ability to read data in transit between two computers. The spoofing example shown earlier is also an example of an information disclosure threat because to replay Blake's credentials, Fletcher must view the credentials first. Denial of service Denial of service (DoS) attacks deny service to valid users— for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability. A very real example of this includes the various distributed denial of service attacks (DDoS), such as Trinoo and Stacheldraht. You can learn more about these attacks at staff.washington.edu/dittrich/misc/ddos/. Elevation of privilege In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed. An example is a vulnerable computer system that allows an attacker to place an executable on the disk and then to wait for the next person to log on to the system. If the next user is an administrator, the malicious code also runs as an administrator.

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

Prime Threats by Asset Type
S T R I D E External Entity         Process     Data Store    Dataflow

Put The Right Things In The Right Place
.NET = Interoperability

4/9/2017 9:17 AM Mitigations User Spoofing is addressed by the use of Smart Card Authentication and Repudiation is addressed with Smart card use with S/MIME. ISA Spoofing is address by the use of SSL, Tampering is addressed by the use of SSL, Repudiation is not a requirement for this process, Information Disclosure is addressed by the combination of SSL, Smart card authentication to Active Directory, Kerberos and Authorization, Denial of Services can be addressed with clustering, Elevation of privilege is addressed by the combination of Smart Card authentication to Active Directory, Kerberos, Authorization, and constrained delegation. ©2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

4/9/2017 9:17 AM Mitigations As the diagram details the Data Flows between the user and ISA can be subject to Tampering, Information Disclosure and Denial of Service. Tampering is addressed with SSL, Information Disclosure is addressed by SSL, and Denial of Service can be addressed by many techniques and is driven by the customer environment and is there for outside the bounds of this document. ©2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

QUESTIONS?

Jon R. Wall Security / IA Microsoft Corp.

Similar presentations

Presentation on theme: "Jon R. Wall Security / IA Microsoft Corp."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Jon R. Wall Security / IA Microsoft Corp.

Similar presentations

Presentation on theme: "Jon R. Wall Security / IA Microsoft Corp."— Presentation transcript:

Similar presentations

About project

Feedback