OWASPAppSec2007Milan_MS_ACETeamAppSecfromTheCore

advertisement
Microsoft ACE Team –
Application Security from the
Core
Simon Roses Femerling
OWASP Pantera Project Lead
Security Technologist, Microsoft
6th
OWASP
AppSec
Conference
Milan - May 2007
simonros@microsoft.com
Copyright © 2007 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the
terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this
license, visit http://creativecommons.org/licenses/by-sa/2.5/
The OWASP Foundation
http://www.owasp.org/
Intro - Who I am?
Security Technologist at Microsoft
Former PwC, @Stake among others…
Postgraduate in E-Commerce from Harvard
University and a B.S. from Suffolk University at
Boston, Massachusetts.
Natural from wonderful Mallorca Island in the
Mediterranean Sea.
6th OWASP AppSec Conference – Milan – May 2007
2
Agenda
SDL-IT Overview
Application Security - ACE Team Style
Threat Modeling
ACE Freeware!!
 Threat Analysis & Modeling (TAM)
 Anti-XSS Library
 AppAssurance
Q&A
6th OWASP AppSec Conference – Milan – May 2007
3
SDL-IT Overview
6th OWASP AppSec Conference – Milan – May 2007
4
Security Development Lifecycle (I)
Requirements
Product Inception
Assign resource
Security plan
Design
Implementation
Guidelines & Best Practices
Coding Standards
Testing based on threat
models
Tool usage
Threat Modeling
Models created
Security Docs &
Mitigations in design
Tools
and functional specs
Customer deliverables
Design
Design guidelines applied
Security architecture
Security design review
Ship criteria agreed upon
for secure deployment
Verification
Release
Response
Final Security Review (FSR)
Review threat models
Penetration Testing
Archiving of Compliance Info
Security Push
Security push training
Review threat models
Review code
Attack testing
Review against new threats
Meet signoff criteria
Security
Response
Feedback loop
- Tools/
Processes
- Postmortems
- SRLs
RTM&
Deployment
Signoff
6th OWASP AppSec Conference – Milan – May 2007
5
Security Development Lifecycle (II)
Process
 Defines security requirements and milestones
 MANDATORY if exposed to meaningful security risks
 Requires response and service planning
 Includes Final Security Review (FSR) and Sign-off
Education
 Mandatory annual training – internal trainers
 BlueHat – external speakers on current trends
 Publish guidance on writing secure code, threat
modeling and SDL; as well as courses
Accountability
 In-process metrics to provide early warning
 Post-release metrics assess final payoff (# of vulns)
 Training compliance for team and individuals
Microsoft Product
Development Lifecycle
Microsoft Security
Development Lifecycle
6th OWASP AppSec Conference – Milan – May 2007
6
Application Security - ACE Team
Style
6th OWASP AppSec Conference – Milan – May 2007
7
Intro ACE Team (I)
 ACE Team Mission: Drive application excellence by providing
engineering leadership through world class performance, security
and privacy software and services.
 We are responsible for application performance, security and privacy
engineering at Microsoft. Our assessment services are available to
any application team at Microsoft who would like to improve their
application's performance, security or privacy characteristics.
 In the last 5 years we have:
 Assess more than +3000 applications for security and performance.
 Identify / Documented / Help to fix more than >50,000 security vulnerabilities.
 Develop many security tools and best practices to use inside and outside
Microsoft for free!!
6th OWASP AppSec Conference – Milan – May 2007
8
Intro ACE Team (II)
 Application Security
 Threat Modeling & Design Reviews
 Security Code Reviews
 Security Process Integration
 Security Guidance & Prototype Development
 Infrastructure Security
 Technical Compliance Management
 Application Performance Tuning
 Performance assessments
 Training: Security & Performance
6th OWASP AppSec Conference – Milan – May 2007
9
Threat Modeling
6th OWASP AppSec Conference – Milan – May 2007
10
Why build a Threat Model?
 The reason for building a threat model is simple: to
identify potential threats so that you can build a solid
security strategy to guard against them.
 You cannot feasibly build a secure system until you
understand the potential threats against it.
 It is important to realize that threats are the by-product
of your own application.
 This is why it is crucial to first understand your
application context, before you begin trying to defend it.
6th OWASP AppSec Conference – Milan – May 2007
11
Threat Model Basics
 Who? You and your team must create the TM.
 What? A process to identify and mitigate threats to your
product.
 When? In Design phase before Implementation phase.
(Basically before writing code!!!)
 Why? To write secure products from the start.
 How? TAM is your friend 
6th OWASP AppSec Conference – Milan – May 2007
12
Threats Classifications
 ACE Team TAM tool uses CIA for Threat Classification that is very
familiar to the secure industry.
 Confidentiality
 Integrity
 Availability
 Other Threat Classification / Threat Model is STRIDE.






Spoofing
Tampering
(Non) Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
 The use of these Threat Classifications depends on your needs.
 CIA = Threat Modeling
 STRIDE = Attack Modeling / Categorization
6th OWASP AppSec Conference – Milan – May 2007
13
Threat Model Summary
 Your first line of defense when developing software.
 A Threat Model is a living document and should be kept
updated.
 TAM has been designed to be used by development
teams without deep security knowledge but is a powerful
tool on hands of security aware people.
6th OWASP AppSec Conference – Milan – May 2007
14
ACE Freeware!!
6th OWASP AppSec Conference – Milan – May 2007
15
Threat Analysis & Modeling
(TAM)
6th OWASP AppSec Conference – Milan – May 2007
16
TAM Overview (I)
 It is easy to use and provides a wizard that guides you to create a
TM in no time.
 The basic steps are:
 Define Business Objectives
 Decompose application
 Define Uses Cases
 Generate threats
 TAM includes an Attack Library.
 Yes, it is free!
6th OWASP AppSec Conference – Milan – May 2007
17
TAM Overview (II)
 TAM can perform analytics on data access, components access and
more.
 Powerful graph capabilities showing Attack Surface and Attack
Trees.
 Compressive or custom generated reports.
 ACE is constantly improving TAM.
6th OWASP AppSec Conference – Milan – May 2007
18
6th OWASP AppSec Conference – Milan – May 2007
19
6th OWASP AppSec Conference – Milan – May 2007
20
Anti-XSS Library
6th OWASP AppSec Conference – Milan – May 2007
21
Anti-XSS Overview (I)
 Powerful library to perform input / output validation in ASP.NET
applications.
 This library differs from most encoding libraries in that it uses the principle of
inclusions technique to provide protection against XSS attacks. This approach
works by first defining a valid or allowable set of characters, and encodes
anything outside this set (invalid characters or potential attacks). This approach
provides a high degree of protection against XSS attacks and is suitable for Web
applications with high security requirements.
 Easy to use and really good documentation 
 Currently version is 1.5
6th OWASP AppSec Conference – Milan – May 2007
22
Anti-XSS Overview (II)
 The library contains the following methods:
Encoding Method
Description
HtmlEncode
Encodes input strings for use in HTML
HtmlAttributeEncode
Encodes input strings for use in HTML attributes
JavaScriptEncode
Encodes input strings for use in JavaScript
UrlEncode
Encodes input strings for use in Universal
Resource Locators (URLs)
VisualBasicScriptEncode
Encodes input strings for use in Visual Basic
Script
XmlEncode
Encodes input strings for use in XML
XmlAttributeEncode
Encodes input strings for use in XML attributes
6th OWASP AppSec Conference – Milan – May 2007
23
Anti-XSS Overview (III)
 Anti-XSS approach:
 Step 1: Review ASP.NET code that generates output
 Step 2: Determine whether output includes un-trusted input
parameters
 Step 3: Determine the context which the un-trusted input is
used as output
 Step 4: Encode output
6th OWASP AppSec Conference – Milan – May 2007
24
Anti-XSS Examples
#1
// Vulnerable code
// Note that un-trusted input is being as an HTML attribute
Literal1.Text = “<hr noshade size=[un-trusted input here]>”;
// Modified code
Literal1.Text = “<hr
noshadesize=”+Microsoft.Security.Application.AntiXss.HtmlAttributeEncode([untrusted input here])+”>”;
#2
<html>
<b>
Hello, <%= AntiXss.HtmlEncode(Request.Form[“UserName”]) %>
</b>
</html>
6th OWASP AppSec Conference – Milan – May 2007
25
AppAssurance
6th OWASP AppSec Conference – Milan – May 2007
26
AppAssurance Overview (I)
 AppAssurance inspects the code of a software
application for a known set of code security flaws, marks
those flaws for inspection by an analyst and provides
both a report of findings and a data flow graph of the
application.
 Can work standalone or as a plug-in for Visual Studio
2005.
 Valueble tool for code review and becoming a must use
tool inside Microsoft.
6th OWASP AppSec Conference – Milan – May 2007
27
AppAssurance Overview (II)
AppAssurance can scan for well-known flaws
like:
SQL Injection
LDAP injection
Xpath Injection
Cross-Site Scripting (XSS)
File Canonicalization
Exception Information
Process Command
Redirection
6th OWASP AppSec Conference – Milan – May 2007
28
AppAssurance Overview (III)
 AppAssurance uses XML files for the rules, so it is very
easy to add and tweak rules.
 How AppAssurance works
 The AppAssurance tool functions to identify security flaws within an application
being examined by scanning the binary and or assembly of the application and
tracing the data flow between statements, methods and assemblies. This
includes indirect data types such as property assignments and instance tainting
operations.
 The engine works by taking the target assembly and all reference assemblies
used in the application and analyzing all of the methods contained within the
types contained within the module. It then uses a graphical modeling technique
using color assigned to known issues, and transverses the sources and sinks of
data to identify use or contact with known issues.
6th OWASP AppSec Conference – Milan – May 2007
29
6th OWASP AppSec Conference – Milan – May 2007
30
6th OWASP AppSec Conference – Milan – May 2007
31
Resources
 Threat Analysis & Modeling (TAM)
 http://msdn2.microsoft.com/en-us/security/aa570413.aspx
 Anti-XSS Library
 http://msdn2.microsoft.com/en-us/security/aa973814.aspx
 ACE Team blog
 http://blogs.msdn.com/ace_team/
6th OWASP AppSec Conference – Milan – May 2007
32
The End
Q&A
 Important: Beer / hard liquor (Vodka/Lemon, Margaritas, Mojitos
you named it…) are always welcome 
 Simon Roses Femerling
simonros@microsoft.com
6th OWASP AppSec Conference – Milan – May 2007
33
Download