Comparing BSIMM and SAMM Software Security Models

Comparing BSIMM and SAMM Software Security Models

The role of the information assurance security program as described by Sadiku, Alam, & Musa (2017) is the practice of protecting and defending information systems by ensuring their availability, confidentiality, integrity, authentication, and non-repudiation. Information assurance is increasing in importance as threats abound in the connected and distributed information sharing networking and information systems. Many organizations do not know how mature there information assurance and security program, process and the procedure is. Implementing an Information Security Assurance Capability Maturity Model (ISA-CCM) can assist the organization in maturing the information assurance and security program as described by Security Horizon. (2012). The Capability Maturity Model (CMM) does not assist an organization in how things are not operating correctly but provides a roadmap for the organization to change the culture as Krebs (2015) points out.

Capability Maturity Model Evolution

Capability Maturity Model Background

The Capability Maturity Model (CMM), at a high level, refers to the process improvement method that is based on process models as Jacobs (2015) discusses. The first CMM was developed by the Software Engineering Institute (SEI) in the 1980s. Following the model developed at the SEI many more process models were released. In fact, the US Department of Defense mandates Capability Maturity Model compliance by all of its more significant product and service suppliers.

The initial funding for the first CMM came from United States military research. Carnegie-Mellon Software Engineering Institute was requested and funded by the US Air Force create a model for the military to use to evaluate software subcontractors objectively, and the outcome of the research was the CMM published in 1989 and entitled Managing the Software Process. A CMM is a method of refining an organization's processes. The CMM provides an organization somewhere to start. The CMM enables a structure for capturing organizations past experiences and allows them to have a shared vision and shared language as Jacobs (2015) points out. The CMM framework assists in rating the priorities and provides a method to identify what the meaning of improvement is to the organization.

Information Security Capability Maturity Models

The Open Web Application Security Project (OWASP) has created many open security standards. One of them is the Software Assurance Maturity Model (SAMM) and OWASP released the 1.0 version in March of 2009. The SAMM project initially developed by Pravir Chandra as Sullivan & Liu (2012) points out. The SAMM defines four business functions, a collection of activities and process that every software engineering shop performs. The high-level functions are Governance, Construction, Verification and Deployment as described by Sullivan & Liu (2012). For each of the four business functions, SAMM identifies three security practices key to making the software security assurance better. SAMM defines four maturity levels for a security practice from zero to four. They are unfulfilled (0), initial understanding (1), increase in efficiency and or effectiveness (2), and mastery at the scale of the security practice (3).

The Information Security (INFOSEC) Assurance Capability Maturity Model (IA-CMM) is created from the information documented in the System Security Engineering Capability Maturity Model (SSE-CMM), as described by Kouns & Minoli (2009), and then revised to include INFOSEC assurance practices. The IA-CMM assessment process focuses on an organization’s capability to support INFOSEC analyst in conducting their mission objectives. Two main things are measured in the IA-CMM which are how mature the processes or functions that create the products. The example of products, in this case, are threats, countermeasures, and identified vulnerabilities. The second measure is the level of compliance a process has concerning an INFOSEC Assurance Training and Rating Program (IATRP) methodology. A measurement of the assurance that the organization can regularly perform a process. Nine processes areas make up the IA-CMM as described by Kouns & Minoli (2009).

Problem Statement

Organizations have problems when they do not have a handle on the information assurance security programs procedures and processes that need to be in place to assist the organization. The cause many times is the security team is unsure how to advance or mature the information security assurance program for the community or organization.

Relevance and Significance

Discussion of the relevance and significance of the research paper. The purpose of this paper is to research and compare the similarities of the Building Security in Maturity Model (BSIMM) Version 8 and the Software Assurance Maturity Model (SAMM) information assurance capability maturity models that assist organizations in building an organizations maturity level from stage one to stage three.

Security Maturity Capability Maturity Models

This section discusses the topics found in both the SAMM and BSIMM. Areas to be compared within each framework are the Controls and Governance, Intelligence and Threat Assessment, Secure Software Development Lifecycle Interactions and a Deployment section that discusses the security maturity in the production release of the software.

Controls and Governance

The business or organization must identify what policies, standards, and controls are essential in implementing to reduce the security risks identified. Promoting awareness and understanding amongst the team members is also required. Once policies, standards, and controls are implemented information security must assess the compliance and control effectiveness of what is put and place and revise if needed as Peltier (2013) discusses.

Security is expensive and complicated and now has focused attention on many organization as described by Brotby (2009) and the outcome has been the high awareness and attention to security governance. For security to become effective, it has to become part of the overall governance of the organization and cannot be outside the overall governance of the organization. Governance, as described by Brotby (2009), consists of a collection of duties implemented by an organization’s board of directors and executive team. The end state is to provide a strategic path that provides for reaching objectives, management of risk levels in the organization, and confirmation that the organizational resources are used correctly.

What follows next is the similarities between the SAMM and BSIMM for the Strategy and Measures, Compliance and Policy, and Education. Table 1. Controls & Governance Similarities is a summary of the similarities discussed.

Strategy & Measures

Having a strategy and measures or metrics is needed to define a software information assurance and security structure in an organization. Having a strategy in place and the ability to understanding or calculate the organization's businesses risk is vital to laying out the security goals as described by OWASP (2018). SAMM, as OWASP (2018) points out, establishes tactical guidelines for securing software at an organization (SAMM SM1), and once these guidelines are in place, they are to maintain them over time. Just as SAMM has the strategic roadmap and metric BSIMM includes a strategy and metrics section. The section includes defining goals, responsibilities, roles, and activities. BISMM as described by McGraw, Miguess & West (2017) also recommends having an internal security evangelist to assist in marketing internally in the organization and also have the organization executives educated in software security. BISMM points out that the metrics or measures should be used, not only for risk as OWASP (2018) discusses, but to drive budgetary requirements too. The areas identified as similar in this section are the identifying risks or educating executives or management, building and maintain a roadmap or process for the information assurance and security program and classifying the software and data based on the risk assessment.

Initial Risk Profile (SM 1.A)

The objective for SAMM is to generate an organizational strategic software security roadmap. The steps to achieve this, as OWASP (2018) points out, is having the organization produce an initial organization risk profile (SM 1.A). Once in place, the team keeps the roadmap up to date. In some cases, this can be done by a third-party consulting company or internal security or audit teams. Whatever resource is chosen, the information captured by the team should identify if the information assurance and security program are in place, if so verify the process. The results of the overall risk profile are to produce a list of the critical risks in the organization from software that is in use. Produce a security roadmap that focuses on the needs of the organization and provides a vision or understanding on how the assurance program will move forward in the future.

The BISIMM provides similar guidelines. The BISIMM section (SM1.3) is identified as “Educate Executives” as described by McGraw et al. (2017). In the section, the executives are provided software security issues within the organization that has a negative impact on business goals and is high risk. Showing the executives actual examples of high-risk software security issues within the organization enable them to embrace the software security initiative and want to add the initiative to the overall business risks for the company. By showing executives and board members working exploits within the organization it provides an example of the impact exploits have on the organization. It is also important to engage security experts to attest to the risks can assist in strengthening the executive team’s attention. Both the SAMM and BSIMM focus is to engage executives in including software security risks in the overall organizational risks for the company.

Organization Roadmap for Information Assurance (SM 1.B)

The organization needs to build a roadmap for software security within the organization as SAMM SM 1.B is discussed by OWASP (2018). Once a roadmap is in place the organization needs to understand the risks and the priorities of each risk. Than on the next iteration of the roadmap, the team can identify the practices that will be improved on the next iteration of the roadmap and risk setting practices. The BSIMM governance, strategy, and metrics section have a sub-area (SM1.1) that talks about publishing processes, roles, responsibilities and a plan. The plan to manage security within applications is referred to as the secure software development lifecycle (SSDL) and is usually a published document within the organization. The SDDL should progress as needed as time goes forward in the organization and be maintained by the Software Security Group (SSG) as McGraw et al. (2017) discusses.

Organization Risk Classification for Applications and Data (SM 2.A)

The SAMM area referred to SM 2.A suggests that an organization classify data and applications as OWASP (2018) points out. The organization needs to be aware of the risks that applications and data carried within the organization. Risk ratings for applications and data should be standardized, published and understood by team members developing software or maintaining data within the organization. The software asset inventory will assist in maintaining a risk rating by the application. The BSIMM section SR1.2, as described by McGraw et al. (2017), recommends that an organization maintain a software application security information site such as a wiki or portal that the SSG regularly updates application and data-oriented. The SSG team will evangelize the importance of the topic and communicate the portal and topics using community of practice meetings and mailing list to assist in directing teams to the portal and keeping them informed about the latest application security techniques.

Compliance & Policy

SAMM policies and compliance include three primary objectives which are to understand what drives appropriate governance and compliance, produce a baseline for security and compliance to understand risks by project and require compliance and measure projects against the organizational policy and standards. The BSIMM compliance and policy practices as described by McGraw et al. (2017) are focused on the regulators the organization or the customers require and become a part of the software security group. Another focus is the protection of personally identifiable information used in software. The team needs to understand the obligations that need to be followed by the organization to protect base on customer or regulatory requirements. The last focus is to define a software security policy that meets requirements that are set out by the organization, government, customer or regulatory requirements.

Identifying Organization Compliance and Policies (PC 1.A)

Recognizing and observing outside compliance drivers (PC 1.A) is part of the policy and compliance section of SAMM as discussed by OWASP (2018). The section focuses on the monitoring the external policy and compliance software programs and data at the organization. Team members also identify and focus on third-party regulatory that are standards for the business the organization is competing in. Adopting the policies and standards are industry standards today such as the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standards (PCI-DSS) or Sarbanes-Oxley Act (SOX). Software handling personally identifiable information (PII) information could have the need to be regulated. The SSG, as described by McGraw et al. (2017), fills this role for the organization as the BSIMM (CP1.2) lays out. Another point that the BISMM points out is that it does not matter where the software is running, in the cloud or the organization's data center.

Building and Maintaining Guidelines for Compliance (PC 1.B)

Building and maintaining an organization's compliance guidelines as described by OWASP (2018) is an area to focus on (PC 1.B). The consolidated list of software and data requirements are yielded from compliance audit results as OWASP (2018) points out, and these lists should be expanded to create a response statement for each requirement or a control statement. The audit process includes verifying each control statement for adequacy and measuring the organization against the control statements. It is important that they accurately signify actual organization practices. The BSIMM area, “Unify Regulatory Pressures Similarly” (CP1.1), as described by McGraw et al. (2017), requires the SSG to take a combined approach to eliminate redundancy and issue surrounding regulatory and compliance drivers. The SSG may need to work on working with internal organizations such as legal or auditing to find a unified solution to addressing how the organization complies with external standards and compliance.

Build policies and standards for security and compliance (PC 2.A)

Once current compliance guidelines are, as OWASP (2018) discusseses, in the SAMM section “Build Policies and Standards for Security and Compliance (PC 2.A)”, the organization continues to work on guidelines by reviewing regulator standards and identifying or recommending the adoptions of security requirements. After researching to discover new compliance implementations, changes to the compliance guidelines may need revision. The SSG team as described by McGraw et al. (2017) in the BSIMM “Create Security Standards (SR1.1)” area discuss that the team needs to publish security guidance and to create security standards that explain the best practice to execute and implement security oriented operations for software implementations. In some cases the implementation can be automated in others this may not be able to transpire, and manual implementation is required.

Education

The Education area identifies the need for organization training materials for secure programming and deployment as described by Security Horizon (2012). Education of the team members with the software lifecycle and its relation to secure development and offer development staff access to resources around the topics of secure programming and deployment.

Security Awareness Training (EG 1.A)

The organization, to keep staff up to date in security, need to conduct security training from internal or external parties as it is pointed out in the SAMM education section Conduct technical security awareness training (EG 1.A). The training topics provided need to cover technical information but also include conceptual training as OWASP (2018) discusses. One effective way to be sure training is completed is to mandate it each year. Comparable to SAMM, BSIMM recommends that the SSG team provide the security training (BSIMM T1.1…) to assist in promoting the software security culture within the organization. McGraw et al. (2017) describe in the BSIMM that providing awareness training focused on roles can assist the organization in enhancing the training and points out that general training is not adequate.

Role Specific Training (EG 2.A)

Conducting job or role specific application security training (EG 2.A) with a specific focus on a job role as SAMM education and guidance points out. Instructor based training or computer-based training should complete specific training for roles in programming, management, testers and auditors and training as OWASP (2018) discusses. Role-specific training as described by McGraw et al. (2017), in BSIMM T1.5, also points out that not only is training needed for software, but also for the development methods, technology stacks and even what common bugs that are pertinent to the software that the organization is training team members on.

Security Mentors and Coaches (EG 2.B)

The concept of a mentor or coach for security, is using an internal or external expert to provide consulting to enhance security on project teams as OWASP (2018) points out. SAMM EG 2.B identifies that the sufficient time to introduce a coach is at initial product conception, before completion of functional design or design. The coach can also be used to evangelize security relevant information throughout the organization. The BISMM as McGraw et al. (2017) points out uses the words satellite instead of a coach in “Create or Grow a Satellite” SM2.3. People are dispersed through the organization, with above average security skills and interest. This group of security activists or volunteers in the organization builds a social network to increase the security practices communications into the software development teams. McGraw et al. (2017) view are that a substantial satellite team or coaches are a sign of a mature software security initiative.

Intelligence & Threat Assessment

The Intelligence and Threat section covers the topics of Attack Methods and Threats, Security Features & Design Architecture, and Standards and Requirements. A summary of the similarities between the SAMM and BSIMM is depicted in Table 2. Intelligence & Threat Assessment Similarities.

Attack Methods and Threats

This section covers building and maintaining an application-oriented threat model and evaluating risks from third-party applications, modules, and open source.

Build & Maintain an Application Oriented Threat Model (TA 1.A)

Threat models that are application specific to the organization should be built and maintained as OWASP (2018) points out in SAMM section TA 1.A. For every business risk profile and software project they work to identify the worst-case scenarios for organizations software teams developing software. Working as a team the developers, architects, and security auditors work to build attack trees or threat modeling approaches. BSIMM’s view in area AA2.1 is to define and use architecture analysis (AA) processes where the SSG produces a process for the analysis and uses it design reviews to find flaws as McGraw et al. (2017) points out. Reviews should be a standardized approach to security attacks, properties, and associated risk.

Evaluate Risk from Third-Party Modules (TA 3.A)

The SAMM Threat Assessment TA 3.A activity assesses the risk from external third-party software components. Examples of third-party software components as described by OWASP (2018) could be purchased consumer off the shelf (COTS) application software, open sources or even software as a service over the Internet. In addition to risk, vulnerabilities and design flaws may be uncovered in the third-party code. BSIMM SR2.4, as McGraw et al. (2017) points out, one must identify the open source in the organization's applications before can understand the dependencies and impact. McGraw et al. (2017) goes on to discuss, in BSIMM SR3.1, that one needs to have control over open source risks of vulnerabilities from old open source code that is not kept updated and is an increased risk to the organization and the SSG.

Security Features & Design Architecture

Security Features and Design Architecture covers the assessment of security and compliance guidelines and building security requirements into third-party agreements and service level agreements.

Assess Security & Compliance Guidance for Requirements (SR 1.B)

SAMM section SR 1.B, as OWASP (2018) describes, entails the security team to identifying the industry best practices that application projects should adopt when in the requirements phase of an application project. If a project already exists, it can be challenging to refactor application code for security best practices. If unable to change the code that exists, recommendations should be provided so those changes can be incorporated into the application project code in the future. The BSIMM SR1.3 section, as McGraw et al. (2017) discusses recommending any compliance needs to be included at the start of the project. An example is if one is processing credit card transactions, then the Payment Card Industry Data Security Standard (PCI DSS) compliance would play a role in the team's project plan.

Include Security Requirements in Supplier Agreements (SR 3.A)

When working with supplier agreements, as described in SAMM SR 3.A, the organization, as OWASP (2018) describes, needs to build in security requirements into each supplier agreement. The application requirements and high-level design are typically produced by internal project members whereas the external application provider completes the detailed design and the implementation. In the BSIMM section CP2.4, McGraw et al. (2017) points out that the software security requirements or software security service level agreement (SLA) is crucial when negotiating an agreement with a cloud provider since the organization has the information technology for the organization running on the cloud provider’s hardware and operating environment.

Secure Software Development Lifecycle Interactions

Secure software development includes analyzing the architecture before the application is created and revisiting the project teams to review the design as the project progresses.

Architecture Analysis

Identify & Promote Security Services and Infrastructure (SA 2.A)

The SAMM Security Architecture SA 2.A and the BSIMM SFD1.1 actions point out that an organization should appoint a shared infrastructure or services with security functionally. These as OWASP (2018) describe typically are sign sign-on services, directory services applications, and access control software. Reducing each type to one solution or standard will simplify application development projects and assist in providing clear guidance from the security team that provides assurance and lowers risk for the organization. The BSIMM SFD1.1, as McGraw et al. (2017), identifies that the SSG needs to provide preemptive assistance by putting together and publishing security features for other groups to use and evangelizing them to the project teams. The SSG, the project team, and the organization benefit from partnering on using standard security solutions.

Identify Security Design Patterns from Architecture (SA 2.B)

The architecture team in the organization defines a standard application architecture. This architecture is followed across application projects. Examples of application categories are micro-service architecture, web, and mobile or desktop style applications. Identifying security design patterns as OWASP (2018) discusses, in the SAMM Secure Architecture area, SA 3.B, the ability of the architecture team to identify general design patterns of implementing security functionality. In some cases, the application code can be written, and in other scenarios, the application code can be purchased. The BSIMM SFD3.1 in addition to what SAMM discusses, McGraw et al. (2017) points out that a review board within the organization should formalize these standards and architecture and reach a consensus on design and security tradeoffs.

Establish Reference Architectures and Platforms (SA 3.A)

Formal platform and reference architecture established in the organization is outlined in the SAMM Secure Architecture SA 3.A activities. These reference platforms and architectures, as discussed by OWASP (2018), provide sample best practice code that becomes a shared application code base for other projects in the organization. The second method as described by OWASP (2018) is to build an initial reference platform by having the security team engage with the application team early in the development life-cycle and assist the team in building reusable code that could become part of the shared code base and used in future projects. BISMM SFD2.1, as described by McGraw et al. (2017), recommends that the SSG is to lead in a proactive way building and to provide advice to project teams on how to secure by design. The SSG is providing common libraries and frameworks which allows the project teams to learn by example.

Validate Usage of Frameworks, Patterns, and Platforms (SA 3.B)

The SAMM Security Architecture section 3.B is for validating the platform, pattern, and frameworks used by project teams in the application design as OWASP (2018) discusses. The routine security audits are in place to ensure the security team set-up assessment services to review software design against general best practices for security as described by OWASP (2018). The security teams is to support ad hoc reviews of software design to ensure baseline mitigations for known risks. BSIMM SFD3.2 as McGraw et al. (2017) points out, must get agreement from the software project teams that security features and frameworks will be used from the approved list published by the SSG. Have the approved list in place and reusing the code enables refreshes when vulnerabilities or other risks are found. Since teams are using software on the approved list, it is easy to roll out common security libraries across project teams.

Design Review

Design review needs to occur at set stages in the development project to ensure baseline mitigations are created for known risks. The security team reviews the design will assist in mitigations and review the software design to compare the design to the security best practices for the organizations. This section covers identifying the software attack surface and how one analyzes a design against a known security requirement.

Identify Software Attack Surface (DR 1.A)

At the beginning of a software project a diagram or view of the system architecture is created, as OWASP (2018) points out, in the SAMM section DR 1.A. The information is gleaned from application project design documents, the interviews done with users and other organizational staff members. Once this information is collected, the software attack areas can be identified. Examples are interfaces for the authorized and authenticated users, any anonymous roles and administrators or operations staff. BSIMM sections AA1.2, AA1.3 and AA3.1 recommend that any applications that are identified as high risk should go through a design review. The SSG team should conduct the security architecture risk assessment, as McGraw et al. (2017) describes, and lead software architects should check the design and provided feedback based on initial standard security design and framework provided to the project team to follow at the start of the project.

Analyze Design against Known Security Requirements (DR 1.B)

The application programming security requirements should be recognized and recorded, as discussed by OWASP (2018), in the SAMM design review section DR 1.B and BSIMM AA.1 as described by McGraw et al. (2017). Once a list is gathered it should be compared to the security requirements and review an application system architecture diagram to assist in verifying each item. The analysis should be completed by a security team member or an application team security advocate with input from architecture, project team members and business stakeholders as needed.

Deployment

The Deployment section covers Security Testing, Configuration & Vulnerability Management, Implementation Review, Issue Management, Environmental Hardening and Operational Enablement. The Deployment similarities covered are summarized in Table 3. Deployment Similarities.

Configuration & Vulnerability Management

Configuration and vulnerability management covers implementation review, issue management, and environmental hardening within the maturity model.

Implementation Review

Perform Point-Review of High-Risk Code (IR 1.B)

The Implementation Review activity referred to as IR 1.B “Performing point-review of high-risk code” by OSWASP (2018) discusses application code identified with a raised or elevated security risk from vulnerabilities have increased impacts. Examples of high-risk areas of code are session management and input validation. Providing the application programming checklist for implementation the new code, then the checklist and analysis becomes a regular part of the development process as described by OWASP (2018). The BSIMM guideline CR1.2, for high-risk application, is to provide ad-hoc reviews by SSG as McGraw et al. (2017) points out. Tools or services are used to conduct the review and sometimes as new technologies are introduced, a new approach for code reviews may be needed.

Utilization of Automated Code Analysis Tools (IR 2.A)

The SAMM 2.A Implementation Review section, as OWASP (2018) and the BSIM section as McGraw et al. (2017), also recommends the use of automated code analysis tools. The scanning tools save time but produce false positives for the users and at the same time provide the ability to quickly draw attention to poorly written or suspicious areas of the application programming code. Application codes have complex portions that have vulnerabilities and software bugs, but with automated tools can easily be parsed and identified. BSIMM also recommends one investigate third-party external services that may be required depending on the type of code that needs to be reviewed as McGraw et al. (2017) points out. BSIMM ST2.4 recommends that SSG, on a regular basis share any security review with the quality assurance (QA) testing team. By sharing the security information with the QA test team, they begin to form a security mindset and assist the SSG team in identifying security issues in the future.

Customize Code Analysis for Application-Specific Concerns (IR 3.A)

Code analysis tools usually are delivered with a built-in database of rules to verify and check the code base against, as OWASP (2018) points out, in the Implementation Review category of the SAMM IR 3.A. Customization of the scanning tool is one way to increase the discovery of organizational or project-oriented security concerns. Tools allow customization and having the ability to check that internal coding standards are adhered or adding the ability to track and verify sensitive data handling is also useful. Code-based changes to the scanner should be reviewed by the security team to review code and rules to be sure the results are in line with expectations of standards and controls in place for the organization. The BSIMM covers custom code analysis in three different ways. The first, as McGraw et al. (2017) points out, is to use automated tools that allow customization (CR2.6) just as the SAMM standards discussed. The second area is the automation of malicious code detection (CR3.4). Having this in place will identify dangerous code written by any internal or external developers on the application development teams. The third area BSIMM recommends to have the SRG enforce coding standards via automation (CR3.5). Requiring code to pass through an automated check before deployment is an important part of a maturity process for enforcing best practices or coding standards set forth by the organization.

Issue Management

Identify Point of Contact for Security Issues (IM 1.A)

Issues occur and to streamline the management of issues, a point of contact is needed for each business unit or division of an organization as described by OWASP (2018) in the SAMM IM 1.A section of the Issue Management. In some cases, a contact at the project team is required. These contacts are needed to assist in adding governance and structure for the management of any incidents or vulnerabilities in the organization. Having a list of the chosen security-savvy technical and management kept up to date is helpful when incidents occur. The incident could occur in one part of the business by security assistance from another part of the business may be required to working an incident elsewhere in the organization. The SSG creates its own incident response capability or regularly connects with the organizations incident response team described in the BSIMM CMVM1.1 configuration management and vulnerability section as McGraw et al. (2017) points out. Many times, incidents response issues turn into software security issues once the incident has been worked and the vulnerability is realized.

Establish Reliable Issue Response Process (IM 2.A)

Having an incident response process consistent across the organization is included in the SAMM issue management IM 2.A. Not only should the procedure be consistent and document, but training provided for any team members that are seen to have involvement in significant incidents in the organization as OWASP (2018) points out. Many parts are included in an incident, such as triage, collecting forensic evidence and a communications plan to stakeholders. It is crucial for the application team to realize when an incident occurs how to contact the security response team if needed to take action. CMVM1.2 BSIMM, described by McGraw et al. (2017), has a similar recommendation, in that they include not only issue response but any errors that are raised by the operations monitoring put in place. The monitoring errors are also funneled back to development teams, so they are resolved. Sometimes they turn out to be security vulnerabilities.

Conduct Issue Root Cause Analysis (IM 3.A)

The issue occurs in the organization when working with software. In the Issue Management section of the SAMM, IM 3.A as OWASP (2018) points out the steps to take when an incident occurs, and the organization needs to include the root cause analysis. The root cause can be many things from human error, natural disaster, or a software bug. Finding the root cause of an incident will assist the organization in finding other potential equivalent weaknesses that could occur. Once identified any recommendations, positive or negative would be presented and reviewed by management and stakeholders to mitigate the risk or even accept it as a known risk. BSIMM CMVM3.2, as discussed by McGraw et al. (2017), have a feedback loop in the SSDL that includes feedback to SSDL so that the development project team gets involved in root cause analysis. McGraw et al. (2017) go on to point out this strategy works best with cross-functional agile teams because all the players on the team are involved.

Environment Hardening

Maintain Operational Environment Specification (EH 1.A)

For every application project implementation, an operating platform is chosen. The platform is created and maintained, and the choice should not only be with the application project team but also the support, operations, development staff and stakeholders. The team should take into account the business function of the software. Examples of drives for the decision is what kind of hardware the application will run on such as a laptop, desktop or mobile device. The confirmation of the requirements should be done with users, operations, and administrators. Taking these people into account for the operating environment is important as OWASP (2018) points out. BSIMM SE1.2 identifies the hosts the applications run on and network security as basics that should be part of the environmental specification. McGraw et al. (2017) goes on to discuss that regular patching of the basic environmental specification by operations security teams such as patching operating system and maintaining firewalls is key to maintaining an operational environment specification.

Identify & Deploy Appropriate Protection Tools (EH 3.A)

Environmental hardening is critical to have in place when the application is implemented to assure the organization's environment. Each organization environment can vary, so it is essential to have the correct tools in place for the situation as described by OWASP (2018) in the Environmental Hardening 3.A are of the SAMM. Examples of typical protection tools are application firewalls or network intrusion detection systems. The operations and support team should work with the project stakeholders to gain an understanding of the application to be implemented to understand tools that are best to implement based on the reducing risk versus return on investment or cost to implement. Monitoring application input for vulnerabilities is seen as environmental hardening in BSIMM SE1.1. An example of input monitoring is a web application firewall (WAF) as McGraw et al. (2017) discuss. One can monitor the input to software with a WAF to stop spot attacks by bad actors.

Operations Enablement

Collect Security Information for Application Deployment (OE 1.A)

The organization application project team should understand that the team needs to collect the critical security information for deployment as OWASP (2018) describes in the Operational Enablement OE 1.A of the SAMM. The security analysis should be completed by the application team and architects to solidify and document the security features included in the applications so, at implementation time security, audit and stakeholders understand the risks of the application. Publishing the installation guide is another way to capture security information for application deployment. BSIMM SE2.2, as McGraw et al. (2017), states that an installation guide should state the correct configuration of the application including security.

Perform Application Code Signing (OE 3.B)

Organizations need to provide data integrity. One method of providing data integrity for application code is by performing code signing in the section OE 3.B of the SAMM, as described by OWASP (2018) and BSIMM SE2.4 as McGraw et al. (2017). Code signing for the application is achieved by using cryptography to verify that the application installed is the application delivered by the organization or third-party software provider. Overhead is incurred signing the application, and the project stakeholders must identify if the application requires code signing or if the security audit team requires this type of integrity checking for applications in the organization.

Conclusion

The CMM, at its highest level, is a method to improve a method or procedure based on a consistently improving processes within the organization. In this paper, an overview of CMM and INFOSEC assurance CMM’s is covered and two INFOSEC assurance CMM’s compared their similarities discussed. The key areas focused on for CMM improvement were controls and governance, intelligence and threat assessment, secure software development lifecycle interactions and the deployment of software application code. By improving processes around these areas using a CMM overtime, the assurance of the software and data will improve as the CMM develops over time. While the CMM secure development methodologies reviewed in the paper cover a broad scope, the focus of the research paper is to understand the similarities between SIMM and BSIMM. Once understanding the similarity between SIMM and BSIMM, the paper inspires an organization to begin to identify and pick high-value return areas, maybe not all at once, but move forward with and gain the ability of applications being secure from attack in the application development teams of an organization.

References

Brotby, W. K. (2009). Information security management metrics. Boca Raton, FL: Auerbach Publications.

Jacobs, S. (2015). Engineering information security: The application of systems engineering concepts to achieve information assurance (2nd ed.). Hoboken, NJ: Wiley.

Kouns, J., & Minoli, D. (2009). Information technology risk management in enterprise environments: A review of industry practices and a practical guide to risk management teams. Hoboken, NJ: Wiley.

Krebs, B. (2015). What's your security maturity level? Krebs on Security.

McGraw, G., Migues, S., & West, J. (2017). Building security in maturity model (BSIMM) version 8. Synopsys.

OWASP. (2018). Software assurance maturity model: A guide to building security into software development, version 1.5. OWASP Foundation.

Peltier, T. R. (2013). Information security fundamentals (2nd ed.). Boca Raton, FL: CRC Press.

Sadiku, M. N. O., Alam, S., & Musa, S. M. (2017). Information assurance benefits and challenges: An introduction. Information & Security, 36, 1–5.

Security Horizon. (2012). Information security assurance capability maturity model (ISA-CMM), draft version 3.2. Security Horizon, Inc.

Sullivan, B., & Liu, V. (2012). Web application security: A beginner's guide. New York, NY: McGraw-Hill.