If you can't read please download the document
Upload
vocong
View
220
Download
1
Embed Size (px)
Citation preview
2009 Cigital
Software Security
Touchpoint:
Architectural Risk Analysis
Gary McGraw, Ph.D.
Chief Technology Officer, Cigital
2009 Cigital
Cigital
Founded in 1992 to provide software security and software
quality professional services
Recognized experts in software security and software quality
Widely published in books, white papers, and articles
Industry thought leaders
http://www.cigital.com/books/wirelesssec/http://www.cigital.com/books/80211/
2009 Cigital
ARA in Context:
State of the Practice
2009 Cigital
A shift from philosophy to HOW TO
Integrating best practices into large organizations
Microsofts SDL
Cigitals touchpoints
OWASP adopts CLASP
2009 Cigital
What works: BSIMM
Building Security
In Maturity Model
Real data from
real initiatives
2009 Cigital
Two kinds of security defectsIMPLEMENTATION BUGS
Buffer overflow
String format
One-stage attacks
Race conditions
TOCTOU (time of check to time of use)
Unsafe environment variables
Unsafe system calls
Cross-site scripting
SQL injection
ARCHITECTURAL FLAWS
Misuse of cryptography
Compartmentalization problems in design
Privileged block protection failure (DoPrivilege())
Catastrophic security failure (fragility)
Type safety confusion error
Insecure auditing
Broken or illogical access control (RBAC over tiers)
Method over-riding problems (subclass issues)
Signing too much code
50% 50%
2009 Cigital
The bugs/flaws continuum
BUGS FLAWS
Customized static rules (Fidelity)
Commercial SCA tools: Fortify,
Ounce Labs, Coverity
Open source tools: ITS4,
RATS, grep()
Architectural risk analysis
gets() attacker in the middle
2009 Cigital
Software security touchpoints
2009 Cigital
Architectural Risk Analysis
2009 Cigital
BSIMM: Ten surprising things
1. Bad metrics hurt
2. Secure-by default
frameworks
3. Nobody uses
WAFs
4. QA cant do
software security
5. Evangelize over
audit
6. ARA is hard
7. Practitioners dont
talk attacks
8. Training is
advanced
9. Pen testing is
diminishing
10. Fuzz testing
http://www.informit.com/articles/article.aspx?p=1315431
2009 Cigital11
Architectural Risk Analysis
For more information, see
http://www.cigital.com/services/security/
2009 Cigital
Touchpoint: Architectural risk analysisArchitectural Risk Analysis
Inputs OutputsActivities
Perform Attack
Resistance
Analysis
Perform
Ambiguity
Analysis
Perform
Underlying
Framework
Weakness
Analysis
Map
Applicable Attack
Patterns
Identify GeneralFlaws
Non-Compliance
Show where
guidelines are not
followed
Show Risks and
Drivers in
Architecture
Ponder Design
Implications
Unify
Understanding Uncover Ambiguity
Identify
Downstream
Difficulty
(Sufficiency
Analysis)
Unravel
Convolutions
Uncover Poor
Traceability
Find & Analyze
Flaws in COTS
Frameworks
Network Topology
Platform
Identify Services
Used By
Application
Documents
Security
Analyst
Generate Separate
Architecture
Diagram
Documents
DocumentsMap Weaknesses
to Assumptions
Made by
Application
Attack Patterns
Show Viability of
Known Attacks
Against Analogous
Technologies
Architectural Risk
Assessment
Report
Software
Flaws
Documents
Attack
Patterns
Exploit Graphs
Secure Design
Literature
Documents
RequirementsArchitectural
Documents
Regulatory
Requirements/
Industry
Standards
Build One Page
Architecture Overview
External
Resources
Mailing Lists
Product
Documentation
Start by building a one-
page overview of your
system
Then apply the three-
step process
Attack resistance
Ambiguity analysis
Weakness analysis
2009 Cigital
Touchpoint: Architectural risk analysis Step one: get an architecture
Forrest level view
Up out of the code
Widespread use of common components helps (but also has security impact!)
Spring
Hibernate
Log4J
OpenSSL
Design patterns also help
2009 Cigital
Design diagrams need security too
14
Data Tier
OLTP
Stored
Procs
Blades
The
Brain
Free
Content
Profile
Messaging
Account
POD
POD Web
Service Main Site
E-Comm
Secure Site
Search
Help
Chat
Chat
Inte
rne
t
Da
ta C
en
ter
ASPX
Pages
Castor
Stored
Procs
Pollux
Stored
ProcsBrowserSmurf
Chat
Client
Herra
Customer
Service
Profile
Review
Smurf
Picker
Da
ta C
en
ter
Offic
e
Marketing
CS Rep
Ad Partner Site
Verisign
User
Identity
Store
Deployment
Descriptor
View
Form
Form request
Form
Inte
rne
t
Da
ta C
en
ter
Authentication
Status
User Creds
Configuration data
User Creds
Authentication
Status
2009 Cigital
Three steps to ARA
Attack Resistance (use a CHECKLIST)
Apply a list of known attacks (like STRIDE)
Calculate risk-based impact
Ambiguity Analysis (multiple PERSPECTIVES)
Find attacks based on how the system works
Expose invalid assumptions
Weakness Analysis (DEPENDENCIES)
Think through dependencies: toolkits and frameworks
In, Over, Under, Outside
15
Ambiguity
Analysis
Attack
Resistance
Analysis
Underlyin
gF
ram
ew
ork
Weakness
Analy
sis
2009 Cigital
Attack resistance: build an attack checklist
Understand known attacks
Designers what controls are needed to prevent common
attacks?
Attackers what to try again
Example: Microsoft SDLs STRIDE model
Spoofing, tampering, repudiation, info disclosure, denial of
service, elevation of privilege
Start with common taxonomies
7 Pernicious Kingdoms; McGraw
19 Deadly Sins; Howard, LeBlanc, Viega
48 Attack Patterns; McGraw/Hoglund
Common Weakness Enumeration
http://cve.mitre.org/cwe
16
2009 Cigital
Attack resistance: common design elements
Flag design elements that are historically vulnerable to attack
Enterprise applications share many of the same design
elements
Distributed architecture
Dynamic code generation and interpretation
APIs across stateless protocols
Rich Internet Applications
Service-oriented Architecture
17
2009 Cigital
Example: distributed architecture risks
Distributed systems are susceptible to network-based attacks
Eavesdropping
Tampering
Spoofing
Hijacking
Observing
Relevant Attack Patterns
Interposition attacks
Network sniffing
Replay attacks
18
Interposition Attack
Fake
Server
Fake
Client
`
Client (Bob)
`
Attacker (Eve)
Server (Alice)
Replay Attack
Resend
Data
Intercept
Data
`
Client (Bob)
`
Attacker (Eve)
Server (Alice)
2009 Cigital19
Ambiguity analysis: model your stuff
Modeling techniques help expose an applications area of
potential vulnerability
Multiple points of view (and sets of experience) help
Trust Modeling identifies the boundaries for security policy for
function and data
Data Sensitivity Modeling indentifies privacy and trust issues
for application data
Threat Modeling identifies the attackers perspective and
areas of weakness
2009 Cigital
Ex: Threat modeling
Threat: agents of
malicious intent
Asset: function and
data the threat
desires
Point of Attack:
Design element
requiring hardening
and/or the method
of attack
20
Saturday,
Hosting Data CenterInternet
Chemistry
Search
Sign Up
Chemistry
Browser
HTML
AJAX
Messaging
Profile
Free
Search
Personality
Test
Identity
Service
Identity
Verifier
Meyers Briggs
Member
Application
No Authorization
Member
Free Pages
Paid Pages
Database User
SOP
Hacker
Scammer
Identity
Thief
Malicious
Admin
User
2
1
3
4
5
6
2
Direct File Access
Direct Call
Direct File AccessAutomated
Messages
Backend Code Injection
Parameter
Manipulation
Cross Site Code Injection
Backend Code Injection
Forged Requests Against
Users Other Sites
2009 Cigital
Ex: modeling users
Threats = malicious
users
Like users, they
have capabilities
within the system
Threats have a
goal that usually
involves subverting
a security control or
finding a loophole
in the system
21
Hosting Data CenterInternet
Chemistry
Search
Sign Up
Chemistry
Browser
HTML
AJAX
Messaging
Profile
Free
Search
Personality
Test
Identity
Service
Identity
Verifier
Meyers Briggs
Member
Application
No Authorization
Member
Free Pages
Paid Pages
Database User
SOP
Paid
Member
Member
Guest
Scammer
Identity
Thief
Hacker
Malicious
Admin
2009 Cigital
Ex: assets
22
Hosting Data CenterInternet
Chemistry
Search
Sign Up
Chemistry
Browser
HTML
AJAX
Messaging
Profile
Free
Search
Personality
Test
Identity
Service
Identity
Verifier
Meyers Briggs
Member
Application
No Authorization
Member
Free Pages
Paid Pages
Database User
SOP
Hacker
Scammer
Identity
Thief
Malicious
Admin
Applications
functions
Sensitive data
Data controlling the
applications state
Users and the
assets of the other
systems the users
access
Credit Card
Personally Identifiable Information
1
2
Escalate Privilege
2
User
Assets of the User
6
Program Control Data
5
Credentials and Keys
3
PII in Log FIles
4
Program Control Data
2009 Cigital
Ex: points of attack
23
Associate threat and
assets (determine
what the attacker can
do)
Ponder nearest,
easiest targets first
Designers: place
controls around
assets
Attackers: start with
direct attacks and
graduate to multi-
step
Hosting Data CenterInternet
Chemistry
Search
Sign Up
Chemistry
Browser
HTML
AJAX
Messaging
Profile
Free
Search
Personality
Test
Identity
Service
Identity
Verifier
Meyers Briggs
Member
Application
No Authorization
Member
Free Pages
Paid Pages
Database User
SOP
Hacker
Scammer
Identity
Thief
Malicious
Admin
User
2
1
3
4
5
6
2
Direct File Access
Direct Call
Direct File AccessAutomated
Messages
Backend Code Injection
Parameter
Manipulation
Cross Site Code Injection
Backend Code Injection
Forged Requests Against
Users Other Sites
2009 Cigital
Framework analysis
Software is built upon layers of other software
24
What kind of flaws exist?
Known vulnerabilities in
open-source or product
versions
Weak security controls
provided with the
framework
Framework features that
must be disabled or
configured to their secure
form
Operating System
Application Middleware
(Application Server)
Application
Framework
(Struts/Spring)
Language
Runtime
Application
2009 Cigital
Framework analysis: interfaces & contracts
Place components or application relative to
dependencies
It is important to see the relationship of an
application or component with other callers of
shared code and data
Identify libraries and secure library versions
Show runtime in diagram where there are security
implications:
Framework controls
VM or other security sandboxes
Client-side runtime
25
2009 Cigital26
Framework security controls
The application environment provides controls. What are the
limitations?
Cryptography
Example: JCA
Authentication and Authorization
Example: JAAS
Input Validation and Output Encoding
.NET validateRequest
Sandboxing
JavaScript Same Origin Policy
2009 Cigital
Combine risks and rank
Take all of your findings and consider business impact
Rank the findings
Come up with solutions
See chapter 5 of Software Security
http://www.informit.com/articles/article.asp?p=446451
2009 Cigital
Touchpoints adoption Code review
Widespread
Customized tools
Training
ARA
Components help
Apprenticeship
Training
Pen testing
No longer solo
Security testing
Training
Abuse cases and security requirements
Training
2009 Cigital
Where to Learn More
2009 Cigital
informIT & Justice League
www.informIT.com
No-nonsense monthly security
column by Gary McGraw
www.cigital.com/justiceleague
In-depth thought leadership
blog from the Cigital Principals
Scott Matsumoto
Gary McGraw
Sammy Migues
Craig Miller
John Steven
2009 Cigital
IEEE Security & Privacy Magazine + 2 Podcasts
www.cigital.com/silverbullet
www.cigital.com/realitycheck
Building Security In
Software Security Best
Practices column edited by
John Steven
www.computer.org/security/bsisub/
2009 Cigital
Software Security: the book
How to DO software security
Best practices
Tools
Knowledge
Cornerstone of the Addison-
Wesley Software Security
Series
www.swsec.com
2009 Cigital
For more Cigitals Software Security
Group invents and delivers Software Quality Management
WE NEED GREAT PEOPLE
See the Addison-Wesley Software Security series
Send e-mail: [email protected]
So now, when we face a choice between adding features and resolving security issues,
we need to choose security.-Bill Gates