Software Security Puzzle Pieces

As you can see by perusing the annotated references, software security exists at the intersection of several disciplines. The following areas of interest are focal points in the field of software security, both among practitioners and among scientists.

• Reconciling security goals and software goals: software quality management in commercial practice

• Security requirements engineering

• Design for security, software architecture, architectural analysis

• Security analysis, security testing, use of the Common Criteria

• Guiding principles for software security, case studies in design and analysis, pedagogical approaches to teaching security architecture

• Software security education: educating students and commercial developers

• Auditing software: implementation risks, architectural risks, automated tools, technology developments (code scanning, information flow, and so on)

• Common implementation risks: buffer overflows, race conditions, randomness, authentication systems, access control, applied cryptography, trust management

• Application security: protecting code postproduction, commercial technologies

• Survivability and penetration resistance, type safety, dynamic policy enforcement

• Denial-of-service protection for concurrent software

• Penetrate-and-patch as an approach to securing software

• Code obfuscation and digital content protection

• Malicious code detection and analysis

Much work remains to be done in each of these areas, but some basic practical solutions are becoming available in the market.

Basic Science: Open Research Areas

Most security researchers agree that we have a pressing problem. In "A Call to Action: Look Beyond the Horizon," Jeannette Wing includes "software design and security" as one of three critical areas to tackle if security research is to make progress [Wing 2003]. In "From the Ground Up: The DIMACS Software Security Workshop," I introduce the software security problem, discuss trends that demonstrate the problem's growth, and introduce the philosophy of proactively attacking the problem at the architectural level [McGraw 2003].

Much work remains to be done in software security, some of it basic and practical (e.g., working software security into the standard software development lifecycle as described by the touchpoints) and some of it far beyond current capabilities (e.g., automated analysis of software architecture for security flaws). Scientists and researchers from academic and commercial labs are working on some of the more difficult problems.

The National Science Foundation suggests that the following eleven open questions be used as drivers for research.

1. How to avoid building security flaws and security bugs into programs

2. How to know when a system has been compromised

3. How to design systems that can tolerate attack and carry out the intended mission

4. How to design systems with security that can be reasonably managed

5. How to provide reasonable protection of intellectual property

6. How to support privacy enforcement technically

7. How to get trustworthy computations from untrusted platforms

8. How to prevent/withstand denial-of-service attacks

9. How to quantify security tradeoffs

10. How to reveal and minimize assumptions in security system designs

11. How to build programs and systems and know exactly what they will do and what they are doing

There is clearly overlap among these problems, but the number of interesting subquestions raised by this list is large.

Careful consideration must be given to design for security. Given a set of principles and properties that we wish a system to have, we must identify guidelines for design and rules for enforcement. Open questions along this line of thinking include: Can principles be refined to guidelines? How can guidelines be reduced to rules that can be enforced statically? What technologies are suited for automated analysis?

Some concrete open research problems include the following:

• Explain why the software security problem is growing.

• Quantify, analyze, and explain bug/flaw categories.

• Do cost/benefit analysis proving that early is good.

• Untangle security software from software security at the requirements stage.

• Explore how to teach software security most effectively both to students and to professionals.

• Invent and apply measures and metrics.

The field is young and there is much to do. Please help!