Implementing a Secure Software Development Program

This article presents the “Open Security Assurance Maturity Model” (Open SAMM). It is very important to have a basic understanding of “Open SAMM” as this is going to be the base for the approach that I am going to demonstrate for the implementation of S-SDLC. Open SAMM as a framework is very flexible and can even be extended if required. This means organizations can use it as a base and then extend it further or even customize it to suit their requirements. However, proper thoughts need to be put into place before doing so.

Author: Chintan Dave

Intended Audience

This article is written keeping in mind Project Managers, Program Managers, Lead Security Engineers and any other stakeholders from Senior Management that are actively involved in reviewing or rolling out the S-SDLC Framework.

It should be noted that “Open SAMM” is not the only option for implementing this program, but it has been chosen based on the flexibility it offers. If readers believe this is not the right framework, they can still implement Secure Software Development Life Cycle (SDLC) using another framework of their choice or design one based on their requirements and expectations. Open SAMM framework has been chosen as it flexible enough to suit the needs of Small, Medium and Large Enterprises.

The rest of the article will focus on the following and the flow of the article will be accordingly:

• High level overview of Open SAMM framework’s business functions
• Measuring the program’s success

Overview of Open SAMM Framework’s Business Functions

Most organizations are caught between stakeholder and management expectations versus technical know-how on how to implement programs such as S-SDLC. This article and all upcoming articles on this subject will focus on practical implementation level understanding and can be used together to implement programs like S-SDLC.

Open SAMM Framework categorizes Software Development into 4 major business functions or areas which are further divided into 3 sub-areas (known as Security Practices) each:

• Governance
• Construction
• Verification
• Deployment

The following is a pictorial representation of the Open SAMM framework

Business FunctionMapping to Software Development Related Activities

It is better to explain this with an example for easier understanding. A car is a combination of multiple mechanical parts like chassis, engine, window glass etc. When all these parts are synchronized and framed to work as a single unit, what we get is a car.

Software development is also like this. Different functions or modules are developed individually while keeping the business requirements in mind. Once all of them are ready, they are synchronized to work together as a single unit, which we call a software product or application.

Open SAMM focuses on mapping software development activities to business functionalities and their corresponding Security Practices which are defined in the framework– thus making it easier going forward to apply the model.

During software development, the organization will perform these activities which fit into one or other Security Practices listed here. There may be variations in naming conventions as organization “x” calls some activity as “a”, while organization “y” might call the same activity as “b”, however the intended function will more or less be similar.

For example: some organization will be conducting in-house training sessions and calling them “Internal Trainings” while another organization may get an external trainer and call it “Professional Learning Activities” even if the same activity is being performed.

Governance

Governance deals more into policies and procedural stuff. It ensures that policies and compliance frameworks, which are created, are enforced. Not following internal policies or dishonoring applicable external compliance can lead to non-compliance related issues. In certain cases, customers using the developed product may run into issues if compliance frameworks are dishonored (e.g. PCI DSS).

• Strategy & Metrics

Focus is on creating an organization wide framework that can be used at a later point of time to measure security assurance.

• Education & Guidance

Educating people about security and awareness is critical. Unless people know the benefits of such programs, they’ll see security as a road block rather than a road map.

• Policy & Compliance

Compliance is one of the factors which can get people to start listening. Fear of being non-compliant many times creates an interest among people for security assurance.

Construction

Construction focuses on software creation related processes and activities. Activities like designing and developing an application or product’s source code and integrating various modules into a single unit fit into this phase.

• Security Requirements

Consider security when charting out software requirements. Understand the business requirements to create security requirements for the product to be developed.

• Threat Assessment

Analyze threats that may affect the organization. Perform threat modeling of applications.

• Secure Architecture

Consider software security when deciding on the application’s architecture. Maintain a list of software frameworks known to be secure.

Verification

Verification focuses on activities that check whether what is being designed or built matches the expectations set for secure software and confirm whether modules introduced to secure applications are built correctly. Similar other questions that one might have in mind are addressed in this phase.

• Design Review

This phase focuses on reviewing design artifacts to check if software is designed securely.

• Code Review

This phase focuses on finding security vulnerabilities from the source code itself using static source code analysis.

• Security Testing

Security Testing ensures that software is securely functioning. This phase focuses on finding security vulnerabilities in the software at run time, i.e. when the application is deployed on the server. While having secure design is good, secure architecture helps in reducing the probability of security vulnerabilities in applications but it does not eliminate the need for security testing.

Deployment

Deployment phase focuses on ensuring that secure deployment practices are followed. A secure environment ensures that the application is maintained in a secure state even in production – when the application is live.

• Environment Hardening

Focuses on base lining and securing operation environment – e.g. hardening of servers, network devices like routers, switches etc. – thus enhancing the security of applications deployed or hosted on the organization’s network.

• Operational Enablement

This phase focuses on enabling positive discussion with the development team and continuous secure operations. Security, although important, should not hamper the operations. It is important to strike a balance of both.

• Vulnerability Management

This phase focuses on management of vulnerabilities both by the internal security team and external researchers. It focuses on developing a process on how to handle these vulnerabilities and track them to closure.

Maturity Levels

Open SAMM framework supports 3 maturity levels for each of these activities. There are a total of 4 business functions and each one has 3 security activities (or practices – as the framework says), so we have a total of 12 Security Practices or activities.

Each Level will have some requirements which need to be addressed; unless these requirements are addressed, expected maturity levels can’t be achieved.

Normally, organizations implementing S-SDLC programs chart out a phase wide Road Map, with each phase having certain levels of maturity associated with them. Once they are accomplished, the phase is completed and the organization can target the next phase and its associated Maturity Levels.

Organizations can even go over and beyond the maturity levels described in the Open SAMM framework, if they desire. The following is a pictorial representation of a sample approach:

Measuring Success

No program is useful from a management perspective unless it can be measured. One of the ways to measure success is by using score cards. Designing a score card right is important because a lot depends on the organization’s expectations.

There may be variations in score cards from organization to organization. For Org 1, some security requirements may be more important and will top the stack of expectations while for Org2, the same requirement might not be so significant. It eventually boils down to the nature of the business and the industry to which the organization belongs to.

What next?

Now that we have a good understanding of what Secure SDLC & Open SAMM framework is, it is time to apply this framework and get the ball rolling. However, there are a few things which we need to look at before we jump into this program: we need to analyze where our organization stands. It should be noted here that it is not necessary that this program be applied only at the organization level. If only a certain department wants to pick up such a program, it is still possible to selectively choose applicable security practices and fine tune the program accordingly.

The next article will focus on areas like implementing Secure SDLC program from scratch – if none exists, since most organizations will have some security measures in place. We will then understand how to analyze the current structure and how to apply the model in such scenarios.

References: http://www.opensamm.org