The four articles in this issue of Software Tech News have provided excellent guidance and a wealth of information about "Secure Software Engineering" from a development, management, supplier, and acquisition perspective. Being a software engineer myself and given the increased importance now of security and trustworthiness of software intensive systems, my perspective in reading these articles is to understand how what I perceive as "best" practices in software engineering are impacted by security issues. Here are the highlights of what I learned:

 

• From a development and lifecycle perspective:

- Need to significantly reduce defects induced and improve methods for detecting software defects throughout the lifecycle. Correctness by Construction is a rigorous methodology which results in very low defect software (<0.1 defects/ksloc). TSP-Secure provides a set of defined and measured best practices for low-defect Secure software development.^{1, 2}

- Need to understand common causes of vulnerabilities and focus on defect reduction techniques for defects that lead to or cause vulnerabilities.^{1, 3}

- Security must be built-in to the software development lifecycle with appropriate checkpoints and reviews.^{1, 2, 3}

- Need to define a set of best practices that development teams can use. Correctness by Construction and TSP-Secure provides best practice approaches.^{1, 2}

- Need to sensitize designers, developers and testers to security issues through training.^{1, 3}

- Tools are available to detect some security vulnerabilities.^{1, 3}

- Best practices for developers and testers includes threat modeling, Fuzz testing, Ballista, penetration analysis static code analysis.^{1, 3}

- Developer accountability helps to ensure security compliance.³

- Correctness by Construction achieves significant defect reduction through rigorous requirements analysis, use of formal design methods and information flow models for design, and verifiable code development (when needed).²

 

• From a management perspective:

- >90% of all vulnerabilities are caused by defects resulting from inadequate, normal software engineering methods.¹

- In building a business case for secure software engineering, need to consider (add) costs of fixing and releasing patches from a supplier, acquirer, and consumer perspective. Not addressing security from a supplier perspective could impact customer satisfaction and result in lawsuits.^{1, 2}

- Need senior management vision, leadership, support, and oversight of implementation of security policies and best practices.^{1, 2, 3}

- Security measures need to be planned, measured, and tracked.¹

- Program managers should collect and maintain information on suppliers used to perform software development.⁴

• From a supplier perspective:

- Suppliers need to ship software where default settings are secure.³

- Perform a security audit prior to release.³

 

• From an acquirer's perspective:

- Acquirers, suppliers, and program managers need to identify and manage risks associated with foreign involvement in development of software (including COTS) for weapon system programs.⁴

- Acquirers need to communicate security requirements through prime development contracts.^{3, 4}

- Acquirers should demand software warranties, award contracts to organizations that deliver low defect software, and provide contract incentives for partnership and improvement.²

- Change, in reality, will come from regulations and financial incentives.²

 

¹ See "Developing Secure Software" by Noopur Davis

² See "The Challenge of Low Defect, Secure Software" by Martin Croxford

³ See "Enhancing Customer Security: Built-in versus Bolt-on" by Glenn Schoonover

⁴ See "Software Development Security: A Risk Management Perspective" by Ellen Walker