Slide 1: Writing Secure Code – Best Practices
Name Job Title Company
Slide 2: What We Will Cover
Secure Development Process Threat Modeling Risk Mitigation Security Best Practices
Slide 3: Session Prerequisites
Development experience with Microsoft Visual Basic® , Microsoft Visual C++® , or C#
Level 200
Slide 4: Agenda
Secure Development Process Threat Modeling Risk Mitigation Security Best Practices
Slide 5: Improving the Application Development Process
Consider security
At the start of the process Throughout development Through deployment At all software review milestones
Do not stop looking for security bugs until the end of the development process
Slide 6: The SD Security Framework
3
SD3
Secure by Design
Secure architecture and code Threat analysis Vulnerability reduction Attack surface area reduced Unused features turned off by default Minimum privileges used Protection: Detection, defense, recovery, and management Process: How to guides, architecture guides People: Training
Secure by Default
Secure in Deployment
Slide 7: Secure Product Development Timeline
Analyze threats Assess security knowledge when hiring team members Determine security sign-off criteria Send out for external review Learn and refine Test for security vulnerabilities
Concept
Designs Complete
Test Plans Complete
Code Complete
Ship
Post-Ship
Train team members Perform security team review
Resolve security issues, verify code against security guidelines Test for data mutation and least privilege
=ongoing
Slide 8: Secure By Design
Raise security awareness of design team
Use ongoing training Challenge attitudes - “What I don’t know won’t hurt me” does not apply!
Get security right during the design phase
Define product security goals Implement security as a key product feature Use threat modeling during design phase
Slide 9: Agenda
Secure Development Process Threat Modeling Risk Mitigation Security Best Practices
Slide 10: What Is Threat Modeling?
Threat modeling is a security-based analysis that:
Helps a product team understand where the product is most vulnerable Evaluates the threats to an application Aims to reduce overall security risks Finds assets Uncovers vulnerabilities Identifies threats Should help form the basis of security design specifications
Slide 11: Benefits of Threat Modeling
Helps you understand your application better Helps you find bugs Identifies complex Vulnerability design bugs Helps integrate new team members Threat Asset Drives well-designed security test plans
Slide 12: The Threat Modeling Process
Threat Modeling Process 1 Identify Assets 2 Create an Architecture Overview 3 Decompose the Application 4 Identify the Threats 5 Document the Threats 6 Rate the Threats
Slide 13: Threat Modeling Process
Step 1: Identify Assets
Build a list of assets that require protection, including:
Confidential data, such as customer databases Web pages System availability Anything else that, if compromised, would prevent correct operation of your application
Slide 14: Threat Modeling Process
Identify what the application does Create an application architecture diagram
File Authorization NTFS Permissions URL Authorization .NET Roles (Authentication) (Authentication) Trust Boundary IIS
Microsoft ASP.NET
Step 2: Create An Architecture Overview
User-Defined Role (Authentication) Trust Boundary ASPNET (Process Identity) IPSec (Private/Integrity) Microsoft Windowsr Authentication
Alice Mary Bob
Microsoft SQL Server™
SSL (Privacy/Integrity) Anonymous Forms Authentication Authentication
Identify the technologies
Slide 15: Threat Modeling Process
Break down the application Create a security profile based on traditional areas of vulnerability Examine interactions between different subsystems Use DFD or UML diagrams
Step 3: Decompose the Application
Identify Trust Boundaries
Identify Data Flow
Identify Entry Points
Identify Privileged Code
Document Security Profile
Slide 16: Threat Modeling Process
Step 4: Identify the Threats
Assemble team Identify threats
Network threats Host threats Application threats
Slide 17: Threat Modeling Process
Types of threats
Identify the Threats by Using STRIDE
Examples
Forging e-mail messages Replaying authentication packets Altering data during transmission Changing data in files Deleting a critical file and deny it Purchasing a product and deny it Exposing information in error messages Exposing code on Web sites Flooding a network with SYN packets Flooding a network with forged ICMP packets Exploiting buffer overruns to gain system privileges Obtaining administrator privileges illegitimately
Spoofing Tampering Repudiation Information
disclosure
Denial of service Elevation of privilege
Slide 18: Threat Modeling Process
Identify the Threats by Using Attack Trees
1.0 View payroll data (I) 1.1 Traffic is unprotected (AND) 1.2 Attacker views traffic Threat #1 (I) 1.2.1 Sniff traffic with protocol analyzer View payroll data 1.2.2 Listen to router traffic 1.2.2.1 Router is unpatched (AND) 1.2.2.2 Compromise router 1.1 1.2 Traffic is Attacker views 1.2.2.3 Guess router password unprotected traffic 1.2.1 Sniff traffic with protocol analyzer 1.2.2.1 Router is unpatched 1.2.2 Listen to router traffic 1.2.2.2 Compromise router 1.2.2.3 Guess router password
Slide 19: Threat Modeling Process
Step 5: Document the Threats
Document threats by using a template:
Threat Description Threat target Risk Attack techniques Countermeasures Injection of SQL Commands
Data Access Component Attacker appends SQL commands to user name, which is used to form a SQL query Use a regular expression to validate the user name, and use a stored procedure with parameters to access the database
Leave Risk blank (for now)
Slide 20: Threat Modeling Process
Step 6: Rate the Threats
Use formula:
Risk = Probability * Damage Potential
Use DREAD to rate threats
Damage potential Reproducibility Exploitability Affected users Discoverability
Slide 21: Threat Modeling Process
Example: Rate the Threats
Threat #1 (I) View payroll data •Damage potential •Affected Users -or•Damage
1.1 Traffic is unprotected
1.2 Attacker views traffic
1.2.1 Sniff traffic with protocol analyzer
1.2.2 Listen to router traffic
•Reproducibility •Exploitability •Discoverability -or•Chance
1.2.2.3 Guess router password
1.2.2.1 Router is unpatched
1.2.2.2 Compromise router
Slide 22: Coding to a Threat Model
Use threat modeling to help
Determine the most “dangerous” portions of your application Prioritize security push efforts Prioritize ongoing code reviews Determine the threat mitigation techniques to employ Determine data flow
Slide 23: Agenda
Secure Development Process Threat Modeling Risk Mitigation Security Best Practices
Slide 24: Risk Mitigation Options
Option 1: Do Nothing Option 2: Warn the User Option 3: Remove the Problem Patrolled Option 4: Fix It
Slide 25: Risk Mitigation Process
Threat Type (STRIDE)
1. Identify category For example: Spoofing
Mitigation Technique
Mitigation Technique
1.
Select techniques For example: Authentication or Protect secret data Choose technology For example: Kerberos
Technology
Technology
Technology
Technology NTLM X.509 certs PGP keys Basic Digest Kerberos SSL/TLS
1.
Spoofing
Authentication
Slide 26: Sample Mitigation Techniques
SSL/TLS IPSec RPC/DCO with Privacy
STRIDE STRIDE
Insecure Network
Configuration Data
STRIDE
Strong access control Digital signatures Auditing
Client
Firewall Limiting resource utilization for anonymous connections
IDE TR S
Server
Authentication Data
Persistent Data
STRIDE
Slide 27: Agenda
Secure Development Process Threat Modeling Risk Mitigation Security Best Practices
Slide 28: Run with Least Privilege
Well-known security doctrine:
“Run with just enough privilege to get the job done, and no more!”
Elevated privilege can lead to disastrous consequences
Malicious code executing in a highly privileged process runs with extra privileges too Many viruses spread because the recipient has administrator privileges
Slide 29: Demonstration 1
ASP.NET Applications Security
Investigating ASP.NET Application Privileges Restricting ASP.NET Applications Trust Levels Sandboxing Privileged Code Using Sandboxed Assemblies
Slide 30: Reduce the Attack Surface
Expose only limited, well documented interfaces from your application Use only the services that your application requires
The Slammer and CodeRed viruses would not have happened if certain features were not on by default ILoveYou (and other viruses) would not have happened if scripting was disabled
Turn everything else off
Slide 31: Do Not Trust User Input
Validate all input
Assume all input is harmful until proven otherwise Look for valid data and reject everything else
Constrain, reject, and sanitize user input with
Type checks Length checks Range checks Format checks
Validator.ValidationExpression =
"\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*";
Slide 32: Demonstration 2
Windows Forms Validation
Viewing a Non-Validating Application Adding Input Validation Validating the Complete Form
Slide 33: Defense in Depth (1 of 3)
Use Multiple Gatekeepers
SQL Server ISA Firewall
IPSec
IIS
ISA Firewall
SSL
Slide 34: Defense in Depth (2 of 3)
Check security Check security
Application.dll
Apply Appropriate Measures for Each Layer
Application.exe
Check security
Application.dll
Secure resource with an ACL
Check security
Slide 35: Defense in Depth (3 of 3)
Use Strong ACLs on Resources
Design ACLs into the application from the beginning Apply ACLs to files, folders, Web pages, registry settings, database files, printers, and objects in Active Directory Create your own ACLs during application installation Include DENY ACEs Do not use NULL DACLs
Slide 36: Do Not Rely on Security by Obscurity
Do not hide security keys in files Do not rely on undocumented registry keys Always assume an attacker knows everything you know
Slide 37: Use Data Protection API (DPAPI) to Protect Secrets
Two DPAPI functions:
CryptProtectData CryptUnprotectData
Two stores for data encrypted with DPAPI:
User store Machine store
Slide 38: Demonstration 3
DPAPI
Storing Connection Strings in Web.config Encrypting Connection Strings with DPAPI Installing the Aspnet_setreg Utility Using Encrypted Attributes in a Configuration File Granting Permissions on Registry Keys
Slide 39: Fail Intelligently (1 of 2)
DWORD dwRet = IsAccessAllowed(…); if (dwRet == ERROR_ACCESS_DENIED) { // Security check failed. // Inform user that access is denied } else { // Security check OK. // Perform task… }
What if IsAccessAllowed() returns ERROR_NOT_ ENOUGH_MEMORY?
If your code does fail, make sure it fails securely
Slide 40: Fail Intelligently (2 of 2)
Do not:
Reveal information in error messages
<customErrors mode="On"/>
Consume resources for lengthy periods of time after a failure
Do:
Use exception handling blocks to avoid propagating errors back to the caller Write suspicious failures to an event log
Slide 41: Test Security
Involve test teams in projects at the beginning Use threat modeling to develop security testing strategy Think Evil. Be Evil. Test Evil.
Automate attacks with scripts and low-level programming languages Submit a variety of invalid data Delete or deny access to files or registry entries Test with an account that is not an administrator account
Know your enemy and know yourself
What techniques and technologies will hackers use? What techniques and technologies can testers use?
Slide 42: Learn from Mistakes
If you find a security problem, learn from the mistake
How did the security error occur? Has the same error been made elsewhere in the code? How could it have been prevented? What should be changed to avoid a repetition of this kind of error? Do you need to update educational material or analysis tools?
Slide 43: Session Summary
Secure Development Process Threat Modeling Risk Mitigation Security Best Practices
Slide 44: Next Steps
Stay informed about security
Sign up for security bulletins:
http://www.microsoft.com/security/security_bulletins/alerts2.asp
Get the latest Microsoft security guidance:
http://www.microsoft.com/security/guidance/
Get additional security training
Find online and in-person training seminars:
http://www.microsoft.com/seminar/events/security.mspx
Find a local CTEC for hands-on training:
http://www.microsoft.com/learning/
Slide 45: For More Information
Microsoft Security Site (all audiences)
http://www.microsoft.com/security
MSDN Security Site (developers)
http://msdn.microsoft.com/security
TechNet Security Site (IT professionals)
http://www.microsoft.com/technet/security
Slide 46: Questions and Answers