Implementing Secure Software Development Program

Background:

This article follows my earlier one: "Secure Software Development Life Cycle" (from now on referenced as S-SDLC), being one Implementation of the S-SDLC program. I have covered the basics of S-SDLC in my previous article – and I recommend readers to go through it if you have not already done so. Before we jump into implementation, it is important to get a good understanding of the base framework.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

It should be noted that each article was written with two things in mind. One, it can be read as a standalone article and second, it can be read as a series. Therefore, the intended audience will not remain uniform as we move forward and it will be dedicated to a more technical audience; however, the rest can still follow provided they are reading them sequentially.

Objective:

The aim of this article is to introduce readers to "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'm 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.

Intended Audience:

This article is written keeping in mind Project Managers, Program Managers, Lead Security Engineers and any other stake holders 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 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
  

For readers interested in further details, stay tuned. I'll cover it in much more detail in an upcoming series of articles.

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'll then understand how to analyze the current structure and how to apply the model in such scenarios.

References:

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

http://www.opensamm.org