Appendix E The Information System Security Management Professional (ISSMP) Certification

Overview

The ISSMP Certification is defined by (ISC)2 as the CISSP concentration area that is designed to denote competence and expertise in information security management.

To qualify for and obtain the ISSMP certification, the candidate must possess the CISSP credential, sit for and pass the ISSMP examination, and maintain the ISSMP credential in good standing.

The ISSMP examination is similar in format to that of the CISSP examination. The questions are multiple choice, with the examinee being asked to select the best answer of four possible answers. The examination comprises 150 questions, 25 of which are experimental questions that are not counted. The candidate is allotted 3 hours to complete the examination.

The ISSMP certification and examination cover the following five primary areas:

• Enterprise security management - Focuses on the fundamental aspects of a security program from an enterprise perspective. This domain deals with policies, business objectives, risk management, change control, the value of certification and accreditation, and security awareness.
• Enterprise-wide systems development practices - Concerned with incorporating security in system development models and configuration management, integrating application and network security controls, and developing processes to identify system threats and vulnerabilities.
• Overseeing compliance of operations security - Details security requirements for the operations staff, managing incidents and security violations, developing help desk and maintenance programs, and ensuring the availability and integrity of system processes.
• Business continuity planning (BCP), disaster recovery planning (DRP), and continuity of operations planning (COOP) - Discusses keeping the business running, restoring information systems, participation in business impact analysis, and developing and testing emergency plans.
• Law, investigation, forensics, and ethics - Develops the parameters of investigations, ensures compliance with appropriate regulations and laws, reviews the rules of evidence and forensics procedures, and discusses professional ethics.

The key concepts that ISSMP candidates need to understand in the five domains are summarized and reviewed in this appendix. A good plan of approach to studying for the ISSMP exam is to review this book concentrating on the five ISSMP domain areas listed. In the following sections, we’ve given you some more detailed information and included some new questions.

Enterprise Security Management Practices

This material is covered in detail in Chapter 1.

Enterprise Wide Systems Development Practices

As stated in the ISSMP Study Guide, the ISSMP candidate is expected to understand the following key knowledge areas in this domain:

• Building security into the Systems Development Life Cycle (SDLC)
• Integrating Application and Network Security Controls
• Integrating Security with the Configuration Management Program
• Developing and Integrating Processes to Identify System Vulnerabilities and Threats

Building Security into the Systems Development Life Cycle (SDLC)

This topic is covered in detail in Appendix D but will be summarized in this appendix for review.

One component of implementing information systems security in the SDLC is the application of the Defense in Depth strategy. The Defense in Depth strategy is built upon three critical elements - people, technology, and operations - and comprises the following information assurance principles:

• Defense in multiple places - Deployment of information protection mechanisms at multiple locations to protect against internal and external threats.
• Layered defenses - Deployment of multiple information protection and detection mechanisms so that an adversary or threat will have to negotiate multiple barriers to gain access to critical information.
• Security robustness - Based on the value of the information system component to be protected and the anticipated threats, estimation of the robustness of each information assurance component in terms of assurance and strength of the information assurance component.
• Deploy KMI/PKI - Deployment of robust key management infrastructures (KMI) and public-key infrastructures (PKI).
• Deploy intrusion detection systems - Deployment of intrusion detection mechanisms to detect intrusions, evaluate information, examine results, and, if necessary, to take action.

The System Development Life Cycle Phases

NIST SP 800-14 defines the system life cycle phases as follows:

• Initiation - The need for the system and its purpose are documented. A sensitivity assessment is conducted as part of this phase. A sensitivity assessment evaluates the sensitivity of the IT system and the information to be processed.
• Development/Acquisition - Comprises the system acquisition and development cycles. In this phase, the system is designed, developed, programmed, and acquired.
• Implementation - Installation, testing, security testing, and accreditation are conducted.
• Operation/Maintenance - The system performs its designed functions. This phase includes security operations, modification/addition of hardware and/or software, administration, operational assurance, monitoring, and audits.
• Disposal - Disposition of system components and products, such as hardware, software, and information; disk sanitization; archiving files; and moving equipment.

Information System Security Applied to the SDLC

The following list summarizes the information system security steps to be applied to the SDLC as described in SP 800-64.

• An organization will use the general SDLC described in this document or will have developed a tailored SDLC that meets its specific needs. In either case, NIST recommends that organizations incorporate the associated IT security steps of this general SDLC into their development process:
• Initiation Phase:
  • Security Categorization - Defines three levels (low, moderate, or high) of potential impact on organizations or individuals should there be a breach of security (a loss of confidentiality, integrity, or availability). Security categorization standards assist organizations in making the appropriate selection of security controls for their information systems.
  • Preliminary Risk Assessment - Results in an initial description of the basic security needs of the system. A preliminary risk assessment should define the threat environment in which the system will operate.

• Acquisition/Development Phase:
  • Risk Assessment - Analysis that identifies the protection requirements for the system through a formal risk assessment process. This analysis builds on the initial risk assessment performed during the Initiation phase but will be more in-depth and specific.
  • Security Functional Requirements Analysis - Analysis of requirements that may include the following components: (1) system security environment (that is, enterprise information security policy and enterprise security architecture) and (2) security functional requirements.
  • Assurance Requirements Analysis Security - Analysis of requirements that address the developmental activities required and assurance evidence needed to produce the desired level of confidence that the information security will work correctly and effectively. The analysis, based on legal and functional security requirements, will be used as the basis for determining how much and what kinds of assurance are required.
  • Cost Considerations and Reporting - Determines how much of the development cost can be attributed to information security over the life cycle of the system. These costs include hardware, software, personnel, and training.
  • Security Planning - Ensures that agreed-upon security controls, planned or in place, are fully documented. The security plan also provides a complete characterization or description of the information system as well as attachments or references to key documents supporting the agency’s information security program (e.g., configuration management plan, contingency plan, incident response plan, security awareness and training plan, rules of behavior, risk assessment, security test and evaluation results, system interconnection agreements, security authorizations/accreditations, and plan of action and milestones).
  • Security Control Development - Ensures that security controls described in the respective security plans are designed, developed, and implemented. For information systems currently in operation, the security plans for those systems may call for the development of additional security controls to supplement the controls already in place or the modification of selected controls that are deemed to be less than effective.
  • Developmental Security Test and Evaluation - Ensures that security controls developed for a new information system are working properly and are effective. Some types of security controls (primarily those controls of a nontechnical nature) cannot be tested and evaluated until the information system is deployed - these controls are typically management and operational controls.
  • Other Planning Components - Ensures that all necessary components of the development process are considered when incorporating security into the life cycle. These components include selection of the appropriate contract type, participation by all necessary functional groups within an organization, participation by the certifier and accreditor, and development and execution of necessary contracting plans and processes.

• Implementation Phase:
  • Inspection and Acceptance - Ensures that the organization validates and verifies that the functionality described in the specification is included in the deliverables.
  • Security Control Integration - Ensures that security controls are integrated at the operational site where the information system is to be deployed for operation. Security control settings and switches are enabled in accordance with vendor instructions and available security implementation guidance.
  • Security Certification - Ensures that the controls are effectively implemented through established verification techniques and procedures and gives organization officials confidence that the appropriate safeguards and countermeasures are in place to protect the organization’s information system. Security certification also uncovers and describes the known vulnerabilities in the information system.
  • Security Accreditation - Provides the necessary security authorization of an information system to process, store, or transmit information that is required. This authorization is granted by a senior organization official and is based on the verified effectiveness of security controls to some agreed-upon level of assurance and an identified residual risk to agency assets or operations.

• Operations/Maintenance Phase:
  • Configuration Management and Control - Ensures adequate consideration of the potential security impacts resulting from specific changes to an information system or its surrounding environment. Configuration management and configuration control procedures are critical to establishing an initial baseline of hardware, software, and firmware components for the information system and subsequently controlling and maintaining an accurate inventory of any changes to the system.
  • Continuous Monitoring - Ensures that controls continue to be effective in their application through periodic testing and evaluation. Security control monitoring (that is, verifying the continued effectiveness of those controls over time) and reporting the security status of the information system to appropriate agency officials is an essential activity of a comprehensive information security program.

• Disposition Phase:
  • Information Preservation - Ensures that information is retained, as necessary, to conform to current legal requirements and to accommodate future technology changes that may render the retrieval method obsolete.
  • Media Sanitization - Ensures that data is deleted, erased, and written over as necessary.
  • Hardware and Software Disposal - Ensures that hardware and software is disposed of as directed by the information system security officer.

Integrating Application and Network Security Controls

Application and network security controls can be presented in the context of systems engineering (SE) and the corresponding information systems security engineering (ISSE) controls.

Systems Engineering

Systems engineering can be defined as the branch of engineering concerned with the development of large and complex systems, where a system is understood to be an assembly or combination of interrelated elements or parts working together toward a common objective. The Systems Engineering process, as defined in Chapter 3 of the Information Assurance Technical Framework (IATF) document 3.1, consists of the following elements:

• Discover needs
• Define system requirements
• Design system architecture
• Develop detailed design.
• Implement system
• Assess effectiveness.

An important characteristic of this process is that it emphasizes the application SE over the entire development life cycle. Figure E-1 illustrates the IATF generic SE process; the arrows show the information flow among activities in the process. The notation of USERS/USERS’ REPRESENTATIVES in the figure is included to emphasize the interaction among the users and the systems engineer throughout the SE process.

Figure E-1: The generic systems engineering process (from IATF document, Release 3.1, September 2002).

This generic SE process will be used as the basis for integration with the ISSE process.

The Information Systems Security Engineering Process

The ISSE process mirrors the generic SE process of IATF document 3.1. The ISSE process elements and the associated SE process elements, respectively, are:

• Discover Information Protection Needs - Discover Needs
• Define System Security Requirements - Define System Requirements
• Design System Security Architecture - Design System Architecture
• Develop Detailed Security Design - Develop Detailed Design
• Implement System Security - Implement System
• Assess Information Protection Effectiveness - Assess Effectiveness

Each of the six ISSE process activities will be reviewed in the following sections.

Discover Information Protection Needs

The information systems security engineer can obtain a portion of the information required for this activity from the SE process. The objectives of this activity are to understand and document the customer’s needs and to develop solutions that will meet these needs. This approach is illustrated in Figure E-2.

Figure E-2: Discover Information Protection Needs activity (from IATF document, Release 3.1, September 2002).

The information systems security engineer should use any reliable sources of information to learn about the customer’s mission and business operations, including areas such as human resources, finance, command and control, engineering, logistics, and research and development. This knowledge can be used to generate a concept of operations (CONOPS) document or a mission needs statement (MNS). Then, with this information in hand, an information management model (IMM) should be developed that ultimately defines a number of information domains. Information management is defined as:

• Creating information
• Acquiring information
• Processing information
• Storing and retrieving information
• Transferring information
• Deleting information

In the Discover Information Protection Needs activity of the ISSE process, the information systems security engineer must document all elements of the activity. These elements include:

• Roles
• Responsibilities
• Threats
• Strengths
• Security services
• Priorities
• Design constraints

These items form the basis of an Information Protection Policy (IPP), which in turn becomes a component of the customer’s Information Management Policy (IMP), as shown in Figure E-2.

The information systems security engineer must also support the certification and accreditation (C&A) of the system. For example, the security engineer can identify the Designated Approving Authority (DAA) and the Certification Authority (CA). A detailed discussion of C&A is given in Chapters 11, 13, and 14.

Define System Security Requirements

In this ISSE activity, the information systems security engineer identifies one or more solution sets that can satisfy the information protection needs of the IPP. This subprocess is illustrated in Figure E-3.

Figure E-3: Mapping of solution sets to information protection needs.

In selecting a solution set, the information systems security engineer must also consider the needs of external systems such as Public Key Infrastructure (PKI) or other cryptographic-related systems, as shown in Figure E-4.

Figure E-4: Mapping of needs to solution set components.

A solution set consists of a preliminary security CONOPS, the system context, and the system requirements. In close cooperation with the customer and based on the IPP, the information systems security engineer selects the best solution among the solution sets. The information protection functions and the information management functions are delineated in the preliminary security CONOPS, and the dependencies among the organization’s mission and the services provided by other entities are identified. In developing the system context, the information systems security engineer uses systems engineering techniques to identify the boundaries of the system to be protected and allocates security functions to this system as well as to external systems. The information systems security engineer accomplishes this allocation by analyzing the flow of data among the system to be protected and the external systems and by using the information compiled in the IPP and IMM.

The third component of the solution set - the system security requirements - is generated by the information systems security engineer in collaboration with the systems engineers. Requirements should be unambiguous, comprehensive, and concise, and they should be obtained through the process of requirements analysis. The functional requirements and constraints on the design of the information security components include regulations, the operating environment, targeting internal as well as external threats, and customer needs.

At the end of this process, the information systems security engineer reviews the security CONOPS, the security context, and the system security requirements with the customer to ensure that they meet the needs of the customer and are accepted by the customer. As with all activities in the ISSE process, documentation is very important and should be generated in accordance with the C&A requirements.

Design System Security Architecture

The requirements generated in the Define System Security Requirements activity of the ISSE process are necessarily stated in functional terms - indicating what is needed but not how to accomplish what is needed. In Design System Security Architecture, the information systems security engineer performs a functional decomposition of the requirements that can be used to select the components required to implement the designated functions. Some aids that are used to implement the functional decomposition are timeline analyses, flow block diagrams, and a requirements allocation sheet. The result of the functional decomposition is the functional architecture of the information security systems, shown schematically in Figure E-5.

Figure E-5: Design system security architecture.

In the decomposition process, the performance requirements at the higher level are mapped onto the lower-level functions to ensure that the resulting system performs as required. Also as part of this activity, the information systems security engineer determines, at a functional level, the security services that should be assigned to the system to be protected as well as to external systems. Such services include encryption, key management, and digital signatures. Because implementations are not specified in this activity, a complete risk analysis is not possible. General risk analysis, however, can be done by estimating the vulnerabilities in the classes of components that are likely to be used.

As always, documentation in accordance with requirements of the C&A process should be performed.

Develop Detailed Security Design

The information protection design is achieved through continuous assessments of risks and the comparison of these risks with the information system security requirements by the ISSE personnel. The design activity is iterative, and it involves both the SE and ISSE professionals. The design documentation should meet the requirements of the C&A process. It should be noted that this activity specifies the system and components but does not specify products or vendors.

The tasks performed by the information systems security engineer include:

• Mapping security mechanisms to system security design elements
• Cataloging candidate commercial off-the-shelf (COTS) products
• Cataloging candidate government off-the-shelf (GOTS) products
• Cataloging custom security products
• Qualifying external and internal element and system interfaces
• Developing specifications such as Common Criteria protection profiles

Implement System Security

This activity moves the system from the design phase to the operational phase. The steps in this process are shown in Figure E-6.

Figure E-6: The path from design to operations in the Implement System Security activity.

The Implement System Security activity concludes with a system effectiveness assessment that produces evidence that the system meets the requirements and needs of the mission. Security accreditation usually follows this assessment.

The assessment is accomplished through the following actions of the information systems security engineer:

• Verifying that the implemented system does address and protect against the threats itemized in the original threat assessment
• Providing inputs to the C&A process
• Application of information protection assurance mechanisms related to system implementation and testing
• Providing inputs to and reviewing the evolving system life cycle support plans
• Providing inputs to and reviewing the operational procedures
• Providing inputs to and reviewing the maintenance training materials
• Taking part in multidisciplinary examinations of all system issues and concerns

An important part of the Implement System Security activity is the determination of the specific components of the information system security solution. Some of the factors that have to be considered in selecting the components include:

• Availability now and in the future
• Cost
• Form factor
• Reliability
• Risk to system caused by substandard performance
• Conformance to design specifications
• Compatibility with existing components
• Meeting or exceeding evaluation criteria (typical evaluation criteria include the Commercial COMSEC Evaluation Program [CCEP], National Information Assurance Partnership [NIAP], Federal Information Processing Standards [FIPS], NSA criteria, and NIST criteria)

Assess Information Protection Effectiveness

In order to assess the effectiveness of the information protection mechanisms and services effectively, this activity must be conducted as part of all the activities of the complete ISSE and SE process.

Summary Showing the Correspondence of the SE and ISSE Activities

As discussed in the descriptions of the SE and ISSE processes, there is a one-to-one correspondence of activities in the ISSE process to those in the SE process. Table E-1, taken from IATF document, Release 3.1, September 2002, summarizes those activities in the ISSE process that correspond to activities in the SE process.

Table E-1: Corresponding SE and ISSE Activities
Open table as spreadsheet

SE ACTIVITIES	ISSE ACTIVITIES
Discover Needs	Discover Information Protection Needs
The systems engineer helps the customer understand and document the information management needs that support the business or mission. Statements about information needs may be captured in an information management model (IMM).	The information systems security engineer helps the customer understand the information protection needs that support the mission or business. Statements about information protection needs may be captured in an Information Protection Policy (IPP).
Define System Requirements	Define System Security Requirements
The systems engineer allocates identified needs to systems. A system context is developed to identify the system environment and to show the allocation of system functions to that environment. A preliminary system concept of operations (CONOPS) is written to describe operational aspects of the candidate system (or systems). Baseline requirements are established.	The information systems security engineer allocates information protection needs to systems. A system security context, a preliminary system security CONOPS, and baseline security requirements are developed.
Design System Architecture	Design System Security Architecture
The systems engineer performs functional analysis and allocation by analyzing candidate architectures, allocating requirements, and selecting mechanisms. The systems engineer identifies components, or elements, allocates functions to those elements, and describes the relationships between the elements.	The information systems security engineer works with the systems engineer in the areas of functional analysis and allocation by analyzing candidate architectures, allocating security services, and selecting security mechanisms. The information systems security engineer identifies components, or elements, allocates security functions to those elements, and describes the relationships between the elements.
Develop Detailed Design	Develop Detailed Security Design
The systems engineer analyzes design constraints, analyzes trade-offs, does detailed system design, and considers life cycle support. The systems engineer traces all the system requirements to the elements until all are addressed. The final detailed design results in component and interface specifications that provide sufficient information for acquisition when the system is implemented.	The information systems security engineer analyzes design constraints, analyzes trade-offs, does detailed system and security design, and considers life cycle support. The information systems security engineer traces all the system security requirements to the elements until all are addressed. The final detailed security design results in component and interface specifications that provide sufficient information for acquisition when the system is implemented.
Implement System	Implement System Security
The systems engineer moves the system from specifications to the tangible. The main activities are acquisition, integration, configuration, testing, documentation, and training. Components are tested and evaluated to ensure that they meet the specifications. After successful testing, the individual components - hardware, software, and firmware - are integrated, properly configured, and tested as a system.	The information systems security engineer participates in a multidisciplinary examination of all system issues and provides inputs to C&A process activities, such as verification that the system as implemented protects against the threats identified in the original threat assessment; tracking of information protection assurance mechanisms related to system implementation and testing practices; and providing inputs to system life cycle support plans, operational procedures, and maintenance training materials.
Assess Effectiveness	Assess Information Protection Effectiveness
The results of each activity are evaluated to ensure that the system will meet the users’ needs by performing the required functions to the required quality standard in the intended environment. The systems engineer examines how well the system meets the needs of the mission.	The information systems security engineer focuses on the effectiveness of the information protection - whether the system can provide the confidentiality, integrity, availability, authentication, and nonrepudiation for the information it is processing that is required for mission success.

ISSE and Its Relationship to C A Processes

The ISSE process provides input to the C&A process in the form of evidence and documentation. Thus, the information systems security engineer has to consider the requirements of the accrediting authority. The Certification and Accreditation Process certifies that the information system meets the defined system security requirements and the system assurance requirements. It is not a design process. The SE/ISSE process also benefits by receiving information back from the C&A process that may result in modifications to the SE/ISSE process activities. Figure E-7 illustrates the relationship of the SE/ISSE process to the C&A process.

Figure E-7: Relationship of the SE/ISSE process to the C&A process (from IATF document, Release 3.1, September 2002).

In summary, the outputs of the SE/ISSE process are the implementation of the system and the corresponding system documentation. The outputs of the C&A process are Certification documentation, Certification recommendations, and an Accreditation decision.

Integrating Security with the Configuration Management Program

Change control, configuration management, and associated information security controls are discussed in detail in Chapter 6. The topic will be summarized in this section.

Change Control

Change control is the management of security features and a level of assurance provided through the control of the changes made to the system’s hardware, software, and firmware configurations throughout the development and operational life cycle.

Change control involves identifying, controlling, and auditing all changes made to the system. It can address hardware and software changes, networking changes, or any other change affecting security. Change control can also be used to protect a trusted system while it is being designed and developed.

The primary security goal of change control is to ensure that changes to the system do not unintentionally diminish security. Another goal of change control is to ensure that system changes are reflected in current documentation to help mitigate the impact that a change may have on the security of other systems, in either the production or the planning stages.

The following are the primary functions of change control:

• To ensure that the change is implemented in an orderly manner through formalized testing
• To ensure that the user base is informed of the impending change
• To analyze the effect of the change on the system after implementation
• To reduce the negative impact that the change may have had on the computing services and resources

Configuration Management

Configuration management is the more formalized, higher level process of managing changes to a complicated system, and it is required for formal, trusted systems. Change control is contained in configuration management. The purpose of configuration management is to ensure that changes made to verification systems take place in an identifiable and controlled environment. Configuration managers take responsibility that additions, deletions, or changes made to the verification system do not jeopardize its ability to satisfy trusted requirements. Therefore, configuration management is vital to maintaining the endorsement of a verification system.

The four major aspects of configuration management are:

• Configuration identification
• Configuration control
• Configuration status accounting
• Configuration auditing

Configuration Identification

Configuration management entails decomposing the verification system into identifiable, understandable, manageable, trackable units known as Configuration Items (CIs). A CI is a uniquely identifiable subset of the system that represents the smallest portion to be subject to independent configuration control procedures. The decomposition process of a verification system into CIs is called configuration identification.

CIs can vary widely in size, type, and complexity. Although there are no hard-and-fast rules for decomposition, the granularity of CIs can have great practical importance. A favorable strategy is to designate relatively large CIs for elements that are not expected to change over the life of the system, and small CIs for elements likely to change more frequently.

Configuration Control

Configuration control is a means of ensuring that system changes are approved before being implemented, only the proposed and approved changes are implemented, and the implementation is complete and accurate. This involves strict procedures for proposing, monitoring, and approving system changes and their implementation. Configuration control entails central direction of the change process by personnel who coordinate analytical tasks, approve system changes, review the implementation of changes, and supervise other tasks such as documentation.

Configuration Accounting

Configuration accounting documents the status of configuration control activities and in general provides the information needed to manage a configuration effectively. It allows managers to trace system changes and establish the history of any developmental problems and associated fixes.

Configuration accounting also tracks the status of current changes as they move through the configuration control process. Configuration accounting establishes the granularity of recorded information and thus shapes the accuracy and usefulness of the audit function.

The accounting function must be able to locate all possible versions of a CI and all the incremental changes involved, thereby deriving the status of that CI at any specific time. The associated records must include commentary about the reason for each change and its major implications for the verification system.

Configuration Audit

Configuration audit is the quality assurance component of configuration management. It involves periodic checks to determine the consistency and completeness of accounting information and to verify that all configuration management policies are being followed. A vendor’s configuration management program must be able to sustain a complete configuration audit by an NCSC review team.

Configuration Management Plan

Strict adherence to a comprehensive configuration management plan is one of the most important requirements for successful configuration management. The configuration management plan is the vendor’s document tailored to the company’s practices and personnel. The plan accurately describes what the vendor is doing to the system at each moment and what evidence is being recorded.

Configuration Control Board (CCB)

All analytical and design tasks are conducted under the direction of the vendor’s corporate entity called the Configuration Control Board (CCB). The CCB is headed by a chairperson, who is responsible for ensuring that changes made do not jeopardize the soundness of the verification system and ensures that the changes made are approved, tested, documented, and implemented correctly.

The members of the CCB should interact periodically, either through formal meetings or other available means, to discuss configuration management topics such as proposed changes, configuration status accounting reports, and other topics that may be of interest to the different areas of the system development. These interactions should be held to keep the entire system team updated on all advancements or alterations in the verification system.

Developing and Integrating Processes to Identify System Vulnerabilities and Threats

Identifying system vulnerabilities and threats and mitigating the corresponding risk are part of the risk management process. This process minimizes the impact of threats realized and provides a foundation for effective management decision making. Thus, it is very important that risk management be a part of the system development life cycle. Risk management is discussed in detail in Appendix D but is summarized in this section.

As defined in NIST SP 800-30, risk management comprises three processes:

• Risk assessment
• Risk mitigation
• Evaluation and assessment

These processes should be performed during each of the five phases of the SDLC. Table E-2, taken from NIST SP 800-30, details the risk management activities that should be performed for each SDLC phase.

Table E-2: Risk Management in the SDLC
Open table as spreadsheet

SDLC	PHASE	RISK MANAGEMENT ACTIVITIES
Phase 1 - Initiation	The need for an IT system is expressed and the purpose and scope of the IT system are documented.	Identified risks are used to support the development of the system requirements, including security requirements, and a security concept of operations (strategy).
Phase 2 - Development or Acquisition	The IT system is designed, purchased, programmed, developed, or otherwise constructed,	The risks identified during this phase can be used to support the security analyses of the IT system, which may lead to architecture and design trade-offs during system development.
Phase 3 - Implementation	The system security features should be configured, enabled, tested, and verified.	The risk management process supports the assessment of the system implementation against its requirements and within its modeled operational environment. Decisions regarding risks identified must be made prior to system operation.
Phase 4 - Operation or Maintenance	The system performs its functions. Typically the system is being modified on an ongoing basis through the addition of hardware and software and by changes to organizational processes, policies, and procedures.	Risk management activities are performed for periodic system reauthorization (or reaccreditation) or whenever major changes are made to an IT system in its operational, production environment (e.g., new system interfaces).
Phase 5 - Disposal	This phase may involve the disposition of information, hardware, and software. Activities may include moving, archiving, discarding, or destroying information and sanitizing the hardware and software.	Risk management activities are performed for system components that will be disposed of or replaced to ensure that the hardware and software are properly disposed of, that residual data is appropriately handled, and that system migration is conducted in a secure and systematic manner.

Roles of Key Personnel in the Risk Management Process

To be effective, risk management must be supported by management and information system security practitioners. Some of the key personnel that should actively participate in the risk management activities are:

• Senior management - Provides the required resources and meet responsibilities under the principle of due care
• Chief information officer (CIO) - Considers risk management in IT planning, budgeting, and meeting system performance requirements
• System and information owners - Ensure that controls and services are implemented to address information system confidentiality, integrity, and availability
• Business and functional managers - Make trade-off decisions regarding business operations and IT procurement that affect information security
• Information system security officer (ISSO) - Participates in applying methodologies to identify, evaluate, and reduce risks to the mission-critical IT systems
• IT security practitioners - Ensure the correct implementation of IT system information system security requirements
• Security awareness trainers - Incorporate risk assessment in training programs for the organization’s personnel

The Risk Assessment Process

As defined in NIST SP 800-30, “Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.” Risk assessment comprises the following steps:

1. System characterization
2. Threat identification
3. Vulnerability identification
4. Control analysis
5. Likelihood determination
6. Impact analysis
7. Risk determination
8. Control recommendations
9. Results documentation

Risk Mitigation

Risk mitigation prioritizes, evaluates, and implements the controls that are an output of the risk assessment process. Risk mitigation is the second component of the risk management process.

Because risk can never be completely eliminated and control implementation must make sense under a cost-benefit analysis, a least-cost approach with minimal adverse impact on the IT system is usually taken.

Risk Mitigation Options

Risk mitigation can be classified into the following options:

• Risk assumption - Accept the risk and keep operating
• Risk avoidance - Forgo some functions
• Risk limitation - Implement controls to minimize the adverse impact of threats realized
• Risk planning - Develop a risk mitigation plan to prioritize, implement, and maintain controls
• Research and development - Researching control types and options
• Risk transference - Transfer risk to other sources, such as purchasing insurance

SP 800-30 emphasizes the following guidance on implementing controls: Address the greatest risks and strive for sufficient risk mitigation at the lowest cost, with minimal impact on other mission capabilities.

The control implementation approach from the risk mitigation methodology recommended by SP 800-30 is given in Figure E-8.

Figure E-8: A control implementation approach (from NIST SP 800-30).

Categories of Controls

Controls to mitigate risks can be broken into the following categories:

• Technical
• Management
• Operational
• A combination of the above

Determination of Residual Risk

The risk that remains after the implementation of controls is called the residual risk. All systems will have residual risk, because it is virtually impossible to completely eliminate risk to an IT system. An organization’s senior management or the DAA is responsible for authorizing/accrediting the IT system to begin or continue to operate. The authorization/accreditation must take place every three years in federal agencies or whenever major changes are made to the system. The DAA signs a statement accepting the residual risk when accrediting the IT system for operation. If the DAA determines that the residual risk is at an unacceptable level, the risk management cycle must be redone with the objective of lowering the residual risk to an acceptable level.

Figure E-9 shows the relationship between residual risk and the implementation of controls.

Figure E-9: The relationship between residual risk and implementation of controls (from NIST SP 800-30).

Risk Management Summary

As stated in SP 800-30, “A successful risk management program will rely on (1) senior management’s commitment; (2) the full support and participation of the IT; (3) the competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization; (4) the awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization; and (5) an ongoing evaluation and assessment of the IT-related mission risks.”

Overseeing Compliance of Operations Security

Chapter 6, “Operations Security,” outlines most of the material that will be helpful in understanding this domain of the ISSMP. The operations staff working with the ISSO are responsible for maintaining an acceptable level of residual risk. The operations management and staff help secure the enterprise with activities such as:

• Performing backups
• Holding training classes
• Managing cryptographic keys
• Keeping up with user administration and access privileges
• Updating security software

Operations Personnel Procedures

To ensure compliance with operational security, management is frequently involved in the screening, hiring, firing, or transfer of personnel in accordance with the organizations personnel security policy. As per NIST, working with other departments, such as human resources, elements of this management include:

• Position categorization - Assigning a risk designation to all positions, establishing screening criteria for individuals filling those positions, and reviewing and revising position risk designations
• Personnel screening - Screening those individuals requiring access to organizational information and information systems before authorizing access, and ensuring that the screening is consistent with the criteria established for the risk designation of the assigned position
• Personnel termination - Ensuring that the organization terminates information system access, ensuring the return of all organizational information system–related property (e.g., keys, identification cards, building passes), and ensuring that appropriate personnel have access to official records created by the terminated employee that are stored on organizational information systems
• Personnel transfer - Reviewing information systems or facilities access authorizations when individuals are reassigned or transferred to other positions within the organization and initiating appropriate actions (e.g., reissuing keys, identification cards, building passes; closing old accounts and establishing new accounts; and changing system access authorizations)
• Access agreements - Completing appropriate access agreements (e.g., nondisclosure agreements, acceptable use agreements, rules of behavior, conflict-of-interest agreements) for individuals requiring access to organizational information and information systems before authorizing access
• Third-party personnel security - Establishing personnel security requirements for third-party providers (e.g., service bureaus, contractors, and other organizations providing information system development, information technology services, outsourced applications, network and security management) and monitoring provider compliance to ensure adequate security
• Personnel sanctions - Employing a formal sanctions process for personnel failing to comply with established information security policies and procedures, and guaranteeing that the sanctions process is consistent with applicable federal laws, directives, policies, regulations, standards, and guidance

Incident Management

The operations group may be involved in the implementation, management and maintenance of an incident reporting and response function. As per NIST, these responsibilities should include:

Incident response training.   Personnel must be trained in their incident response roles and responsibilities, and refresher training should be provided at least annually. The organization should incorporate simulated events into the incident response training to facilitate effective response by personnel in crisis situations, and employ automated mechanisms to provide a more thorough and realistic training environment.

Incident response testing.   The incident response capability for the information system should be tested annually to determine the incident response effectiveness, and the results must be documented.

Incident handling.   An incident-handling capability must be implemented for security incidents, including preparation, detection, analysis, containment, eradication, and recovery. The organization should incorporate the lessons learned from ongoing incident-handling activities into the incident response procedures.

Incident monitoring.   Information system security incidents must be tracked and documented on an ongoing basis.

Incident reporting.   Incident information must be promptly reported to appropriate authorities. Management must ensure that the types of incident information reported, the content and timeliness of the reports, and the list of designated reporting authorities or organizations are consistent with applicable federal laws, directives, policies, regulations, standards, and guidance.

Incident response assistance.   An incident support resource should be provided to offer advice and assistance to users of the information system for the handling and reporting of security incidents. The support resource should be an integral part of the organization’s incident response capability. Possible implementations of incident support resource include a help desk or an assistance group and access to forensics services, when required.

Managing System Maintenance

The operations function will have to provide system maintenance oversight, particularly where security issues are involved. Again, as per NIST, this includes:

Periodic maintenance.   This entails scheduling, performing, and documenting routine preventative and regular maintenance on the components of the information system in accordance with manufacturer or vendor specifications and/or organizational requirements.

Off-site repair.   If the information system or component of the system requires off-site repair, all information must be removed from associated media using approved procedures. Appropriate organizational officials must approve the removal of the information system or information system components from the facility when repairs are necessary. After maintenance is performed on the information system, operations checks the security features to ensure that they are still functioning properly.

Maintenance logs.   A log must be maintained for the information system that includes:

• The date and time of maintenance
• Name of the individual performing the maintenance
• Name of escort, if necessary
• Description of the maintenance performed
• List of equipment removed or replaced, including identification numbers, if applicable

Maintenance scheduling.   Automated mechanisms should be employed to ensure that periodic maintenance is scheduled and conducted as required, and that a log of maintenance actions, both needed and completed, is up-to-date, accurate, complete, and available.

Maintenance tools.   The operations function is responsible for approving, controlling, and monitoring the use of information system maintenance tools and maintains the tools on an ongoing basis. This consists of:

• Inspecting all maintenance tools (e.g., diagnostic and test equipment) carried into a facility by maintenance personnel for obvious improper modifications.
• Checking all media containing diagnostic test programs (e.g., software or firmware used for system maintenance or diagnostics) for malicious code before the media is used in the information system.
• Checking all maintenance equipment with the capability of retaining information to ensure that no organizational information is written on the equipment or the equipment is appropriately sanitized before release. If the equipment cannot be sanitized, the equipment remains within the facility or is destroyed, unless an appropriate organization official explicitly authorizes an exception.

Remote maintenance.   Operations is responsible for approving, controlling, and monitoring remotely executed maintenance and diagnostic activities. Elements of secure remote maintenance include:

• Encryption and decryption of diagnostic communications
• Strong identification and authentication techniques
• Remote disconnect verification

When remote maintenance is completed, all sessions and remote connections must be terminated. If password-based authentication is used during remote maintenance, the passwords must be changed following each remote maintenance service. For high-impact information systems, if remote diagnostic or maintenance services are required from a service or organization that does not implement for its own information system the same level of security as that implemented on the system being serviced, the system being serviced is sanitized and physically separated from other information systems before the connection of the remote access line.

Maintenance personnel.   Operations must maintain a list of personnel authorized to perform maintenance on the information system. Only authorized personnel perform maintenance on the information system. Maintenance personnel have appropriate access authorizations to the information system when maintenance activities allow access to organizational information. If maintenance personnel do not have the needed access authorizations, operations personnel with appropriate access authorizations must supervise maintenance personnel during the performance of maintenance activities on the information system.

Business Continuity Planning (BCP), Disaster Recovery Planning (DRP), and Continuity of Operations Planning (COOP)

This material is covered in detail in Chapter 8.

Law, Investigation, Forensics, and Ethics

This material is covered in detail in Chapter 9.

Assessment Questions ISSMP

You can find the answers to the following questions in Appendix A.

1.	Which one of the following is not one of the five system life cycle planning phases as defined in NIST SP 800-14? Initiation phase Requirements phase Implementation phase Disposal phase
2.	The IATF document 3.1 stresses that information assurance relies on three critical components. Which one of the following answers correctly lists these components? People, documentation, technology People, Defense in Depth, technology People, evaluation, certification People, operations, technology
3.	Risk management, as defined in NIST SP 800-30, comprises which three processes? Risk assessment, risk mitigation, and evaluation and assessment Risk identification, risk mitigation, and evaluation and assessment Risk assessment, risk impacts, and risk mitigation Risk assessment, risk mitigation, and risk identification
4.	In the system development life cycle, SDLC, or system life cycle as it is sometimes called, in which one of the of the five phases are the system security features configured, enabled, tested, and verified? Operation/maintenance Development/acquisition Implementation Initiation
5.	Which one of he following activities is performed in the Development/Acquisition phase of the SDLC? The scope of the IT system is documented. The IT system is developed, programmed, or otherwise constructed. The system performs its function. Disposition of information, hardware, or software.
6.	In NIST SP 800-30, risk is defined as a function of which set of the following items? Threat likelihood, vulnerabilities, and impact Threat likelihood, mission, and impact Vulnerabilities, mission and impact Threat likelihood, sensitivity, and impact
7.	The risk assessment methodology described in NIST SP 800-30 comprises nine primary steps. Which one of the following is not one of these steps? System characterization Control analysis Impact analysis Accreditation boundaries
8.	Which one of the following items is not one of the activities of the generic systems engineering (SE) process? Discover needs Define system requirements Obtain accreditation Assess effectiveness
9.	The elements of Discover Information Protection Needs, Develop Detailed Security Design, and Assess Information Protection Effectiveness are part of what process? The systems engineering (SE) process The information systems security engineering process (ISSE) The system development life cycle (SDLC) The risk management process
10.	In the ISSE process, information domains are defined under the Discover Information Protection Needs process. Which one of the following tasks is not associated with the information domain? Identify the members of the domain List the information entities that are under control in the domain Identify the applicable privileges, roles, rules, and responsibilities of the users in the domain Map security mechanisms to security design elements in the domain
11.	As part of the Define System Security Requirements activity of the ISSE process, the information systems security engineer identifies and selects a solution set that can satisfy the requirements of the IPP. Which one of the following elements is not a component of the solution set? Functional decomposition Preliminary security concept of operations (CONOPS) System context System requirements
12.	The information systems security engineer’s tasks of cataloging candidate commercial off-the-shelf (COTS) products, government off-the-shelf (GOTS) products, and custom security products are performed in which one of the following ISSE process activities? Define System Security Requirements Develop Detailed Security Design Implement System Security Design System Security Architecture
13.	Which ISSE activity includes conducting unit testing of components, integration testing, and developing installation and operational procedures? Assess Information Protection Effectiveness Develop Detailed Security Design Implement System Security Design System Security Architecture
14.	Security certification is performed in which phase of the SDLC? Implementation phase Validation phase Development/Acquisition phase Operations/Maintenance phase
15.	The certification and accreditation process receives inputs from the ISSE process. These inputs are which one of the following items? Certification documentation Certification recommendations Accreditation decision Evidence and documentation
16.	Security categorization is part of which phase of the SDLC? Initiation Acquisition/Development Implementation Requirements
17.	Which one of the following items is not an activity under the Acquisition/Development phase of the SDLC? Preliminary risk assessment Security functional requirements analysis Cost considerations and reporting Developmental security evaluation
18.	According to NIST SP 800-64, which phase of the SDLC includes the activities of functional statement of need, market research, cost-benefit analysis, and a cost analysis? Initiation Acquisition/Development Implementation Operations/Maintenance
19.	In NIST SP 800-30, a threat is defined as which one of the following items? Intent and method targeted at the intentional exploit of a vulnerability The likelihood that a given threat source will exercise a particular potential vulnerability, and the resulting impact of that adverse event on the organization The potential for a threat source to exercise a specific vulnerability A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised and result in a security breach or a violation of the system’s security policy
20.	Questionnaires, on-site interviews, review of documents, and automated scanning tools are primarily used to gather information for which one of the following steps of the risk assessment process? System characterization Risk determination Vulnerability identification Control analysis
21.	In performing an impact analysis as part of the risk assessment process, three important factors should be considered in calculating the negative impact. Which one of the following items is not one of these factors? The sensitivity of the system and its data The management of the system The mission of the system The criticality of the system, determined by its value and the value of the data to the organization
22.	Which choice would not be considered an operations management task related to system maintenance? Approving, controlling, and monitoring remotely executed maintenance and diagnostic activities Scheduling, performing, and documenting routine preventative and regular maintenance on the components of the IS Prioritizing, evaluating, and implementing the controls that are an output of the risk assessment process Maintaining a list of personnel authorized to perform maintenance on the information system
23.	Which task is not a common incident reporting task? Tracking information system security incidents on an ongoing basis Employing a formal sanctions process for personnel failing to comply with established information security policies and procedures Promptly reporting incident information to appropriate authorities Providing an incident support advice and assistance to users of the information system
24.	Which choice accurately describes a task of operations security? Terminating information system access to terminated employees Incorporating security in system development models and configuration management Integrating application and network security controls Developing processes to identify system threats and vulnerabilities
25.	Which choice would not be considered an element of managing operations security compliance? Developing continuity of operations plans Managing incidents and security violations Developing help desk and maintenance programs Ensuring the availability and integrity of system processes

Answers

1.	Answer: b The requirements phase is not one of the five system life cycle planning phases. The other two phases of the system life cycle are the Development/Acquisition phase and the Operations phase.
2.	Answer: d Answers a, b, and c are distracters.
3.	Answer: a Answers b, c, and d are distracters.
4.	Answer: c
5.	Answer: b Answer a refers to the Initiation phase; answer c refers to the Operation/Maintenance phase; and answer d refers to the Disposal phase.
6.	Answer: a Answers b, c, and d are distracters.
7.	Answer: d Delineating accreditation boundaries is a subset of answer a, system characterization.
8.	Answer: c Obtaining accreditation is not one of the SE process activities. The other SE process activities are to design system architecture, to develop detailed design, and to implement the system.
9.	Answer: b
10.	Answer: d
11.	Answer: a Functional decomposition is part of the Design System Security Architecture activity of the ISSE process.
12.	Answer: b
13.	Answer: c
14.	Answer: a Answer b, Validation, is not a phase of the SDLC. Answers c and d are additional phases of the SDLC.
15.	Answer: d Answers a, b, and c are outputs of the Certification and Accreditation process.
16.	Answer: a Security categorization defines low, moderate, or high levels of potential impact on organizations as a result of a security breach. Answers b and c are other phases of the SDLC. Answer d is not a phase of the SDLC.
17.	Answer: a This activity is performed in the initiation phase of the SDLC. Additional activities under the acquisition/development phase of the SDLC are risk assessment, assurance requirements analysis security, security planning, and security control development.
18.	Answer: b Additional activities under this phase include requirements analysis, alternatives analysis, and a software conversion study.
19.	Answer: c Answer a is a threat source, answer b defines risk, and answer d is the definition of vulnerability.
20.	Answer: a
21.	Answer: b
22.	Answer: c
23.	Answer: b
24.	Answer: a
25.	Answer: a