CMM

Lifecycle Model: Software Capability Maturity Model

● The Software Engineering Institute (SEI) at Carnegie Mellon University
introduced the Capability Maturity Model for Software, also known as the
Software Capability Maturity Model (abbreviated as SW-CMM, CMM, or SCMM),
which contends that all organizations engaged in software development move
through a variety of maturity phases in sequential fashion.
○ The SW-CMM describes the principles and practices underlying software process maturity.

● It is intended to help software organizations improve the maturity and quality of

their software processes by implementing an evolutionary path from ad hoc,
chaotic processes to mature, disciplined software processes. The idea behind
the SW-CMM is that the quality of software depends on the quality of its
development process.
 Innovative: Continuous
improvement

Predictable: Measure the processes

Core Competency: Come up with a generalized process for

wider audiences and domains

Control: Initiate defining processes at a high level, isolated projects

Ad-Hoc: Unplanned, Unsystematic, and Inconsistent

Lifecycle Model: Software Capability Maturity Model
● Level 1: Initial In this phase, you’ll often find hardworking people charging ahead
in a disorganized fashion. There is usually little or no defined software
development process.
Lifecycle Model: Software Capability Maturity Model
● Level 2: Repeatable In this phase, basic lifecycle management processes are
introduced.
○ Reuse of code in an organized fashion begins to enter the picture, and repeatable results are
expected from similar projects.
○ SEI (Software Engineering Institute) defines the key process areas for this level as Requirements
Management, Software Project Planning, Software Project Tracking and Oversight, Software
Subcontract Management, Software Quality Assurance, and Software Configuration Management.
● Level 3: Defined In this phase, software developers operate according to a set of
formal, documented software development processes.
○ All development projects take place within the constraints of the new standardized management
model.
○ SEI defines the key process areas for this level as Organization Process Focus, Organization
Process Definition, Training Program, Integrated Software Management, Software Product
Engineering, Intergroup Coordination, and Peer Reviews.
Lifecycle Model: Software Capability Maturity Model
● Level 4: Managed In this phase, management of the software process proceeds
to the next level.
○ Quantitative measures are utilized to gain a detailed understanding of the development process.
○ SEI defines the key process areas for this level as Quantitative Process Management and
Software Quality Management.

● Level 5: Optimizing In the optimized organization, a process of continuous

improvement occurs.
○ Sophisticated software development processes are in place that ensure that feedback from one
phase reaches to the previous phase to improve future results.
○ SEI defines the key process areas for this level as Defect Prevention, Technology Change
Management, and Process Change Management.
Threat Modeling
 Threat Modeling Concepts and Methodologies
● Threat modeling is the security process where potential threats are identified,
categorized, and analyzed.
○ Begin threat modeling early in the design process of a system and continue throughout its lifecycle.

● For example, Microsoft uses a Security Development Lifecycle (SDL) process to

consider and implement security at each stage of a product’s development.
○ This supports the motto of “Secure by Design, Secure by Default, Secure in Deployment and
Communication” (also known as SD3+C).
○ It has two goals in mind with this process:
■ To reduce the number of security-related design and coding defects
■ To reduce the severity of any remaining defects

● In other words, it attempts to reduce vulnerabilities and reduce the impact of any
vulnerabilities that remain. The overall result is reduced risk.
 Threat Modeling Concepts and Methodologies
● A proactive approach to threat modeling takes place during the early
stages of systems development, specifically during initial design and
specifications establishment.
○ This method is based on predicting threats and designing in specific defenses during the coding and
crafting process, rather than relying on post-deployment updates and patches.

● A reactive approach to threat modeling takes place after a product has

been created and deployed.
○ This deployment could be in a test or laboratory environment or to the general marketplace.
○ This technique of threat modeling is the core concept behind ethical hacking, penetration testing,
source code review, and fuzz testing.
 Identifying Threats
● Focused on Assets This method uses asset valuation results and attempts to identify threats to
the valuable assets.
○ For example, a specific asset can be evaluated to determine if it is susceptible to an attack. If the
asset hosts data, access controls can be evaluated to identify threats that can bypass authentication
or authorization mechanisms.
● Focused on Attackers Some organizations are able to identify potential attackers and can
identify the threats they represent based on the attacker’s goals.
○ For example, a government is often able to identify potential attackers and recognize what the
attackers want to achieve. They can then use this knowledge to identify and protect their relevant
assets. A challenge with this approach is that new attackers can appear that weren’t previously
considered a threat.
● Focused on Software If an organization develops software, it can consider potential threats
against the software. Although organizations didn’t commonly develop their own software
years ago, it’s common to do so today.
○ Specifically, most organizations have a web presence, and many create their own web pages. Fancy
web pages drive more traffic, but they also require more sophisticated programming and present
additional threats.
 Identifying Threats
● Microsoft developed a threat categorization scheme known as the
STRIDE threat model. STRIDE is often used in relation to assessing
threats against applications or operating systems.
○ Spoofing: An attack with the goal of gaining access to a target system through
the use of a falsified identity. Spoofing can be used against Internet Protocol
(IP) addresses, MAC addresses, usernames, system names, wireless
network service set identifiers (SSIDs), email addresses, and many other
types of logical identification.
○ Tampering
○ Repudiation
○ Information disclosure: The revelation or distribution of private, confidential, or
controlled information to external or unauthorized entities.
○ Denial of Service
○ Elevation of Privilege
 Identifying Threats
● Process for Attack Simulation and Threat Analysis (PASTA) is a
seven-stage threat modeling methodology.
● PASTA is a risk-centric approach that aims at selecting or
developing countermeasures in relation to the value of the
assets to be protected.
○ Stage I: Definition of the Objectives (DO) for the Analysis of Risks
○ Stage II: Definition of the Technical Scope (DTS)
○ Stage III: Application Decomposition and Analysis (ADA)
○ Stage IV: Threat Analysis (TA)
○ Stage V: Weakness and Vulnerability Analysis (WVA)
○ Stage VI: Attack Modeling & Simulation (AMS)
○ Stage VII: Risk Analysis & Management (RAM)
 Identifying Threats
● Other methods
○ Trike
○ Disaster, Reproducibility, Exploitability, Affected Users, and Discoverability
(DREAD)
○ Visual, Agile, and Simple Threat (VAST) is a threat modeling concept based on
Agile project management and programming principles.
 Determining Potential Attacks
Once a diagram has been crafted, identify all of the technologies
involved. This would include operating systems, applications
(network service and client based), and protocols. Be specific as to
the version numbers and update/patch level in use.

Next, identify attacks that could be targeted at each element

of the diagram. Keep in mind that all forms of attacks should
be considered, including logical/technical, physical, and social.
 Performing Reduction Analysis
● Reduction analysis is also known as decomposing the application, system, or
environment.
○ The purpose of this task is to gain a greater understanding of the logic of the product as
well as its interactions with external elements.

○ Whether an application, a system, or an entire environment, it needs to be divided into

smaller containers or compartments.
■ Those might be subroutines, modules, or objects if you’re focusing on software,
computers, or operating systems;
■ they might be protocols if you’re focusing on systems or networks; or
■ they might be departments, tasks, and networks if you’re focusing on an entire
business infrastructure.

○ Each identified sub-element should be evaluated in order to understand inputs,

processing, security, data management, storage, and outputs.
 Performing Reduction Analysis
● In the decomposition process, you must identify five key concepts:
○ Trust Boundaries Any location where the level of trust or security
changes”
○ Data Flow Paths The movement of data between locations
○ Input Points Locations where external input is received
○ Privileged Operations Any activity that requires greater privileges
than of a standard user account or process, typically required to
make system changes or alter security
○ Details about Security Stance and Approach The declaration of the
security policy, security foundations, and security assumptions
 Prioritization and Response
● As threats are identified, document those.
● After documentation, rank or rate the threats.
○ Use techniques such as Probability × Damage Potential ranking,
high/medium/low rating, or the DREAD system.
■ Damage potential: How severe is the damage likely to be if the threat is realized?
■ Reproducibility: How complicated is it for attackers to reproduce the exploit?
■ Exploitability: How hard is it to perform the attack?
■ Affected users: How many users are likely to be affected by the attack (as a
percentage)?
■ Discoverability: How hard is it for an attacker to discover the weakness?

● Response options should include making adjustments to software architecture,

altering operations and processes, and implementing defensive and detective
components.