Transcript Building Secure Software (tutorial)

Getting Past <THAT PROBLEM>
Why Architecture is the Key to
Software Security
Gary McGraw, Ph.D.
CTO, Cigital
http://www.cigital.com
SSI 2003
© 2003 Cigital
Old school security is reactive





SSI 2003
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
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
3000
2500
Software vulnerability
reports to CERT/CC
2000
1500
1000
500
0
1995
SSI 2003
1996
1997
1998
1999
2000
2001
© 2003 Cigital
Software Security Pitfalls
SSI 2003
© 2003 Cigital
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
SSI 2003
“Container” systems
 CORBA
 EJB
 DCOM
 Authentication mechanism
 Biometrics
 Password systems
 Tokens
 Smart cards
 PCI keys
 Network
 802.11b (wireless)

© 2003 Cigital
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.
SSI 2003
© 2003 Cigital
Security problems are complicated





SSI 2003
IMPLEMENTATION 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
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?!)
JavaCard
J2EE
More
resources
TINI
SSI 2003
MicroChai
J2ME
J2SE
© 2003 Cigital
Principles and Guidelines for
Better Design
SSI 2003
© 2003 Cigital
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
SSI 2003
© 2003 Cigital
Ten guiding principles for secure design
1.
2.
3.
4.
5.
SSI 2003
Secure the weakest link
Practice defense in depth
Fail securely
Follow the principle of least
privilege
Compartmentalize
6.
7.
8.
9.
10.
Keep it simple
Promote privacy
Remember that hiding
secrets is hard
Be reluctant to trust
Use your community
resources
© 2003 Cigital
Twelve guidelines for writing safer Java
1.
2.
3.
4.
5.
6.
7.
SSI 2003
don’t depend on initialization
limit access to entities
make everything final
don’t depend on package
scope
don’t use inner classes
avoid signing your code
put all signed code in one
archive
make classes uncloneable
9. make classes
unserializeable
10. make classes
undeserializeable
11. don’t compare classes by
name
12. don’t store secrets
8.
© 2003 Cigital
Problem: Serialization


SSI 2003
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
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”);
}
SSI 2003
© 2003 Cigital
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”
SSI 2003
© 2003 Cigital
Why Design?
SSI 2003
© 2003 Cigital
On Bricks and Walls


SSI 2003
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
On architectural analysis







SSI 2003
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
Defects at Each Stage of Software Development
Percentage of Defects
60
50
40
30
20
Requirements
Design
Coding
Testing
Maintenance
10
0
Source: TRW
SSI 2003
© 2003 Cigital
Cost of Fixing Defects at Each Stage
of Software Development
Cost Per Defect
$15,000
$12,000
Requirements
Design
$9,000
Coding
$6,000
Testing
$3,000
0
SSI 2003
Maintenance
Source: TRW
© 2003 Cigital
@stake: Security Defects
Security Defects by Category
Design
related
Serious
design
flaws*
Session replay/hijacking
Password controls
27%
31%
57%
36%
Buffer overflows
27%
Authentication/access control 62%
89%
64%
File/application enumeration
27%
Configuration management
42%
41%
16%
Weak encryption
24%
Cryptographic algorithms
33%
93%
61%
Information gathering
47%
51%
20%
Password sniffing
24%
Input validation
71%
50%
32%
Cookie manipulation
20%
Parameter manipulation
33%
81%
73%
Administrative channels
20%
Sensitive data handling
33%
70%
41%
Log storage/retrieval issues
20%
Session management
40%
94%
79%
Error codes
20%
Category
Engagements
where
observed
Top 10 Application Security Defects
Administrative interfaces
Total
45
70%
47%
*Scores of 3 or higher for exploit risk and business impact
SSI 2003
31%
Source: 2002 @stake - The Hoover Project (n=45)
Assessments where
encountered, percent
© 2003 Cigital
@stake: Early is Good




Although benefits can be found throughout the lifecycle, earlier
involvement is most beneficial
Vulnerabilities are harder to address post-design
Security ROI by Phase
System-wide changes
25%
may be required at
21%
later stages
20%
Enabling
15%
improvements
15%
can be made
Return on Security
Investment (NPV)
at design state
12%
10%
5%
Source: 2002 @stake - The Hoover Project
0%
Design
SSI 2003
Implementation
Testing
© 2003 Cigital
Microsoft’s software security process
Where we need new tools and techniques
Secure questions
during interviews
Concept
Learn &
Refine
External
review
Designs
Complete
Team member
training
Security
Review
SSI 2003
Security push/audit
Threat
analysis
Test plans
Complete
Data mutation
& Least Priv
Tests
Code
Complete
Ship
Review old defects
Check-ins checked
Secure coding guidelines
Use tools
Post
Ship
= on-going
© 2003 Cigital
Open Questions







SSI 2003
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
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
3000
2500
2000
1500
1000
500
0
1995
SSI 2003
1996
1997
1998
1999
2000
2001
© 2003 Cigital
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
SSI 2003
© 2003 Cigital