3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

Certification and Accreditation Guide > 3 Certification and Accreditation Overview

Show

Certification and Accreditation Overview

3.1

The Certification and Accreditation Process

Certification is the comprehensive evaluation of a systems 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 systems 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)

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 systems entire life cycle. The level of risk the AA is willing to accept of a system should be commensurate with the systems value to the Ministry or its directorates 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.

1 of 7

6/7/2012 10:17 PM

3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

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 owners 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 owners 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.

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 systems 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 systems 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 systems 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

2 of 7

6/7/2012 10:17 PM

3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

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 systems 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 User Representative Responsibilities 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 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 Coordinates all steps of the system life cycle Coordinates with key players throughout the C&A process Reviews information Provides input 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 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

Certification Authority

Program Manager

ISO Representative

Approving Authority

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-

3 of 7

6/7/2012 10:17 PM

3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

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 Sections[2] 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.

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:

4 of 7

6/7/2012 10:17 PM

3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

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 systems 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
5 of 7

Exceptions to Security Requirements

6/7/2012 10:17 PM

3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

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 systems 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.

6 of 7

6/7/2012 10:17 PM

3 Certification and Accreditation Overview

http://www.moct.gov.sy/ICTSandards/en/3/3_Certification_and_Accredita...

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.

7 of 7

6/7/2012 10:17 PM