gavi's picture
From gavi rss RSS  subscribe Subscribe

Writing Secure Code -- Best Practices 



Secure Development Process
Threat Modeling
Risk Mitigation
Security Best Practices

 

 
 
Tags:  Secure  Code  MSDN 
Views:  2494
Downloads:  32
Published:  August 05, 2007
 
0
download

Share plick with friends Share
save to favorite
Report Abuse Report Abuse
 
Related Plicks
Best Practices and Techniques for Building Secure Microsoft ASP.NET Applications

Best Practices and Techniques for Building Secure Microsoft ASP.NET Applications

From: gavi
Views: 3111 Comments: 0

 
Best Practices for Building Web Services with Visual Studio .NET

Best Practices for Building Web Services with Visual Studio .NET

From: gavi
Views: 2028 Comments: 0

 
cv.doc

cv.doc

From: anurado
Views: 7 Comments: 0
cv.doc
 
BI in SQL Server 2008 for Architects

BI in SQL Server 2008 for Architects

From: adeema
Views: 521 Comments: 0

 
See all 
 
More from this user
Microsoft Office Business Scorecard Manager 2005

Microsoft Office Business Scorecard Manager 2005

From: gavi
Views: 3183
Comments: 0

Google Earth

Google Earth

From: gavi
Views: 4477
Comments: 1

Comparing J2EE with .NET

Comparing J2EE with .NET

From: gavi
Views: 3658
Comments: 0

flash

flash

From: gavi
Views: 1789
Comments: 0

Evolution Of Soa - Gartner

Evolution Of Soa - Gartner

From: gavi
Views: 3667
Comments: 0

 
See all 
 
 
 URL:          AddThis Social Bookmark Button
Embed Thin Player: (fits in most blogs)
Embed Full Player :
 
 

Name

Email (will NOT be shown to other users)

 

 
 
Comments: (watch)
 
 
Notes:
 
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

   
Time on Slide Time on Plick
Slides per Visit Slide Views Views by Location