Security for Developers Threat Modeling and the Security

Security for Developers Threat Modeling and the Security Development Lifecycle Steven Borg & Richard Hundhausen Accentient, Inc

Agenda Costs of Lax Security Common Threats Secure Coding Design Principles Threat Modeling Wrap Up

Cost of Security Threats Sabotage $ 0. 9 Million System penetration $ 0. 9 Million Web site defacement Misuse of public Web applications Telecom fraud Unauthorized access Laptop theft Financial fraud Abuse of wireless networks Insider abuse of Net access Theft of proprietary information Denial of service Viruses $ 1 Million $ 2. 7 Million $ 4. 3 Million $ 6. 7 Million $ 7. 7 Million $ 10. 2 Million $ 10. 6 Million $ 11. 5 Million $ 26. 1 Million $ 55. 1 Million

Why Security? 2002 Computer Crime and Security Survey Percentages of companies who participated in the survey Reported security breaches in the last 12 months 90% Acknowledged financial losses as a result 80% Identified Internet connection as frequent source of attacks Reported intrusions to authorities i http: //www. gocsi. com/press/20020407. html 74% 34%

How Does This Happen? Common Software Vulnerabilities Percentages of apps that have "serious design flaws" in the indicated areas 79% 73% Session management Parameter manipulation 64% 61% Access control Cryptographic algorithms Handling of sensitive data Administrative controls Input validation 41% 36% 32%

Your Dilemma Principle #1: The defender must defend all points; the attacker can choose the weakest point. Principle #2: The defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities. Principle #3: The defender must be constantly vigilant; the attacker can strike at will. Principle #4: The defender must play by the rules; the attacker can play dirty.

Trustworthy Computing Security Resilient to attack Protects confidentiality, integrity, availability and data Privacy Individuals control personal data Products and online services adhere to fair information principles Availability Reliability Business Integrity Dependable Available when needed Performs at expected levels Vendors provide quality products Product support is appropriate

Security SD 3 + Communications Secure by Design Writing Secure Code Publishing of book by same name Designing Secure Products Secure by Default Reduce attack surface area Unused features off by default Principle of least privilege Secure in Deployment Communications Patch management and installation Protect, defend, recover, manage Process: How to’s, architecture guides Clear security commitment Full member of the security community Microsoft Security Response Center

Call to Action Secure software requires knowledgeable and dedicated IT personnel Software isn't secure if the network is not Administration is the bedrock of security Secure software also requires knowledgeable and dedicated developers Proper administration is meaningless if the code you write isn't secure Most developers today don't know they're writing insecure code

Agenda Costs of Lax Security Common Threats Secure Coding Design Principles Threat Modeling Wrap Up

Types of Threats Network Host Threats against the network Spoofed packets, etc. Threats against the host Buffer overflows, illicit paths, etc. Threats against the application SQL injection, XSS, input tampering, etc. Application

Network Threats Threat Information gathering Eavesdropping Denial of service (Do. S) Spoofing Examples Port scanning Trace routing to detect network topologies Using broadcast requests to enumerate subnet hosts Using packet sniffers to steal passwords SYN floods ICMP echo request floods Malformed packets Packets with spoofed source addresses

Defending the Network Harden firewalls • Stay current with patches and updates • Block unused ports and protocols • Use filtering to reject illicit requests Harden routers and switches • Stay current with patches and updates • Use ingress/egress filtering to reject spoofed packets • Screen ICMP traffic from the internal network • Screen directed broadcast requests from the internal network • Reject trace routing requests Encrypt sensitive communications

Host Threats Threat Arbitrary code execution File disclosure Denial of service (Do. S) Unauthorized access Exploitation of open ports and protocols Examples Buffer overflows in ISAPI DLLs (e. g. , MS 01033) Directory traversal attacks (MS 00 -078) Malformed HTR requests (MS 01 -031) Virtualized UNC share vulnerability (MS 00019) Malformed SMTP requests (MS 02 -012) Malformed Web. DAV requests (MS 01 -016) Malformed URLs (MS 01 -012) Brute-force file uploads Resources with insufficiently restrictive ACLs Spoofing with stolen login credentials Using Net. BIOS and SMB to enumerate hosts Connecting remotely to SQL Server

Defending the Host Stay current with service packs and updates Harden IIS with IISLockdown and URLScan Harden the Web server's TCP/IP stack Run ASP. NET using principle of least privilege ACL resources to prevent unauthorized access Disable unused shares and services Move Web root to drive other than C:

Defending The Host Disable unused shares and services Delete nonessential shares and restrict access to others Disable nonessential services and protocols (e. g. , SMB and Net. BIOS) Remove or secure Remote Data Services (RDS) Harden user accounts Disable the Guest account Use strong passwords on all accounts Rename the administrator account Disallow null sessions (anonymous logons) Restrict remote logons to only those who need it Be aggressive about logging and auditing Log failed logon attempts Log failed actions anywhere in the system Secure IIS log files with NTFS permissions Audit access to Metabase. bin

Application Threats Threat SQL injection Examples Including a DROP TABLE command in text typed into an input field Cross-site scripting Using malicious client-side script to steal cookies Hidden-field Maliciously changing the value of a hidden tampering field Eavesdropping Using a packet sniffer to steal passwords and cookies from traffic on unencrypted connections Session hijacking Using a stolen session ID cookie to access someone else's session state Identity spoofing Using a stolen forms authentication cookie to pose as another user Information Allowing client to see a stack trace when an disclosure unhandled exception occurs

Defending the Application Never trust user input (validate!) Access databases securely Avoid vulnerabilities in forms authentication Secure ASP. NET session state Store secrets securely Anticipate errors and handle them appropriately

Agenda Costs of Lax Security Common Threats Secure Coding Design Principles Threat Modeling Wrap Up

Understand The Threats Need to understand threats to build secure applications Modeling finds different flaws than code reviews and testing Design flaws vs. implementation flaws Modeling finds flaws that might otherwise be found by attackers

Designing Secure Code Defense in Depth Secure by Design Security features != Secure features Do Not Depend on Security Through Obscurity Least Privilege Secure by Default Fail to a Secure Mode Learn from Past Mistakes

Agenda Costs of Lax Security Common Threats Secure Coding Design Principles Threat Modeling Wrap Up

Threat Modeling Structured approach to identifying, quantifying, and addressing threats Essential part of development process Just like specing and designing Just like coding and testing One technique presented here There are others (e. g. , OCTAVE)

The Threat Modeling Process 1 Identify assets 2 Document architecture 3 Decompose application 4 Identify threats 5 Document threats 6 Rate threats

1 Identifying Assets What is it that you want to protect? Private data (e. g. , customer list) Proprietary data (e. g. , intellectual property) Potentially injurious data (e. g. , credit card numbers, decryption keys) These also count as "assets" Integrity of back-end databases Integrity of the Web pages (no defacement) Integrity of other machines on the network Availability of the application

2 Documenting Architecture Define what the app does and how it's used Users view pages with catalog items Users perform searches for catalog items Users add items to shopping carts Users check out Diagram the application Show subsystems Show data flow List assets

Example Asset #1 Asset #2 Database Server Web Server Bob Bill Login Firewall Alice Asset #3 IIS ASP. NET Main State Asset #4 Asset #5 Asset #6

3 Decomposing the App Refine the architecture diagram Show authentication mechanisms Show authorization mechanisms Show technologies (e. g. , DPAPI) Diagram trust boundaries Identify entry points Begin to think like an attacker Where are my vulnerabilities? What am I going to do about them?

Example Forms Authentication URL Authorization Web Server Trust Database Server Bob Bill Login Firewall Alice IIS ASP. NET Main State DPAPI Windows Authentication

4 Identifying Threats Method #1: Threat lists Start with laundry list of possible threats Identify the threats that apply to your app Method #2: STRIDE Categorized list of threat types Identify threats by type/category Optionally draw threat trees Root nodes represent attacker's goals Trees help identify threat conditions

STRIDE S Spoofing T Tampering Can an attacker gain access using a false identity? Can an attacker modify data as it flows through the application? R Repudiation If an attacker denies an exploit, can you prove him or her wrong? I Information disclosure Can an attacker gain access to private or potentially injurious data? of service D Denial Can an attacker crash or reduce the availiability of the system? of privilege E Elevation Can an attacker assume the identity of a privileged user?

Threat Trees Theft of Auth Cookies Obtain auth cookie to spoof identity OR AND Unencrypted Connection Eavesdropping Cookies travel over unencrypted HTTP Attacker uses sniffer to monitor HTTP traffic AND Cross-Site Scripting Attacker possesses means and knowledge XSS Vulnerability Application is vulnerable to XSS attacks

Documenting Threats 5 Document threats using a template Theft of Auth Cookies by Eavesdropping on Connection Threat target Risk Attack techniques Countermeasures Connections between browsers and Web server Attacker uses sniffer to monitor traffic Use SSL/TLS to encrypt traffic Theft of Auth Cookies via Cross-Site Scripting Threat target Vulnerable application code Risk Attack techniques Countermeasures Attacker sends e-mail with malicious link to users Validate input; HTML-encode output

6 Rating Threats Simple model Risk = Probability * Damage Potential 1 -10 Scale 1 = Least probable 10 = Most probable 1 = Least damage 10 = Most damage DREAD model Greater granularization of threat potential Rates (prioritizes) each threat on scale of 1 -15 Developed and widely used by Microsoft

DREAD potential D Damage What are the consequences of a successful exploit? R Reproducibility Would an exploit work every time or only under certain circumstances? E Exploitability How skilled must an attacker be to exploit the vulnerability? users A Affected How many users would be affected by a successful exploit? D Discoverability How likely is it that an attacker will know the vulnerability exists?

DREAD, Cont. High (3) Damage potential Reproducability Exploitabilty Affected users Discoverabilty Attacker can retrieve extremely sensitive data and corrupt or destroy data Works every time; does not require a timing window Bart Simpson could do it Most or all users Attacker can easily discover vulnerability Medium (2) Low (1) Attacker can retrieve sensitive data but do little else Attacker can only retrieve data that has little or no potential for harm Timing-dependent; works only within a time window Rarely works Attacker must be somewhat knowledgeable and skilled Some users Attacker must be VERY knowledgeable and skilled Few if any users Attacker might discover the vulnerability Attacker will have to dig to discover the vulnerability

Example Threat Auth cookie theft (eavesdropping) Auth cookie theft (XSS) D R E A D Sum 3 2 3 13 3 2 2 2 3 12 Potential for damage is high (spoofed identities, etc. ) Cookie can be stolen any time, but is only useful until expired Anybody can run a packet sniffer; XSS attacks require moderate skill All users could be affected, but in reality most won't click malicious links Easy to discover: just type a <script> block into a field Prioritized Risks

Sample Threat Tree 1. 2. 1 Parse Request STRIDE Threat (Goal) Threat DREAD KEY Condition Threat Subthreat Sub threat Condition DREAD Condition

Pruning Threat Trees Threat (Goal) Subthreat Condition Mitigated Condition Subthreat

Ongoing Threat Modeling is a Design Activity Start Early Update Model Regularly New features New threats New ways of attacking systems

Microsoft Threat Modeling Tool Allows users to create threat model documents Organizes relevant data points Entry points Assets Trust levels Data Flow Diagrams Threat Trees Other Vulnerabilities Supports XML, HTML and MHT

Microsoft Threat Modeling Tool

Agenda Costs of Lax Security Common Threats Secure Coding Design Principles Threat Modeling Wrap Up

Common Defects: Trusting User Input Do Not Trust User Input Validate, Validate Look for correct data, reject all else “All input is evil, until proven otherwise” Michael Howard Microsoft Corporation

Rant Do not provide users with security warnings they must accept to get their job done!!! Users are way too Pavlovian!

Trust nothing and no one! “Don’t trust anybody. Even the people you do trust, don’t trust ‘em” – Fahrenheit 9/11 Create trust boundaries Create input choke points Authentication Validation Authorisation?

Information Disclosure Which is the better error message?

Some Things Can’t Be Avoided

Writing Secure Code Second Edition http: //www. microsoft. com/MSPress/ books/5957. asp

Resources Steve’s Blog: http: //blog. accentient. com Rich’s Blog: http: //blog. hundhausen. com MS Security: http: //www. microsoft. com/security Threat Modeling: http: //msdn. microsoft. com/security/ securecode/threatmodeling/default. aspx Security Wiki / Book: https: //www. threatsandcountermeasures. com /wiki/default. aspx

Your Feedback is Important! Please Fill Out a Survey for This Session on Comm. Net

© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.