How a process model can help bring security into software development

Third in a series on the secure software lifecycle.

Lifecycle processes have been around for years, so why has it been so difficult to incorporate security into the process? The secure software development lifecycle (sSDLC) comprises a number of complex processes that require early involvement by business users, project managers and applications developers, as well as information security practitioners, to successfully develop a functional and secure product. An organization must adopt a process model wherein process improvements are managed from a common framework. This disciplined approach will not alleviate all vulnerabilities but will increase the likelihood of building secure software to meet users’ needs in a cost-effective fashion. Several models are described below.

Related articles:

How control gates can help secure the software development life cycle

The recipe for 'baking in' security in software systems

Implementing process improvement attuned to organizational culture increases the likelihood of building secure software by following software engineering practices – good design, quality practices, testing methods, risk management and project management. However, well-known software development processes and frameworks are designed to produce quality and reliable products but ones that do not specifically address security requirements. According to NASA’s Software Assurance Guidebook, a minimum security assurance program will include:

• A security risk evaluation.
• Established security requirements for information and software.
• Established security requirements for development and maintenance processes.
• Reviews of security requirements in evaluations.
• Provisions for security through the configuration management process.
• Prevention of security violations through the change evaluation process.
• Provisions of adequate physical security.

Risk management throughout the sSDLC is integral to the development of a secure application that meets business needs. According to the National Institute of Standards and Technology’s Special Publication 800-30, “Effective risk management must be totally integrated into the SDLC ... [which] has five phases: initiation, development or acquisition, implementation, operation or maintenance and disposal.” The process begins by identifying the information assets that the software will be processing and ensuring that business owners specify requirements for confidentiality, integrity, availability and auditability. By understanding the value of information assets, threats can be identified and proper controls designed into the software, thereby reducing risk. Once the application characterization has been performed, the scope can be defined and boundaries identified, along with the resources, integration points, and information that constitute the application.

The next step is to perform an architectural risk analysis to spot exploitable vulnerabilities. The activities encompass known vulnerability analysis, ambiguity analysis and underlying platform vulnerability analysis. Known vulnerability analysis is performed on known documented vulnerabilities and practices in the code and system management. Ambiguity analysis is the analysis between business requirements and software development. The underlying platform vulnerability analysis includes the operating system, network, platform and interaction vulnerabilities. The phase of the sSDLC where the vulnerability analysis is performed dictates the type of analysis performed and which security features are incorporated.

Also consider the acquisition of commercial off-the-shelf (COTS), government off-the-shelf (GOTS) or open-source software, which all present security risks. Often, such software does not meet the functional or security requirements of the acquiring organization. To address this problem, Federal Acquisition Regulation 7.104(b)(17) was modified in 2005 to include the following language: “For information technology acquisitions, discuss how agency information security requirements will be met.” In 2006, the Open Web Application Security Project (OWASP) Legal Project developed a Contract Annex of a sample contract that included security requirements for the life cycle so that COTS products would be more secure. Movement to include more strenuous contracting language is adding impetus for including and assessing software assurance requirements.

In reviewing the Information Assurance Technology Analysis Centers’ “Software Security Assurance, State-of-the Art Report,” several methods of incorporation of security into the SDLC have been proposed. Cigital’s Gary McGraw and John Viega propose the following activities in their book, “Building Secure Software”:

• Security requirements derivation/elicitation and specification.
• Security risk assessment.
• Secure architecture and design.
• Secure implementation.
• Security testing.
• Security assurance.

Further, Cigital has developed a proprietary risk management framework (RFM) that it used to develop the Build Security In (BSI) RMF, a condensed version of its RMF, under contract to the Homeland Security Department. The BSI RMF consists of five phase risk management activities:

1. Understanding the business context in which software risk management will occur.
2. Identifying and linking the business and technical risks within the business context to clarify and quantify the likelihood that certain events will directly affect business goals – including analyses of software and development artifacts.
3. Synthesizing and ranking the risks.
4. Defining a cost-effective risk mitigation strategy
5. Carrying out and validating the identified fixes for security risks.

McGraw also provides seven – plus one – touch points for software security in “Software Security: Building Security In” (Addison-Wesley, 2006) that are “lightweight” best practices that can be applied in software development. The touch points are:

1. Static analysis/review of source code.
2. Risk analysis of architecture and design.
3. Penetration testing.
4. Risk-based security testing.
5. Building abuse cases.
6. Security requirements specification.
7. Security operations.
8. “Bonus” for external analysis.

Marco Morana of Foundstone proposes a long-term, holistic software security approach that recommends considering software security and information security risks together rather than separately. Below, Morana provides a Notional Software Security Framework.

Click for larger image.

Microsoft also published its own Security RMF mapping to its Microsoft Solutions Framework. Unfortunately, it is oriented towards turnkey software products rather than software integration. Microsoft has also established its own security enhanced software development process that integrates tasks and checkpoints to improve security of the software produced by reducing the number of security-related design and coding defects and the severity of impact of residual defects.

Another methodology to insert security into the lifecycle is the Comprehensive, Lightweight Application Security Process (CLASP), developed by John Viega, of McAfee, Inc. CLASP’s core feature is to integrate 30 security-focused activities into the software development process. The key activities include:

• Monitoring security metrics.
• Identifying user roles and requirements.
• Researching and assessing security solutions.
• Performing security analysis of system design.
• Identifying and implementing security tests.

Baking security into software development would seem to be a naturally occurring process, but it has not been the case. The complexity of the software development process requires that good security requirements be defined in the development process by all stakeholders. Security must be designed in from the start of development and security features tested and verified before the application is deployed. By building the system following disciplined processes that incorporate security, development costs can be more accurately defined and controlled, service and maintenance costs will be reduced and time for retrofits will be drastically minimized. The very costly (time as well as money) model of build and patch – and patch again – will finally be obsolete.