Secure Software

From John D. McGregor's article on Secure Software in the Journal of Object Technology:

Poorly written software will have more security vulnerabilities than well written software. Incorporate security as a quality consideration early in the development life cycle.

McGraw’s trinity of trouble:[McGraw 04]
Three problems that contribute to increasing security problems:

• Ubiquitous network connections
• Easily extensible systems
• Increasingly complex systems

Qualities of software products that reduce the probability of security problems:
Correct: the ability of a software product to satisfy its functional requirements. If the program is not correct then it becomes difficult to know whether the program’s failure to meet expectations is due to a security breach or just built-in incorrectness.
Robust: percentage of time that a product can continue to function in the face of unusual conditions. Robustness is achieved by allowing for “other” cases at every opportunity. That is, the design should anticipate that not all cases are covered by the specification.
Reliable: percentage of the operating time that the product performs requested functions correctly. Quality assurance activities such as conducting active design reviews, establishing and checking compliance with design and coding standards, and testing the product code contribute to the reliability of the resulting product.

BUILDING SECURE SOFTWARE
Extensible: software is designed to be extensible, holes are created that are vulnerable to attack. The technique for making extension points secure will vary with the binding time (at design time or at execution time).
Complex: security vulnerabilities will be more likely to exist and to be hidden from the usual testing. Decompose it away. The key is to start small and grow as the product comes together.
Consistent error handling: provide a consistent error handling scheme. The point to be made here is that the error handling needs to be visible at the appropriate design level.
Robust data structures: you can’t overflow a hardware buffer. Why should it be different with a software buffer?
Misuse and Abuse case: describe misuse and abuse cases as an approach to helping stakeholders think about possible scenarios that need to be defended against [Hope04]
Plan of action: attribute-driven design approach (ADD) [Bass00]:

• A clear definition of the quality attribute
• A framework for reasoning about the quality
• A set of architectural tactics that enhance the quality

The secure quality attribute has to be as carefully engineered as every other quality upon which our strategic goals depend.

Read the complete article:
John McGregor: “Secure Software", in Journal of Object Technology, vol. 4, no. 4, May-June 2005, pp. 33-42

Recommended reading: Building Secure Software: How to Avoid Security Problems the Right Way,By John Viega, Gary McGraw (2002), good on both the theory and practice of secure software design, for both manager and programmer. First chapters describe how vulnerabilities creep into the software, while the later chapters explain the secure coding techniques.

[Bass 00] Felix Bachmann; Len Bass; Gary Chastek; Patrick Donohoe; and F. Peruzzi. The Architecture Based Design Method (CMU/SEI-2000-TR-001, ADA37581). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000
[Hope 04] Paco Hope, Gary McGraw, and Annie I. Anton. Misuse and Abuse Cases: Getting Past the Positive, IEEE Security and Privacy, IEEE Computer Society, 2004.
[McGraw 04] Gary McGraw. Software Security, IEEE Security & Privacy, IEEE Computer Society, 2004