NIST SP 800-53A Footnotes

1

While agencies are required to follow NIST guidance in accordance with OMB policy, there is flexibility within NIST's guidance in how agencies apply the guidance. Unless otherwise specified by OMB, the 800-series guidance documents published by NIST generally allow agencies some latitude in their application. Consequently, the application of NIST guidance by agencies can result in different security solutions that are equally acceptable, compliant with the guidance, and meet the OMB definition of adequate security for federal information systems. When assessing agency compliance with NIST guidance, auditors, inspectors general, evaluators, and/or assessors should consider the intent of the security concepts and principles articulated within the particular guidance document and how the agency applied the guidance in the context of its specific mission responsibilities, operational environments, and unique organizational conditions.

2

The one-year compliance date for revisions to NIST Special Publications applies only to the new and/or updated material in the publications resulting from the periodic revision process. Agencies are expected to be in compliance with previous versions of NIST Special Publications within one year of the publication date of the previous versions.

3

The Risk Management Framework is described in NIST Special Publication 800-39 and consists of a six-step process to ensure the development and implementation of comprehensive information security programs for organizations.

4

FIPS 200, Minimum Security Requirements for Federal Information and Information Systems.

5

FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.

6

An assessment case represents a worked example of an assessment procedure that provides specific actions that an assessor might carry out during the assessment of a security control or control enhancement in an information system.

7

Additional details on the ISAP/SCAP initiative, as well as freely available SCAP reference data, can be found at the NIST website at http://nvd.nist.gov.

8

An information system is a discrete set of information resources organized expressly for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

9

When selecting security controls for an information system, the organization also considers potential impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level impacts.

10

For example, detailed test scripts may need to be developed for the specific operating system, network component, middleware, or application employed within the information system to adequately assess certain characteristics of a particular security control. Such test scripts are at a lower level of detail than provided by the assessment procedures contained in Appendix F (Assessment Procedures Catalog) and are therefore beyond the scope of this publication.

11

The agreed-upon security controls for the information system are documented in the security plan after the initial selection of the controls as described in NIST Special Publication 800-53. The security plan is approved by appropriate organizational officials prior to the start of the security control assessment.

12

In this publication, the term risk is used to mean risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation.

13

NIST Special Publication 800-53A is a companion publication to NIST Special Publication 800-53, not a replacement or update. Special Publication 800-53 remains the definitive NIST recommendation for employing security controls in federal information systems.

14

Assessment results can be obtained from many activities that occur routinely during the System Development Life Cycle processes within organizations. For example, assessment results are produced during the testing and evaluation of new information system components during system upgrades or system integration activities. Organizations should take advantage of previous assessment results whenever possible, to reduce the overall cost of assessments and to make the assessment process more efficient.

15

Organizations should review the component product's available information to determine: (i) what security controls are implemented by the product; (ii) if those security controls meet intended control requirements of the information system under assessment; (iii) if the configuration of the product and the environment in which the product operates are consistent with the environmental and product configuration as stated by the vendor/developer; and (iv) if the assurance requirements stated in the developer/vendor specification satisfy the assurance requirements for assessing those controls. Meeting the above criteria provides a sound rationale that the product is suitable and meets the intended security control requirements of the information system under assessment.

16

There are five phases in the system development life cycle: (i) system initiation; (ii) system acquisition/development; (iii) system implementation; (iv) system operations and maintenance; and (v) system disposition (disposal). NIST Special Publications 800-64 and 800-100 provide guidance on integrating information security activities into the specific phases of the system development life cycle.

17

The information system owner is the organizational official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.

18

An assurance case is a body of evidence organized into an argument demonstrating that some claim about an information system holds (i.e., is assured). An assurance case is needed when it is important to show that a system exhibits some complex property such as safety, security, or reliability. Additional information can be obtained at https://buildsecurityin.us- http://cert.gov/daisy/bsi/articles/knowledge/assurance/643.html.

19

References to security controls under assessment also include control enhancements.

20

Mechanisms also include physical protection devices associated with an information system (e.g., locks, keypads, security cameras, fire protection devices, fireproof safes, etc.).

21

In this context, a developer/implementer is an individual or group of individuals responsible for the development or implementation of security controls within an information system. This may include, for example, hardware and software vendors providing the controls, contractors implementing the controls, or organizational personnel such as information system owners, information system security officers, system and network administrators, or other individuals with security responsibility for the information system.

22

For example, the assurance requirements in NIST Special Publication 800-53 at the moderate-impact level are designed to ensure that security controls within the information system contain specific actions and the assignment of responsibilities to provide increased grounds for confidence that the controls are implemented correctly and operating as intended. At the high-impact level, the assurance requirements are designed to ensure that when security controls are implemented, the controls will continuously and consistently (i.e., across the information system) meet their required function or purpose and support improvement in the effectiveness of the controls. These requirements are reflected in the associated security control assessment procedures at the appropriate impact level of the information system under assessment.

23

Whereas a set of potential assessment methods and objects have been included in the catalog of assessment procedures in Appendix F, these are not intended to be mandatory or exclusive and, depending on the particular circumstances of the information system to be assessed, not all methods and objects may be required.

24

In the CP-1 example above, the control requirements are divided among two assessment objectives primarily because the elements within the security control are of two types—actions (first objective) and adequacy (second objective). However, an assessment procedure consisting of one objective covering all control requirements would also be acceptable. The number of objectives is kept as small as possible while still providing a meaningful subdivision of assessment results and providing for any needed differentiation between objectives and assessment methods that apply.

25

Actions to be accomplished in the execution of the Risk Management Framework prior to the assess security controls step include; (i) developing a security plan that defines the security controls for the information system; (ii) assessing this plan for completeness, correctness, and compliance with federal and organizational requirements; (iii) appropriate organizational officials approving the plan; and (iv) implementing the security controls called out in the plan. The security plan assessment represents, along with a verification that appropriate officials have approved the plan, the assessment of security controls PL-2 and, as appropriate, PL-3. The assessment of security control PL-2 (and PL-3) provides key information to be used by authorizing officials in their determination whether or not to approve the security plan, and hence represent assessment activity that should be completed prior to the formal security controls assessment step in the Risk Management Framework.

26

The security control assessment may include common controls that are the responsibility of organizational entities other than the information system owner inheriting the controls or hybrid controls where there is shared responsibility among the system owner and designated organizational entities.

27

Typically, these individuals include authorizing officials, information system owners, mission and information owners (if other than the information system owner), chief information officers, senior agency information security officers, inspectors general, information system security officers, users from organizations that the information system supports, and assessors (e.g., certification agents/teams, independent auditors).

28

Information system owners and organizational entities developing, implementing, and/or administering common security controls are responsible for providing needed information to assessors/assessment teams.

29

In situations where there are multiple security control assessments ongoing or planned within an organization, access to organizational elements, individuals, and artifacts supporting the assessments should be centrally managed by the organization to ensure a cost-effective use of time and resources.

30

In accordance with NIST Special Publication 800-37, the security accreditation package consists of the security plan (including the risk assessment), the security assessment report, and the plan of action and milestones (POAM).

31

Organizations may choose to develop an assessment summary from the detailed findings that are generated during a security control assessment. An assessment summary can provide an authorizing official with an abbreviated version a of Security Assessment Report focusing on the highlights of the assessment, synopsis of key findings, and/or recommendations for addressing weaknesses and deficiencies in the security controls.

32

Section 3.2.7 provides guidance on optimizing assessment procedures.

33

NIST Special Publication 800-39 provides further information on selecting security controls in an information system to be assessed as part of a continuous monitoring process. NIST Special Publication 800-37 provides guidance on continuous monitoring as part of the security certification and accreditation process.

34

See Section on Reuse of assessment evidence-related considerations on page 20.

35

The selection of assessment methods and objects (including the number and type of assessment objects) can be a significant factor in cost-effectively meeting the assessment objectives.

36

In the absence of any suggested applicability designators for assessment methods, or in cases where a security control or control enhancement is used at a lower impact level than commonly applied, assessors will need to determine the appropriate applicability of the methods with regard to meeting the assessment expectations for the information system under assessment.

37

Common security controls support multiple information systems within the organization and the protection measures provided by those controls are inherited by the individual systems under assessment. Therefore, the organization should determine the FIPS 199 impact level associated with the designated common controls to ensure that both the strength of the controls (i.e., security capability) and level of rigor and intensity of the control assessments are commensurate with the impact level of the individual information systems inheriting those controls. In general, the impact level associated with the organization's common controls should support the highest impact level of any individual information system within the organization relying on those controls.

38

If assessment results are not currently available for the common controls, the assessment plans for the information systems under assessment that depend on those controls should be duly noted. The assessments cannot be considered complete until the assessment results for the common controls are made available to information system owners.

39

Previously accepted or approved assessments include those assessments of common security controls that are managed by the organization and support multiple information systems.

40

It should be noted that information technology product assessments are based upon the assumption that the products are properly and appropriately configured when installed in particular information systems in specific operational environments. If not properly configured, the products may not perform in the manner verified during the assessment.

41

An external information system is an information system or component of an information system that is outside of the accreditation boundary established by the organization and for which the organization typically has no direct control over the application of required security controls or the assessment of security control effectiveness. NIST Special Publications 800-39 and 800-53 provide additional guidance on external information systems and the effect of employing security controls in those types of environments.

42

Security control assessment sequencing is also addressed in the assessment cases described in Appendix J.

43

Organizations should establish a security assessment plan approval process with the specific organizational officials (e.g., information systems owners, information system security officers, senior agency information security officers, authorizing officials) designated as approving authorities for the security plan of the information system being assessed.

44

Determining the size and organizational makeup of the security assessment team (i.e., skill sets, technical expertise, and assessment experience of the individuals composing the team) is part of the risk management decisions made by the organization requesting and initiating the assessment of the information system.

45

For assessment findings that are other than satisfied, organizations may choose to define subcategories of findings indicating the severity/criticality of the weaknesses or deficiencies discovered and the potential adverse effects on organizational operations and assets, individuals, other organizations, and the Nation. Defining such subcategories of findings can help to establish priorities for needed risk mitigation actions.

46

The correction of deficiencies in security controls or carrying out of selected assessor recommendations during the information system owner's review of the initial (draft) security assessment report is not intended to replace the formal risk mitigation process by the organization which occurs after the delivery and acceptance of the final report. Rather, it provides the information system owner with an opportunity to address problems or deficiencies that may be quickly corrected.

47

The status and most current versions of NIST publications including FIPS and Special Publications in the 800-series (draft and final) can be found at http://csrc.nist.gov/publications.

48

While additional documentation is likely for mechanisms when moving from generalized to focused to detailed examinations, the documentation used with regard to specifications and activities may be the same for focused and detailed examinations, with the rigor of the examinations of these documents being increased at the detailed level.

49

The organization, considering a variety of factors (e.g., available resources, importance of the assessment, the organization's overall assessment goals and objectives), confers with assessors and provides direction on the type, number, and specific objects to be examined for the particular attribute value described.

50

The organization, considering a variety of factors (e.g., available resources, importance of the assessment, the organization's overall assessment goals and objectives), confers with assessors and provides direction on the type, number, and specific individuals to be interviewed for the particular attribute value described.

51

Testing is typically used to determine if mechanisms or activities meet a set of predefined specifications. Testing can also be performed to determine characteristics of a security control that are not commonly associated with predefined specifications, with an example of such testing being penetration testing. Guidelines for conducting penetration testing are provided in Appendix G.

52

The organization, considering a variety of factors (e.g., available resources, importance of the assessment, the organization's overall assessment goals and objectives), confers with assessors and provides direction on the type, number, and specific objects to be tested for the particular attribute value described. For mechanism-related testing, the coverage attribute also addresses the extent of the testing conducted (e.g., for software, the number of test cases and modules tested; for hardware, the range of inputs, number of components tested, and range of environmental factors over which the testing is conducted).

53

To define an appropriate level of rigor and intensity for low-impact information system assessments sufficient to achieve the stated assessment expectations, organizations should consider starting with depth and coverage attribute values of generalized and representative, respectively, for assessment methods employed (see Appendix D).

54

To define an appropriate level of rigor and intensity for moderate-impact information system assessments sufficient to achieve the stated assessment expectations, organizations should consider a range of depth and coverage attribute values for assessment methods employed (see Appendix D) up to and including focused and specific, respectively.

55

To define an appropriate level of rigor and intensity for high-impact information system assessments sufficient to achieve the stated assessment expectations, organizations should consider a range of depth and coverage attribute values for assessment methods employed (see Appendix D) up to and including detailed and comprehensive, respectively.

56

For ease of use and quick reference, a description of the security controls and control enhancements from NIST Special Publication 800-53 (as amended) is provided in the shaded grey areas at the beginning of the assessment procedures. In the event of any differences between this description and the most recent version of NIST Special Publication 800-53, Special Publication 800-53 remains the definitive expression of the control or enhancement.

57

The execution of the Risk Management Framework includes the selection of an initial set of baseline security controls for low-impact, moderate-impact, and high-impact information systems followed by a security control tailoring and supplementation process. The tailoring and supplementation process will likely change the set of security controls that will be contained in the final, agreed upon, security plan for the information system. Therefore, the selection of assessment procedures from the catalog of available procedures should be based solely on the content of the security plan after the tailoring and supplementation activities are completed.

58

See Section 3.2.3 on tailoring assessment procedures for specific operating environments.

59

The lack of an L, M, or H designation in the assessment procedure catalog does not mean the assessment method is not applied at that level or that the security control or control enhancement is not used in a system at that level. Rather, since the control or enhancement was not in the original security control baseline in NIST Special Publication 800-53 (i.e., anticipated common usage), a recommendation for applicability of the potential assessment methods to that impact level was simply not provided. In the absence of any suggested applicability designators for assessment methods or in cases where a control or enhancement is employed at a lower impact level than that commonly applied, assessors will need to determine the appropriate applicability of the methods with regard to meeting the assessment expectations for the information system under assessment.

60

The failure of an assessor or group of assessors to penetrate an information system may be more indicative of team expertise, resources applied, or hindrance by rules of engagement than a statement of overall system security.

61

The security plan column can also be used to indicate whether the security control is a system-specific control, common control, or a hybrid control. For common controls, a notation should also be made as to the FIPS 199 impact level at which the common control (or the common portion of the hybrid control) is being managed by the organization to ensure that it is commensurate with the impact level of the information system being assessed.

62

The security assessment report is included in the security accreditation package along with the information system security plan (including updated risk assessment), and the plan of action and milestones to provide authorizing officials with the information necessary to make credible, risk-based decisions on whether to place an information system into operation or continue its operation. As the security certification and accreditation process becomes more dynamic in nature, relying to a greater degree on the continuous monitoring aspects of the process as an integrated and tightly coupled part of the system development life cycle, the ability to update the security assessment report frequently becomes a critical aspect of an information security program. It is important to emphasize the relationship, described in NIST Special Publication 800-37, among the three key documents in the accreditation package (i.e., the system security plan including risk assessment, the security assessment report, and the plan of action and milestones). It is these documents that provide the best indication of the overall security status of the information system and the ability of the system to protect, to the degree necessary, the organization's operations and assets, individuals, other organizations, and the Nation. Updates to these key documents should be provided on an ongoing basis in accordance with the continuous monitoring program established by the organization.

63

While the rationale for each determination made is a part of the formal Security Assessment Report, the complete set of records produced as a part of the assessment is likely not included in the report. However, organizations should retain the portion of these records necessary for maintaining an audit trail of assessment evidence, facilitating reuse of evidence as appropriate, and promoting repeatability of assessor actions.

64

NIST initiated the Assessment Case Development Project in October 2007 in cooperation with the Departments of Justice, Energy, Transportation, and the Intelligence Community. The interagency task force developed a full suite of assessment cases based on the assessment procedures provided in NIST Special Publication 800-53A. The assessment cases are available to all public and private sector organizations and can be downloaded from the NIST web site at http://csrc.nist.gov/sec-cert.