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

CHAPTER TWO

THE FUNDAMENTALS

BASIC CONCEPTS ASSOCIATED WITH MANAGING RISK FROM INFORMATION SYSTEMS

2.1 INTEGRATED ENTERPRISE-WIDE RISK MANAGEMENT

Paragraph 4 of section 2.1: As-is "When a diversity of risk assessment methods is allowed, organizations employ some means of translation and/or synthesis of the risk-related information to ensure that the output of the different risk assessment activities can be correlated in a meaningful manner."

Suggested change: "When a diversity of risk assessment methods is allowed, organizations shall employ some means of translation and/or synthesis of the risk-related information to ensure that the output of the different risk assessment activities can be correlated in a meaningful manner at the organizational level." Eric D. Silberman 22:46, 23 December 2009 (UTC)

Paragraph 6 of section 2.1: "If these tasks are not adequately performed during the initiation, development, and acquisition phases of the system development life cycle, the tasks will, by necessity, be undertaken later in the life cycle and be more costly to implement." Suggestion: this is definitely the paragraph to reference 800-64 !Eric D. Silberman 23:24, 23 December 2009 (UTC)

Paragaph 7 of section 2.1: As-is: "Authorizing information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable."Eric D. Silberman 23:24, 23 December 2009 (UTC)

Suggested change: "Authorizing information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this aggregate risk is acceptable." Eric D. Silberman 23:24, 23 December 2009 (UTC)

2.2 SYSTEM DEVELOPMENT LIFE CYCLE

OMB has prescribed and measured 800-37 compliance whereas 800-64 has not been so blessed. The FISMA scorecard counts the percentage of IS with ATO, and consequently agency management focuses on what is measured. Given the problems of retrofitting security when the IS is designed and ready to deploy, incorporation of 800-64 into 800-37 makes a lot of sense. Save for continuous monitoring, the 800-53 controls are applied in the SCA or ST&E which is typically performed once evey three years. Incorporating security controls into the SDLC or other development processes will require a significant rethinking of C&A as practiced. --Walter Houser 22:53, 19 December 2009 (UTC)

Paragraph 1 of Section 2.2: As-is: "Security requirements are a subset of the overall functional requirements levied on an information system"

Suggested change: "subset of the overall functional requirements asked of an information system" Eric D. Silberman 23:27, 23 December 2009 (UTC)

Paragraph 1 of Section 2.2: As-is: "Organizations prioritize information system requirements, both functional and security-related,"

Suggested change: "Organizations shall prioritize information system requirements, both functional and security-related," Eric D. Silberman 23:27, 23 December 2009 (UTC)

Paragraph 2 of Section 2.2: As-is: "Integrating information security requirements into the system development life cycle" Suggested change: "Early integration of information security requirements into the system development life cycle" Eric D. Silberman 23:33, 23 December 2009 (UTC)

Paragraph 2 of Section 2.2: As-is: "As part of their ongoing management and oversight responsibilities, organizational officials ensure" Suggested change: "As part of their ongoing management and oversight responsibilities, organizational officials shall ensure" Eric D. Silberman 23:33, 23 December 2009 (UTC)

As-is: "Resource allocation includes both funding to carry out the risk management tasks and assigning the personnel needed to accomplish the tasks." Suggested change: "Resource allocation includes both funding to carry out the risk management tasks as well as assigning the personnel needed to accomplish the tasks." Eric D. Silberman 23:33, 23 December 2009 (UTC)

2.3 INFORMATION SYSTEM BOUNDARIES

2.3.1 Establishing Information System Boundaries

Paragraph 1 of Section 2.3.1: As-is: "The allocation of information resources<ref>Information resources consist of information and related resources including personnel, equipment, funds, and information technology.</ref> to an information system defines the boundary for that system. Organizations have significant flexibility in determining what constitutes an information system."

Suggested change: "The set of information resources<ref>Information resources consist of information and related resources including personnel, equipment, funds, and information technology.</ref> allocated to an information system defines the boundary for that system. Organizations have significant flexibility in determining what constitutes an information system and what its boundaries are." Eric D. Silberman 23:44, 23 December 2009 (UTC)

Final chapter of this section is very concerning to me. Seems to imply that security of the Operating System is the paramount concern without regard to the fact that applications are where the majority of government data is held. Dan Philpott 03:26, 8 December 2009 (UTC)

I believe Dan is referring to the section that that begins … “Software applications are included in the boundary of an information system hosting the applications and do not require a separate risk management process (including a separate security authorization).”

The types of situations where a distinct system enforces additional security at the application layer are exceptional, in my opinion. An example might be the case of the web application firewall. A less obvious example might be an instance where an application leverages a directory service provider for account control. In this example, the application can inherit a secure process from another system in order to control access. Either way, it is unlikely that security measures implemented in a hosting information system will be sufficient to the extent that application security can be essentially ignored. The statement would be best rewritten something like:

"Software applications should take advantage of the security controls provided by the hosting information system to help provide a foundational level of protection, when this type of inheritance is applicable."

Note that the assertion that applications “do not require a separate risk management process (including a separate security authorization)” has been omitted. This is important, because I think an application is itself a subsystem which warrants its own risk management process, with technical attention placed on proactive vulnerability discovery and mitigation. --Frank Ervin 20:10, 23 December 2009 (UTC)

Paragraph immediately before 2.3.2: As-is: "Rather, software applications take advantage of the security controls" Suggested change: "Rather, software applications leverage the security controls" Eric D. Silberman 00:51, 24 December 2009 (UTC)

As-is: "Additional application-level security controls are provided by" Suggested change: "Additional application-level security controls shall be provided by" Eric D. Silberman 00:51, 24 December 2009 (UTC)

As-is: "Security controls provided by the hosted software application are documented in the security plan for the hosting information system and assessed for effectiveness" Suggested change: "Security controls provided by the hosted software application shall be documented in the security plan for the hosting information system and shall be assessed for effectiveness" Eric D. Silberman 00:51, 24 December 2009 (UTC)

As-is: "Organizations ensure that all security controls," Suggested change: "Organizations shall ensure that all security controls," Eric D. Silberman 00:51, 24 December 2009 (UTC)

As-is: "Information system owners ensure that hosted applications do not" Suggested change: "Information system owners shall ensure that hosted applications do not" Eric D. Silberman 00:51, 24 December 2009 (UTC)

2.3.2 Boundaries for Complex Information Systems (System of Systems)

Take the following statement about the System of Systems … “the organization is responsible for ensuring that these separate subsystems can work together in both a secure and functional manner.”

In the case where the C&A process has failed to identify a high risk application as a system, then the focus prescribed by this chapter leaves only server logs (i.e. little to no evidence at an application layer) to identify security and functional shortcomings of the system as a whole. This is not sufficient. --Frank Ervin 21:04, 23 December 2009 (UTC)

paragraph 2, Section 2.3.2 1. general comment about this paragraph: I feel that this is an important place for the document to remind readers about the "High-Water Mark" concept. I don't have any suggested text about the best way to do that, just that I think this concept should be reiterated here. Eric D. Silberman 01:04, 24 December 2009 (UTC)

As-is: "While subsystems of complex information systems may sometimes exist as full systems, for complex systems, these portions" Suggested change: remove the second comma in this sentence: "While subsystems of complex information systems may sometimes exist as full systems, for complex systems these portions" Eric D. Silberman 01:04, 24 December 2009 (UTC)

Paragraph 4, Section 2.3.2 As-is: "Common controls provided by different organization often require such boundary protection interface controls." Suggested change: this appears to be a genuine typographical error which needs to be corrected by adding the letter 's' to pluralize: "Common controls provided by different organizations often require such boundary protection interface controls. Eric D. Silberman 01:04, 24 December 2009 (UTC)

Paragraph 4, Section 2.3.2 As-is: "approach facilitates a more targeted and cost-effective risk management process by scaling the level of effort in accordance with" Suggested change: "approach facilitates a more targeted and cost-effective risk management process by scaling the level of effort of the assessment in accordance with" Eric D. Silberman 01:04, 24 December 2009 (UTC)

2.4 SECURITY CONTROL ALLOCATION

Overall, this system of security control allocation might be the most effective way to create any efficiency in the FISMA process. The main problem as I see it is that the resulting documentation is likely to become fragmented and no longer resemble anything that is operationally useful. --Frank Ervin 20:47, 23 December 2009 (UTC)

Footnotes

Footnote 27: As-is: "Integrated project teams are multidisciplinary entities consisting of individuals with appropriate skills and expertise to help facilitate the development of information systems that meet the requirements of the organization."

Suggested change: "Integrated project teams are multidisciplinary entities consisting of a number of individuals with a range of skills and roles to help facilitate the development of information systems that meet the requirements of the organization." Eric D. Silberman 23:37, 23 December 2009 (UTC)

Footnote 33, Section 2.3.2 As-is: "vector of attack against the intranet by requiring security controls commensurate with a lower impact level" Suggested change: "vector of attack against the intranet by erroneously suggesting security controls commensurate with a lower impact level" Eric D. Silberman 01:04, 24 December 2009 (UTC) Similarly, my comment about footnote 33 is that this is another good place to reiterate the High-Water Mark concept. Eric D. Silberman 01:04, 24 December 2009 (UTC)