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

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

From OWASP
Revision as of 20:10, 23 December 2009 by Frank Ervin (talk | contribs) (2.3.1 Establishing Information System Boundaries)

Jump to: navigation, search

CHAPTER TWO

THE FUNDAMENTALS

BASIC CONCEPTS ASSOCIATED WITH MANAGING RISK FROM INFORMATION SYSTEMS


2.1 INTEGRATED ENTERPRISE-WIDE RISK MANAGEMENT

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. --Frank Ervin 20:10, 23 December 2009 (UTC)

2.3.2 Boundaries for Complex Information Systems (System of Systems)

2.3.3 Dynamic Subsystems

2.4 SECURITY CONTROL ALLOCATION

Footnotes