Secure Software Development Model (SSDM)

The number of malicious attacks on software applications and systems increases from year to year.  Addressing this issue requires multiple solutions and resources which can have multiple impacts throughout the software development lifecycle. Software security vulnerabilities can be caused by defects introduced in each phase of the product development life cycle.  Many of the practices which have demonstrated positive results for quality become the foundation for new practices required for security.   Having high maturity software development practices for quality does not guarantee a secure product, but it does increase the probability of having a more secure product. 

Organizations seem to implement secure development in piecemeal fashion. There is focus on secure coding and testing for security but all other phases of development like requirements, design, and management are ignored. In order to have a good set of secure software development processes, it is important to have a good security framework or model. This model should help the organization create and improve secure software development processes.

During my days at Motorola Software, Singapore, I had architected MSSDM – Motorola Secure Software Development Model. I had written a white paper on the model together with my colleague Margaret Nadworny, a link to the white paper can be found below.

http://www.iiisci.org/journal/CV$/sci/pdfs/S452FP.pdf

There are five process areas within SSDM, they are described briefly below:

Secure Development Processes (SDP)

Secure practices in this process area incorporate security into the product development life cycle.  These processes consist of the elicitation of non-functional security requirements as well as the analysis and selection of a secure architecture and design. These practices also include detailed design for security, secure implementation, verification and validation for security. In order to implement these items, methods like threat modelling, security design patterns and secure coding guidelines are highly recommended.

Secure Management Processes (SMP)

The Security Management process area addresses the need for the project to effectively consider both functional and nonfunctional security requirements and how they may be satisfied by both management activities and technical methods.

The integration of security management with other planning viewpoints (e.g., quality, risk, supplier agreement management, cost, and schedule) ensures that security activities are given the planning, monitoring, and control focus commensurate with their importance.

When suppliers external to the project are used to provide products, components, and services, security management ensures that relevant requirements are incorporated into supplier agreements and that these agreements are satisfied.  Furthermore, suppliers should be held accountable for the security vulnerabilities contained within their products.

Organization Security Focus (OSF)

The intention of this process area is to plan and implement organizational security policy and processes based on a thorough understanding of known security vulnerabilities and risks. Practices in this process area consist of establishing a security policy, updating process assets for security, assessing the organization for security, and identifying, collecting, analyzing, and taking corrective action on measures at the organizational level.

Discovery of Security Vulnerabilities and Risks (DSV)

The rationale behind this process area is to put activities in place to ensure that vulnerabilities are exposed. Practices under this process area span the complete lifecycle of product development. All security vulnerability discovery activities such as reviews, inspections, audits and test fall under this process area. Discovery is a painful and effort intensive activity if performed manually.  Hence, there is a practice to encourage the usage of tools for discovery activities.

Corrective Security Actions (CSA)

The goal of this process area is to identify the causes of security vulnerabilities and to prevent them from re-occurring. Practices under this process area focus on the classification, prioritization and analysis of vulnerabilities.  The identification of root causes and the selection of a solution from alternatives, fixing and tracking them to closure fall under the scope of this process area. 

Today hackers seem to be one up in the battle. The applications you develop today are going to stay with your organization for the next 5, 10, 15 years. So the applications developed today should be able to withstand the hackers of tomorrow. If you have not considered secure development until now, it is time to take at least some baby steps.