Talk:Industry:Project Review/NIST SP 800-37r1 FPD Appendix G - Revision history

Walter Houser: /* G.1 MONITORING STRATEGY */

2009-12-19T22:44:58Z

‎G.1 MONITORING STRATEGY

Walter Houser: /* G.1 MONITORING STRATEGY */

2009-12-19T20:50:36Z

‎G.1 MONITORING STRATEGY

Walter Houser: /* G.1 MONITORING STRATEGY */

2009-12-19T20:13:47Z

‎G.1 MONITORING STRATEGY

Walter Houser: /* G.1 MONITORING STRATEGY */

2009-12-19T20:08:51Z

‎G.1 MONITORING STRATEGY

Walter Houser: /* G.1 MONITORING STRATEGY */

2009-12-19T20:06:59Z

‎G.1 MONITORING STRATEGY

Dan Philpott: Added footnotes section.

2009-12-16T02:35:42Z

Added footnotes section.

Dan Philpott: Installing layout of main document to structure comments

2009-12-04T15:22:14Z

Installing layout of main document to structure comments

New page

{| align="right"
| __TOC__
|}

<big>APPENDIX G</big>

<big>'''CONTINUOUS MONITORING'''</big>

MANAGING AND TRACKING THE SECURITY STATE OF INFORMATION SYSTEMS

== G.1 MONITORING STRATEGY ==

== G.2 SELECTION OF SECURITY CONTROLS FOR MONITORING ==

== G.3 CRITICAL DOCUMENT UPDATES AND STATUS REPORTING ==

[[Category:GIC-NISTSP80037r1FPD]]

@@ Line 14: / Line 14: @@
 Section 2.2 SYSTEM DEVELOPMENT LIFE CYCLE states "Security requirements are a subset of the overall functional requirements levied on an information system and therefore, whenever possible, are incorporated into the system development life cycle at the earliest opportunity. Without the early infusion of security requirements, significant expense may be incurred by the organization later in the life cycle to address security considerations that could have been included in the initial design. This may also result in less than effective information security solutions."
-Yet, this section of the draft appears to see security requirements as separate from functional requirements.  However, the "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should be articulated in the requirements analsysis stage(s), mapped to the features intended to implement them, and incorporated into the regression testing performed when any (and all) changes are verified and validated. [[User:Walter Houser|Walter Houser]] 20:08, 19 December 2009 (UTC)
+Yet, this section of the draft appears to see security requirements as separate from functional requirements.  A "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should be articulated in the requirements analsysis stage(s), mapped to the features intended to implement them, and incorporated into the regression testing performed when any (and all) changes are verified and validated. [[User:Walter Houser|Walter Houser]] 20:08, 19 December 2009 (UTC)
 == G.2  SELECTION OF SECURITY CONTROLS FOR MONITORING ==

@@ Line 12: / Line 12: @@
 == G.1  MONITORING STRATEGY ==
-The draft appears to see security requirements as separate from functional requirements.  However, the "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should be articulated in the requirements analsysis stage(s), mapped to the features intended to implement them, and incorporated into the regression testing performed when any (and all) changes are verified and validated. [[User:Walter Houser|Walter Houser]] 20:08, 19 December 2009 (UTC)
+Section 2.2 SYSTEM DEVELOPMENT LIFE CYCLE states "Security requirements are a subset of the overall functional requirements levied on an information system and therefore, whenever possible, are incorporated into the system development life cycle at the earliest opportunity. Without the early infusion of security requirements, significant expense may be incurred by the organization later in the life cycle to address security considerations that could have been included in the initial design. This may also result in less than effective information security solutions."
 == G.2  SELECTION OF SECURITY CONTROLS FOR MONITORING ==

@@ Line 12: / Line 12: @@
 == G.1  MONITORING STRATEGY ==
-The draft appears to see security requirements as separate from functional requirements.  However, the "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should also be incorporated into the regression testing performed when any changes are verified and validated. --[[User:Walter Houser|Walter Houser]] 20:08, 19 December 2009 (UTC)
+The draft appears to see security requirements as separate from functional requirements.  However, the "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should be articulated in the requirements analsysis stage(s), mapped to the features intended to implement them, and incorporated into the regression testing performed when any (and all) changes are verified and validated. [[User:Walter Houser|Walter Houser]] 20:08, 19 December 2009 (UTC)
 == G.2  SELECTION OF SECURITY CONTROLS FOR MONITORING ==

@@ Line 12: / Line 12: @@
 == G.1  MONITORING STRATEGY ==
-The draft appears to see security requirements as separate from functional requirements.  However, the "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should also be incorporated into the regression testing performed when any changes are verified and validated.
+The draft appears to see security requirements as separate from functional requirements.  However, the "build security in" philosophy would include security requirements in the analysis, desgin, and testing stages of the SDLC.  Therefore, security requirements should also be incorporated into the regression testing performed when any changes are verified and validated. --[[User:Walter Houser|Walter Houser]] 20:08, 19 December 2009 (UTC)
 == G.2  SELECTION OF SECURITY CONTROLS FOR MONITORING ==

← Older revision		Revision as of 02:35, 16 December 2009
Line 19:		Line 19:

	== G.3 CRITICAL DOCUMENT UPDATES AND STATUS REPORTING ==		== G.3 CRITICAL DOCUMENT UPDATES AND STATUS REPORTING ==
		+
		+
		+
		+	==Footnotes==
		+



	[[Category:GIC-NISTSP80037r1FPD]]		[[Category:GIC-NISTSP80037r1FPD]]