Software Security

by Gary McGraw, Ph.D.

Presented by Don Brown April 4, 2006

Security: Untangling it

Software

• Building secure software

• Designing software to be secure

• Making sure software is secure

• Educating developers, architects, and users about how to build secure things

vs. Application

• Protecting software & systems it runs in after it is built

• Sandboxing code (e.g. Java VM)

• Protecting against malicious code

• Obfuscating code

• Locking down executables

• Monitoring running programs (especially their inputs)

• Enforcing software use policy with technology

• Dealing with extensible systems (network-centric)

Application Security Is:

• Finding and fixing known security problems

REACTIVELY

after they have been exploited in fielded systems.

Software Security Is:

• Building software to withstand attacks

PROACTIVELY

before problems are exploited in fielded systems.

• The process of designing, building, and testing software for security

• Identifies and expunges problems in the software itself

• For example, fix broken code and avoid buffer overflow completely rather than trying to stop attacks by observing port 80 HTTP traffic

• In the long run, we desperately must figure out ways to build robust, easier-to-defend code!

• However, put glibly, software security is not security software¹ (e.g. over-reliance upon cryptography).

The Software Security Problem

• CERT reported 4,129 vulnerabilities in 2003, a 70% increase over 2002, a 400% increase over 2001².

• Internet enabled applications present the highest security risk encountered today.

• The central and critical aspect of the computer security problem is a software problem (bad software is to blame¹):

– Software implementation defects such as buffer overflows,

– Design flaws such as inconsistent error handling.

• A “Trinity of trouble” impacts software security in a negative way:

– Connectedness (ubiquitous networking),

– Complexity (systems) (e.g. 40million lines of code in XP),

– Extensibility (built-ins).

• Common Impediments:

– Time-to-Market—throwing software engineering practices out the window,

– Extensible software—preventing proper software engineering practices,

– Poor or non-existent specifications.

Software Vulnerabilities

• Buffer Overflows,

• Heap Overflows,

• Stack Overflows,

• Race Conditions.

• Security is a subset of Reliability.

• A DoS attack can result from a repeated attack against a vulnerability caused by a program bug.

Threats to Software

• Viruses (Trojan Horses),

• SPAM Emails,

• Hacking into Systems,

• “Script Kiddies”,

• “Back Door” Portals,

• Breaking encrypted software publications,

• Worms

Software Security Goals

• What is it we are trying to protect?

• From whom are we protecting it?

• How do we get what we want?

Additional Goals to keep in mind:

• Prevention,

• Traceability and Auditing

• Monitoring,

• Confidentiality (and Privacy),

• Multilevel Security,

• Anonymity,

• Authentication,

• Integrity.

Software Engineering is really Risk Management

• Adopt “Spiral Model”.

• Auditing of software and analysis.

• Analysis throughout all phases of product life cycle.

• Requirements flow through entire process– encompass management, design, validation, and verification.

Engineering Secure Software

• Security is not a “bolt-on” feature.

• “Penetrate and patch” is not an economically viable methodology.

• The most effective means of assuring maximum security is to carefully implement, and extensively test the system before release.

• Tackle the creation of secure software by exploring

Software Best Practices...

Software Best Practices Requirements

• Security needs to be explicitly at requirements stage (overt functional – cryptography) and (emergent characteristics)

• Build abuse cases – describing behavior whilst under attack – from what to protect, from whom to protect it, and for how long

Principles

• Design in security principles – such as principle of least privilege

• Everyone should clearly document assumptions and identify possible attacks

• Risk analysis is a must – analysts must uncover and rank risks to begin mitigation

• External review is often necessary

Software Best Practices
Code

• Code level implementation

• Focus on flaws using static analysis tools – scan for common vulnerabilities

• Code review – necessary but not sufficient

• Bugs in C/C++ can be deadly

Testing

• Strategies: functional and risk-based on attack patterns and threat models

• Plan traceable to requirements

• Penetration: black box truly BAD;

take architecture into account GOOD

• Track both threat models and attack patterns in field – cycle knowledge gained back into development organization on recurring basis

Using Cryptography

• Principle #1: “Never roll your own”

• Obtain advice from Cryptography experts.

• Use common cryptographic libraries, create a symmetric program, hashing, create a public key program, use Threading, use Cookie Encryption, Transport Layer Security Programs, One-Time Pads.

• Applied cryptography is an important weapon in the software security arsensal, however, it is insufficient for security.

Aspect-Oriented Programming

• An approach using the AspectJ tool³ which extends Java.

• Idea of building a secure system from scratch is “utopian”.

• Unanticipated threats always arise.

• Environment in which software operates changes.

• Some form of patching always necessary.

• Moreover, trying to build secure software from scratch makes it complex and expensive.

Aspect-Oriented Programming (contd)

• Application Logic and Security Logic are inherently structurally different.

• Separating concerns is supported as in Object Oriented programming leads to ease of development, maintenance, etc.

• Techniques cannot focus on other than one view of the problem; they lack ability to approach the problem from different viewpoints simultaneously.

• Cross-cutting concerns cannot be fully separated.

Aspect-Oriented Programming (contd)

• Provides more advanced modularization techniques.

• Specifies the behavior of one concern as well as how this behavior relates to other concerns (binding).

• A unit of modularization is called an aspect and a unit of binding is called a pointcut.

• Some security mechanisms require information not localized in the application software (such as encryption keys).

• Modularizing security not addressed adequately by ongoing community.

Aspect-Oriented Programming (contd)

• Key advantages are the full separation of business logic and security logic.

• Security experts allowed to concentrate on their core business, and the centralization of the security policy that raises policy verification to a higher level.

• Research is continuing in order to cover challenge of combining aspects that result from complementary, relatively unrelated concerns, where advanced aspect compositions are required.

Some Observations

• Approaching Security by building Secure Software from the beginning as proposed by the author is likely to prove unsuccessful.

• Unanticipated threats will always be with us.

• New techniques are needed to separate software security concerns from software functional concerns and to apply both to the cross-cutting requirements of each.

References

[1] J. Viega, and G. McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, Addison-Wesley, ISBN 0-201-72152-X.

[2] G. McGraw, “From the Ground Up: The DIMACS Software Security Workshop,” IEEE Security & Privacy, vol. 1, no. 2, 2003, pp.59-66.

[3] B. De Win, B. Vanhaute, and B. De Decker, “How Aspect-Oriented Programming can help to build Secure Software,” Informatica, vol. 26, 2003, pp.141-149.

Questions?