The Certification Phase

Overview

This chapter gets to the heart of C&A: the Certification Phase. First you’ll examine the general steps involved in conducting a system certification, and then you’ll look at a specific example of certification using DITSCAP. The first two phases of DITSCAP are examined in this chapter, then Phases 3 and 4 are looked at in the next chapter, “The Accreditation Phase.”

According to NIST 800-37, the Security Certification Phase consists of two primary tasks:

1. Perform the security control assessment
2. Prepare the security certification documentation

The goal of the Certification Phase is to determine how well the information system security controls are implemented, whether they are operating as intended, and whether the controls are meeting the security requirements for the system.

The Certification Phase also addresses specific actions taken to correct deficiencies in the security controls and to reduce or eliminate known vulnerabilities in the system.

After the Certification Phase is complete, the Designated Approving Authority (DAA) or other authorizing official should have enough information to be able to make the appropriate accreditation determination - that is, whether the system security controls provide the required risk mitigation level to allow the system to operate within the system’s concept of operations (CONOPS).

CONCEPT OF OPERATIONS (CONOPS)

The Concept of Operations (CONOPS) is a document detailing the method, act, process, or effect of using an Information System. The CONOPS is a statement of a commander’s assumptions or intent in regard to an IS and how it relates to the concept of operations embodied in campaign plans and operational plans. The concept is designed to give an overall picture of the IS and its function and environment.

Security Control Assessment

The objective of the security control assessment task is threefold:

1. Prepare for the assessment of the security controls in the information system.
2. Conduct the assessment of the security controls.
3. Document the results of the assessment.

This task greatly involves the Certification Agent (CA). By the end of the Security Control Assessment the CA will be able to determine the extent to which the security controls in the information system are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system.

The output of this task will also enable the CA to make recommendations on corrective actions for security control deficiencies. The CA can then offer advice to the information system owner and authorizing official on how the known vulnerabilities in the system translate into actual risk.

Prepare for the Assessment

Preparation for the security assessment involves:

• Gathering the appropriate planning and supporting materials
• Collecting all available system requirements and design documentation
• Gathering the security control implementation evidence
• Compiling the results from previous security assessments, security reviews, or audits

THE SYSTEM SECURITY PLAN

The purpose of the System Security Plan (SSP) is to provide an overview of the security requirements of the system and describe the controls in place or planned, responsibilities and expected behavior of all individuals who access the system. The system security plan should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system. It should reflect input from various managers with responsibilities concerning the system, including information owners, the system operator, and the system security manager.

Additional information may be included in the basic plan and the structure and format organized according to agency needs, so long as the major sections described in this document are adequately covered and readily identifiable.

Gather the Documentation

The information system owner should assist the certification agent in gathering all relevant documents and supporting materials from the agency that will be required during the assessment of the security controls. The IS owner and the CA should assemble any documentation and supporting materials necessary for the assessment of the security controls in the information system; if these documents include previous assessments of security controls, the IS owner and the CA should review the findings, results, and evidence.

Certification agents should maximize the use of previous assessment results in determining the extent to which the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The certification agent may incorporate those results into the security certification.

Useful materials can include:

• Supporting materials such as procedures, reports, logs, and records showing evidence of security control implementation
• Previous evaluation results and/or information system audits, security certifications, security reviews or self-assessments
• Previous assessment results from programs that test and evaluate the security features of commercial information technology products or prior security test and evaluation reports
• Prior assessment results from the system developer
• Privacy impact assessments
• Other documents and supporting materials included or referenced in the system security plan, such as NIST Special Publication 800-53A, ISO/IEC 15408 (Common Criteria) validations, and FIPS 140-2 validations

Define the Assessment Methods and Procedures

Preparation also involves developing specific methods and procedures to assess the security controls in the information system. The certification agent must select, or develop when needed, appropriate methods and procedures to assess the management, operational, and technical security controls in the information system. The assessment methods and procedures may need to be tailored for specific system implementations; therefore, the CA can supplement these methods and procedures.

Conduct the Security Assessment

The CA then must assess the management, operational, and technical security controls in the information system using methods and procedures selected or developed. Security assessment determines the extent to which the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The results of the security assessment, including recommendations for correcting any deficiencies in the security controls, are documented in the security assessment report.

Prepare the Security Assessment Report

After the assessment, the Certification Agent prepares the final security assessment report. The security assessment report is part of the final accreditation package along with the updated system security plan, plan of action, and milestones. The security assessment report is the certification agent’s statement regarding the security status of the information system.

The security assessment report contains:

1. The results of the security assessment
2. Recommendations for correcting deficiencies in the security controls and reducing or eliminating identified vulnerabilities.

SECURITY TEST AND EVALUATION (ST&E)

As discussed in Chapter 12, a Security Test and Evaluation (ST&E) is an examination and analysis of the safeguards required to protect an automated information system (AIS) as they have been applied in an operational environment to determine the security posture of that system. It is defined in the SSAA and executed in Phase 3.

Security Certification Documentation

The objectives of the security certification documentation task are to:

• Provide the certification findings and recommendations to the information system owner
• Update the system security plan (and risk assessment) based on the results of the security assessment and any modifications to the security controls in the information system
• Prepare the plan of action and milestones based on the results of the security assessment.
• Assemble the final security accreditation package and submit it to the authorizing official

The information system owner has an opportunity to reduce or eliminate vulnerabilities in the information system prior to the assembly and compilation of the accreditation package and submission to the authorizing official. This is accomplished by implementing corrective actions recommended by the Certification Agent. The CA should assess any security controls modified, enhanced, or added during this process. The completion of this task concludes the Security Certification Phase.

Provide the Findings and Recommendations

The information system owner may choose to act on selected recommendations of the CA before the accreditation package is finalized if there are specific opportunities to correct deficiencies in security controls and reduce or eliminate vulnerabilities in the information system. To ensure effective allocation of resources agencywide, any actions taken by the information system owner prior to the final accreditation decision should be coordinated with the authorizing official and senior agency information security officer.

The CA then assesses any changes made to the security controls in response to corrective actions by the information system owner and updates the assessment report as appropriate.

Update the System Security Plan

The information system owner should update the system security plan as needed. The system security plan should reflect the actual state of the security controls after the security assessment and any modifications by the information system owner in addressing the recommendations for corrective actions from the certification agent.

At the completion of the Security Certification Phase, the security plan and risk assessment should contain an accurate list and description of the security controls implemented and a list of identified vulnerabilities (i.e., controls not implemented).

Prepare the Plan of Action

The information system owner also must prepare the plan of action. The Plan of Action and Milestones document, one of the three key documents in the security accreditation package, describes actions taken or planned by the information system owner to correct deficiencies in the security controls and to address remaining vulnerabilities in the information system (i.e., reduce, eliminate, or accept the vulnerabilities).

The Plan of Action and Milestones document identifies:

• The tasks needing to be accomplished
• The resources required to accomplish the elements of the plan
• Any milestones in meeting the tasks
• Scheduled completion dates for the milestones

Assemble the Accreditation Package

The information system owner is responsible for the assembly and compilation of the final security accreditation package, with inputs from the information system security officer and the CA. The accreditation package contains:

• The security assessment report from the certification agent providing the results of the independent assessment of the security controls and recommendations for corrective actions
• The plan of action and milestones from the information system owner, indicating actions taken or planned to correct deficiencies in the controls and to reduce or eliminate vulnerabilities in the information system
• The updated system security plan with the latest copy of the risk assessment

The information system owner may also wish to consult with other key agency participants (e.g., the user representatives) prior to submitting the final accreditation package to the authorizing official. The authorizing official will use this information during the Security Accreditation Phase to determine the risk to agency operations, agency assets, or individuals. The accreditation package can be submitted in either paper or electronic form. The contents of the accreditation package should be protected appropriately in accordance with agency policy.

DITSCAP Certification Phases

As a good example of a specific C&A process, we’ll use DITSCAP. The first two phases of a DITSCAP C&A fit nicely within the umbrella of the Certification Phase, while Phases 3 and 4 can be examined in the next chapter, “The Accreditation Phase.” Also, DITSCAP has traditionally been the model for InfoSec C&A programs, and the subtasks described here can give you an excellent view into the mechanisms of C&A.

Phase 1 Definition

The goals of Phase 1, the Definition Phase, are to define the C&A level of effort, identify the principal C&A roles and responsibilities, and create an agreement on the method for implementing the security requirements that will be documented in the SSAA. Phase 1 starts with the input of the mission need statement (or other justification for the system) and ends by producing the SSAA. DITSCAP Phase 1, shown in Figure 13-1, contains three process activities:

• Document mission need
• Registration
• Negotiation

Figure 13-1: DITSCAP Phase 1 activities.

Document Mission Need

Information and documentation are collected about the system during this task, including capabilities and functions that the system will perform, desired interfaces and data flows associated with those interfaces, information to be processed, operational organizations supported, intended operational environment, and operational threat.

This information comes from many sources. Examples of the types of documentation and information collected and reviewed during the preparation phase include:

• Business case or mission need statement
• System specifications
• Architecture and design documents
• Network diagrams
• Configuration management documents
• Threat analysis
• User manuals
• Operating procedures
• Federal and organization IA and security instructions and policies

Registration

Registration begins with preparing the mission description and system identification and concludes with preparing an initial draft of the SSAA. The main purpose of the registration activity during Phase 1 is to initiate the risk management agreement process among the four principals: the DAA, certifier, program manager, and user representative.

During registration, information is evaluated, applicable IA requirements are determined, risk management and vulnerability assessment actions begin, and the level of effort required for C&A is determined and planned.

The registration tasks include:

• Preparing business or operational functional description and system identification
• Informing the DAA, certifier, and user representative that the system will require C&A support
• Preparing the environment and threat description
• Preparing a system architecture description and a description of the C&A boundary
• Determining system security requirements
• Tailoring DITSCAP tasks, determining the C&A level-of-effort, and preparing a DITSCAP plan
• Identifying organizations that will be involved in the C&A identifying resources required
• Developing the first draft of the SSAA

A very important registration task is the preparation of a description of the C&A boundary. The accreditation boundary should include all IS facilities and equipment under the control of the DAA to be addressed in the C&A. The relationship of the accreditation boundary to any existing external interfaces or other equipment or systems also must be determined. Any facility or equipment that is not under the control of the DAA is considered an external interface.

When registration activities are concluded, the draft SSAA is submitted to the DAA, certifier, program manager, and user representative. The draft SSAA is then used as the basis for discussions during the negotiation phase. The program manager normally drafts the SSAA, but the certifier (or certification team) may also draft it.

Negotiation

During negotiation, all participants involved in the IS development, acquisition, operation, security certification, and accreditation agree on the implementation strategy to be used to satisfy the security requirements identified during system registration. The purpose of negotiation is to ensure that the SSAA properly and clearly defines the approach and level of effort.

The primary negotiation tasks are:

1. Conduct the Certification Requirement Review (CRR)
2. Agree on the security requirements, level of effort, and schedule
3. Approve final Phase 1 SSAA

All participants will develop an understanding of their roles and responsibilities during negotiation. They review the proposed certification efforts and resource requirements to determine that the appropriate assurance is being applied.

Each role has a defined task during negotiation:

• The DAA conducts a complete review of the draft SSAA to determine that all appropriate IA and security requirements are included.
• The certifier conducts a comprehensive evaluation of the technical and nontechnical security features of the IS.
• The program manager reviews the SSAA for accuracy, completeness, costs, and schedule considerations.
• The user representative reviews the SSAA to determine whether the system will support the user’s mission and that appropriate security operating procedures will be available at system delivery.

Negotiation ends when the responsible organizations adopt the SSAA and concur that those objectives have been reached. The Certification Requirement

Review (CRR) must result in an agreement regarding the level of effort and the approach that will be taken to implement the security requirements. The CRR must include the information documented in the SSAA (mission and system information, operational and security functionality, operational environment, security policy, system security requirements, known security problems or deficiencies, and other relevant security information).

The System Security Authorization Agreement (SSAA)

The product of the DITSCAP Phase 1 is the System Security Authorization Agreement (SSAA). The SSAA is a formal agreement among the DAA(s), certifier, user representative, and program manager. The objective of the SSAA is to establish an evolving yet binding agreement on the level of security required before the system development begins or changes to a system are made.

The SSAA is used throughout the entire C&A process to guide actions, document decisions, specify IA requirements, document certification tailoring and level of effort, identify possible solutions, and maintain operational systems security. After accreditation, the SSAA becomes the baseline security configuration document.

Both the DITSCAP and NIACAP SSAAs are very similar, with only minor differences. NIACAP identifies it as a System Security Plan (SSP), however, rather than a SSAA.

The SSAA should:

• Document the formal agreement among the DAA(s), the CA, the user representative, and the program manager
• Document all requirements necessary for accreditation
• Document all security criteria for use throughout the IT system life cycle
• Minimize documentation requirements by consolidating applicable information into the SSAA, such as security policy, concept of operations (CONOPS), plans, and architecture description
• Document the DITSCAP plan

SSAA Outline

The SSAA is a living document that represents the formal agreement among the DAA, the CA, the user representative, and the program manager. The SSAA is developed in Phase 1 and updated in each phase as the system development progresses and new information becomes available.

At minimum, the SSAA should contain the information in the following sample format:

• 1. Mission Description and System Identification
• 1.1. System name and identification
• 1.2. System description
• 1.3. Functional description
• 1.3.1. System capabilities
• 1.3.2. System criticality
• 1.3.3. Classification and sensitivity of data processed
• 1.3.4. System user description and clearance levels
• 1.3.5. Life cycle of the system
• 1.4. System CONOPS summary
• 2. Environment Description
• 2.1. Operating environment
• 2.2. Software development and maintenance environment
• 2.3. Threat description
• 3. System Architectural Description
• 3.1. Hardware
• 3.2. Software
• 3.3. Firmware
• 3.4. System interfaces and external connections
• 3.5. Data flow (including data flow diagrams)
• 3.6. TAFIM DGSA, security view
• 3.7. Accreditation boundary
• 4. ITSEC System Class
• 4.1. Interfacing mode
• 4.2. Processing mode
• 4.3. Attribution mode
• 4.4. Mission-reliance factor
• 4.5. Accessibility factor
• 4.6. Accuracy factor
• 4.7. Information categories
• 4.8. System class level
• 4.9. Certification analysis level
• 5. System Security Requirements
• 5.1. National and DoD security requirements
• 5.2. Governing security requisites
• 5.3. Data security requirements
• 5.4. Security CONOPS
• 5.5. Network connection rules
• 5.5.1. To connect to this system
• 5.5.2. To connect to the other systems defined in the CONOPS
• 5.6. Configuration and change-management requirements
• 5.7. Reaccreditation requirements
• 6. Organizations and Resources
• 6.1. Identification of organizations
• 6.1.1. Identification of the DAA
• 6.1.2. Identification of the CA
• 6.1.3. Identification of the user representative
• 6.1.4. Identification of the organization responsible for the system
• 6.1.5. Identification of the program manager or system manager
• 6.2. Resources
• 6.2.1. Staffing requirements
• 6.2.2. Funding requirements
• 6.3. Training for certification team
• 6.4. Roles and responsibilities
• 6.5. Other supporting organizations or working groups
• 7. C&A Plan
• 7.1. Tailoring factors
• 7.1.1. Programmatic considerations
• 7.1.2. Security environment
• 7.1.3. IT system characteristics
• 7.1.4. Reuse of previously approved solutions
• 7.1.5. Tailoring summary
• 7.2. Tasks and milestones
• 7.3. Schedule summary
• 7.4. Level of effort
• 7.5. Roles and responsibilities

SSAA Additional Material

Appendixes shall be added to include system C&A artifacts. Optional appendixes may be added to meet specific needs. Include all documentation that will be relevant to the system’s C&A.

• APPENDIX A. Acronym list
• APPENDIX B. Definitions
• APPENDIX C. References
• APPENDIX D. Security requirements and/or requirements traceability matrix
• APPENDIX E. Security test and evaluation plan and procedures
• APPENDIX F. Certification results
• APPENDIX G. Risk assessment results
• APPENDIX H. CA’s recommendation
• APPENDIX I. System rules of behavior
• APPENDIX J. Contingency plan(s)
• APPENDIX K. Security awareness and training plan
• APPENDIX L. Personnel controls and technical security controls
• APPENDIX M. Incident response plan
• APPENDIX N. Memorandums of agreement - system interconnect agreements
• APPENDIX O. Applicable system development artifacts or system documentation
• APPENDIX P. Accreditation documentation and accreditation statement

The Requirements Traceability Matrix (RTM)

A Requirements Traceability Matrix (RTM) is used by project managers to manage user requirements for defining new systems. The RTM is used in a variety of ways throughout the systems development life cycle. In DITSCAP, the RTM is developed in the requirements gathering phase and is used to organize and track the security requirements of the target system to be accredited. It is commonly part of the SSAA as an addendum.

The RTM is referenced during all phases of the C&A to:

• Track whether and how all security requirements are being met by the system
• Assist in the development of test scripts for the System Test and Evaluation (ST&E)
• Support the documentation that all system security requirements have been met in the accreditation phase of the C&A

The manner in which these security protection features are considered with respect to the requirements is usually contained in the Security Test Plan and Procedures subset of the SSAA.

Figure 13-2 shows an RTM that was used for a military SBU-class type accreditation. It’s common to use a database tool such as Microsoft® Access to build the RTM, employing established information assurance databases of standards, such as TCSEC.

Figure 13-2: An RTM database tool.

For example, the database tool enables the certifier to compile security requirements derived from multiple sources (e.g., the Army and the Navy) and filter them based on the TCSEC class of the system. These tools are also a great help in establishing the relationship of interdependent standards to the system and its environment.

Figure 13-3 shows a screen of the DoD Information Assurance Requirements Traceability Matrix and shows the description of a specific fundamental InfoSec TCSEC requirement.

Figure 13-3: DoD IA RTM.

Figure 13-4 shows a page of the report output from the RTM database. An excellent example of a sample Traceability Matrix can be found at www.jiludwig.com/Traceability_Matrix_Structure.html.

Figure 13-4: RTM report example.

Phase 2 Verification

The goal of Phase 2 is to obtain a fully integrated system for certification testing and accreditation. Phase 2 occurs between the signing of the initial version of the SSAA and the formal accreditation of the system. The process activities of Phase 2 verify the evolving system’s compliance with the requirements agreed on in the SSAA. These activities are intended to verify the evolving system’s compliance with the risk management requirements in the SSAA.

Phase 2 activities verify security requirements during system development, or modification by certification analysis and assessment of the certification results. As shown in Figure 13-5, Phase 2 process activities include:

• Continuing refinement of the SSAA
• System development
• Certification analysis
• Assessment of the Analysis Results

Figure 13-5: DITSCAP Phase 2 activities.

Refine the SSAA

At each stage of development or modification, details are added to the SSAA. Throughout Phase 2 the SSAA is reviewed and updated to include changes made during system development and the results of the certification analysis.

Any changes in the system that affect its security posture must be submitted to the DAA, certifier, program manager, and user representative for approval and inclusion in the revised SSAA.

System Development and Integration

System development and integration activities are those activities required for development or integration of the information system components as defined in the system’s functional and security requirements. The specific activities will vary depending on the overall program strategy, the life cycle management process, and the position of the information system in the life cycle.

System development and integration tasks include:

• Preparing the system architecture
• Preparing high-level and detailed design documents
• Integrating commercial off-the-shelf (COTS) products
• Conducting system integration testing

Initial Certification Analysis

The initial certification analysis determines whether the information system is ready to be evaluated and tested under Phase 3. It verifies by analysis, investigation, and comparison methodologies that the IS design implements the SSAA requirements and that the IS components critical to security function properly. This verifies that the development, modification, and integration efforts will result in a higher probability of success for an accreditable IS before Phase 3 begins.

When the Phase 2 initial certification analysis is completed, the system should have a documented security specification, comprehensive test procedures, and written assurance that all network and other interconnection requirements have been implemented.

Initial certification analysis tasks include:

• System architecture analysis.   Verify that the system architecture complies with the architecture description in the SSAA. The interfaces between this and other systems must be identified and evaluated to assess their effectiveness in maintaining the security posture of the infrastructure.
• Software, hardware, and firmware design analysis.   Evaluate how well the software, hardware and firmware reflect the security requirements of the SSAA and the security architecture of the system.
• Network connection rule compliance analysis.   Evaluate the intended connections to other systems and networks to ensure the system design will enforce specific network security policies and protect the IS from adverse confidentiality, integrity, availability, and accountability impacts.
• Integrity analysis of integrated products.   Evaluate the integration of COTS or GOTS software, hardware, and firmware to ensure that their integration into the system design complies with the system security architecture. The product security functionality should be verified by the certification team to confirm that the needed security functions are present and properly integrated into the system.
• Life cycle management analysis.   Verify that change control and configuration management practices are in place, or will be, and are sufficient to preserve the integrity of the security-relevant software and hardware.
• Security requirements validation procedure preparation.   Define the procedures to be used to verify compliance with all the defined security requirements. The security requirements document must identify the type of review required to validate each requirement. If test procedures are prepared, they should be added to the SSAA.
• Vulnerability assessment.   The initial certification analysis tasks conclude with a vulnerability assessment to identify the residual risk. A vulnerability assessment evaluates security vulnerabilities with regard to confidentiality, integrity, availability, and accountability and recommends applicable countermeasures. It uses techniques such as static penetration, flaw hypothesis, and threat-vulnerability pairing to determine the ability to exploit the vulnerabilities.

Assess Analysis Results

At the conclusion of each development or integration milestone, the certification analysis results are reviewed for SSAA compliance. If the results indicate significant deviation from the SSAA, the NIACAP should return to Phase 1 to resolve the problems. If the risk exceeds the maximum acceptable risk, the system must return to Phase 1 for reconsideration of the IS business functions, operating environment, and IS architecture. If the results are acceptable, the NIACAP proceeds to Phase 3.

Key DITSCAP Roles

The four key roles in the DITSCAP are:

• System program manager.   The program manager represents the interests either of the system acquisition or maintenance organization, with engineering, scheduling, and funding responsibility; or of the system operations organization, with responsibility for daily operations, performance, and maintenance. The organization the program manager represents is usually determined by the phase in the life cycle of the system.
• Designated approving authority (DAA).   The DAA is usually a senior operational commander with the authority and ability to evaluate the operational needs for the system in view of the security risks. The DAA must have the authority to oversee the operations and use of systems under his/her purview. The DAA represents the interests of mission need, controls the operating environment, and defines the system level security requirements.
• Certification agent (CA).   The CA provides the technical expertise to conduct the certification. The CA, security teams, and so forth are the technical experts that support the C&A process.
• User representative.   The interests of the system’s users are vested in the user representative. In the DITSCAP, the user representative, at minimum, is concerned with system availability, access, integrity, functionality, and performance.

These individuals reach agreement during Phase 1 (Negotiation) and approve the SSAA. During Phases 2, 3, and 4, these four key individuals return to Phase 1 negotiation and subsequent revision of the SSAA if the system is changed or any of the agreements delineated in the SSAA are modified.

DIACAP Certification Phases

As we mentioned in Chapter 11, DITSCAP (DoDI 8510.bb) is being replaced by DIACAP, which was expected to be signed in May 2006. The new DIACAP rules will take effect during the first FISMA cycle following the signing. The Information Assurance Technology Analysis Center’s Web site (http://iac.dtic.mil/iatac/) is currently scheduled to host the DIACAP knowledge base, providing user implementation guidance.

We briefly list the DIACAP certification phases here for reference and comparison. The DIACAP process is a five-phase process:

1. Initiate and Plan
2. Implement and Validate
3. Make C&A Decisions
4. Maintain ATO/Reviews
5. Decommission

Phases 1 and 2 loosely fit in the NIST Certification Phase, Phases 3 and 4 in the Accreditation Phase, and Phase 5 in the Continuous Monitoring Phase. The specific subtasks relating to the certification tasks are:

• Phase 1: Initiate and Plan
  • Register System
  • Assign IA Controls
  • Assemble Team
  • Develop Strategy
  • Initiate IA Implementation Plan

• Phase 2: Implement and Validate
  • Execute and Update IA Implementation Plan
  • Conduct Validation Activities
  • Compile Validation Results

We’ll examine the DIACAP accreditation-related phases in the next chapter.

End of the Certification Phase

At the end of the Certification Phase, and before proceeding to the Accreditation Phase, two important questions need to be answered. To what extent are the security controls in the information system implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system? What specific actions have been taken or are planned to correct deficiencies in the security controls and to reduce or eliminate known vulnerabilities in the information system?

Assessment Questions

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

Answers