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.3
- 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).2
• From a
management perspective:
- >90% of all vulnerabilities are caused by defects
resulting from inadequate, normal software engineering methods.1
- 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.1
- Program managers should collect and maintain
information on suppliers used to perform software development.4
• From a
supplier perspective:
- Suppliers need to ship software where default settings
are secure.3
- Perform a security audit prior to release.3
• 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.4
- 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.2
- Change, in reality, will come from regulations and
financial incentives.2
1 See "Developing Secure Software" by Noopur
Davis
2 See "The Challenge of Low Defect, Secure
Software" by Martin Croxford
3 See "Enhancing Customer Security: Built-in
versus Bolt-on" by Glenn Schoonover
4 See "Software Development Security: A Risk
Management Perspective" by Ellen Walker
DACS Gold Practice Initiative
ROI Dashboard
