Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

CHAPTER THREE

THE PROCESS

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. Dan Philpott 04:10, 8 December 2009 (UTC)

APPLICATION OF THE RISK MANAGEMENT FRAMEWORK

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." Dan Philpott 03:28, 22 December 2009 (UTC)

Playing Devil's Advocate here, how can an "appropriate level of trust" be considered to be more of a "known" factor than knowing your degree of assurance? Either measure requires trusting the entity providing the "assurance" to have done their due diligence and thoroughly, at that. Taking this into consideration, the solution doesn't really change anything. - Jack Mannino

You're right of course, neither is anything like an objective measure. The only difference is that level of trust is a concept woven into FISMA guidance and has guidance available for establishing a subjective 'level of trust' or 'chain of trust'. NIST SP 800-53r3 even includes a control called Trustworthiness (SA-13). I'm not a fan of either of these subjective measures but at least with the level of trust there is some guidance to work with. Dan Philpott 20:35, 24 December 2009 (UTC)

3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM

TASK 1-1 SECURITY CATEGORIZATION

TASK

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. Dan Philpott 03:42, 22 December 2009 (UTC)

Supplemental Guidance

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. Dan Philpott 04:03, 22 December 2009 (UTC)

TASK 1-2 INFORMATION SYSTEM DESCRIPTION

Supporting Roles

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. Dan Philpott 04:11, 22 December 2009 (UTC)

Supplemental Guidance

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". Dan Philpott 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. Dan Philpott 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. Dan Philpott 04:27, 22 December 2009 (UTC)

TASK 1-3 INFORMATION SYSTEM REGISTRATION

Supplemental Guidance

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. Dan Philpott 04:46, 22 December 2009 (UTC)

References

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. Dan Philpott 04:35, 22 December 2009 (UTC)

3.2 RMF STEP 2 - SELECT SECURITY CONTROLS

TASK 2-2 COMMON CONTROL IDENTIFICATION

Supplemental Guidance

"Organizations may choose to defer common control identification and security control selection until later in the system development life cycle." While it is stated that organizations can defer identification of common controls and security controls until later in the development life cycle, the guidance does not state whether finite points in the development life cycle exist as to when this activity can be deferred. Recommend consideration of the ramifications of this language, with the inclusion of language mandating when this activity must be performed (example- prior to implementation in a production environment). -Jack Mannino

TASK 2-3 MONITORING STRATEGY

Supplemental Guidance

Within this section, there is a great deal of language highlighting the reliance (or over-reliance) on the use of automation to monitor security controls implementation. While automation does indeed permit the average organization to increase the frequency and efficiency of monitoring, automation cannot be fully trusted as a foolproof measure to identifying security deficiencies or non-compliance in any way, shape, or form. Recommend the inclusion of a requirement to identify target areas that cannot be fully automated, and to develop manual processes and the frequencies in which they will be performed, within levels of effort proportionate to an organization's alloted resources. Also recommend that a reference be made to performing gap-analysis to identify areas relevant to an organization that cannot be adequately addressed via automated means, which has the potential to lead to a greater level of accountability as well as more a more holistic overall approach to security. -Jack Mannino

3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM

TASK 5-5 RISK ACCEPTANCE

Supplemental Guidance

In the line: "Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function)." The word 'key' implies that the list of organizational officials the authorizing official can receive input from are limited to those defined in Appendix D/listed as primary or supporting roles. This unnecessarily limits the resources authorizing officials can draw upon to inform their decision. An example of where this would be a problem would be if an authorizing official did not sufficiently understand a technology or policy issue and consulted with anyone outside of the defined list of roles for background information. Limiting this kind of interaction would lower the quality of authorization decisions with a likely outcome of poorer security being implemented. Recommend removal of the word 'key' from the sentence. Dan Philpott 04:09, 23 December 2009 (UTC)