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

APPENDIX F

SECURITY AUTHORIZATION

AUTHORIZATION DECISIONS AND SUPPORTING EVIDENCE

F.4 ONGOING AUTHORIZATION
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". Dan Philpott 04:36, 9 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. 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. Dan Philpott 04:36, 9 December 2009 (UTC)