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

Latest revision as of 20:55, 24 December 2009

APPENDIX F

SECURITY AUTHORIZATION

AUTHORIZATION DECISIONS AND SUPPORTING EVIDENCE

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 -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. -Wade Woolwine

F.2 AUTHORIZATION DECISIONS

Authorization to Operate

Denial of Authorization to Operate

F.3 AUTHORIZATION DECISION DOCUMENT

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)

Footnotes

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