A framework is a basic conceptual structure used to solve or address complex issues. This very broad definition has allowed the term to be used as a buzzword, especially in a software context.

A structure to hold together or support something, a basic structure.

The Capability Maturity Model Integration (CMMI®) is a world-class performance improvement framework for competitive organizations that want to achieve high-performance operations. Building upon an organization’s business performance objectives, CMMI provides a set of practices for improving processes, resulting in a performance improvement system that paves the way for better operations and performance. More than any other approach, CMMI doesn’t just help you to improve your organizational processes. CMMI also has built-in practices that help you to improve the way you use any performance improvement approach, setting you up to achieve a positive return on your investment.

CMMI does not provide a single process. Rather, the CMMI framework models what to do to improve your processes, not define your processes. CMMI is designed to compare an organization’s existing processes to proven best practices developed by members of industry, government, and academia; reveal possible areas for improvement; and provide ways to measure progress.

The result? CMMI helps you to build and manage performance improvement systems that fit your unique environment.

CMMI is not just for software development. CMMI helps software and services organizations in a variety of industries to align meaningful process improvement with business and engineering goals for cost, schedule, productivity, quality, and customer satisfaction.

CMMI helps companies to improve operational performance by lowering the cost of development, production, and delivery. CMMI provides the framework for you to consistently and predictably deliver the products and services that your customers want, when they want them.

CMMI offers three constellations—CMMI for Acquisition, CMMI for Development, and CMMI for Services—that help to improve specific business needs, plus the People Capability Maturity Model (People CMM), which uses process framework as a foundation to help organizations managing and developing their workforce to become an employer of choice. Across these three constellations and the People CMM, CMMI delivers measurable results for organizations of all sizes in a variety of industries, including aerospace, finance, health services, software, defense, transportation, and telecommunications.

Companies want to deliver products and services better, faster, and cheaper. At the same time, in the high-technology environment of the twenty-first century, nearly all organizations have found themselves building increasingly complex products and services. It is unusual today for a single organization to develop all the components that compose a complex product or service. More commonly, some components are built in-house and some are acquired; then all the components are integrated into the final product or service. Organizations must be able to manage and control this complex development and maintenance process.

The problems these organizations address today involve enterprise-wide solutions that require an integrated approach. Effective management of organizational assets is critical to business success. In essence, these organizations are product and service developers that need a way to manage their development activities as part of achieving their business objectives.

In the current marketplace, maturity models, standards, methodologies, and guidelines exist that can help an organization improve the way it does business. However, most available improvement approaches focus on a specific part of the business and do not take a systemic approach to the problems that most organizations are facing. By focusing on improving one area of a business, these models have unfortunately perpetuated the stovepipes and barriers that exist in organizations.

CMMI® for Development (CMMI-DEV) provides an opportunity to avoid or eliminate these stovepipes and barriers. CMMI for Development consists of best practices that address development activities applied to products and services. It addresses practices that cover the product’s lifecycle from conception through delivery and maintenance. The emphasis is on the work necessary to build and maintain the total product.

Organizations are increasingly becoming acquirers of needed capabilities by obtaining products and services from suppliers and developing less and less of these capabilities in-house. This widely adopted business strategy is designed to improve an organization’s operational efficiencies by leveraging suppliers’ capabilities to deliver quality solutions rapidly, at lower cost, and with the most appropriate technology.

Acquisition of needed capabilities is challenging because acquirers have overall accountability for satisfying the end user while allowing the supplier to perform the tasks necessary to develop and provide the solution.

Mismanagement, the inability to articulate customer needs, poor requirements definition, inadequate supplier selection and contracting processes, insufficient technology selection procedures, and uncontrolled requirements changes are factors that contribute to project failure. Responsibility is shared by both the supplier and the acquirer. The majority of project failures could be avoided if the acquirer learned how to properly prepare for, engage with, and manage suppliers.

In addition to these challenges, an overall key to a successful acquirer-supplier relationship is communication.

Unfortunately, many organizations have not invested in the capabilities necessary to effectively manage projects in an acquisition environment. Too often acquirers disengage from the project once the supplier is hired. Too late they discover that the project is not on schedule, deadlines will not be met, the technology selected is not viable, and the project has failed.

The acquirer has a focused set of major objectives. These objectives include the requirement to maintain a relationship with end users to fully comprehend their needs. The acquirer owns the project, executes overall project management, and is accountable for delivering the product or service to the end users. Thus, these acquirer responsibilities can extend beyond ensuring the product or service is delivered by chosen suppliers to include activities such as integrating the overall product or service, ensuring it makes the transition into operation, and obtaining insight into its appropriateness and adequacy to continue to meet customer needs.

CMMI® for Acquisition (CMMI-ACQ) enables organizations to avoid or eliminate barriers in the acquisition process through practices and terminology that transcend the interests of individual departments or groups.

The service industry is a significant driver for worldwide economic growth. Guidance on developing and improving mature service practices is a key contributor to the service provider performance and customer satisfaction. The CMMI® for Services (CMMI-SVC) model is designed to begin meeting that need.

All CMMI-SVC model practices focus on the activities of the service provider. Seven process areas focus on practices specific to services, addressing capacity and availability management, service continuity, service delivery, incident resolution and prevention, service transition, service system development, and strategic service management processes.

The purpose of the BSIMM is to quantify the activities carried out by real software security initiatives. Because these initiatives make use of different methodologies and different terminology, the BSIMM requires a framework that allows us to describe all of the initiatives in a uniform way. Our Software Security Framework (SSF) and activity descriptions provide a common vocabulary for explaining the salient elements of a software security initiative, thereby allowing us to compare initiatives that use different terms, operate at different scales, exist in different vertical markets, or create different work products.

We classify our work as a maturity model because improving software security almost always means changing the way an organization works—something that doesn’t happen overnight. We understand that not all organizations need to achieve the same security goals, but we believe all organizations can benefit from using the same measuring stick.

BSIMM6 is the sixth major version of the BSIMM model. It includes updated activity descriptions, data from 78 firms in multiple vertical markets, and a longitudinal study.

The BSIMM is meant for use by anyone responsible for creating and executing a software security initiative. We have observed that successful software security initiatives are typically run by a senior executive who reports to the highest levels in an organization. These executives lead an internal group that we call the software security group (SSG), charged with directly executing or facilitating the activities described in the BSIMM. The BSIMM is written with the SSG and SSG leadership in mind.

Our work with the BSIMM model shows that measuring a firm’s software security initiative is both possible and extremely useful. BSIMM measurements can be used to plan, structure, and execute the evolution of a software security initiative. Over time, firms participating in the BSIMM show measurable improvement in their software security initiatives.

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. The resources provided by SAMM will aid in:

• Evaluating an organization’s existing software security practices

• Building a balanced software security assurance program in well-defined iterations

• Demonstrating concrete improvements to a security assurance program

• Defining and measuring security-related activities throughout an organization

SAMM was defined with flexibility in mind such that it can be utilized by small, medium, and large organizations using any style of development. Additionally, this model can be applied organization-wide, for a single line-of-business, or even for an individual project. Beyond these traits, SAMM was built on the following principles:

• An organization’s behavior changes slowly over time—A successful software security program should be specified in small iterations that deliver tangible assurance gains while incrementally working toward long-term goals.

• There is no single recipe that works for all organizations—A software security framework must be flexible and allow organizations to tailor their choices based on their risk tolerance and the way in which they build and use software.

• Guidance related to security activities must be prescriptive—All the steps in building and assessing an assurance program should be simple, well-defined, and measurable. This model also provides roadmap templates for common types of organizations.

The foundation of the model is built upon the core business functions of software development with security practices tied to each [see Table 3.2]. The building blocks of the model are the three maturity levels defined for each of the twelve security practices. These define a wide variety of activities in which an organization could engage to reduce security risks and increase software assurance. Additional details are included to measure successful activity performance, understand the associated assurance benefits, estimate personnel, and other costs.

Table 3.2 OWASP SAMM Business Functions and Security Practices [OWASP 2015]

Practical Measurement Framework for Software Assurance and Information Security provides an approach for measuring the effectiveness of achieving software assurance goals and objectives at an organizational, program, or project level. It addresses how to assess the degree of assurance provided by software, using quantitative and qualitative methodologies and techniques. This framework incorporates existing measurement methodologies and is intended to help organizations and projects integrate SwA measurement into their existing programs.

Practical Measurement Framework for Software Assurance and Information Security provides an approach for measuring the effectiveness of achieving software assurance goals and objectives at an organizational, program, or project level. It addresses how to assess the degree of assurance provided by software, using quantitative and qualitative methodologies and techniques. This framework incorporates existing measurement methodologies and is intended to help organizations and projects integrate SwA measurement into their existing programs.

Software assurance is interdisciplinary and relies on methods and techniques produced by other disciplines, including project management, process improvement, quality assurance, training, information security/information assurance, system engineering, safety, test and evaluation, software acquisition, reliability, and dependability [as shown in Figure 3.2].

Figure 3.2 Cross-Disciplinary Nature of SwA [Bartol 2008]

The Practical Measurement Framework focuses principally, though not exclusively, on the information security viewpoint of SwA. Many of the contributing disciplines of SwA enjoy an established process improvement and measurement body of knowledge, such as quality assurance, project management, process improvement, and safety. SwA measurement can leverage measurement methods and techniques that are already established in those disciplines, and adapt them to SwA. The Practical Measurement Framework report focuses on information assurance/information security aspects of SwA to help mature that aspect of SwA measurement.

This framework provides an integrated measurement approach, which leverages five existing industry approaches that use similar processes to develop and implement measurement as follows:

• Draft National Institute of Standards and Technology (NIST) Special Publication (SP) 800-55, Revision 1, Performance Measurement Guide for Information Security

• ISO/IEC 27004 Information technology—Security techniques—Information security management measurement

• ISO/IEC 15939, System and Software Engineering—Measurement Process, also known as Practical Software and System Measurement (PSM)

• CMMI Measurement and Analysis Process Area

• CMMI GQ(I)M—Capability Maturity Model Integration Goal Question Indicator Measure

The Practical Measurement Framework authors selected these methodologies because of their widespread use among the software and systems development community and the information security community. The Framework includes a common measure specification table which is a crosswalk of specifications, templates, forms and other means of documenting individual measures provided by the five industry approaches listed above that were leveraged to create the framework.

Measures are intended to help answer the following five questions:

• What are the defects in the design and code that have a potential to be exploited?

• Where are they?

• How did they get there?

• Have they been mitigated?

• How can they be avoided in the future?

A number of representative key measures for different stakeholder groups are included in the framework to help organizations assess the state of their SwA efforts during any stage of a project:

• Supplier—an individual or an organization that offers software and system-related products and services to other organizations. This includes software developers, program managers, and other staff working for an organization that develops and supplies software to other organizations.

• Acquirer—an individual or an organization that acquires software and system-related products and services from other organizations. This includes acquisition officials, program managers, system integrators, system owners, information owners, operators, designated approving authorities (DAAs), certifying authorities, independent verification and validation (IV&V), and other individuals who are working for an organization that is acquiring software from other organizations.

Within each supplier and acquirer organization, the following stakeholders are considered:

• Executive Decision Maker—a leader who has authority to make decisions and may require quantifiable information to understand the level of risk associated with software to support decision-making processes.

• Practitioner—an individual responsible for implementing SwA as a part of their job.

Secure by Design

Secure architecture, design, and structure. Developers consider security issues part of the basic architectural design of software development. They review detailed designs for possible security issues, and they design and develop mitigations for all threats.

• Threat modeling and mitigation. Threat models are created, and threat mitigations are present in all design and functional specifications.

• Elimination of vulnerabilities. No known security vulnerabilities that would present a significant risk to the anticipated use of the software remain in the code after review. This review includes the use of analysis and testing tools to eliminate classes of vulnerabilities.

• Improvements in security. Less secure legacy protocols and code are deprecated, and, where possible, users are provided with secure alternatives that are consistent with industry standards.

Secure by Default

• Least privilege. All components run with the fewest possible permissions.

• Defense in depth. Components do not rely on a single threat mitigation solution that leaves users exposed if it fails.

• Conservative default settings. The development team is aware of the attack surface for the product and minimizes it in the default configuration.

• Avoidance of risky default changes. Applications do not make any default changes to the operating system or security settings that reduce security for the host computer. In some cases, such as for security products, it is acceptable for a software program to strengthen (increase) security settings for the host computer. The most common violations of this principle are games that either open firewall ports without informing the user or instruct users to open firewall ports without informing users of possible risks.

• Less commonly used services off by default. If fewer than 80 percent of a program’s users use a feature, that feature should not be activated by default. Measuring 80 percent usage in a product is often difficult because programs are designed for many different personas. It can be useful to consider whether a feature addresses a core/primary use scenario for all personas. If it does, the feature is sometimes referred to as a P1 feature.

Secure in Deployment

• Deployment guides. Prescriptive deployment guides outline how to deploy each feature of a program securely, including providing users with information that enables them to assess the security risk of activating non-default options (and thereby increasing the attack surface).

• Analysis and management tools. Security analysis and management tools enable administrators to determine and configure the optimal security level for a software release.

• Patch deployment tools. Deployment tools aid in patch deployment.

Communications

• Security response. Development teams respond promptly to reports of security vulnerabilities and communicate information about security updates.

• Community engagement. Development teams proactively engage with users to answer questions about security vulnerabilities, security updates, or changes in the security landscape.

2. Risk Management

Outcome: Graduates will have the ability to perform risk analysis and tradeoff assessment and to prioritize security measures.

2.1. Risk Management Concepts

2.1.1. Types and classification [L4]

Different classes of risks (for example, business, project, technical)

2.1.2. Probability, impact, severity [L4]

Basic elements of risk analysis

2.1.3. Models, processes, metrics [L4] [L3—metrics]

Models, process, and metrics used in risk management

2.2. Risk Management Process

2.2.1. Identification [L4]

Identification and classification of risks associated with a project

2.2.2. Analysis [L4]

Analysis of the likelihood, impact, and severity of each identified risk

2.2.3. Planning [L4]

Risk management plan covering risk avoidance and mitigation

2.2.4. Monitoring and management [L4]

Assessment and monitoring of risk occurrence and management of risk mitigation

2.3. Software Assurance Risk Management

2.3.1. Vulnerability and threat identification [L3]

Application of risk analysis techniques to vulnerability and threat risks

2.3.2. Analysis of software assurance risks [L3]

Analysis of risks for both new and existing systems

2.3.3. Software assurance risk mitigation [L3]

Plan for and mitigation of software assurance risks

2.3.4. Assessment of Software Assurance Processes and Practices [L2/3]

As part of risk avoidance and mitigation, assessment of the identification and use of appropriate software assurance processes and practices

Our research has confirmed that decisions made in the acquisition and development of new software and software-based systems have a major impact on operational security. The challenge begins with properly stating software requirements and ensuring they clearly and practically define security. This is fundamental to the development and fielding of effectively secure systems. When these systems must interoperate with other systems built at a different time and with varying degrees of security, effective operational security becomes much more complex. Software and systems acquired, designed, and developed with operational security in mind are more resistant to both intentional attack and unintentional failures. The goal is to build and acquire better, minimally defective software and systems that can

• possess, through testing and analysis, some measurable level of assurance of minimal vulnerabilities

• operate correctly in the presence of most attacks by either resisting the exploitation of weaknesses in the software or tolerating the failures that result from such exploits

• recognize an attack and respond with expected behaviors that support resistance and recovery

• limit the damage from failures caused by attack or unanticipated faults and events and recover as quickly as possible

Managing complexity and ensuring survivability requires engineering methods based on solid foundations and the realities of current and emerging systems. A great deal of security response is reactive—addressing security issues in response to an attack. A more effective approach is to reduce the potential of such attacks by removing the vulnerabilities that allow a compromise in the first place. Our efforts to address issues before they become a security problem focus on the following key areas:

Secure Coding addresses tools, techniques, and standards that software developers and software development organizations require to eliminate vulnerabilities resulting from coding errors before software is deployed.

Vulnerability Analysis reduces the security risks posed by software vulnerabilities by addressing both the number of vulnerabilities in software that is being developed and the number of vulnerabilities in software that is already deployed. Our vulnerability analysis work is divided into two areas. Identifying and reducing the number of new vulnerabilities before the software is deployed is the focus of our vulnerability discovery effort, while our vulnerability remediation work deals with existing vulnerabilities in deployed software. We regularly comment on issues of importance to the vulnerability analysis and security community through the CERT/CC Blog.

Cyber Security Engineering addresses research needed to prepare acquirers, managers, developers, and operators of largescale, complex, networked systems to address security, survivability, and software assurance throughout the design and acquisition lifecycles. This research encompasses four areas: Software Assurance, Security Requirements, Software Supply Chain Risk Management (SCRM), and Software Risk Management. Because much of the DoD software is vendor developed, the research addresses both internal development and acquired software sources.

• Establish a plan for addressing resiliency as part of the organization’s (or supplier’s) regular development lifecycle and integrate the plan into the organization’s corresponding development process. Plan development and execution includes identifying and mitigating risks to the success of the project.

• Identify practice-based guidelines that apply to all phases such as threat analysis and modeling as well as those that apply to a specific lifecycle phase.

• Elicit, identify, develop, and validate assurance and resiliency requirements (using methods for representing attacker and defender perspectives, for example). Such processes, methods, and tools are performed alongside similar processes for functional requirements.

• Use architectures as the basis for design that reflect a resiliency and assurance focus, including security, sustainability, and operations controls.

• Develop assured and resilient software and systems through processes that include secure coding of software, software defect detection and removal, and the development of resiliency and assurance controls based on design specifications.

• Test assurance and resiliency controls for software and systems and refer issues back to the design and development cycle for resolution.

• Conduct reviews throughout the development life cycle to ensure that resiliency (as one aspect of assurance) is kept in the forefront and given adequate attention and consideration.

• Perform system-specific continuity planning and integrate related service continuity plans to ensure that software, systems, hardware, networks, telecommunications, and other technical assets that depend on one another are sustainable.

• Perform a post-implementation review of deployed systems to ensure that resiliency (as well as assurance) requirements are being satisfied as intended.

• In operations, monitor software and systems to determine if there is variability that could indicate the effects of threats or vulnerabilities and to ensure that controls are functioning properly.

• Implement configuration management and change control processes to ensure software and systems are kept up to date to address newly discovered vulnerabilities and weaknesses (particularly in vendor-acquired products and components) and to prevent the intentional or inadvertent introduction of malicious code or other exploitable vulnerabilities.

Resiliency requirements for software and system technology assets in operation, including those that may influence quality attribute requirements in the development process, are developed and managed in the Resiliency Requirements Development (RRD) and Resiliency Requirements Management (RRM) process areas respectively.

Identifying and adding newly developed and acquired software and system assets to the organization’s asset inventory is addressed in the Asset Definition and Management (ADM) process area.

The management of resiliency for technology assets as a whole, particularly for deployed, operational assets, is addressed in the Technology Management (TM) process area. This includes, for example, asset fail-over, backup, recovery, and restoration.

Acquiring software and systems from external entities and ensuring that such assets meet their resiliency requirements throughout the asset life cycle is addressed in the External Dependencies Management process area. That said, RTSE specific goals and practices should be used to aid in evaluating and selecting external entities that are developing software and systems (EXD:SG3.SP3), formalizing relationships with such external entities (EXD:SG3.SP4), and managing an external entity’s performance when developing software and systems (EXD:SG4).

Monitoring for events, incidents, and vulnerabilities that may affect software and systems in operation is addressed in the Monitoring (MON) process area.

Service continuity plans are identified and created in the Service Continuity (SC) process area. These plans may be inclusive of software and systems that support the services for which planning is performed.