Initiation of the System Authorization Process

The information system authorization process comprises a number of steps, such as categorizing the security requirements, performing an initial risk estimate, determining appropriate security controls, and documenting the selected controls. Publications that provide useful guidance in performing the system authorization function include Federal Information Processing Standard (FIPS)-199, “Standard for Security Categorization of Federal Information and Information Systems”; National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, “Recommended Security Controls for Federal Information Systems”; NIST SP 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems”; and NIST SP 800-30, “Risk Management Guide for Information Technology Systems.”

The policies and guidance for information assurance in U.S. defense organizations are given in DoD Directive 8500.1, “Information Assurance (IA),” October 4, 2002. Additional support and implementation guidance is also provided by DoD Directive 8500.2, “Information Assurance (IA) Implementation,” February 6, 2003; DoD 5025.1-M, “DoD Directives System Procedures,” current edition; and DoD Directive 8000.1, “Management of DoD Information Resources and Information Technology,” February 27, 2002.

This chapter details the principal elements of system authorization, namely security categorization, initial risk estimation, selection of security controls, and documentation of security controls.

Security Categorization

In order to increase the security of Federal information systems, the Federal Information Security Management Act (FISMA), which is Title III of the E-Government Act of December 2002 (Public Law 107-347), was passed. FISMA was enacted to:

1. “Provide a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support Federal operations and assets”
2. “Recognize the highly networked nature of the current Federal computing environment and provide effective government-wide management and oversight of the related information security risks, including coordination of information security efforts throughout the civilian, national security, and law enforcement communities”
3. “Provide for development and maintenance of minimum controls required to protect Federal information and information systems”
4. “Provide a mechanism for improved oversight of Federal agency information security programs”

FISMA, the Paperwork Reduction Act (PRA) of 1980 as amended by the Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35), and the ClingerCohen Act (also known as the Information Technology Management Reform Act of 1996) (P.L. 104-106, Division E) promote a risk-based policy for cost effective security. The Clinger-Cohen Act supplements the information resources management policies contained in the PRA by establishing a comprehensive approach for executive agencies to improve the acquisition and management of their information resources. FISMA also specifies that national security classified information should be handled in accordance with the appropriate national security directives as provided by DoD and NSA.

FISMA charges the Director of the Office of Management and Budget (OMB) with the responsibility of overseeing the security polices and practices of all agencies of the executive branch of the Federal government, including “coordinating the development of standards and guidelines between NIST and the NSA and other agencies with responsibility for national security systems.” Agencies of the executive branch of the U.S. government are defined as:

• An Executive Department specified in 5 U.S.C. § 101
• Within the Executive Office of the President, only OMB and the Office of Administration
• A Military Department specified in 5 U.S.C. § 102
• An independent establishment as defined in 5 U.S.C. § 104(1)
• A wholly owned government corporation fully subject to the provisions of 31 U.S.C., Chapter 91

OMB Circular A-130, Appendix III, “Security of Federal Automated Information Resources,” specifies that Federal government agencies perform the following functions:

• Plan for security
• Ensure that appropriate officials are assigned security responsibility
• Review the security controls in their information systems
• Authorize system processing prior to operations and periodically thereafter

OMB Circular A-130, Appendix III, also requires that each agency perform security accreditation, which is considered “a form of quality control and challenges managers and technical staffs at all levels to implement the most effective security controls possible in an information system, given mission requirements, technical constraints, operational constraints, and cost/schedule constraints. By accrediting an information system, an agency official accepts responsibility for the security of the system and is fully accountable for any adverse impacts to the agency if a breach of security occurs.”

The actions that FISMA requires each government agency to perform in developing and implementing an agencywide information security program are specified in NIST Special Publication 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems,” Second Public Draft, June 2003. FISMA specifies that the program must include:

1. Periodic assessments of risk, including the magnitude of harm that can result from the unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems that support the operations and assets of the agency
2. Policies and procedures that are based on risk assessments, cost-effectively reduce information security risks to an acceptable level, and ensure that information security is addressed throughout the life cycle of each agency information system
3. Subordinate plans for providing adequate information security for networks, facilities, information systems, or groups of information systems, as appropriate
4. Security awareness training to inform personnel (including contractors and other users of information systems that support the operations and assets of the agency) of the information security risks associated with their activities and their responsibilities in complying with agency policies and procedures designed to reduce these risks
5. Periodic testing and evaluation of the effectiveness of information security policies, procedures, practices, and security controls to be performed with a frequency depending on risk, but no less than annually
6. A process for planning, implementing, evaluating, and documenting remedial action to address any deficiencies in the information security policies, procedures, and practices of the agency
7. Procedures for detecting, reporting, and responding to security incidents
8. Plans and procedures to ensure continuity of operations for information systems that support the operations and assets of the agency

Identification of Information Types

FISMA assigned to NIST the responsibility for developing the following information system–related standards and guidelines:

1. Standards to be used by all Federal agencies to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to a range of risk levels
2. Guidelines recommending the types of information and information systems to be included in each category
3. Minimum information security requirements (i.e., management, operational, and technical controls)

In order to satisfy item 1, NIST developed FIPS Publication 199, “Standards for Security Categorization of Federal Information and Information Systems.” FIPS 199 and the recently developed FIPS 200 standard, entitled “Minimum Security Requirements for Federal Information and Federal Information Systems,” are two mandatory standards specified in the FISMA legislation.

FIPS 199 is used to identify and categorize information and information systems and, as cited in the standard, should be used “To provide a common framework and understanding for expressing security that, for the Federal government promotes: (i) effective management and oversight of information security programs, including the coordination of information security efforts throughout the civilian, national security, emergency preparedness, homeland security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures, and practices.”

The FIPS 199 standard is applicable to:

• “All information within the Federal government other than that in-formation that has been determined pursuant to Executive Order 12958, as amended by Executive Order 13292, or any predecessor order, or by the Atomic Energy Act of 1954, as amended, to require protection against unauthorized disclosure and is marked to indicate its classified status
• All Federal information systems other than those information systems designated as national security systems as defined in 44 United States Code Section 3542(b)(2). National security systems are information systems operated by the U.S. Government, its contractors, or agents that contain classified information or that:
  • Involve intelligence activities
  • Involve cryptographic activities related to national security
  • Involve command and control of military forces
  • Involve equipment that is an integral part of a weapon or weapons systems
  • Are critical to the direct fulfillment of military or intelligence missions, not including routine administrative and business applications

• Agency officials shall use the security categorizations described in FIPS 199 whenever there is a Federal requirement to provide such a categorization of information or information systems.”

Potential Harmful Impact Levels

FIPS 199 addresses and defines categories for both information and information systems in the context of the potential harmful impact that may result from the occurrence of different attack scenarios. These categories are to be applied with the corresponding threat and vulnerability characteristics of the information or information system. Information is identified according to its type. FIPS 199 describes an information type as “a specific category of information defined by an organization or in some instances, by a specific law, executive order, directive, policy, or regulation.” Typical information types include:

• Financial
• Investigative
• Medical
• Personal
• Legal
• Sensitive

The security objective stated by FISMA is the standard preservation of confidentiality, integrity, and availability. These three terms are defined by FISMA as follows:

• Confidentiality - Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information [44 U.S.C. § 3542]. A loss of confidentiality is the unauthorized disclosure of information.
• Integrity - Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity [44 U.S.C. § 3542]. A loss of integrity is the unauthorized modification or destruction of information.
• Availability - Ensuring timely and reliable access to and use of information [44 U.S.C., § 3542]. A loss of availability is the disruption of access to or use of information or an information system.

Assignment of Impact Level Scores

FIPS Publication 199 defines three levels of potential impact to the compromise of confidentiality, integrity, and availability. These levels are summarized in Table 12-1, taken from the publication.

FIPS 199 establishes security categories for an information type and information systems. A security category is a function of the potential impact on information or information systems as a result of threat realized exploiting a system vulnerability. The security category, SC, of an information type is given by the formula:

SCinformation type = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where the acceptable values for potential impact are LOW, MODERATE, HIGH, or NOT APPLICABLE as defined in Table 12.1.

The formula for the SC of an information system is given as:

SC information system = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where the acceptable values for potential impact are LOW, MODERATE, or HIGH. (A value of NOT APPLICABLE cannot be applied to the impact level of an information system.)

Assignment of System Impact Level

Examples of SCs for different applications will serve to clarify the use of the formulas.

The research department of a large pharmaceutical company has developed a novel antiviral medicine. The company has invested millions of dollars in its development, and sales of the medication could yield a very large return on its investment and make the company a leader in the marketplace. The research director has determined that, for the information on the medication, there would be a high potential impact from a loss of confidentiality, a high potential impact from a loss of integrity, and a moderate potential impact from a loss of availability. Thus, the security category, SC, of this information type would be:

SCresearch information = {(confidentiality, HIGH), (integrity, HIGH), (availability, MODERATE)}

Now, assume that the benefits department of the same pharmaceutical company determines that, for the employees’ benefits information, there would be a moderate potential impact from a loss of confidentiality, a high potential impact from a loss of integrity, and a moderate potential impact from a loss of availability. Thus, the security category, SC, of this information type would be:

SCbenefits information = {(confidentiality, MODERATE), (integrity, HIGH), (availability, MODERATE)}

In order to determine the SC for an information system, the potential impact values assigned to the security objectives of confidential, integrity, and availability must be the maximum (worst-case) values assigned among the security categories that have been assigned to the different types of information residing on the system.

In the pharmaceutical company example, if the information system comprises only the research and benefits databases, the impact values in the information system SC formula would be the highest values assigned to the security objectives in the research information and benefits information SC formulas.

Thus, the security category of the pharmaceutical information system would comprise of the highest values of the two information categories resident on the system. Therefore,

SCpharmaceutical information system = {(confidentiality, HIGH), (integrity, HIGH), (availability, MODERATE)}

Initial Risk Estimation

NIST SP 800-30, “Risk Management Guide for Information Technology Systems,” addresses risk assessment for Federal agencies. SP 800-30 defines risk as “a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.” A threat-source is “either (1) intent and method targeted at the intentional exploitation of a vulnerability or (2) a situation and method that may accidentally trigger a vulnerability.”

Impact refers to “the magnitude of harm that could be caused by a threat’s exercise of a vulnerability.” A threat is “the potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.”

Threats to an information system have to be categorized and analyzed along with the system vulnerabilities in order to determine the potential impact on the system. SP 800-30 characterizes risk assessment by means of the following nine components:

1. System Characterization
2. Threat Identification
3. Vulnerability Identification
4. Control Analysis
5. Likelihood Determination
6. Impact Analysis
7. Risk Determination
8. Control Recommendations
9. Results Documentation

In particular, threat identification and the threat likelihood of occurrence are critical to the certification and accreditation process.

Threat Source Identification

As part of certification and accreditation of an IT system, threat-sources must be identified that have the potential of exploiting vulnerabilities in that system. Threat-sources can be environmental, natural, or the result of human actions.

Environmental Threat-Sources

The following are examples of environmental threat sources:

• Chemicals
• Gases
• Pollution
• Humidity
• Water
• Extended power failure

Natural Threat-Sources

Natural threat-sources include:

• Hurricanes
• Earthquakes
• Tornadoes
• Floods
• Snowstorms
• Ice
• Thunderstorms
• Avalanches
• Organisms
• Forest fires

Human Threat-Sources

Examples of human threats are:

• Sabotage
• War
• Network attacks
• Downloading malicious code
• Vandalism
• Unauthorized access to sensitive data
• Strikes

Table 12-2, taken from NIST SP 800-30, summarizes the most common threat-sources along with motivations and methods for the corresponding attacks.

Threat Likelihood of Occurrence

The likelihood of a threat occurring is a function of the threat-source, potential IT system vulnerabilities, and any security controls that have been put into place.

Methods for analyzing vulnerabilities are addressed in NIST SP 800-30 and NIST SP 800-42, “Guideline on Network Security Testing.”

Analyzing for Vulnerabilities

In order to determine the existing and potential vulnerabilities in an information system, a combination of approaches should be employed, including using sources of compiled vulnerability information such as http://icat.nist.gov/icat.cfm, www.securityfocus.com/, and http://cve.mitre.org/.

Vulnerabilities can be determined during the different stages of the IT system life cycle, as illustrated in Table 12-3.

Additional sources of vulnerability information include:

• Internet listings of service packs and patches
• NIST vulnerability database (http://icat.nist.gov)
• Carnegie Mellon Software Engineering Institute, Computer Emergency Response Team, CERT/CC (http://www.cert.org)
• Vendor Web pages
• System test and evaluation (STE) reports
• The Federal Computer Incident Response Center, FedCIRC, (www.fedcirc.gov)

Another NIST document, SP 800-26, “Security Self-Assessment Guide for Information Technology Systems,” provides a questionnaire and checklist through which systems can be evaluated for compliance against specific control objectives. This approach is useful in identifying potential vulnerabilities.

A related technique is to develop a security requirements checklist, in which the system design and implementation are evaluated to determine how effectively they meet the system security requirements in management, technical, and operational areas.

Testing is also extremely useful in determining a system’s vulnerabilities and should be conducted at appropriate portions of the system development life cycle (SDLC). A typical SDLC consists of the following stages:

1. Initiation - The system, mission, purpose, and configuration are described.
2. Development and Acquisition - The system is developed and built according to requirements.
3. Implementation and Installation - The system is installed and integrated.
4. Operational and Maintenance - The system is operated and maintained according to its mission.
5. Disposal - The system is deactivated and removed from active use.

Security testing is usually conducted in the Implementation and Operational stages of the SDLC. Security testing approaches include penetration testing, security test and evaluation (ST&E), and using automated vulnerability-scanning software.

Penetration testing (discussed in Chapter 2) examines an IT system’s information security measures and is used to determine the vulnerabilities of the system. Penetration testing, also known as ethical hacking, attempts to evaluate the resistance of an information system to a determined hacker. Some of the areas scrutinized by a penetration test are:

• Access controls
• Application code
• Communications security
• Containment measures
• Denial of service susceptibility
• Fax systems
• Firewalls
• Information security
• Infrared systems
• Intrusion detection systems
• Modems
• Network architecture and security
• Password strength
• PBXs
• Physical security
• Port scanning
• Privacy protections
• Routers
• Susceptibility to social engineering
• Robustness of trusted systems
• Voicemail security
• Wireless security

Penetration tests can attempt to exploit a vulnerability to determine it existence. Some of the areas that can be exploited include:

• Kernel flaws - Exploitation of kernel code flaws in the operating system
• Buffer overflows - Exploitation of a software failure to properly check for the length of input data, allowing input data to overflow its memory buffer. This overflow can result in arbitrary code being run and causing malicious behavior on the system.
• Race conditions - A situation in which an attacker can gain access to a system as a privileged user when a program in the system has validly entered a privileged mode
• File and directory permissions - An attacker exploiting inadequate and weak permissions restrictions to gain unauthorized access to files or directories
• Trojan horses - Programs that can exploit and information system by executing along with a valid program to which they are attached
• Social engineering - An attacker using social skills and persuasion to acquire information that can be used to successfully conduct an attack against a system

There are a number of categories of penetration tests. These categories are a function of the amount of information available to the tester and are summarized in Table 12-4.

Security test and evaluation (ST&E) is another component of risk assessment that is useful in discovering system vulnerabilities. According to NIST SP 800-42, “Guideline on Network Security Testing,” ST&E is used to:

• Uncover design, implementation and operational flaws that could allow the violation of security policy
• Determine the adequacy of security mechanisms, assurances, and other properties to enforce the security policy
• Assess the degree of consistency between the system documentation and its implementation

ST&E involves the examination and analysis of the safeguards required to protect an IT system in an operational environment. Proper execution of ST&E requires developing a test plan, executing the plan, and generating a report. The report is a key component of the final security certification material and is the certification agent’s statement regarding the security posture of the information system. The report includes:

• Results showing the effectiveness of the security controls
• Confirmed vulnerabilities
• Corrective actions that can reduce the vulnerabilities

A third type of test uses vulnerability-scanning tools, which scan networks or hosts for services that exhibit known potential vulnerabilities. These tools compare scanned services, operating systems, and applications against vulnerability databases to identify potential system vulnerabilities.

System Accreditation Boundary

NIST SP 800-37 defines the accreditation boundary as:

All components of an information system to be accredited by an authorizing official and excludes separately accredited systems, to which the information system is connected. Synonymous with the term security perimeter defined in the Committee on National Security Systems (CNSS) Instruction 4009 and Department of Central Intelligence Directive (DCID) 6/3.

CNSS 4009 defines an accreditation boundary/security perimeter as:

All components/devices of an information system (IS) to be accredited. Separately accredited components generally are not included within the perimeter.

In order to perform accreditation, the components to be included in the accreditation process have to be identified. This accreditation boundary has to be determined in order to develop an information security plan and conduct a risk assessment. There are trade-offs in determining the elements to include in the accreditation effort. If too many components are included, the certification and accreditation process will increase in complexity, but the number of accreditations that have to be performed and, generally, the corresponding costs will be reduced. Conversely, if a small number of items are included in the certification and accreditation tasks, the process will be simpler, but more accreditations will have to be performed and the costs will usually increase. These trade-offs are shown in Figure 12-1.

Figure 12-1: Accreditation trade-offs.

If an information system is unduly large and comprises many varied elements that may be physically and logically distributed, it should be partitioned into manageable subsystems that can be the objects of the accreditation process.

An important criterion that is useful in establishing an accreditation boundary is the organizational structure encompassing an information system. In particular, the information system and its associated resources should be under the same direct management control. Direct management control of an information system can be characterized as follows:

• Authority for budgets
• Management of a large information system that is made up of information subsystems and applications, which may involve subordinate managers
• Responsibility for development and deployment of new systems
• Responsibility for maintenance
• Responsibility for operations

The security categories defined in FIPS 199 also provide a basis for determining accreditation boundaries. The boundaries can be assigned according to the impact on the information system resulting from a compromise of confidentiality, integrity, or availability.

Additional considerations for assigning the accreditation boundary of an information system are:

• Components are in a common operating environment.
• Components have identical information security requirements.
• Information system resources have common functions.
• Information system resources have the same mission.

Legal and Regulatory Requirements

OMB Circular A-130, revised, lists legal and regulatory requirements of Federal agencies in managing their information resources. Section 8, “Policy,” of Circular A-130 states that agencies must “consider the effects of their actions on the privacy rights of individuals, and ensure that appropriate legal and technical safeguards are implemented” throughout the information management planning life cycle. Section 9 requires that agencies restrict the amount of individually identifiable information that they use or share to that which is legally necessary and authorized for an agency to carry out its mission and to ensure the confidentiality of that information. It also charges agencies with implementing the regulations, standards, and guidelines specified by OMB.

In general, risk management has to consider legal liability issues resulting from the following events:

• Failure to exercise due care in the operation of an information system
• Omissions and errors
• System interruptions caused by disasters
• Unauthorized disclosure, modification, or destruction of data

Risk management is defined by NIST SP 800-30 as:

The total process of identifying, controlling, and mitigating information system related risks. It includes risk assessment; cost-benefit analysis; and the selection, implementation, test, and security evaluation of safeguards. This overall system security review considers both effectiveness and efficiency, including impact on the mission and constraints due to policy, regulations, and laws.

FISMA also promotes a government-wide risk-based approach to information security and accountability through a comprehensive evaluation of agency information security systems. FISMA does not require a single simultaneous evaluation of all information systems in an agency but requires thorough annual tests of selected systems.

The information systems should be reviewed at different frequencies as a function of information criticality, information sensitivity, and risk levels. However, the combination of the reviews conducted by the agency should result in a comprehensive evaluation of an agency’s security posture.

Selection of Security Controls

NIST Special Publication 800-53 provides guidance in the selection and configuration of security controls for Federal information systems. It replaces controls discussed in NIST SP 800-18 and NIST SP 800-26. SP 800-53 defines minimum security controls in accordance with low, moderate, and high impact categories of FIPS 199. These controls should be used as part of the risk assessment process and their implementation should address the stated system security objectives. FIPS 200 provides links to SP 800-53, which addresses security controls that can meet the minimum security requirements of FIPS 200. The minimum security requirements of FIPS 200 cover the following seventeen areas:

• Access control
• Awareness and training
• Audit and accountability
• Certification, accreditation, and security assessments
• Configuration management
• Contingency planning
• Identification and authentication
• Incident response
• Maintenance
• Media protection
• Physical and environmental protection
• Planning
• Personnel security
• Risk assessment
• Systems and services acquisition
• System and communication protection
• System and information integrity

The security controls in SP 800-53 are organized into three different classes - Management, Operational, and Technical - with families falling under these classes. The controls are summarized in a security control catalog, which is Appendix F of SP 800-53. This Appendix is reproduced in this text as Appendix F, also. Table 12-5, taken from SP 800-53, lists the classes and families of controls, including a two character identifier for each family.

Thus, as shown in the table, the risk assessment family of controls is part of the Management class and is identified as RA. Further, a number is attached to a family to identify a particular control in the family. For example, RA-2 would designate Security Categorization, the second control in the risk assessment family. Appendix F of SP 800-53 provides the details of RA-2 as follows:

RA-2 SECURITY CATEGORIZATION

Control: The organization categorizes the information system and the information processed, stored, or transmitted by the system in accordance with FIPS 199 and documents the results (including supporting rationale) in the system security plan. Designated senior-level officials within the organization review and approve the security categorizations. Supplemental Guidance: NIST Special Publication 800-60 provides guidance on determining the security categories of the information types resident on the information system. The organization conducts security categorizations as an organization-wide activity with the involvement of the chief information officer, senior agency information security officer, information system owners, and information owners.

Supplemental guidance: None

Control enhancements: None.

LOW RA-2 MOD RA-2 HIGH RA-2

As can be seen in the RA-2 example, there are three parts to the control structure:

• Control section
• Supplemental guidance section
• Control enhancements section

At the end of the particular control section, the minimum security controls are specified for the low, moderate, and high impact baselines.

The Control Section

The control section describes information security actions that have to be taken by the organization to protect the information system. Some aspects of these activities are left to the organization through the application of assignment and selection operations within the main body of the control. Examples of such operations would be specifying the frequency of performing a certain test, the number of times per day backups are performed, and so on. Also, selection statements may constrain choices by providing a list of acceptable values from which to choose.

The Supplemental Guidance Section

This section provides additional information and guidance that organizations can use in their application of security controls to information systems. Sources of supplemental guidance include NIST Special Publications, legislation, executive orders, OMB circulars, directives, standards, and regulations.

The Control Enhancements Section

Control enhancements listed in this section are aimed at either adding to the functionality or increasing the strength of a basic control. These additional capabilities can provide increased protection for information systems over the protection available from the basic control. Control enhancements are identified by sequential numbering that can be added to the basic control. The Control section, Supplemental Guidance section, and Control Enhancements section are illustrated in another example from Appendix F of NIST SP 800-53, the 17th control of the Access Control Family (AC-17).

AC-17 REMOTE ACCESS

Control: The organization documents, monitors, and controls all methods of remote access (e.g., dial-up, Internet) to the information system including remote access for privileged functions. Appropriate organization officials authorize each remote access method for the information system and authorize only the necessary users for each access method.

Supplemental Guidance: Remote access controls are applicable to information systems other than public web servers or systems specifically designed for public access. The organization restricts access achieved through dial-up connections (e.g., limiting dial-up access based upon source of request) or protects against unauthorized connections or subversion of authorized connections (e.g., using virtual private network technology). The organization permits remote access for privileged functions only for compelling operational needs. NIST Special Publication 800-63 provides guidance on remote electronic authentication.

Control Enhancements:

1. The organization employs automated mechanisms to facilitate the monitoring and control of remote access methods.
2. The organization uses encryption to protect the confidentiality of remote access sessions.
3. The organization controls all remote accesses through a managed access control point.

LOW AC-17 MOD AC-17 (1) (2) (3) HIGH AC-17 (1) (2) (3)

The previous example shows the security control baselines and enhancements to the baselines for low-impact, moderate-impact, and high-impact information systems, based on FIPS 199. For a low-impact information system, security control AC-17 is listed. For moderate- and high-impact information systems, control AC-17 augmented with enhancements (1), (2), and (3) is specified. The table in Appendix G of this text, taken from NIST SP 800-53, summarizes the security controls and enhancements to the baselines. A control that is not used is indicated in the table with the term “not selected.”

Assurance

Assurance is defined in SP 800-53 as “the grounds for confidence that the security controls implemented within an information system are effective in their application.” The minimum assurance requirements for low, moderate, and high baseline controls are given in Table 12-6.

Common and System Specific Security Controls

In many instances, a set of security controls is applicable to more than one of the information systems in an organization. These controls are called common security controls and are applicable to the certification and accreditation process. For example, physical security controls, security awareness training controls, and contingency planning controls are good candidates for common security controls, because they are applicable across the enterprise. Controls that are not defined as common security controls are considered system-specific controls. A third category of control is the hybrid control, in which one portion of the control is system-specific and the other is common. For example, the policy segment of a control can be common to the enterprise while the implementation procedures are system-specific.

Considerable time and resource savings can be achieved during the certification and accreditation process by assessing the common controls once and applying the results across the corresponding information systems.

Security Controls and the Management of Organizational Risk

Organizational risk is the risk associated with the operation of an information system. The selection and application of appropriate security controls are key elements of managing organizational risk. The risk management process is outlined in Figure 12-2.

Figure 12-2: Organizational risk management process.

Managing organizational risk is an important component of a successful information security activity for both new and existing systems. Additional functions that support managing organizational risk detailed in SP 800-53 include:

• Categorizing the information system and its associated information according to a FIPS 199 impact analysis
• Choosing a baseline set of information system security controls based on the FIPS 199 security categorization
• Customizing the initial set of baseline security controls based on risk assessments, threat analysis, special security needs, and availability of controls
• Including the selected security controls in the system security plan
• Implementing the specified security controls in the information system
• Evaluating the assurance of the selected security controls with appropriate methodologies
• Assessing the risk associated with the operation of the information system
• Authorizing information system processing (or for legacy systems, authorize continued system processing) if the level of risk to the organization’s operations or assets is acceptable
• Continuously monitoring the information system security controls, including any system configuration changes and system security posture

Documenting Security Controls in the System Security Plan

It is important that the management of an agency has the latest and accurate documentation on the security status of its information systems. This information is necessary to support the accreditation decision. Recall that the security certification and accreditation process comprises the following phases:

• Initiation phase
• Security certification phase
• Security accreditation phase
• Continuous monitoring phase

These phases incorporate security documentation as follows:

• Initiation phase
  • System security plan analysis
  • System security plan updates
  • System security plan acceptance

• Security certification phase
  • Security certification documentation

• Security accreditation phase
  • Security accreditation documentation

• Continuous monitoring phase
  • Status reporting and documentation

The system security plan is developed by the owner of the information system and approved by the authorizing official. The plan is part of the security accreditation package and outlines the information system security requirements and associated planned and existing controls. It can also reference incident response plans, contingency plans, configuration management plans, risk assessments, and security configuration checklists. Figure 12-3, taken from NIST SP 800-37, summarizes the security accreditation package.

Figure 12-3: The Security Accreditation Package.

In addition to ensuring that the security controls for an information system are documented in the system security plan, agency management must have business continuity or contingency plans in place. NIST SP 800-53 specifies a family of contingency planning controls denoted by CP in the Operational class. Table 12-7, with data from NIST SP 800-53, summarizes the CP control baselines according to the categories of FIPS 199.

The Control sections of CP-1 and CP-2 summarize the basic management obligations for contingency planning as follows:

CP-1 CONTINGENCY PLANNING POLICY AND PROCEDURES

Control: The organization develops, disseminates, and periodically reviews/updates: (i) a formal, documented, contingency planning policy that addresses purpose, scope, roles, responsibilities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls.

CP-2 CONTINGENCY PLAN

Control: The organization develops and implements a contingency plan for the information system addressing contingency roles, responsibilities, assigned individuals with contact information, and activities associated with restoring the system after a disruption or failure. Designated officials within the organization review and approve the contingency plan and distribute copies of the plan to key contingency personnel.

Assessment Questions

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

Answers