Richard A. Caralli, Julia H. Allen, David W. White. CERT Resilience Management Model

Подождите немного. Документ загружается.

2. Communicate the list of stakeholders to planners and those responsible for

process performance.

3. Involve relevant stakeholders in the process as planned.

RRM:GG2.GP8 MONITOR AND CONTROL THE PROCESS

Monitor and control the resilience requirements management process against the plan for

performing the process and take appropriate corrective action.

Refer to the Monitoring process area for more information about the collection, organization,

and distribution of data that may be useful for monitoring and controlling processes.

Refer to the Measurement and Analysis process area for more information about establishing

process metrics and measurement.

Refer to the Enterprise Focus process area for more information about providing process

information to managers, identifying issues, and determining appropriate corrective actions.

Subpractices

1. Measure actual performance against the plan for performing the process.

2. Review accomplishments and results of the process against the plan for

performing the process.

Elaboration:

These are examples of metrics for the resilience requirements management process:

• number and percentage of services and assets for which requirements have been

defined and documented

• number and percentage of services and assets for which there are no stated

requirements or that have incomplete resilience requirements

Stakeholders are involved in various tasks in the resilience requirements manage-

ment process, such as

• planning for the management of resilience requirements

• resolving issues with the understanding of the requirements

• assessing the impact of requirements changes

• communicating requirements changes to those with a need to know

• identifying inconsistencies between requirements and the activities performed

to meet the requirements

• managing operational risks to assets

• managing relationships with external entities that support process activities

• reviewing and appraising the effectiveness of process activities

• resolving issues in the process

Resilience Requirements Management 787

RRM

3. Review activities, status, and results of the process with the immediate level of

management responsible for the process and identify issues.

Elaboration:

The results of periodic reviews should be elevated to higher-level managers to

ensure that the strategies for protecting and sustaining assets continue to be in

alignment with (1) their resilience requirements (that is, able to satisfy the

requirements) as requirements change and (2) the organization’s enterprise

resilience requirements and strategic objectives.

• number and percentage of asset owners actively participating in managing

changes to requirements for the assets under their control

• number and percentage of documented requirements that have not been

implemented

• number and percentage of asset custodians who are aware of and accept

responsibility for implementing requirements

• number and percentage of documented requirements that have not been

committed to

• number and percentage of requirements changed

• number of requirements changes and frequency of changes in total and by asset

or asset type

• number and percentage of requirements changes that are not subject to the

organization’s change control process

• number of unapproved requirements

• number of requirements that cannot be traced to a source

• schedule for analysis of proposed requirements changes

• number of requirements satisfied by existing controls

• number of inconsistencies detected between requirements and the activities in

place to satisfy the requirements

• number of action items required to address gaps and overlapping requirements

• number of requirements risks referred to the risk management process; number of

risks where corrective action is still pending (by risk rank)

• costs of documenting, analyzing, managing, and tracking requirements and

changes to requirements

• level of adherence to requirements management policies; number of policy viola-

tions; number of policy exceptions requested and number approved

• number of process activities that are on track per plan

• rate of change of resource needs to support the process

• rate of change of costs to support the process

788 PART THREE CERT-RMM PROCESS AREAS

4. Identify and evaluate the effects of significant deviations from the plan for

performing the process.

5. Identify problems in the plan for performing and executing the process.

6. Take corrective action when requirements and objectives are not being satisfied,

when issues are identified, or when progress differs significantly from the plan

for performing the process.

7. Track cor re ctive ac tion to closure.

RRM:GG2.GP9 OBJECTIVELY EVALUATE ADHERENCE

Objectively evaluate adherence of the resilience requirements management process against

its process description, standards, and procedures, and address non-compliance.

Elaboration:

Objective evaluation of the resilience requirements management process is

intended to ensure that requirements are up-to-date and available as the basis

for the organization’s development, implementation, and management of

strategies to protect and sustain assets and services. Therefore, objective eval-

uation should be focused on determining whether there is alignment between

requirements and the activities being performed to meet the requirements, as

well as ensuring that requirements changes are managed and controlled.

Periodic reviews of the resilience requirements management process are needed to

ensure that

• requirements are being gathered, organized, analyzed, and validated

• all high-value services and assets have defined resilience requirements, including

newly acquired assets

• asset owners are involved in the process of validating and changing requirements

• requirements changes are being communicated to custodians through formal

channels

• requirements are changed as conditions dictate

• inconsistencies between requirements and requisite activities are being

identified and addressed

• status reports are provided to appropriate stakeholders in a timely manner

• requirements issues are referred to the risk management process when necessary

• actions requiring management involvement are elevated in a timely manner

• the performance of process activities is being monitored and regularly reported

• key measures are within acceptable ranges as demonstrated in governance dash-

boards or scorecards and financial reports

• actions resulting from internal and external audits are being closed in a timely

manner

Resilience Requirements Management 789

RRM

RRM:GG2.GP10 REVIEW STATUS WITH HIGHER-LEVEL MANAGERS

Review the activities, status, and results of the resilience requirements management

process with higher-level managers and resolve issues.

Elaboration:

Assets that do not have resilience requirements, have poorly defined require-

ments, or have outdated requirements should be brought to the attention of

higher-level managers as a symptom of potential process inadequacies. In addi-

tion, inconsistencies between requirements and strategies for protecting and

sustaining assets and services should also be reported. Audits of the process

should be conducted regularly to ensure that the process is functioning prop-

erly across organizational units and the enterprise.

These are examples of work products to be reviewed:

• enterprise, service, and asset resilience requirements

• commitment documents

• change logs

• requirements baseline and database

• requirements traceability matrix

• documentation of inconsistencies and corrective actions

• process plan and policies

• issues that have been referred to the risk management process

• process methods, techniques, and tools

• metrics for the process (Refer to RRM:GG2.GP8 subpractice 2.)

• contracts with external entities

These are examples of activities to be reviewed:

• gathering and organizing resilience requirements

• obtaining commitments to requirements by owners and custodians

• maintaining changes to requirements

• maintaining traceability of requirements

• correcting inconsistencies between requirements and strategies for protecting

and sustaining assets and services

• aligning stakeholder requirements with the process plan

• assigning responsibility, accountability, and authority for process activities

• determining the adequacy of process reports and reviews in informing decision

makers regarding the performance of operational resilience management activi-

ties and any need to take corrective action

790 PART THREE CERT-RMM PROCESS AREAS

Refer to the Enterprise Focus process area for more information about providing sponsor-

ship and oversight to the operational resilience management system.

RRM:GG3 INSTITUTIONALIZE A DEFINED PROCESS

Resilience requirements management is institutionalized as a defined process.

RRM:GG3.GP1 ESTABLISH A DEFINED PROCESS

Establish and maintain the description of a defined resilience requirements management

process.

Elaboration:

The identification, tracking, and management of resilience requirements may be

best performed at a level commensurate with direct ownership of the asset.

Thus, this process may be often carried out at the organizational unit level.

However, to ensure consistency of requirements across organizational units, the

process must be tailored from the organization’s enterprise process definition.

Establishing and tailoring process assets, including standard processes, are addressed in

the Organizational Process Definition process area.

Establishing process needs and objectives and selecting, improving, and deploying process

assets, including standard processes, are addressed in the Organizational Process Focus

process area.

Subpractices

1. Select from the organization’s set of standard processes those processes that cover

the resilience requirements management process and best meet the needs of the

organizational unit or line of business.

2. Establish the defined process by tailoring the selected processes according to the

organization’s tailoring guidelines.

3. Ensure that the organization’s process objectives are appropriately addressed in

the defined process, and ensure that process governance extends to the tailored

processes.

4. Document the defined process and the records of the tailoring.

5. Revise the description of the defined process as necessary.

RRM:GG3.GP2 COLLECT IMPROVEMENT INFORMATION

Collect resilience requirements management work products, measures, measurement

results, and improvement information derived from planning and performing the process

to support future use and improvement of the organization’s processes and process assets.

Resilience Requirements Management 791

RRM

Elaboration:

Establishing the measurement repository and process asset library is addressed in the

Organizational Process Definition process area. Updating the measurement repository

and process asset library as part of process improvement and deployment is addressed

in the Organizational Process Focus process area.

Subpractices

1. Store process and work product measures in the organization’s measurement

repository.

2. Submit documentation for inclusion in the organization’s process asset library.

3. Document lessons learned from the process for inclusion in the organization’s

process asset library.

4. Propose improvements to the organizational process assets.

These are examples of improvement work products and information:

• information about the types and extent of requirements changes (from baseline)

• inconsistencies arising between requirements and strategies for protecting and

sustaining assets and services

• the ease of understanding and traceability of requirements

• the level of asset owner and custodian commitment to the requirements

• metrics and measurements of the viability of the requirements management

process (Refer to RRM:GG2.GP8 subpractice 2.)

• changes and trends in operating conditions, risk conditions, and the risk environ-

ment that affect resilience requirements and the process

• lessons learned in post-event review of asset incidents and disruptions in conti-

nuity (including confidentiality, integrity, availability, and privacy)

• conflicts and risks arising from dependencies on external entities

• resilience requirements that are not being satisfied or are being exceeded

792 PART THREE CERT-RMM PROCESS AREAS

793

RESILIENT TECHNICAL SOLUTION ENGINEERING

Engineering

Purpose

The purpose of Resilient Technical Solution Engineering is to ensure that software

and systems are developed to satisfy their resilience requirements.

Introductory Notes

Software and systems are pervasive organizational assets that automate services and

support business processes to help organizations meet their missions. The impor-

tance of resilient technical solutions—software and systems that resist threats,

function satisfactorily in the face of adversity, and continue to help services meet

their missions during times of stress—cannot be overstated.

Resilient software and systems do not become survivable and resistant to

threat without an organizational commitment to address resilience throughout

the development process. These assets must be specifically designed and developed

with consideration of the types of threats they will face, the operating conditions

and changing risk environment in which they will operate, and the priority and

needs to sustain the services they support. Typical software and system develop-

ment life cycles understandably focus on identifying and satisfying functional

requirements; that is, most of the effort goes into defining and designing what the

software or system must do to fulfill its use case, purpose, objectives, and ulti-

mately its mission. However, requirements for quality attributes, such as security,

availability, performance, reliability, and the ability to sustain software and system

assets, can in the long run be equally important to the usability and longevity of

software and system assets and require considerable resources to address in the

operations phase if they are not considered early in the development life cycle.

Unfortunately, quality attribute requirements can be harder to define, design,

and implement and in many cases require significant business impact and cost

analysis up front to ensure that they are worth investing in. This leads to a ten-

dency to ignore these requirements early in the development life cycle and to bolt

on solutions to address them later in the design and implementation phases, when

they are more costly, less effective, and typically harder to manage and sustain in

RTSE

794 PART THREE CERT-RMM PROCESS AREAS

an operational mode. The failure to consider requirements for quality attributes

is a primary reason why software and systems in operation are subject to high

levels of operational risk resulting from failed technology and processes. This

expands an already complex operational risk environment brought about by the

integration of software and systems with other technology assets such as infor-

mation, hardware, networks, and telecommunications. In essence, ignoring qual-

ity attributes creates additional security, continuity, and other related operational

risks that must be managed in the operations phase of the life cycle, typically at

higher cost, lower efficacy, and potentially increased consequences to the organi-

zation. In some cases, these problems may be so significant as to shorten the

expected life of the software and systems, diminish their overall operational

resilience, and result in cumulatively lower than expected return on investment.

The functional aspects of software and systems do not have meaning if they

are not resistant to disruption or cannot be sustained under degraded conditions.

High-quality software and systems cannot be produced and sustained without

addressing these issues early in the development life cycle. The controls neces-

sary to demonstrate that integrity and availability requirements are met must be

identified as early as the needs determination phase. Controls can then be

designed to fit the architecture and functionality of the software and systems in

their expected operating environment and can be implemented and made opera-

ble to ensure that they achieve the desired effect. This process cannot be short-

changed; it must be wholly integrated into the organization’s development

process and must be measured, managed, and improved in the same manner as

highly effective and mature software and system development processes.

Developing or acquiring resilient technical solutions such as software and sys-

tems requires a dedicated process that encompasses the asset’s life cycle. The

process begins with establishing a plan for addressing resilience as part of the

organization’s regular development life cycle and the integration of the plan into

the organization’s corresponding development process. The identification, devel-

opment, and validation of quality attribute requirements are performed alongside

similar processes for functional requirements. Resilient software and systems are

designed through the elicitation and identification of resilience requirements and

the design of architectures that reflect a resilience focus, including security, oper-

ations controls, and the ability to sustain software and system assets. Resilient

software and systems are developed through processes that include secure coding

of software, software defect detection and removal, and the development of

resilience controls based on design specifications. The resilience controls for soft-

ware and systems are tested, and issues are referred back to the design and develop-

ment cycle for resolution. Reviews are conducted throughout the development

life cycle to ensure that resilience is kept in the forefront and given adequate

attention and consideration. System-specific continuity planning is performed

and integrated with service continuity planning to ensure that software, systems,

Resilient Technical Solution Engineering 795

hardware, networks, telecommunications, and other technical assets can be

sustained. A post-implementation review of deployed systems is performed to

ensure that resilience requirements are being satisfied as intended.

In operation, software and systems are monitored to determine if there is

variability that could indicate the effects of threats or vulnerabilities and to

ensure that controls are functioning properly. Configuration management and

change control processes are implemented 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.

To e ff ec ti ve ly in te gr at e re si li en c e co ns id e ra ti on s, th e org an iz at io n m us t e st ab -

lish guidelines for developing resilient software and systems, develop a plan for

selecting, tailoring, and integrating selected guidelines into existing development

life cycles and processes for any given development project, and then execute the

plan. Plan development and execution include identifying and mitigating risks to

the success of the development project.

The Resilient Technical Solution Engineering process area is strongly influenced

by two Capability Maturity Model Integration (CMMI) process areas [CMMI Product

Te am 2 00 6] :

• Requirements Development, the purpose of which is to produce and analyze customer

requirements and software and system product and product component requirements

• Technical Solution, the purpose of which is to design, develop, and implement solu-

tions to software and system requirements (Solutions, designs, and implementations

encompass software and system products, product components, and product-related

life-cycle processes, either singly or in combination as appropriate.)

There are a growing number of reputable sources to consider when identifying

and selecting candidate guidelines for the development of resilient software and

systems across the life cycle, particularly for software security and assurance.

These are examples of sources of guidelines:

• Building Security In Maturity Model (BSIMM2) v2.0, http://bsimm2.com/

• Open Web Applications Security Project (OWASP) Software Assurance Maturity

Model (SAMM) v1.0, www.owasp.org/index.php/Category:Software_Assurance_

Maturity_Model

• Microsoft’s Security Development Lifecycle, Version 4.1, www.microsoft.com/security/

sdl/

• Department of Homeland Security Assurance for CMMI Process Reference Model,

https://buildsecurityin.us-cert.gov/swa/procwg.html

RTSE

796 PART THREE CERT-RMM PROCESS AREAS

The Resilient Technical Solution Engineering process area assumes that the

organization has one or more existing, defined processes for software and system

development into which resilience controls and activities can be integrated. If

this is not the case, the organization should not attempt to implement the goals

and practices identified in this process area.

Note: This process area does not address the unique aspects of the resilience

of embedded systems or the resilience of hardware that is part of a software-

intensive system.

Related Process Areas

Resilience 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 Resilience Requirements Development and Resilience

Requirements Management process areas, respectively.

Identifying and adding newly developed and acquired software and system assets to the orga-

nization’s asset inventory are addressed in the Asset Definition and Management process area.

The management of resilience for technology assets as a whole, particularly for deployed,

operational assets, is addressed in the Technology Management 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

resilience requirements throughout the asset life cycle are addressed in the External Dependen-

cies 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 process area.

Service continuity plans are identified and created in the Service Continuity process area.

These plans may be inclusive of software and systems that support the services for which

planning is performed.

Summary of Specific Goals and Practices

RTSE:SG1 Establish Guidelines for Resilient Technical Solution Development

RTSE:SG1.SP1 Identify General Guidelines

RTSE:SG1.SP2 Identify Requirements Guidelines

RTSE:SG1.SP3 Identify Architecture and Design Guidelines

RTSE:SG1.SP4 Identify Implementation Guidelines

RTSE:SG1.SP5 Identify Assembly and Integration Guidelines

RTSE:SG2 Develop Resilient Technical Solution Development Plans

RTSE:SG2.SP1 Select and Tailor Guidelines

RTSE:SG2.SP2 Integrate Selected Guidelines with a Defined Software and System Development Process