© 2003 cigitalssi 2003 getting past why architecture is the key to software security gary mcgraw,...
TRANSCRIPT
© 2003 CigitalSSI 2003
Getting Past <THAT PROBLEM>Why Architecture is the Key to
Software Security
Gary McGraw, Ph.D.CTO, Cigital
http://www.cigital.com
© 2003 Cigital SSI 2003
Old school security is reactive Defend the perimeter with a
firewall To keep stuff out
Over-rely on crypto “We use SSL”
“Review” products when they’re done Why your code is bad
Promulgate “penetrate and patch”
Disallow advanced technologies Extensible systems (Java and
.NET) are dangerous
The “fat guy with keys” does not really understand software development.
© 2003 Cigital SSI 2003
Modern security is about managing risks There is no such thing as
100% secure Must make tradeoffs Should be business
decisions Proactive security is about
building things right Design for security Security analysis Secure coding practice Security testing
It’s all about the software Most security problems
are caused by software bugs and flaws
We must build secure software
0
500
1000
1500
2000
2500
3000
1995 1996 1997 1998 1999 2000 2001
Software vulnerability reports to CERT/CC
© 2003 CigitalSSI 2003
Software Security Pitfalls
© 2003 Cigital SSI 2003
Technology choices are glossed Language (#1)
C/C++ Java, C# Perl, python, PHP
Operating system Windows 9X Windows NT/XP Unix flavors
The environment in which software
operates is critical
“Container” systems CORBA EJB DCOM
Authentication mechanism Biometrics Password systems Tokens
Smart cards PCI keys
Network 802.11b (wireless)
© 2003 Cigital SSI 2003
Sociology problems Most security organizations
are made up of network security people MIS, IT focus CISSP
Network people do not often understand software development Code reviews alone do
not cut it!
Most development shops have good intentions, but little security knowledge Want to “build stuff” No good knowledge
source See security review as a
waste of time and a big hassle
Software security is
currently nobody’s job.
© 2003 Cigital SSI 2003
Security problems are complicatedIMPLEMENTATION BUGS
THAT PROBLEM String format One-stage attacks
Race conditions TOCTOU (time of check
to time of use) Unsafe environment
variables Unsafe system calls
System() Untrusted input problems
ARCHITECTURAL FLAWS Misuse of cryptography Privileged block protection
failure Catastrophic security failure
(fragility) Type safety confusion error Insecure auditing Broken or illogical access
control
© 2003 Cigital SSI 2003
FLAW: Architectural problems with Java Java’s classloading
architecture flawed Separate instantiate class
from manage name spaces Every release had
problems March 96: JDK 1.0 March 97: JDK 1.0.7 July 98: JDK 1.2
What is “Java” anyway? (and what is .NET?!)
J2EE
J2SE
JavaCard
J2ME
MicroChai
TINI
More resources
© 2003 CigitalSSI 2003
Principles and Guidelines for
Better Design
© 2003 Cigital SSI 2003
Reaching for the brass ring Design for security is critical
Teaching people HOW to do this is very hard Apprenticeship is the state of the art today Guidelines can help (but tend to be unsatisfyingly
high level)
Guidelines can help, but are no magic bullet
© 2003 Cigital SSI 2003
Ten guiding principles for secure design1. Secure the weakest link
2. Practice defense in depth
3. Fail securely
4. Follow the principle of least privilege
5. Compartmentalize
6. Keep it simple
7. Promote privacy
8. Remember that hiding secrets is hard
9. Be reluctant to trust
10. Use your community resources
© 2003 Cigital SSI 2003
Twelve guidelines for writing safer Java1. don’t depend on initialization
2. limit access to entities
3. make everything final
4. don’t depend on package scope
5. don’t use inner classes
6. avoid signing your code
7. put all signed code in one archive
8. make classes uncloneable
9. make classes unserializeable
10. make classes undeserializeable
11. don’t compare classes by name
12. don’t store secrets
© 2003 Cigital SSI 2003
Problem: Serialization While serialized, objects aren’t protected by access controls
An attacker can read or modify the object in its serialized form
An attacker can create a serialized representation from scratch to insert into the system with bad data
Serialized data can be modified in several ways Extending objects and overriding read/writeObject() Extending ObjectInputStream/ObjectOutputStream Capturing the data through network monitoring
© 2003 Cigital SSI 2003
Fix: Serialization Declare sensitive fields as transient if possible If class will be serialized
Implement final writeObject() and readObject() methods to prevent subclasses overriding
Make sure readObject() was called - “initialized” set If class should not be serialized
Prevent subclasses from overriding methods
private final void writeObject()(ObjectOutputStream out) throws java.io.IOException {
throw new java.io.IOException(“Object can not be serialized”);}
private final void readObject()(ObjectOutputStream out) throws java.io.IOException {
throw new java.io.IOException(“Object can not be deserialized”);}
© 2003 Cigital SSI 2003
Fix: Serialization Disallow permissions that allow modification to IO streams
SerializablePermission(“enableSubclassImplementation”) SerializablePermission(“enableSubstitution”)
Encrypt serialized streams At application level (key management is hard) Through network mechanisms (SSL, IPSEC)
Consider using externalization as an alternative Less data is transferred Less ability for attacker to inject new classes
Guidelines: “Make your classes Unserializable,” “Make your classes Undeserializable”
© 2003 CigitalSSI 2003
Why Design?
© 2003 Cigital SSI 2003
On Bricks and Walls Proper use of “dangerous” system calls is equivalent to using
solid bricks Without an architecture, using all the right system calls won’t
help
© 2003 Cigital SSI 2003
On architectural analysis Designers should not do this Build a one page white board
design model (like that ) Use hypothesis testing to
categorize risks Threat modeling/Attack
patterns Rank risks Tie to business context Suggest fixes Repeat
© 2003 Cigital SSI 2003
Defects at Each Stage of Software Development
Requirements
Design
Testing
Coding
Maintenance
0
10
20
30
40
50
60
Perc
en
tag
e o
f D
efe
cts
Source: TRW
© 2003 Cigital SSI 2003
Cost of Fixing Defects at Each Stage of Software Development
Requirements
Design
Testing
Coding
Maintenance
0
$3,000
$6,000
$9,000
$12,000
$15,000
Cost
Per
Defe
ct
Source: TRW
© 2003 Cigital SSI 2003
Engagements Seriouswhere Design design
Category observed related flaws*
Administrative interfaces 31% 57% 36%
Authentication/access control 62% 89% 64%
Configuration management 42% 41% 16%
Cryptographic algorithms 33% 93% 61%
Information gathering 47% 51% 20%
Input validation 71% 50% 32%
Parameter manipulation 33% 81% 73%
Sensitive data handling 33% 70% 41%
Session management 40% 94% 79%
Total 45 70% 47%
*Scores of 3 or higher for exploit risk and business impact
Top 10 Application Security Defects
Password controls
Buffer overflows
Weak encryption
File/application enumeration
Password sniffing
Cookie manipulation
Administrative channels
Log storage/retrieval issues
Error codes
Assessments whereencountered, percent
Session replay/hijacking 31%
27%
27%
27%
24%
24%
20%
20%
20%
20%
Security Defects by Category
@stake: Security Defects
Source: 2002 @stake - The Hoover Project (n=45)
© 2003 Cigital SSI 2003
@stake: Early is Good
Although benefits can be found throughout the lifecycle, earlier involvement is most beneficial
Vulnerabilities are harder to address post-design System-wide changes
may be required atlater stages
Enablingimprovementscan be madeat design state
Source: 2002 @stake - The Hoover ProjectDesign
5%
10%
15%
20%
25%
Implementation Testing
21%
15%
12%
Security ROI by Phase
Return on SecurityInvestment (NPV)
0%
© 2003 Cigital SSI 2003
Microsoft’s software security process
Secure questionsduring interviews
Concept DesignsComplete
Test plansComplete
CodeComplete
Ship PostShip
Threatanalysis
SecurityReview
Team membertraining
Data mutation& Least PrivTests
Review old defects Check-ins checkedSecure coding guidelinesUse tools
Security push/audit
= on-going= on-going
Learn & Refine
External review
Where we need new tools and techniques
© 2003 Cigital SSI 2003
Open Questions How is security best integrated into a
standard engineering-based approach?
Do all engineers need to understand security?
What kind of organization can build secure software?
Is expertise and experience necessary for good security analysis?
Where does it come from? How does auditing designs differ from
auditing source code? What role should security testing play
in analysis?
© 2003 Cigital SSI 2003
Suggested research agenda Quantify, analyze, and explain bug/flaw categories Do more cost/benefit analysis proving that early is
good Untangle security software from software security at
the requirements stage Explain why the software security problem is
growing Build tools for earlier in the lifecycle Find out how to teach this stuff Invent measures and metrics
0
500
1000
1500
2000
2500
3000
1995 1996 1997 1998 1999 2000 2001
© 2003 Cigital SSI 2003
Pointers Cigital’s Software Security Group invents and practices
Software Quality Management
Get Building Secure Software
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