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: gem@cigital.com “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