This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3"
Dan Philpott (talk | contribs) (→References) |
Dan Philpott (talk | contribs) (→Supplemental Guidance) |
||
| Line 72: | Line 72: | ||
==== Supplemental Guidance ==== | ==== 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. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC) | ||
==== References ==== | ==== References ==== | ||
Revision as of 04:46, 22 December 2009
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)
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)
Primary Responsibility
Supporting Roles
System Development Life Cycle Phase
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)
References
TASK 1-2 INFORMATION SYSTEM DESCRIPTION
TASK
Primary Responsibility
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)
System Development Life Cycle Phase
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)
References
TASK 1-3 INFORMATION SYSTEM REGISTRATION
TASK
Primary Responsibility
Supporting Roles
System Development Life Cycle Phase
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)
