BSIMM Software Security Framework A Quick Walkthrough
With the continuous increase in a data breach, organizations have started taking security seriously and have also introduced Secure Software Development (SDLC) programs on their systems. But the dilemma is that they don’t know where to start from. Even though they are investing in security activities, measuring the impact of these security services is often overlooked. Which results in over-investment in low-impact activities. There are many standards and frameworks developed for such organizations to measure their state of Software Security. One such framework is called the Building Security in Maturity Model (BSIMM).
What is BSIMM?
BSIMM is a software security measurement framework established to help organizations compare their software security to other organizations initiatives and find out where they stand.
“The Building Security In Maturity Model is a study of existing software security initiatives. By quantifying the practices of many different organizations, we can describe the common ground shared by many as well as the variation that makes each unique”.
The model is based on the study done on organizations across the industries like Financial service sectors, Healthcare sectors, Software sectors, Cloud providers and more.
How Does BSIMM Work?
The model is based on observational science around software security. Over the years of research and findings, it provides a common measuring stick with using 113 activities for organizations. These activities are broken into 12 practices organized into 4 Domains viz. Governance, Intelligence, SSDL Touchpoints, and Deployment. BSIMM’s Software Security Framework (SSF) and activity description provide a common mechanism to explain elements of software security initiatives, thus enabling organizations to uniformly compare their maturity model accordingly.
Advantages Of Adopting BSIMM Framework:
Enables organizations to start a Software Security Initiative (SSI)
Provide standard measuring criteria to measure and compare SSI within a domain or the Industry
Helps organizations to learn from other’s mistakes. So that they don’t repeat the same. It helps the members of the BSIMM community by bringing together people from companies who've measured, and they can compare notes and realize that often they have the same problems.
It will help them to plan, execute and measure initiate on their own without having on board any third party for the same. The analysis consists of around 100 big companies like Microsoft, EMC, Google etc, which can help you leverage the years of experience captured in the model and help you improve your own software security initiative.
It gives you the clarity on what is “the right thing to do”.
This model will help industries and business units, measure the current state of their software security initiative, identify gaps, prioritize change, by applying scientific principles and determine how and where to apply resources for immediate improvement by comparing it with other existing security software initiative organizations.
It helps in cost reduction through standard, repeatable processes.
Roles In Software Security Initiative
When it comes to making the software security initiative to perform well, one of the important factors is determining roles to perform the activities described in the BSIMM framework. Let us begin with the brief outlook of those roles:
A senior executive plays a primary role in SSF by handling operations and garner resources. The senior executive supports to address two main management concerns: empowerment and accountability. Most of the organizations have the executive in charge of SSF, but they are designated in different names. Chief of Product Security, VP Cybersecurity, CIO, CISO, Chief Data Security & Privacy Officer, to name a few.
Software Security Group (SSG)
Next, to senior executive, the software security group is the most important role to create before adapting the activities of BSIMM. A good SSG should include the persons with coding knowledge and personal with the architectural skill set. Make sure that the people involved in the SSG team possess skills like communication skill, consulting practical knowledge and teaching capability since they are often required to train the hundreds of developers.
Satellite refers the group of people, including developers, testers & architects who are interested in software security, but not worked with the SSG team. The organization should identify those professionals and develop the satellite to work well with BSIMM.
The following are other roles who commonly need to be involved in addressing software security.
Builders - They can be developers or architectures and they are required to ensure that the system developed is flawless and defensible.
Testers – Required to perform security testing practices to catch the security problems.
Operations – These people are responsible to maintain and defend the system continued even after delivery.
Administrator – One who aware the distributed nature of the system and ensure the least privilege principle especially in the cloud.
Executive & Middle Management – Includes product managers and business owners who understand the necessity of focussing on early security design and analysis and enforce the same.
Vendors – Includes people who are supplying custom software, COTS and software-as-a-service. They are required to review that the application is a development of the process of secure SDLC.
After doing research and interviewing 109 organizations from various sectors, BSIMM developed a framework to assist the organization in quantifying the software security initiatives. The framework has organized 113 activities under 12 security practices to evaluate the software security initiatives. The following image illustrates the domains and security practices:
Image source: BSIMM
These are practices, assisting companies to organize, manage and measure a Software Security Initiatives (SII).
Strategy & Metrics (SM):
This practice ensures security process planning and publication, assisting in defining software security goals and required measurement metrics. Identify quality gates along with the definition of roles and responsibilities. It also talks about awareness related education programs especially for Management/Executives to ensure well-informed decision making.
Compliance & Policy (CP):
As the name suggests, Compliance and Policy practice has focused on regulatory or compliance drivers such as PCI DSS and HIPPA. It consists of activities related to PII obligation identification, defining security policy and processes to fulfil such requirements like defining SLA, Contracts, audit scope, etc.
Training is required to have basic security knowledge for all level of participants in SSDLC. Awareness Training should be mandatory for all, along with identification training requirement based on individual Role and Responsibility.
These are practices results in collections and identification of corporate intelligence related to SSI. Pro-active Security Guidance along with processes like Threat Modeling define different activities.
Attack Models (AM)
In this practice, the developer thinks like an attacker and create knowledge of technology-specific attack patterns. This knowledge will then guide decisions about code and controls. Data Classification, collecting information on technology-specific attack patterns, building possible attack list and related case studies, etc are some of the major activities as part of defining Attack Models.
Security Features & Design (SFD)
SFD practice provides guidance on building, reviewing and publication of proactive security features, building or providing pointers to secure-by-design frameworks along with mature design patterns for major security controls.
Standards & Requirements (SR)
This practice explains the standard explicit security requirements for the organizations. It assists in both building recommendation and tracking of standard Security Controls to be used aligned with industry standards. Creation of the review board, SLA checkpoints and policies to handle open source risk are part of the same.
This domain is the most familiar of the four. It talks about essential security best practices required in Software Development Phases (SDLC).
Architecture Analysis (AA):
The primary goal of this practice is to build the quality control, by performing security feature and design review process for high-risk applications.
Code Review (CR):
As the name suggests, these practices include activities related to secure code implementation and review process. Defining different roles involved in the code review process, standards to follow in coding along with a process for defect management is part of the same. It also provides a track for both manual and automated code review process.
Security Testing (ST):
This practice deals with activities related different Security Testing methods like Black-box, Fuzzing, Automation, Risk-driven White Box Analysis etc. It deals with vulnerabilities in application construction.
This domain includes practices that deals with network security and software maintenance requirements. Software configuration, maintenance and other environmental issues and their impact are detailed in this domain.
Penetration Testing (PT):
This practice involves the activities related to vulnerability discovery and correction of security defects, on to the software that has moved to deploy. This needs to be done adhering to standards and reuse of approved security features. Handling external penetration testing process and defining the scope for same is part of such activities.
Software Environment (SE):
This practice includes activities related to Secure Software Deployment and Maintenance. Usage of code protection mechanism, publication of installation and secure deployment practice/guides, configuration documentation etc. are part of such activities. It also talks about mechanism related to application behavior monitoring and diagnostics.
Configuration Management & Vulnerability Management (CMVM):
The goal of this practice is track activities related to patching, version control, and change management. It also deals with building Incident Handling plans and simulate responses to software crisis.
Based on the report of activities of the various participating companies, BSIMM provides the BSIMM skeleton that offers the way to understand the model and assess the security initiatives. Based on the percentage of companies performing particular activities, they mention 12 security activities as the core activities that are commonly found in successful programs. Any organization who wants to work with their own security initiatives, can consider those twelve core activities that every organization does. The following image illustrates the core activities:
Image Source: BSIMM
BSIMM standards are highly accepted by organizations across the industries and it is also helping them to compare their software security initiations with industry peers. This is helping them to increase their business units, and drive their budgeting. According to many security reports, the computer security industry is growing fast at a rate of about 8.9% per year, generating between $20 and $40 billion in revenue annually. Currently, Software Security accounts for 10% of that growth and is growing at twice the rate per year.
Hack2Secure assist organization in the adoption of BSIMM framework along with evaluation and implementation of security controls across Secure SDLC phases.