Doc:NIST SP 800-37r1 Appendix F

From FISMApedia
Jump to: navigation, search

APPENDIX F

SECURITY AUTHORIZATION

AUTHORIZATION DECISIONS AND SUPPORTING EVIDENCE

This appendix provides information on the security authorization process to include: (i) the content of the authorization package; (ii) types of authorization decisions; (iii) the content of the authorization decision document; and (iv) maintenance of authorizations through continuous monitoring processes and conditions for reauthorization.


F.1 AUTHORIZATION PACKAGE

The security authorization package documents the results of the security control assessment and provides the authorizing official with essential information needed to make a risk-based decision on whether to authorize operation of an information system or a designated set of common controls. Unless specifically designated otherwise by the chief information officer or authorizing official, the information system owner or common control provider is responsible for the assembly, compilation, and submission of the authorization package. The information system owner or common control provider receives inputs from the information system security officer, security control assessor, senior information security officer, and risk executive (function) during the preparation of the authorization package. The authorization package[1] contains the following documents:

The security plan, prepared by the information system owner or common control provider, provides an overview of the security requirements and describes the security controls in place or planned for meeting those requirements. The plan provides sufficient information to understand the intended or actual implementation of each security control employed within or inherited by the information system.[2] The security plan also contains as supporting appendices or as references to appropriate sources, other risk and security-related documents such as a risk assessment, privacy impact assessment, system interconnection agreements, contingency plan, security configurations, configuration management plan, incident response plan, and continuous monitoring strategy. In accordance with the near real-time risk management objectives of the security authorization process, the security plan is updated whenever events dictate changes to the security controls employed within or inherited by the information system. Updates to the security plan may be triggered by a variety of events, including for example: (i) a vulnerability scan of the information system or vulnerability assessment of the environment of operation; (ii) new threat information; (iii) weaknesses or deficiencies discovered in currently deployed security controls after an information system breach; (iv) a redefinition of mission priorities or business objectives invalidating the results of the previous security categorization process; and (v) a change in the information system (e.g., adding new hardware, software, or firmware; establishing new connections) or its environment of operation (e.g., moving to a new facility).

The security assessment report, prepared by the security control assessor, provides the results of assessing the implementation of the security controls identified in the security plan to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the specified security requirements. The security assessment report also contains a list of recommended corrective actions for any weaknesses or deficiencies identified in the security controls.[3] Supporting the near real-time risk management objectives of the security authorization process, the security assessment report is updated on an ongoing basis whenever changes are made to the security controls employed within or inherited by the information system.[4] Updates to the security assessment report help to ensure that the information system owner, common control provider, and authorizing officials maintain the appropriate awareness with regard to security control effectiveness. The overall effectiveness of the security controls directly affects the ultimate security state of the information system and decisions regarding explicit acceptance of risk.

The plan of action and milestones, prepared by the information system owner or common control provider, describes the specific measures planned: (i) to correct weaknesses or deficiencies noted in the security controls during the assessment; and (ii) to address known vulnerabilities in the information system.[5] The content and structure of plans of action and milestones are informed by the organizational risk management strategy developed as part of the risk executive (function) and is consistent with the plans of action and milestones process established by the organization and any specific requirements defined in federal policies, directives, memoranda, or regulations. The most effective plans of action and milestones contain a robust set of actual weaknesses or deficiencies identified in the security controls employed within or inherited by the information system. Assuming that most information systems and the environments in which those systems are deployed, have more vulnerabilities than available resources can realistically address, organizations define a strategy for developing and implementing plans of action and milestones that facilitates a prioritized approach to risk mitigation and that is consistent across the organization. This strategy helps to ensure that plans of action and milestones are based on:

  • The security categorization of the information system;
  • The specific weaknesses or deficiencies in the security controls;
  • The importance of the identified security control weaknesses or deficiencies (i.e., the direct or indirect effect the weaknesses or deficiencies may have on the overall security state of the information system and hence on the risk exposure[6] of the organization);
  • The organization's proposed risk mitigation approach to address the identified weaknesses or deficiencies in the security controls (e.g., prioritization of risk mitigation actions, allocation of risk mitigation resources); and
  • The organization's rationale for accepting certain weaknesses or deficiencies in the security controls.[7]

Organizational strategies for plans of action and milestones are guided by the security categories of the respective information systems affected by the risk mitigation activities. Organizations may decide, for example, to allocate the vast majority of risk mitigation resources initially to the highest-impact information systems because a failure to correct the weaknesses or deficiencies in those systems could potentially have the most significant adverse effects on the organization's missions or business operations. Organizations also prioritize weaknesses or deficiencies using information from organizational assessments of risk and the risk management strategy developed as part of the risk executive (function). Therefore, a high-impact system would have a prioritized list of weaknesses or deficiencies for that system, as would moderate-impact and low-impact systems. In general, the plan of action and milestones strategy always addresses the highest-priority weaknesses or deficiencies within those prioritized systems.

After completion of the security plan, security assessment report, and plan of action and milestones, the information system owner or common control provider submits the final security authorization package to the authorizing official or designated representative. Figure F-1 illustrates the key sections of the authorization package.


File:80037r1 FigureF-1.png
FIGURE F-1: SECURITY AUTHORIZATION PACKAGE


F.2 AUTHORIZATION DECISIONS

Authorization decisions are based on the content of the authorization package including inputs from the organization's risk executive (function) and any additional supporting documentation required by the authorizing official. The security authorization package provides comprehensive information on the security state of the information system. Risk executive (function) inputs, including the previously established overarching risk guidance derived from the risk management strategy, provide additional information to the authorizing official that may be relevant and affect the final authorization decision (e.g., organizational risk tolerance, organization's overall risk mitigation strategy, core mission and business requirements, dependencies among information systems, ongoing risk monitoring requirements, and other types of risks not directly associated with the information system or its environment of operation). Risk executive (function) inputs are documented and become part of the authorization decision. Organizations determine how the risk management strategy and risk-related guidance from the risk executive (function) influences/impacts the authorization decisions of authorizing officials. Security authorization decisions are conveyed to information system owners and common control providers and are made available to selected officials within the organization (e.g., information system owners inheriting common controls, authorizing officials for interconnected systems, chief information officers, senior information security officers, information owners/stewards). There are two types of authorization decisions that can be rendered by authorizing officials:


Authorization to Operate

If the authorizing official, after reviewing the authorization package and any additional inputs provided by the risk executive (function), deems that the risk to organizational operations and assets, individuals, other organizations, and the Nation is acceptable, an authorization to operate is issued for the information system or for the common controls inherited by organizational information systems. The information system is authorized to operate for a specified time period in accordance with the terms and conditions established by the authorizing official.[9] For common control providers external to an information system, the authorization decision means that the common controls under their control are approved for inheritance by organizational information systems. An authorization termination date is also established by the authorizing official as a condition of authorization. The authorization termination date can be adjusted by the authorizing official to reflect an increased level of concern regarding the security state of the information system including the security control employed within or inherited by the system. Authorization termination dates do not exceed the maximum allowable time periods for authorization established by federal or organizational policy.

The authorizing official takes specific actions to reduce or eliminate vulnerabilities identified during the execution of the Risk Management Framework unless the vulnerabilities have been explicitly accepted as part of the authorization decision. In addition, the information system owner or common control provider establishes a disciplined, structured, and repeatable process to monitor the ongoing effectiveness of the deployed security controls and the progress of any actions taken to correct or eliminate weaknesses or deficiencies. The plan of action and milestones submitted by the information system owner is used by the authorizing official to monitor the progress in correcting deficiencies and weaknesses noted during the security control assessment.


Denial of Authorization to Operate

If the authorizing official, after reviewing the authorization package and any additional inputs provided by the risk executive (function), deems that the risk to organizational operations and assets, individuals, other organizations, and the Nation is unacceptable and immediate steps cannot be taken to reduce the risk to an acceptable level, a denial of authorization to operate is issued for the information system or for the common controls inherited by organizational information systems. The information system is not authorized to operate and is not placed into operation. If the system is currently in operation, all activity is halted. For common control providers external to an information system, the authorization decision means that the common controls under their control are not approved for inheritance by organizational information systems. Failure to receive an authorization to operate indicates that there are major weaknesses or deficiencies in the security controls employed within or inherited by the information system. The authorizing official or designated representative works with the information system owner or common control provider to revise the plan of action and milestones to ensure that appropriate measures are taken to correct the identified weaknesses or deficiencies.

A special case of a denial of authorization to operate is an authorization rescission. Authorizing officials can rescind a previous authorization decision at any time in situations where there is a specific violation of: (i) federal/organizational security policies, directives, regulations, standards, guidance, or practices; or (ii) the terms and conditions of the original authorization. For example, failure to maintain an effective continuous monitoring program may be grounds for rescinding an authorization decision. Authorizing officials consult with the risk executive (function) and the senior information security officer before rescinding security authorizations.


F.3 AUTHORIZATION DECISION DOCUMENT

The authorization decision document transmits the final security authorization decision from the authorizing official to the information system owner or common control provider and other key organizational officials, as appropriate. The authorization decision document contains the following information:

The security authorization decision indicates whether the information system is: (i) authorized to operate; or (ii) not authorized to operate. For common controls, the authorization decision means that the controls are approved for inheritance by organizational information systems. The terms and conditions for the authorization provide a description of any limitations or restrictions placed on the operation of the information system or the implementation of common controls that must be followed by the system owner or common control provider. The authorization termination date, established by the authorizing official, indicates when the security authorization expires and reauthorization is required. An authorizing official designated representative prepares the authorization decision document for the authorizing official with authorization recommendations, as appropriate. The authorization decision document is attached to the original authorization package and transmitted to the information system owner or common control provider.[10]

Upon receipt of the authorization decision document and authorization package, the information system owner or common control provider acknowledges and implements the terms and conditions of the authorization and notifies the authorizing official. The information system owner or common control provider retains the original authorization decision document and authorization package.[11] The organization ensures that authorization documents for information systems and for common controls are available to appropriate organizational officials (e.g., information system owners inheriting common controls, the risk executive [function], chief information officers, senior information security officers, information system security officers). The contents of the security authorization documentation, especially information regarding information system vulnerabilities, are: (i) marked and appropriately protected in accordance with federal/organizational policy; and (ii) retained in accordance with the organization's record retention policy. The authorizing official verifies on an ongoing basis, that the terms and conditions established as part of the authorization are being followed by the information system owner or common control provider.


F.4 ONGOING AUTHORIZATION

A robust and comprehensive continuous monitoring[12] strategy integrated into the organization's system development life cycle process, promotes risk management on an ongoing basis and can significantly reduce the resources required for reauthorization, if required. Using automation and state-of-the-practice tools, techniques, and procedures, risk management can become near real-time with ongoing monitoring of security controls and changes to the information system and its environment of operation. When monitoring is conducted in accordance with the needs of the authorizing official, that monitoring results in the production of key information needed to determine: (i) the current security state of the information system (including the effectiveness of the security controls employed within and inherited by the system); (ii) the resulting risks to organizational operations, organizational assets, individuals, other organizations, and the Nation; and (iii) whether to authorize continued operation of the system or continued use of common controls inherited by organizational information systems.

Continuous monitoring also helps to amortize the resource expenditures for reauthorization activities over the authorization period. The ultimate objective is to achieve a state of ongoing authorization where the authorizing official maintains sufficient knowledge of the current security state of the information system (including the effectiveness of the security controls employed within and inherited by the system) to determine whether continued operation is acceptable based on ongoing risk determinations, and if not, which step or steps in the Risk Management Framework needs to be re-executed in order to adequately mitigate the additional risk. Formal reauthorization actions are avoided in situations where the continuous monitoring process provides authorizing officials the necessary information to manage the potential risk arising from changes to the information system or its environment of operation. Organizations maximize the use of status reports and security state information produced during the continuous monitoring process to minimize the level of effort required if a formal reauthorization action is required. Formal reauthorization actions occur at the discretion of the authorizing official in accordance with federal or organizational policy. If a formal reauthorization action is required, organizations maximize the use of security and risk-related information produced during the continuous monitoring and ongoing authorization processes currently in effect.

Reauthorization actions, if initiated, can be either time-driven or event-driven. Time-driven reauthorizations occur when the authorization termination date is reached. Authorization termination dates are influenced by federal and/or organizational policies and by the requirements of authorizing officials which may establish maximum authorization periods. For example, if the maximum authorization period for an information system is three years, then an organization establishes a continuous monitoring strategy for assessing a subset of the security controls employed within and inherited by the system during the authorization period. This strategy allows all security controls designated in the respective security plans to be assessed at least one time by the end of the three-year period. This also includes any common controls deployed external to organizational information systems. If the security control assessments are conducted by qualified assessors with the required degree of independence based on federal/organizational policies, appropriate security standards and guidelines, and the needs of the authorizing official, the assessment results can be cumulatively applied to the reauthorization, thus supporting the concept of ongoing authorization.[13] The reauthorization action can be as simple as updating the security status information in the authorization package (i.e., the security plan, security assessment report, and plan of action and milestones). The authorizing official subsequently signs an updated authorization decision document based on the current determination and acceptance of risk to organizational operations and assets, individuals, other organizations, and the Nation.[14]

Unless otherwise handled by continuous monitoring and ongoing authorization, event-driven reauthorizations can occur when there is a significant change to an information system or its environment of operation. A significant change is defined as a change that is likely to affect the security state of an information system. Significant changes to an information system may include for example: (i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform; (iv) modifications to cryptographic modules or services; or (v) modifications to security controls. Examples of significant changes to the environment of operation may include for example: (i) moving to a new facility; (ii) adding new core missions or business functions; (iii) acquiring specific and credible threat information that the organization is being targeted by a threat source; or (iv) establishing new/modified laws, directives, policies, or regulations.[15] If a formal reauthorization action is initiated, the organization targets only the specific security controls affected by the changes and reuses previous assessment results wherever possible. Most routine changes to an information system or its environment of operation can be handled by the organization's continuous monitoring program, thus supporting the concept of ongoing authorization. An effective monitoring program can significantly reduce the overall cost and level of effort of reauthorization actions.

In the event that there is a change in authorizing officials, the new authorizing official reviews the current authorization decision document, authorization package, and any updated documents created as a result of the ongoing monitoring activities. If the new authorizing official is willing to accept the currently documented risk, then the official signs a new authorization decision document, thus formally transferring responsibility and accountability for the information system or the common controls inherited by organizational information systems and explicitly accepting the risk to organizational operations and assets, individuals, other organizations, and the Nation. If the new authorizing official is not willing to accept the previous authorization results (including identified level of risk), a reauthorization action may need to be initiated or the new authorizing official may instead establish new terms and conditions for continuing the original authorization, but not extend the original authorization termination date. In all situations where there is a decision to reauthorize an information system or the common controls inherited by organizational information systems, the maximum reuse of authorization information is strongly encouraged to minimize the time and expense associated with the reauthorization effort.[16]


F.5 TYPE AUTHORIZATION

A type authorization is an official authorization decision to employ identical copies of an information system or subsystem (including hardware, software, firmware, and/or applications) in specified environments of operation.[17] This form of authorization allows a single authorization package (i.e., security plan, security assessment report, and plan of action and milestones) to be developed for an archetype (common) version of an information system that is deployed to multiple locations, along with a set of installation and configuration requirements or operational security needs, that will be assumed by the hosting organization at a specific location. The type authorization is used in conjunction with the authorization of site-specific controls (e.g., physical and environmental protection controls, personnel security controls) inherited by the information system.[18] The RMF tasks listed in Chapter 3 address the authorization activities associated with the employment of system-specific, hybrid, and common controls.


F.6 AUTHORIZATION APPROACHES

Organizations can choose from three different approaches when planning for and conducting security authorizations to include: (i) an authorization with a single authorizing official; (ii) an authorization with multiple authorizing officials; or (iii) leveraging an existing authorization.[19] The first approach is the traditional authorization process defined in this appendix where a single organizational official in a senior leadership position is both responsible and accountable for an information system. The organizational official also accepts the information system-related security risks that may impact organizational operations and assets, individuals, other organizations, or the Nation.

The second approach, or joint authorization, is employed when multiple organizational officials either from the same organization or different organizations, have a shared interest in authorizing an information system. The organizational officials collectively are responsible and accountable for the information system and jointly accept the information system-related security risks that may adversely impact organizational operations and assets, individuals, other organizations, and the Nation. A similar authorization process is followed as in the first approach with the essential difference being the addition of multiple authorizing officials. Organizations choosing a joint authorization approach are expected to work together on the planning and the execution of RMF tasks (see Appendix H) and to document their agreement and progress in implementing the tasks. Collaborating on the security categorization, selection of security controls, plan for assessing the controls to determine effectiveness, plan of action and milestones, and continuous monitoring strategy, is necessary for a successful joint authorization. The specific terms and conditions of the joint authorization are established by the participating parties in the joint authorization including for example, the process for ongoing determination and acceptance of risk. The joint authorization remains in effect only as long as there is mutual agreement among authorizing officials and the authorization meets the requirements established by federal and/or organizational policies.

The final approach, leveraged authorization, is employed when a federal agency[20] chooses to accept some or all of the information in an existing authorization package generated by another federal agency (hereafter referred to as the owning organization[21]) based on a need to use the same information resources (e.g., information system and/or services provided by the system). The leveraging organization reviews the owning organization's authorization package as the basis for determining risk to the leveraging organization.[22] When reviewing the authorization package, the leveraging organization considers risk factors such as the time elapsed since the authorization results were produced, the environment of operation (if different from the environment of operation reflected in the authorization package), the criticality/sensitivity of the information to be processed, stored, or transmitted, as well as the overall risk tolerance of the leveraging organization. If the leveraging organization determines that there is insufficient information in the authorization package or inadequate security measures in place for establishing an acceptable level of risk, the leveraging organization may negotiate with the owning organization for additional security measures and/or security-related information.[23] Additional security measures may include, for example, increasing the number of security controls, conducting additional assessments, implementing compensating controls, or establishing constraints on the use of the information system or services provided by the system. Security-related information may include, for example, other information that the owning organization may have discerned in the use or assessment of the information system that is not reflected in the authorization package. The additional security measures and/or security-related information may be provided by the leveraging organization, the information system developer, some other external third party, or some combination of the above.

The leveraged authorization approach provides opportunities for significant cost savings and avoids a potentially costly and time-consuming authorization process by the leveraging organization. Leveraging organizations generate an authorization decision document and reference, as appropriate, information in the authorization package from the owning organization. In situations where addition security measures are implemented, the leveraging organization documents those measures by creating an addendum to the original authorization package of the owning organization. This addendum may include, as appropriate, updates to the security plan, security assessment report, and/or plan of action and milestones. Consistent with the traditional authorization process described above, a single organizational official in a senior leadership position in the leveraging organization is both responsible and accountable for accepting the information system-related security risks that may impact the leveraging organization's operations and assets, individuals, other organizations, or the Nation. The leveraged authorization remains in effect as long as the leveraging organization accepts the information system-related security risks and the authorization meets the requirements established by federal and/or organizational policies. This requires the sharing of information resulting from continuous monitoring activities conducted by the owning organization (e.g., updates to the security plan, security assessment report, plan of action and milestones, and security status reports). To enhance the security of all parties, the leveraging organization can also share with the owning organization, the results from any RMF-related activities it conducts to supplement the authorization results produced by the owning organization.

For all three authorization approaches described above, risk management-related activities (including RMF tasks) involving external providers are carried out in accordance with the guidance provided in Appendices H and I.


Footnotes

  1. ↑ 60 The authorizing official determines what additional supporting documentation or references may be required to be included in the security authorization package. Appropriate measures are employed to protect information contained in security authorization packages in accordance with federal and organizational policy.
  2. ↑ 61 The security plan is a conceptual body of information which may be accounted for within one or more repositories and include documents (electronic or hard copy) that come from a variety of sources produced throughout the system development life cycle. For example, information system owners inheriting common controls can either document the implementation of the controls in their respective security plans or reference the controls contained in the security plans of common control providers.
  3. ↑ 62 Organizations may choose to develop an executive summary from the detailed findings that are generated during a security control assessment. An executive summary provides an authorizing official with an abbreviated version of the security assessment report focusing on the highlights of the assessment, synopsis of key findings, and recommendations for addressing weaknesses and deficiencies in the security controls.
  4. ↑ 63 Organizations maintain strict version control as critical documents in the authorization package are updated.
  5. ↑ 64 Organizations may choose to document the specific measures implemented to correct weaknesses or deficiencies in security controls in the plan of action and milestones, thereby providing an historical record of actions completed.
  6. ↑ 65 In general, risk exposure is the degree to which an organization is threatened by the potential adverse effects on organizational operations and assets, individuals, other organizations, or the Nation.
  7. ↑ 66 Organizations document their rationale for accepting security control weakness or deficiencies.
  8. ↑ 67 An interim authorization to test is a special type of authorization decision allowing an information system to operate in an operational environment for the express purpose of testing the system with actual operational (i.e., live) data for a specified time period. An interim authorization to test is granted by an authorizing official only when the operational environment or live data is required to complete specific test objectives.
  9. ↑ 68 Some organizations may choose to use the term interim authorization to operate to focus attention on the increased risk being accepted by the authorizing official in situations where there are significant weaknesses or deficiencies in the information system, but an overarching mission necessity requires placing the system into operation or continuing its operation.
  10. ↑ 69 Authorization decision documents may be digitally signed to ensure authenticity.
  11. ↑ 70 Organizations may choose to employ automated tools to support the development, distribution, and archiving of risk management documentation to include artifacts associated with the security authorization process.
  12. ↑ 71 Continuous monitoring is described in Appendix G.
  13. ↑ 72 NIST Special Publication 800-53A describes the specific conditions when security-related information can be reused in security authorizations, ongoing authorizations, and reauthorizations.
  14. ↑ 73 Decisions to initiate a formal reauthorization action include inputs from the risk executive (function) and the senior information security officer.
  15. ↑ 74 The examples of changes listed above are only significant when they meet the threshold established in the definition of significant change (i.e., a change that is likely to affect the security state of the information system).
  16. ↑ 75 The decision to initiate a formal reauthorization action can be based on a variety of factors, including for example, the acceptability of the previous authorization information provided in the authorization package, the length of time since the previous authorization decision, the risk tolerance of the new authorizing official, and current organizational requirements and/or priorities.
  17. ↑ 76 Examples of type authorizations include: (i) an authorization of the hardware and software applications for a standard financial system deployed in several locations around the world; or (ii) an authorization of a common workstation or operating environment (i.e., hardware, operating system, middleware, and applications) deployed to all operating units within an organization.
  18. ↑ 77 Site-specific controls are typically implemented by an organization as common controls.
  19. ↑ 78 Authorization approaches can be applied to both information systems and to common controls inherited by one or more organizational information systems.
  20. ↑ 79 In this situation, federal agency includes any organizations that are subordinate to the agency. For example, NIST is a subordinate organization to the Department of Commerce.
  21. ↑ 80 The term owning organization refers to the federal agency or subordinate organization that owns the authorization package. The information system may not be owned by the same organization that owns the authorization package, for example, in situations where the system/services are provided by an external provider.
  22. ↑ 81 The sharing of the authorization package (including the security plan, security assessment report, plan of action and milestones, and authorization decision document) is accomplished under terms and conditions agreed upon by all parties (i.e., the owning organization and the leveraging organization).
  23. ↑ 82 Negotiations with the owning organization may include other organizations (e.g., when the information system and/or services are provided to the owning organization in full or in part, by an external provider).


Source

Retrieved from "http://fismapedia.org/index.php?title=Doc:NIST_SP_800-37r1_Appendix_F&oldid=50246"