Difference between revisions of "Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 2"

Revision as of 23:17, 23 December 2009

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)

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)

2.3 INFORMATION SYSTEM BOUNDARIES

2.3.1 Establishing Information System Boundaries

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)

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)

2.3.3 Dynamic Subsystems

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