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

Dan Philpott: /* F.1 AUTHORIZATION PACKAGE */

2009-12-24T20:55:02Z

‎F.1 AUTHORIZATION PACKAGE

Wade Woolwine: /* F.1 AUTHORIZATION PACKAGE */

2009-12-23T12:36:05Z

‎F.1 AUTHORIZATION PACKAGE

Wade Woolwine: /* F.1 AUTHORIZATION PACKAGE */

2009-12-23T12:35:13Z

‎F.1 AUTHORIZATION PACKAGE

Walter Houser at 23:18, 21 December 2009

2009-12-21T23:18:25Z

Walter Houser: /* F.4 ONGOING AUTHORIZATION */

2009-12-19T19:55:30Z

‎F.4 ONGOING AUTHORIZATION

Walter Houser: /* F.4 ONGOING AUTHORIZATION */

2009-12-19T19:52:32Z

‎F.4 ONGOING AUTHORIZATION

Walter Houser: /* F.4 ONGOING AUTHORIZATION */

2009-12-19T19:41:02Z

‎F.4 ONGOING AUTHORIZATION

Walter Houser: /* F.4 ONGOING AUTHORIZATION */

2009-12-19T19:35:00Z

‎F.4 ONGOING AUTHORIZATION

Walter Houser: /* F.4 ONGOING AUTHORIZATION */

2009-12-19T19:33:16Z

‎F.4 ONGOING AUTHORIZATION

Dan Philpott: Added footnotes section.

2009-12-16T02:35:39Z

Added footnotes section.

@@ Line 12: / Line 12: @@
 == F.1  AUTHORIZATION PACKAGE ==
 "a risk assessment, privacy impact assessment, system interconnection agreements, contingency plan, security configurations, configuration management plan, incident response plan, and continuous monitoring strategy"
-:None of the links seem to provide a clear definition and requirements for each of these items. Does it exist? If not, I would think it would make for much more streamlined and complete security package submissions
+:None of the links seem to provide a clear definition and requirements for each of these items. Does it exist? If not, I would think it would make for much more streamlined and complete security package submissions -Wade Woolwine
 "(i) a vulnerability scan of the information system or vulnerability assessment of the environment of operation; (ii) new threat information; (iii) weaknesses or deficiencies discovered in currently deployed security controls after an information system breach; (iv) a redefinition of mission priorities or business objectives invalidating the results of the previous security categorization process; and (v) a change in the information system (e.g., adding new hardware, software, or firmware; establishing new connections) or its environment of operation (e.g., moving to a new facility)."
-:Should this specifically call out new code drops for custom applications? Software is listed as part of (v) but doesn't do much to call it out specifically.
+:Should this specifically call out new code drops for custom applications? Software is listed as part of (v) but doesn't do much to call it out specifically. -Wade Woolwine
 == F.2  AUTHORIZATION DECISIONS ==

@@ Line 13: / Line 13: @@
 "a risk assessment, privacy impact assessment, system interconnection agreements, contingency plan, security configurations, configuration management plan, incident response plan, and continuous monitoring strategy"
 :None of the links seem to provide a clear definition and requirements for each of these items. Does it exist? If not, I would think it would make for much more streamlined and complete security package submissions
 == F.2  AUTHORIZATION DECISIONS ==

@@ Line 11: / Line 11: @@
 == F.1  AUTHORIZATION PACKAGE ==
+"a risk assessment, privacy impact assessment, system interconnection agreements, contingency plan, security configurations, configuration management plan, incident response plan, and continuous monitoring strategy"
+:None of the links seem to provide a clear definition and requirements for each of these items. Does it exist? If not, I would think it would make for much more streamlined and complete security package submissions
 == F.2  AUTHORIZATION DECISIONS ==

@@ Line 34: / Line 34: @@
 In the second paragraph of page F-7 a definition is offered for significant change, the text reads "A significant change is defined as a change that has the potential to affect the security state of an information system."  This definition is overbroad and includes almost any activity on a computer as all activity has the potential to affect the security state of the system.  The threshold should be raised to either "a change that is likely to affect" or "a change that has the potential to significantly affect". [[User:Dan Philpott|Dan Philpott]] 04:36, 9 December 2009 (UTC)
-NIST has previously not defined "significant change," leaving the decision to reauthorize after such a change entirely to the agencies' discretion.  This has led many to consider no change to rise to significance. Ocassionally, agencies may delay valuable upgrades to avoid triggering the reauthorization process.  The risk with providing a definition and illustrative examples is to disincentivize improvements in security or functionality. Reauthorization should only be triggered in the event of a fundamental transfomation of the system's architecture, mission, or technology. The events cited in the draft appear routine and can be reasonably documented in the SSP and tested as part of the continuous monitoring process. [[User:Walter Houser|Walter Houser]] 19:33, 19 December 2009 (UTC)
+The risk with providing this definition and its illustrative examples can be to disincentivize improvements in security or functionality. NIST has previously not defined "significant change," leaving the decision to reauthorize after such a change entirely to the agencies' discretion.  This has led many to consider that no change needs to rise to significance, largely to avoid reauthorization. Or agencies may delay valuable upgrades to avoid triggering the reauthorization process.  Reauthorization should only be triggered in the event of a fundamental transfomation of the system's architecture, mission, or technology. The events cited in the draft appear routine and can be reasonably documented in the SSP and tested as part of the continuous monitoring process. [[User:Walter Houser|Walter Houser]] 19:33, 19 December 2009 (UTC)
 Text of the examples in the event-driven reauthorizations paragraph (page F-7) should reflect that the examples are only significant when they meet the threshold established in the definition of significant change.  Otherwise misreading of the lines is likely to occur with the affect of causing unnecessary effort without worthwhile security gains. [[User:Dan Philpott|Dan Philpott]] 04:36, 9 December 2009 (UTC)

@@ Line 34: / Line 34: @@
 In the second paragraph of page F-7 a definition is offered for significant change, the text reads "A significant change is defined as a change that has the potential to affect the security state of an information system."  This definition is overbroad and includes almost any activity on a computer as all activity has the potential to affect the security state of the system.  The threshold should be raised to either "a change that is likely to affect" or "a change that has the potential to significantly affect". [[User:Dan Philpott|Dan Philpott]] 04:36, 9 December 2009 (UTC)
-NIST has previously not defined "significant change," leaving the decision to reauthorize after such a change entirely to the agencies' discretion.  This has led many to consider no change to rise to significance. Ocassionally, agencies may delay valuable upgrades to avoid triggering the reauthorization process.  The risk with providing a definition and illustrative examples is to disincentivize improvements in security or functionality. Reauthorization should only be triggered in the event of a fundamental transfomation of the system's architecture, mission, or technology. The events cited in the text appear routine and can most often be documents in the SSP and test as part of the continuous monitoring process. [[User:Walter Houser|Walter Houser]] 19:33, 19 December 2009 (UTC)
+NIST has previously not defined "significant change," leaving the decision to reauthorize after such a change entirely to the agencies' discretion.  This has led many to consider no change to rise to significance. Ocassionally, agencies may delay valuable upgrades to avoid triggering the reauthorization process.  The risk with providing a definition and illustrative examples is to disincentivize improvements in security or functionality. Reauthorization should only be triggered in the event of a fundamental transfomation of the system's architecture, mission, or technology. The events cited in the draft appear routine and can be reasonably documented in the SSP and tested as part of the continuous monitoring process. [[User:Walter Houser|Walter Houser]] 19:33, 19 December 2009 (UTC)
 Text of the examples in the event-driven reauthorizations paragraph (page F-7) should reflect that the examples are only significant when they meet the threshold established in the definition of significant change.  Otherwise misreading of the lines is likely to occur with the affect of causing unnecessary effort without worthwhile security gains. [[User:Dan Philpott|Dan Philpott]] 04:36, 9 December 2009 (UTC)

@@ Line 36: / Line 36: @@
 Text of the examples in the event-driven reauthorizations paragraph (page F-7) should reflect that the examples are only significant when they meet the threshold established in the definition of significant change.  Otherwise misreading of the lines is likely to occur with the affect of causing unnecessary effort without worthwhile security gains. [[User:Dan Philpott|Dan Philpott]] 04:36, 9 December 2009 (UTC)
 Footnote 63 should add the word can between "action include" unless the requirement is to always have both the Risk Executive (Function) and SISO/CISO provide input whenever the decision to initiate a formal reauthorization is made.  This could cause unnecessary effort for an AO who is making the decision to initiate reauthorization for a system and reduce the likelihood it will occur. [[User:Dan Philpott|Dan Philpott]] 04:36, 9 December 2009 (UTC)
 [[Category:GIC-NISTSP80037r1FPD]]