Institutional and Sector Modernisation Facility

ICT Standards

Project Funded by the European Union

Certification and Accreditation Guide Document number: ISMF-ICT/3.03 - ICT Security/MISP/SD/C&A Version: 1.30

1 Document control

1.1 List of Abbreviations Abbreviation Description MISP Ministry Information Security Program C&A Certification and Accreditation SSAA System Security Authorization Agreement SLC System Life Cycle AA Approving Authority CA Certification Authority ISO Information Security Office PM Program Manager RA Risk Assessment SSP System Security Plan DRP Disaster Recovery Plan CM Configuration Management

1.2 Purpose of this Document The Certification and Accreditation Guide is an attachment to the MISP Policy and MISP Handbook. It is part of the ICT Security package that has been produced within the scope of the ICT Standards project. This project is one of the three sub-projects executed under the global project name “Software Development and Technical Assistance for NISFED, e-Government and ICT Standards Applications”, started 20/08/2006 and rolled out within the scope of the ISMF programme1.

1 For a complete list of documents related to the ICT Standards project, refer to the Project Master Plan; ISMF-ICT/3.01, V.2.00.

2 Introduction The Certification and Accreditation Guide was created as part of the Ministry Information Security Program (MISP) supporting documents. It serves as a guide to the Ministry and its directorates to implement a Certification and Accreditation program for their information systems.

2.1 Purpose This guide provides the Ministry with a standardized, but adaptable Certification and Accreditation (C&A) process that is in line with the Ministry policies. C&A is a process designed to certify that a system meets documented security requirements and will continue to maintain the accredited security posture throughout the System Life Cycle (SLC). This guide identifies the steps involved in the C&A process, describes the critical roles and responsibilities at the Ministry and it’s directorates key staff, and provides sample documents to assist in the C&A process.

3 Certification and Accreditation Overview

3.1 The Certification and Accreditation Process Certification is the comprehensive evaluation of a system’s technical, managerial, and operational security safeguards that establish the extent to which a particular design and its implementation meet a set of specified security requirements. The Certification phase of the C&A process includes a system analysis to identify any weaknesses in operating the system with specified countermeasures in a particular environment, as well as an analysis of the potential vulnerabilities associated with the weaknesses. Planning for C&A should be implemented at the beginning of the system’s life cycle to ensure that: � Security protection mechanisms and safeguards are designed and integrated into the

system and its subsystems � Security documentation is developed and available prior to system implementation � Security decisions are not delayed, because this leads to costly revisions and delays in

operationally fielding the system � Adequate resources are provided for C&A activities The certification process supports accreditation, which is the formal declaration by management, hereafter known as an Approving Authority (AA), that the system is approved to operate in a particular security mode using a prescribed set of safeguards. (Figure 1)

Planning for Certification and

Accreditation

System Analysis

VulnerabilityAnalysis

Approval by AAbased on level

of acceptable risk

SystemImplementation

Planning for Certification and

Accreditation

System Analysis

VulnerabilityAnalysis

Approval by AAbased on level

of acceptable risk

SystemImplementation

CERTIFICATION

ACCREDITATION

SYSTEM RISK CHANGES

Figure 1 - Certification and Accreditation Cycle

Accreditation should be based strongly on an acceptable level of residual risks identified during certification. Because risk to a system changes over the life of the system, the AA must be actively involved in the accreditation and re-accreditation processes during the system’s entire life cycle. The level of risk the AA is willing to accept of a system should be commensurate with the system’s value to the Ministry or its directorate’s mission.

The C&A process provides a structure to ensure that each system is evaluated against security requirements and is formally approved by the responsible AA before implementation. C&A must be conducted on the Ministry and its directorate systems. No waivers shall be granted to allow a system to operate without certification prior to accreditation.

3.2 C&A Applicability to System Owners A system owner can apply the three concepts of C&A to a specific system throughout its life cycle: Assurance, Certification, and Accreditation. The most applicable concept is assurance. � Assurance is the measure of a system owner’s confidence that the security features,

attributes, and functions enforce the security policy. It can be applied to operations, systems, operational environments, and components or mechanisms and it refers to a system owner’s claims and evidence for accepting the correctness, effectiveness, and quality of the security service or mechanism. Life-cycle assurance requirements provide a system owner with a framework for secure system design, implementation, and maintenance.

� Certification verifies and validates the security assurance for a system associated with an environment.

� Accreditation then determines whether the operational impacts associated with any residual system weaknesses are tolerable or unacceptable, based on the information provided in the certification. The degree of assurance that a system owner or AA assumes about a system reflects the confidence that the system is able to enforce its security policy correctly during use and in the face of attacks. These phases are depicted in Figure 2.

Level of confidencein the effectiveness and

correctness of the system

Verifies and validates

the systemassurance

Evaluates theacceptabilityof a system’s

weakness

CertificationAssurance Accreditation

Figure 2 - The three Certification and Accreditation phases

3.3 C&A Roles and Responsibilities Many positions within the Ministry and its directorates have significant roles that contribute to the security of the Ministry and / or directorate system throughout its entire life cycle. The C&A process requires specific roles with significant input, oversight, and decision-making authority on the best management of system risks to the Ministry and its directorates primary missions. The C&A process integrates these primary roles throughout the SLC. The primary C&A roles include the User Representative, Program Manager, Certification Authority (CA), and Approving Authority (AA). Additional roles from the Systems Security Office (ISO) may be added to increase the integrity and objectivity of C&A decisions in support of the system business case or mission.

These minimum roles provide flexibility to tailor and scope the C&A efforts to the particular mission, environment, system architecture, threats, funding, and schedule of the system. � User Representative. An individual who has intimate knowledge of the system’s purpose

and goals and, therefore, provides valuable input to the C&A process. Throughout the SLC, the user representative acts as a liaison for the user community, defines the operational and functional requirements, and ensures that user requirements are fully integrated in each step of the life cycle.

� Program Manager (PM). The individual responsible for coordinating all steps of the system’s life cycle, from design through implementation and maintenance. Throughout the C&A process, the PM will coordinate with the other key players, reviewing information and providing input to ensure that the System Security Authorization Agreement (SSAA) is maintained and updated with the most accurate information throughout the system’s life cycle.

� Certification Authority (CA). The CA provides the technical expertise to conduct the certification through the system's life cycle based on the documented security requirements. The CA determines the level of residual risk and makes an accreditation recommendation to the AA. To ensure an objective certification process, the CA should be independent of the organization that developed or operates the system. The CA can request assistance in performing the C&A from government security personnel or contractors specializing in security. The CA can delegate duties like developing and documenting security procedures; however, only the CA can offer the final recommendation to the AA.

� Approving Authority (AA). The AA is the primary Ministry official responsible for allocating resources. The AA is a senior government executive with the authority to oversee and influence the budget and business operations of the systems under its jurisdiction. The AA is responsible for determining an acceptable level of risk for the system and establishing the approved system security posture. The AA may � Grant an Authorization to Operate, � Grant an Interim Authorization to Operate, or � Decide that the system’s weakness is of too great a risk and unacceptable, therefore,

refusing to allow the system to operate until risks are reduced. These decisions should be supported by the information contained in the accreditation package.

� Representative from the Information Security Office (ISO). Is responsible for the security of the information system during the course of its operations. The ISO ensures that the system is implemented, maintained, and operated in a secure manner

The C&A roles and responsibilities are as follows: C&A Role Responsibilities User Representative • Has ultimate knowledge of the system

• Acts as a liaison for the use community • Defines the operational and functional requirements • Ensures that user requirements are fully integrated in each step of

the life cycle Certification Authority • Conducts the certification process

• Determines whether the system is ready for certification • Reports to the AA whether the system should be accredited on the

basis of the existing risk • Independent of the organization that developed or that is

operating the system Program Manager • Coordinates all steps of the system life cycle

• Coordinates with key players throughout the C&A process • Reviews information • Provides input

ISO Representative • Responsible for the security of the system during course of operations

• Ensures that the system is implemented, maintained and operated in accordance with the SSAA

Approving Authority • Primary government official responsible for the system • Responsible for assigning an acceptable level of risk • May grant full or interim authorization, or refusal to operate

All senior management and/or program officials are in some way responsible for the security of a system.

3.4 C&A Standards After the required activities, such as Security Testing & Evaluation and Risk Assessments (RA) are completed, the certification file is assembled. This file is then sent to the AA for an accreditation decision. If the AA is presented with information that indicates that the levels of residual security risks are at an acceptable level, the AA may choose to grant an Authorization to operate (i.e. full accreditation) to that system for a period not to exceed three years. The AA will issue an Intermediate Authorization to operate for currently operating systems that meet a cross-section of the Ministry C&A standards. The Intermediate Authorization is only a temporary solution for keeping information systems in an accredited operational status for a designated period of time until the more comprehensive C&A process can be conducted. These standards will then be re-applied for purposes of re-accrediting a system when it becomes applicable. The criteria for these standards are discussed in the following subsections.

3.5 Security Testing and Evaluation The Security Testing & Evaluation process includes the verification and validation of both technical and non-technical controls. Technical controls include those system configurations and features designed within the system such as identification and authorization, audit, and operating system security policies. Non-technical controls include management and operational security controls such as rules of behavior, configuration management plans, contingency and disaster recovery plans, interface control documents, physical security controls, and/or interconnection agreements. These documents are part of the accreditation file. There is also a Security Testing & Evaluation report that documents the planned approaches and results of the process.

3.6 Risk Assessment Organizations use Risk Assessments (RA) to determine the extent of the potential threat and risk associated with an IT system throughout its life cycle. The RA is typically performed independently of the project office or system owner by a third party to assure an unbiased assessment. However, meaningful knowledge is obtained from the system owner and project personnel as input to the assessment. The output of this process helps to identify appropriate controls for reducing or eliminating risk during the risk mitigation process. Results of the assessment include the identified vulnerabilities, the assessed likelihood and impact of risk, and the recommended countermeasures. This information, documented in a RA report, is a mandatory requirement of the certification package.

3.7 Certification File Contents For each system reviewed, the CA is responsible for developing a system certification file that is forwarded to the appropriate AA for review to aid in the accreditation decision. At a minimum, the certification file for an Authorization to operate consists of the following documents: � All SSAA Template Sections2

� Selected appendices including: � System Security Plan � Report on Security Testing & Evaluation � Final Risk Assessment � CA recommendation statement � System Rules of Behavior � Personnel Controls and Technical Security Controls � Memorandums of Agreement – System Interconnection Agreements

The Security Testing & Evaluation plan, the SSP, the RA, and additional required security documents are discussed in greater detail in section 5.

2 Refer to the Certification and Accreditation Template, reference ICT Security/MISP/SD/C&A Template

3.8 Accreditation Decisions and Accreditation File Once the AA receives the system certification file, the file is reviewed and the AA makes an accreditation decision. The accreditation file consists of the applicable certification file (i.e., Authorization or Intermediate Authorization) and the accreditation decision letter. The AA can grant one of the following three types of accreditation: � Authorization to operate (full accreditation) is documented with an Authorization to Operate

memorandum and shall be granted when following is completed: � The certification file is complete � No corrective actions are required � Residual risks are acceptable to the AA.

� Intermediate Authorization to Operate (temporary accreditation). Four typical cases in which may be employed are as follows: � A new system is in an advanced test phase and must use some actual operational

data for final design and test before initial operational capability. � A survey has concluded that there are no apparent security problems that would allow

unauthorized persons to access data in a system, but there has been insufficient time or resources for rigorous hardware and software testing.

� The configuration of an operational system has been altered. Initial security evaluation by appropriate personnel does not reveal any severe problems, but a full evaluation has had scheduling delays.

� A system that will be installed at multiple sites has been evaluated in a test environment. Full accreditation will occur at the site when it is installed.

� At a minimum, the following documents are required to achieve an intermediate Authorization: � Risk Assessment � System Security Plan � Schedule to correct the deficiencies to achieve full accreditation. This plan must be

mutually acceptable to the program manager and the AA. � Denial. If the system cannot meet intermediate requirements or the AA considers the

residual risks to great to accept, the accreditation shall be denied. The system may not be placed into operation until an intermediate authorization, at a minimum, can be granted.

3.9 Re-Accreditation Ministry regulations mandate that systems be re-accredited every three years or when significant changes are made to the system configuration. Program managers and system owners should keep this in mind when planning system changes. If the system is not significantly altered, the system owner should begin the C&A process for re-accreditation in a timely fashion to ensure that the process is complete before the three-year anniversary of the system accreditation has passed. If significant changes occur on a system during the three-year period that the CA deems as a negative affect to the system’s approved security posture, a re-accreditation process must be initiated to regain the approved status.

Examples of significant changes may include the following: � The addition of an application or significant changes to an application program or design

including: � Installation of patches � Change in the Graphical User Interface (GUI) that affects security controls � Change in supporting security components or functionality � Observations of an audit or external assessment � Findings from any security review that identify significant vulnerabilities � Assessments and audits including internal IT security scans, physical or information

security inspections, internal control reviews � Change in the operating system, security software, or hardware that affects the

accredited security countermeasure implemented � Change to network configuration and architecture � Change in the criticality or sensitivity level that causes a change in the

countermeasures required (e.g., the addition of applications containing Privacy Act information, financial data)

� Breach of security or violation of system integrity, which reveals a flaw in security design, system security management, policy, or procedure

3.10 Exceptions to Security Requirements Limitations in resources and technical capabilities may prevent full compliance with all security requirements without introducing unacceptable delays. In this section, an exception indicates that the implementation of one or more security requirements is postponed temporarily and that satisfactory substitutes for the requirement(s) may be used for a specified time period. The AA is authorized to grant exceptions to some security requirements identified in the Ministry Information Security Program Policy under the following conditions: � An exception request is submitted and includes the following:

� A statement of the requirements that are not being met, the reason that identified requirements cannot be implemented, evidence to support that claim, the offsetting countermeasures that are to be substituted, and a timetable for completion

� A statement on which aspect of the threat is related to the proposed request and evidence that planned countermeasures will allow the secure operation of the system at an acceptable level of risk

� A plan for implementing the excepted security requirements later in the life cycle. Upon approval of the exception, the AA shall take the necessary programmatic, planning, and funding steps to ensure implementation of any security requirements that are postponed temporarily as a consequence of approval of the exception. The approved written exception shall be maintained with the accreditation package.

3.11 Certification and Accreditation in the System Life Cycle The Ministry and its directorates use an eight-phase approach to SLC management, ranging from the system concept to the retirement of a production system. Like other aspects of information processing systems, security is most cost-effective and efficient if planned and integrated at the beginning of an IT system’s life cycle. “Add-on” security addressed after development usually results in increased cost and may unnecessarily impede the ability of the system to meet performance and operational requirements. The C&A process allows the integration of security throughout the SLC. Figure 3 illustrates the relationship of the certification and accreditation process to the SLC.

The first three phases of the SLC coincide with the activities in the definition phase of the C&A process. These phases develop the operational and functional requirements for the IT system. Security requirements must also be addressed and are documented in Phase 1 of the SSAA.

The design and development phases implement technical solutions for operational requirements and security. Specific technical solutions may be selected based on having security solutions already embedded instead of requiring a separate add-on security solution that must be integrated into the system.

The build and test (implementation) phases of the SLC are integrated with the processes inherent in the validation phase of C&A. Building and testing the system for performance and compliance with operational requirements should also address security requirements. Successfully completing the test phase should result in system accreditation and authorization to operate.

To express the need for a system, its purpose and to document high-level

requirements

To design and build or purchase the

system

To test and implement the system on the field

Ensure the system performs the work

for which it has been implemented

Implementation Ops./MaintainBuildDesignDefinitionPlanning Analysis

Ensure dis-posal once

transition to a new system is

completed

Disposal

Definition Verification Validation Post Accreditation

To Understand the security requirements and level of effort

necessary to achieve certification and accreditation

To ensure that the fully integrated system will

be ready for certification testing

To confirm compliance of the fully integrated system with the security policy and requirements in the SSAA

To ensure secure system management, operation, and maintenance. To preserve an

acceptable level of residual risk

Figure 3 - The System Life Cycle and the C&A Process

The implementation phase addresses the processes required to install, make operational, and turn the system over to the user.

The last two life cycle phases, operations and maintenance and disposal, address the post accreditation life of the system. Configuration management practices allow system modifications and upgrades that ensure its effectiveness in meeting operational and security needs throughout its life span.

4 Certification and Accreditation Process

4.1 Overview The C&A process will standardize all Ministry and its directorate’s activities leading to successful accreditations. The principal purpose of the process is to protect and secure the entities comprising the Ministry and directorate information system environment with a proper balance between the benefits to the operational missions, the risks to those same missions, and the life-cycle costs. Standardizing the process helps to ensure that the shared interests of the common infrastructure are accurately represented and accounted for in the decision-making process. The C&A process consists of the Definition, Verification, Validation, and Post Accreditation Phases, as outlined in Figure 4.

Definition Verification Validation Post Accreditation

Figure 4 - C&A Phases

4.2 Certification and Accreditation Phases The C&A process establishes general tasks, a standard national process, a set of activities, and a management structure to certify and accredit systems that maintain the Information Assurance and security posture of a system or site. The process is designed to certify that the information system meets documented security requirements and continues to maintain the accredited security posture throughout the system’s life cycle.

4.2.1 Phase 1 – Definition

The Definition Phase is focused on understanding the information system business case, environment, and architecture to determine the security requirements and level of effort necessary to achieve certification and accreditation. The objective of Phase 1 is to agree on the security requirements, C&A boundary, schedule, level of effort, resources required, and accreditation type (i.e. the section Mission Description and System Identification from the SSAA template). Phase 1 closes with a documented agreement between the PM, AA, CA and User Representative on the approach and results of the Phase 1 activities.

Phase 1 contains three activities: Preparation, Registration, and Negotiation as outlined in Figure 5. This phase starts with a review of the system and site-related documents and ends by producing the SSAA. The C&A process is initiated in response to an identified operational requirement, or mission need. Any security-relevant changes should initiate a C&A for any existing or legacy Ministry and directorate information system. The C&A documents available for legacy systems should be converted to the SSAA format when the system is re-accredited.

System Docs,Requirements

Etc.

RegistrationPreparation Negotiation Agreement SSAA

1. ReviewDocumentation

10.Certification requirements review

11.Agree on level of effort and schedule Phase 1 approval

2. Prepare mission description and system identification

3. Register the system

4. Describe environment and threats

5. Describe system architecture

6. Determine security requirements

7. Identify resources8. Plan work9. Draft SSAA

Inpu

tsAc

tivity

Task

s

Phase 2Verification

Figure 5 - C&A Phase 1, Definition

4.2.2 Phase 2 – Verification

The Verification Phase confirms the evolving or modified system’s compliance with the information in the SSAA. The objective of this phase is to ensure that the fully integrated system will be ready for certification testing. These activities occur between the signing of the initial version of the SSAA and the formal C&A of the system. Phase 2 activities, as outlined in Figure 6, verify security requirements during system development (or modification) by certification analysis and assessment of the certification results. The SSAA is refined during Phase 2.

SSAA from Phase 1

System docs.Plans Etc.

InitialCertification

Analysis

SystemActivities Pass? Updated

SSAA

1. System Architecture2. Software Design3. Network Connections4. Integrity of integrated Products5. Life-Cycle Management

Inpu

tsAc

tivity

Task

s

Phase 3Validation

Pass?

ReanalyseRevise No

Yes Yes

No

A

Figure 6 - C&A Phase 2, Verification

4.2.3 Phase 3 – Validation

The Validation Phase confirms compliance of the fully integrated system with the security policy and requirements in the SSAA. This phase also validates that the preceding work has produced an information system that operates in a specified computing environment with an acceptable level of residual risk. The objective of Phase 3, as outlined in Figure 7, is to produce the required evidence to support the AA in making an informed decision to grant an (intermediate) authorization to operate the system. Phase 3 includes a review of the SSAA, an evaluation of the integrated information system, certification, and accreditation.

SSAA from Phase 2

Test Procs.Site info.

CertificationEvaluation

DevelopRecommendation

AccreditationGranted?

UpdatedSSAA

1. Security Test & Evaluation

2. Penetration Testing3. System Management

Analysis4. Site Evaluation5. Contingency Plan

Inpu

tsA

ctiv

ityTa

sks

Phase 4Post-Accreditation

CertifySystem? Yes

No

A

Yes

No

A

Figure 7 - C&A Phase 3, Validation

4.2.4 Phase 4 - Post Accreditation

The Post Accreditation Phase commences after the system has been certified and accredited for operations. This phase, as outlined in Figure 8, includes those activities necessary for the continuing operation of the accredited information system in its computing environment and for addressing the changing threats and small-scale changes that a system faces through its life cycle. The objective of Phase 4 is to ensure secure system management, operation and maintenance and to preserve an acceptable level of residual risk.

SSAA from Phase 3

Test Procs.Site info.

SystemsOperations

SecurityOperations

ComplianceValidation

Change Needed?

Inpu

tsA

ctiv

ityTa

sks

Phase 1Definition

ValidationNeeded? Yes

No

Yes

7. Site & Physical Security Validation8. Security Procedures Validation9. System Changes and Related Impact

Validation10.System Architecture and Interfaces

Validation11.Management Procedures Validation12.Risk Decisions Validation

1. SSAA Maintenance2. Review Physical, Management &

Personnel Controls3. Contingency Plan Maintenance4. Change Management5. System Security Management6. Review Risk Management

No

Figure 8 - C&A Phase 4, Post-Accreditation

5 Security Document Requirements The MISP Policy requires that specific security documents exist. This includes the documents from the C&A file. The following subsections provide descriptive information on several of the primary required security documents for the C&A package.

5.1 System Security Authorization Agreement The System Security Authorization Agreement (SSAA) is a formal agreement among the AA, CA, User Representative, and PM. It is the cornerstone document used throughout the C&A process, and incorporates other security documents as appendices. The SSAA guides actions and documents decisions; it specifies information assurance requirements and documents certification tailoring and level of effort specific to the organization. It identifies potential solutions, and maintains systems security. The objective is to use the SSAA 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. After accreditation, the SSAA becomes the baseline security configuration document. The specific uses of the SSAA during the first three C&A phases and also during the post accreditation phase are as follows: The SSAA during Certification & Accreditation The SSAA during Post-Accreditation • Guides actions to be taken • Documents decisions • Specifies information assurance requirements • Documents how the certification will go • Document the level of effort specific to the

Ministry environment • Identifies potential solutions • Describes operating environment and threat • Describes system security architecture • Establishes the C&A boundary of the system to

be accredited • Documents the formal agreement among AA, CA,

PM and user representative • Documents all requirements necessary for

accreditation • Minimizes documentation requirements by

consolidating by consolidating applicable information into the SSAA

• Documents test plans and procedures, certification results and residual risk

• Establishes the baseline security configuration document

• Documents and maintains the current system security behaviour

• Documents historical records, agreements and decisions

• Supports the system change management • Establishes system security policies

The SSAA should be tailored to meet the requirements of the Ministry and its directorates. The physical characteristics of the SSAA depend on the certification complexity and organizational requirements. The SSAA can be as simple as a single document or a complex document with multiple appendices and enclosures. The SSAA should be consistent with the Risk Assessment and other applicable C&A and security documents.

It is recommended that the information in the SSAA is consistent with that in the SSP. The goal is to produce an SSAA that is the basis of agreement throughout the system’s life cycle. The SSAA is intended to consolidate security-related documentation into one document. This consolidation eliminates the redundancy and potential confusion caused by multiple documents to describe the system, security policy, and/or system and security architecture. When feasible, the SSAA can be tailored to incorporate other documents as appendices or by reference. Once a system is certified, the Ministry and its directorates shall retain the official file copy for all accreditation packages. An outline of a sample SSAA is available under the title Certification and Accreditation Template, referenced ICT Security/MISP/SD/C&A Template.

5.2 System Security Plan The System Security Plan (SSP) provides an overview of the security requirements of the system and to describe existing or planned controls for meeting those requirements. The SSP also outlines the roles, responsibilities, and expected behaviour of all persons who access the system. This document and its appendices provide the information required in the NIST-recommended format for an SSP. The SSP should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system. The SSP should reflect input from Ministry and directorate system owners and managers, specifically those with staff members responsible for financial information and technical resources associated with the system. The NIST SP 800-18 R1, Guide for Developing Security Plans for Federal Information Systems provides guidelines for SSP contents. Additionally, the SSP should be included to address system-specific and directorate-specific needs. An outline of a sample SSP is available under the title System Security Plan Template,referenced ICT Security/MISP/SD/SSP Template.

5.3 Security Test and Evaluation Plan The Security Test and Evaluation assesses the technical implementation of the security design, ensures that the security controls have been implemented as described in the SSAA, and ensures that the features perform as planned. The Security Test and Evaluation plan should clearly define the process and procedures that will be employed during the test and evaluation phase. The plan should address each of the security requirements for the system, validate that they are functioning correctly, and clearly demonstrate the level of residual risk that exists. This plan is designed to validate the correct implementation of the security controls and is illustrated in Figure 9.

A Plan forSecurity Test and Evaluation

Assesses the technical

implementation of the security design

Ensures that security controls are

implemented as described in the

SSAA

Ensures that security features

perform as planned

Assesses the technical

implementation of the security design

Ensures that security controls are

implemented as described in the

SSAA

Ensures that security features

perform as planned

Figure 9 - Purposes of the Security Test & Evaluation Plan

The Security Test & Evaluation plan provides high-level guidance on security testing, identifies the security safeguards to be tested, provides detailed information on the test items, and supports system certification and accreditation. The Security Test & Evaluation plan is designed to evaluate and test the Ministry and directorate network, their critical systems, and supporting components for compliance with MISP requirements. The plan describes the test environment, identifies the tests to be performed, provides a schedule of test activities, and describes the test cases, preparations, and procedures used. The test procedures and test cases demonstrate how the security safeguards are tested.

5.4 Risk Assessment The objective of performing a Risk Assessment (RA) is to enable the Ministry and its directorates to accomplish their missions by: � Securing the IT systems that store, process, or transmit organizational information � Enabling management to make well-informed risk management decisions to justify the

expenditures that are part of an IT budget � Assisting management in authorizing (or accrediting) the IT systems on the basis of

supporting documentation resulting from the performance of risk management. Once the RA has been completed (threat sources and vulnerabilities identified, risks assessed, and recommended controls provided), the results should be documented in an official report or briefing. An RA report is a management report that helps senior management and the mission owners make decisions on policy, procedure, budget, system operational and management changes. Unlike an audit or investigative report, which looks for any suspicious activities, an RA report should be presented as an aid to assessing risk so that senior management will understand the risks and allocate resources to reduce and correct potential losses: Risk Assessment Report Audit or Investigative Report Helps senior management and mission owners make decisions

Looks for wrongdoing

Presented as a systematic and analytical approach to assessing risk

Presented in an accusatory manner

Threat and vulnerability pairs are presented as observations

Threat and vulnerability pairs are presented as findings

5.5 Disaster Recovery Plan A Disaster Recovery Plan (DRP) applies to major, usually catastrophic, events that deny access to the normal facility for an extended period. Very often, a DRP refers to an IT-focused plan designed to restore operability of a system, an application, or computer facility at an alternate site after an emergency. The DRP scope may overlap an IT contingency plan; however, the DRP is narrower in scope and does not address minor disruptions that do not require relocation. The DRP provides a key means of returning an organization to normal operations following a disaster. The DRP should include information that management and designated personnel can use to � In the short term, restore critical operations and, � In the long term, return the organization to its pre-disaster state

5.6 Configuration Management Plan The Configuration Management (CM) plan establishes a baseline of hardware, software, firmware, telecommunications, documentation, test, test equipment, and test documentation, as well as changes to it throughout the development and life cycle of the information system. The CM plan ensures control of the information system throughout its life cycle. It assures that additions, deletions, or changes made to the information system do not unintentionally or unknowingly diminish security. The security goal of the CM plan is to know what changes occur, how the changes affect system security, and to ensure that changes to the system are authorized and documented. The CM plan has a direct bearing on recovery capability. If the change is major, the security of the system must be reanalyzed. The CM plan must be implemented for the Ministry and directorate systems.

6 Estimated Level of Effort MISP recommends a tiered approach to establishing the required C&A level of effort. This approach ensures that the proper C&A level of effort are used to certify and accredit the Ministry and its directorate system requiring a C&A. Each system is categorized into one of five certification tiers (e.g., Tier 0 through Tier 4). The level of documentation (Tiers 1-4 require a completed SSAA and associated appendices that constitute the required SSP) and testing necessary for the C&A process depends on the certification tier category. The level of effort required for certification of a system is determined by analyzing the system’s mission, information, and availability as follows: � Criticality to the responsible organization’s mission � Sensitivity as related to confidentiality, integrity, and availability of system information. Sections 6.1 through 6.3 and 6.5 describe the system characteristics and methodology used to determine the Certification Analysis Level.

6.1 System Criticality System criticality is determined based on how integral the system is in carrying out the mission of the responsible organization. The system is categorized as one of three criteria: Mission Critical, Mission Important or Mission Supportive. Criteria definitions are as follows: Criticality Level Description ScoreMission Critical Automated information resources whose failure would preclude

the Ministry from accomplishing its core business operations 3

Mission Important Automated information resources whose failure would not preclude the Ministry from accomplishing core business processes in the short term (a few hours), but would cause failure in the mid to long term (a few hours to a few weeks)

2

Mission Supportive Automated information resources whose failure would not preclude the Ministry from accomplishing core business operations in the short to long term (a few hours to a few weeks), but would have an impact on the effectiveness or efficiency of day-to-day operations

1

A numerical score is assigned to each criticality criteria as indicated. This scoring will be used to calculate the certification score and level.

Exam

ple

A system has been found Mission Supportive, it gets Criticality Score 1

6.2 System Sensitivity

Sensitivity Criteria The criteria used to measure a system’s sensitivity include information Confidentiality, Integrity,and Availability.

Confidentiality Confidentiality is with regard to the assurance that information in an IT System is not disclosed to unauthorized persons, processes or devices.

Integrity Integrity is with regard to the assurance that information in an IT System is protected from unauthorised, unanticipated or unintentional modification or deletion.

Availability Availability is with regard to the assurance that information, application services and system resources are accessible to authorised users and/or system-related processes on a timely and reliable basis and are protected from denial of service.

Sensitivity Rates Each sensitivity criteria is rated on a scale of High, Moderate, or Low and is assigned a numerical score as follows: High = 3, Moderate = 2, and Low = 1. This scoring will be used to help calculate the certification score and level. The table on next page provides definitions and guidance in determining the appropriate rating.

Sensitivity Criteria Level of Risk

Low Moderate High CONFIDENTIALITY

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information

• The unauthorized disclosure of information could be expected to have adverse effect on directorate operations (including mission, functions, image, or reputation), assets or individuals

• A loss of confidentiality could be expected to cause a negative outcome or result in limited damage to operations or assets requiring minor corrective repairs

• The unauthorized disclosure of information could be expected to have serious adverse effect on directorate operations (including mission, functions, image, or reputation), assets, or individuals

• A loss of confidentiality could be expected to cause significant degradation in mission capability, place the directorate at a significant disadvantage or result in major damage to operations or assets, requiring minor corrective repairs.

• The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on directorate operations (including mission, functions, image, or reputation), assets, or individuals

• A loss of confidentiality could be expected to cause a loss of mission capability for a period that poses a threat to human life or results in a loss of major assets.

INTEGRITY

Guarding against improper information modification, destruction, and includes ensuring information non-repudiation and authenticity

• The unauthorized modification or destruction of information could be expected to have a limited adverse effect on directorate operations (including mission, functions, image, or reputation), assets, or individuals

• A loss of integrity could be expected to cause a negative outcome or result in limited damageto operations or assets, requiring minor corrective actions or repairs

• The unauthorized disclosure of information could be expected to have a serious adverse effect on directorate operations (including mission, functions, image, or reputation), assets, or individuals

• A loss of confidentiality could be expected to cause significant degradation in mission capability, place the directorate at a significant disadvantage, or result in major damage to assets, requiring extensive actions or repairs

• The unauthorized disclosure of information could be expected to have a serious or catastrophic adverse effect on directorate operations (including mission, function, image, or reputation), assets, or individuals

• A loss of confidentiality could be expected to cause a loss of mission capability for a period that poses a threat to human life, or results in a loss of major assets.

AVAILABILITY

Ensuring timely and reliable access to and use of information

• The disruption of access to information could be expected to have a limited adverse effect on directorate operations (including mission, function, image, or reputation), assets, or individuals

• A loss of availability could be expected to cause a negative outcome or result in limited damage to operations or assets, requiring minor corrective repairs

• The disruption of access to information could be expected to have a serious adverse effect on operation (including mission, function, image, or reputation), assets, or individuals

• A loss of availability could be expected to cause significant degradation in mission capability, place the directorate at a significant disadvantage, or result in major damage to assets requiring extensive corrective actions or repairs

• The disruption of access to information could be expected to have a severe or catastrophic adverse effect on directorate operation (including mission, function, image, or reputation), assets, or individuals

• A loss of availability could be expected to cause a loss of mission capability for a period that poses a threat to human life, or results in a loss of major assets

Sensitivity Score The Sensitivity Score – or Data Sensitivity Score – is determined by totalling the rates for Confidentiality, Integrity and Availability.

Exam

ple

The system has been determined to be of • High Confidentiality level, it gets Confidentiality rate 3 • High Integrity level, it gets Integrity rate 3 • Low Availability level, it gets Availability rate 1 The System’s Sensitivity Score is therefore 3 + 3 + 1 = 7

6.3 System Certification Score The System Certification Score is determined by totalling the System Criticality Score and the System Sensitivity Score previously determined.

Exam

ple

The above system’s Certification score is the sum of • Its Criticality score, i.e. 1 • Its Sensitivity score, i.e. 7 The System’s Data Certification score therefore 1 + 7 = 8

6.4 System Certification Tier The Certification Tier for a system is determined from the certification score. The Level of Effort required for certifying and accrediting the system is related to the system’s Tier Level. The following table summarizes the Level of Effort Activities related to the system’s Tier level; note that systems assigned a certification score of 4 are assigned Certification Tier 0 and therefore, do not require a formal C&A. Tier Levels Assessment Certification Score Risk Assessment (Level of Effort)0 No 4 Not Required 1 Basic 5-6 Based on

• Baseline Security Requirements (Checklist) 2 Minimal 7-8 Based on

• Baseline Security Requirements (Checklist) • Additional System Specific Security

Requirements 3 Detailed 9-10 Based on

• Baseline Security Requirements (Checklist) • Additional System Specific Security

Requirements • Conduct System Test & Evaluation • Vulnerability Scanning

4 Comprehensive 11-12 Based on • Baseline Security Requirements (Checklist) • Additional System Specific Security

Requirements • Conduct System Test & Evaluation • Vulnerability Scanning • Penetration Testing

Even though C&A activities are assigned to each tier, these can be changed based on the discussions and agreements with the ISO. For example, Tier 4 C&A activities include penetration testing. The system owner or ISO may not be comfortable with conducting a penetration test; therefore, one may not be required if formal agreement between the C&A stakeholders is accomplished.

6.5 Certification Tier Activities The level of effort required to complete the C&A is guided by the degree of assurance needed in the areas of mission criticality and system sensitivity (i.e., confidentiality, integrity, and availability). The C&A process has four levels of certification to provide the flexibility for appropriate assurance within schedule and budget limitations. Based on previous analysis, the certification level was determined: Tier 1 - basic review, Tier 2 - minimum analysis, Tier 3 - detailed analysis, or Tier 4 - comprehensive analysis, summarised as follows: SSAA / SSAA Appendices Tier 1 Tier 2 Tier 3 Tier 4 Main Sections All All All All Appendix A Acronym List Yes Yes Yes Yes Appendix B Definitions Yes Yes Yes Yes Appendix C References Yes Yes Yes Yes Appendix D Security Requirements Compliance Matrix

(SRCM) Yes Yes Yes Yes

Appendix E Security Testing and evaluation Plan and Procedures

As Indicated in E1 and E2 Below

E1 Formal Security Testing and Evaluation Plan and Procedures

NA As Needed

Yes Yes

E2 NIST 800-26 or Minimum Security Checklist

Yes Yes Yes Yes

Appendix F Certification Results (test results) Yes Yes Yes Yes Appendix G Risk Assessment and Plan of Actions &

Milestones Yes Yes Yes Yes

Appendix H Certification Authority Recommendation (certification statement)

Yes Yes Yes Yes

Appendix I System Security Policy NA As Needed

Yes Yes

Appendix J System Rules of Behaviour NA Yes Yes Yes Appendix K Security Operating Procedures NA As

Needed Yes Yes

Appendix L Contingency Planning and Disaster Recovery Plan

NA As Needed

Yes Yes

Appendix M Security Awareness and Training Plan NA As Needed

Yes Yes

Appendix N Personnel Control and Technical Security Controls Certification Statement

NA Yes Yes Yes

Appendix O Incident Response Plan NA Yes Yes Yes Appendix P Memoranda of Agreement –System

Interconnect Agreement Yes Yes Yes Yes

Appendix Q Applicable System and System Development Documentation

Yes Yes Yes Yes

Appendix R Accreditation Documentation and Accreditation Statement

Yes Yes Yes Yes