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
Difference between revisions of "Talk:Industry:Project Review/NIST SP 800-37r1 FPD Appendix F"
(→F.4 ONGOING AUTHORIZATION) |
|||
| 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) | 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. | + | 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) | 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) | ||
Revision as of 23:18, 21 December 2009
APPENDIX F
SECURITY AUTHORIZATION
AUTHORIZATION DECISIONS AND SUPPORTING EVIDENCE
F.1 AUTHORIZATION PACKAGE
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)
