OWASP - User contributions [en]

Using freed memory

2010-08-09T18:56:11Z

Dan Philpott: Added some links to referenced conditions, no content changes.

{{Template:Vulnerability}}
{{Template:SecureSoftware}}
{{Template:Fortify}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Referencing memory after it has been freed can cause a program to crash.

The use of heap allocated memory after it has been freed or deleted leads to undefined system behavior and, in many cases, to a [[Write-what-where_condition|write-what-where condition]].

Use after free errors occur when a program continues to use a pointer after it has been freed. Like [[Doubly_freeing_memory|double free error]]s and [[memory leak]]s, use after free errors have two common and sometimes overlapping causes:

* Error conditions and other exceptional circumstances
* Confusion over which part of the program is responsible for freeing the memory

Use after free errors sometimes have no effect and other times cause a program to crash. While it is technically feasible for the freed memory to be re-allocated and for an attacker to use this reallocation to launch a buffer overflow attack, we are unaware of any exploits based on this type of attack.

'''Consequences'''

* Integrity: The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.
* Availability: If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.
* Access Control (instruction processing): If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code.

'''Exposure period'''

* Implementation: Use of previously freed memory errors occur largely at implementation time.

'''Platform'''

* Languages: C, C++, Assembly
* Operating Platforms: All

'''Required resources'''

Any

'''Severity'''

Very High

'''Likelihood of exploit'''

High

The use of previously freed memory can have any number of adverse consequences - ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw.

The simplest way data corruption may occur involves the system's reuse of the freed memory. In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process.

If the newly allocated data chances to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

==Risk Factors==

TBD

==Examples==

===Example1===

<pre>
#include <stdio.h>
#include <unistd.h>

#define BUFSIZER1 512
#define BUFSIZER2 ((BUFSIZER1/2) - 8)

int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf2R2;
char *buf3R2;

buf1R1 = (char *) malloc(BUFSIZER1);
buf2R1 = (char *) malloc(BUFSIZER1);

free(buf2R1);

buf2R2 = (char *) malloc(BUFSIZER2);
buf3R2 = (char *) malloc(BUFSIZER2);

strncpy(buf2R1, argv[1], BUFSIZER1-1);
free(buf1R1);
free(buf2R2);
free(buf3R2);
}
</pre>

===Example2===

<pre>
char* ptr = (char*)malloc (SIZE);
...
if (err) {
abrt = 1;
free(ptr);
}
...
if (abrt) {
logError("operation aborted before commit", ptr);
}
</pre>

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Buffer Overflow]] (in particular, heap overflows): The method of exploitation is often the same, as both constitute the unauthorized writing to heap memory.
* [[Write-what-where condition]]: The use of previously freed memory can result in a write-what-where in several ways.

==Related [[Controls]]==

* Implementation: Ensuring that all pointers are set to NULL once the memory they point to has been freed can be effective strategy. The utilization of multiple or complex data structures may lower the usefulness of this strategy.

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD
[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Range and Type Error Vulnerability]]
[[Category:OWASP_CLASP_Project]]
[[Category:Code Quality Vulnerability]]
[[Category:Implementation]]
[[Category:Code Snippet]]
[[Category:C]]

Global Industry Committee

2010-01-04T15:25:53Z

Dan Philpott: /* Work in Progress */ Removing NIST SP 800-37r1 FPD from work in progress list

'''The Global Industry Committee was created during the OWASP EU Summit in Portugal. The primary purpose of the Global Industry Committee is to work with industry executives to gather requirements from industry, work with Membership, Projects and others.'''

==Mission Statement==

''To expand awareness of and promote the inclusion of software security best practices in Industry, Government, Academia and regulatory agencies and be a voice for industry. We will accomplish this through outreach; including presentations, development of position papers and collaborative efforts with other entities.'' [https://www.owasp.org/index.php/Global_Industry_Committee#General_Presentations_and_Reports Powerpoint of Accomplishments]

==Committee Plan==

Step 1:
[[Industry:Organizations_for_Outreach|Identify specific organizations]] worth working with to spread the OWASP gospel

Step 2:
Prioritize the proposed liasons based on potential impact, and also realistic likelihood of the organization actively working with us

Step 3:
Execute, leveraging global OWASP resources as much as possible to maximize impact

Step 4:
Evaluate progress & repeat Step 1-3

==Committee Members==

Board Member Rep: [mailto:tomb@owasp.org Tom Brennan]

Committee Members:

{| class="prettytable"
! Name
! Email
! Location
|-
| Joe Bernik
|
| US
|-
| Rex Booth
| rex.booth 'at' gt dot com
| US
|-
| David Campbell
| dcampbell 'at' owasp dot org
| US
|-
| Alexander Fry
| alexander.fry 'at' owasp dot org
| US
|-
| Georg Hess
| georg.hess 'at' artofdefence dot com
| Germany
|-
| Eoin Keary
| eoin.keary 'at' owasp dot org
| Ireland
|-
| Yiannis Pavlosoglou
| yiannis 'at' owasp dot org
| UK
|-
| Colin Watson
| colin.watson 'at' owasp dot org
| UK
|-
|}

OWASP Employees:
* Alison
* Kate Hartman

==Getting Involved==

=== Mailing List ===

[http://lists.owasp.org/mailman/listinfo/global_industry_committee Join our mailing list]

=== Meetings ===

The next Global Industry Committee meeting will be:

* TBC (Conference Bridge: 1-866-534-4754)

Host Code: check calendar invite

Guest Code: 192341

Previous meeting minutes are:

* [[Industry:Minutes 2009-01-23|23 Jan 2009]]

=== Membership ===

[[Membership]] explains how to become an OWASP organization supporter or individual member.

You don't have to be an OWASP Member or Committee Member to contribute - the current committee members joined for a 12 month term - see [[How to Join a Committee]] and [[Global Committee Pages]].

=== Other ongoing initiatives ===

* [http://www.owasp.org/index.php/Global_Industry_Committee-SIG Special Interest Groups] - Outreach to sector-specific critical infrastructures worldwide.
* [http://www.owasp.org/index.php/Category:India OWASP India Advisory Board] - Regional panel contributing to the software outsourcing industry.
* [http://www.owasp.org/index.php/Industry:Citations OWASP Citations] - References to OWASP in official, or otherwise important, documents.

==Current Activity==

=== Work in Progress ===

The current activities being undertaken:

{| class="prettytable"
! Task
! Deadline
! Type
! Status
! Description
! Who
|-
| [http://www.enisa.europa.eu/ ENISA] Cloud Computing Common Assurance Metrics
| 2010
| Standards
| New
| Work with [[:Category:OWASP Cloud ‐ 10 Project]] to contribute to the development of Common Assurance Metrics for ENISA's [http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-information-assurance-framework?searchterm=cloud Cloud Computing Information Assurance Framework]. See also the [http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment Cloud Computing Risk Assessment] report.
| CW
|-
| [[Industry:Personal Information Online Code of Practice|Personal Information Online COP]]
| 5 Mar 2010
| Legislation
| In Progress
| Provide response to UK Information Commissioner's Office draft "Personal Information Online Code of Practice"
| CW
|-
| [http://www.spva.org Secure POS Vendor Alliance (SPVA)]
| -
| Outreach
| In Progress
| Begin dialogue about possibility of working together
| DC
|}

=== Completed Items ===

{| class="prettytable"
! Task
! Completed
! Type
! Status
! Description
! Who
|-
| [[:Industry:Draft_NIST_SP_800-37_Revision_1|NIST SP 800-37 Revision 1 FPD]] Review Project
| 30 Dec 2009
| Standards
| Closed
| Provide response to "NIST SP 800-37 Revision 1 Final Public Draft, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach"
| RB
|-
| [http://www.crest-approved.org/ CREST] CRESTCon
| 15 Dec 2009
| Outreach
| Closed
| Already an oversubscribed event, YP & CW have been placed on the reserve list. Update: Positions secured for the 15th.
| YP
|-
| [http://msdn.microsoft.com/en-us/security/cc448177.aspx SDL Pro Network]
| 30 Nov 2009
| Outreach
| Closed
| Contact SDL Pro Network to discuss if there are opportunities for OWASP to become involved or connected in some way
| CW
|-
| [[Industry:Draft NIST IR 7628|Draft NIST IR 7628]]
| 25 Nov 2009
| Standards
| Closed
| Provide response to "NIST IR 7628 Draft Smart Grid Cyber Security Strategy and Requirements"
| CW
|-
| [http://www.owasp.org/index.php/OWASP_AppSec_DC_2009 Appsec DC 2009]
| 10-13 Nov 2009
| Outreach
| Closed
| Conference organisation - special effort to engage with US Federal sector
| RB
|-
| [http://www.justice.gov.uk/ UK Ministry of Justice]
| -
| Legislation
| Closed
| Ask to be added to official consultation list
| CW
|-
| [http://www.it-sa.de/ IT-SA]
| 13-15 Oct 2009
| Outreach
| Closed
| OWASP booth at trade show
| GH
|-
| [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009]
| 13 Oct 2009
| Outreach
| Closed
| Conference organisation
| GH
|-
| US [http://www.loc.gov Library of Congress]
| 28 Sep 2009
| Outreach
| Closed
| Presentation about OWASP
| RB
|-
| [http://www.owasp.org/index.php/OWASP_Ireland_AppSec_2009_Conference OWASP Ireland AppSec 2009]
| 10 Sep 2009
| Outreach
| Closed
| Conference organisation
| EK
|-
| OWASP Citations
| 7 Sep 2009
| Other
| Closed
| Identify and record the most important references to OWASP in official, or otherwise important, documents. Page created at: [[Industry:Citations]]
| CW
|-
| US [http://www.loc.gov Library of Congress]
| 26 Aug 2009
| Outreach
| Closed
| Presentation about OWASP
| RB
|-
| OWASP webcast at Brighttalk [http://www.brighttalk.com/summit/dataprivacy2 Data and Privacy in Web 2.0 Summit]
| 13 Aug 2009
| Outreach
| Closed
| Deliver [http://www.brighttalk.com/webcasts/4767/attend OWASP presentation on XSS, client side exploitation, and countermeasures].
| DC
|-
| [[Industry:SAFECode Secure Development Practices (update to Oct 2008 version)|SAFECode Secure Development Practices (update to Oct 2008 version)]]
| 31 Jul 2009
| Standards
| Closed
| Response to [http://www.safecode.org/ SAFECode] "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today."
| CW
|-
| [http://www.owasp.org/index.php/Category:OWASP_CSA_Project OWASP CSA Project]
| 8 Jul 2009
| Standards
| Closed
| Response to RFC [http://www.cloudsecurityalliance.org/guidance/csaguide.pdf Cloud Security Alliance Guidance v1.0]
| TB
|-
| [[Scotland]]
| 25 Jun 2009
| Outreach
| Closed
| Presentation about the Global Industry Committee, its role and recent activities (presentation slides [[Image:Owasp-scotland-industry-committee-june-2009.ppt]] and written notes [[Image:Owasp-scotland-industry-committee-june-2009-notes.pdf]])
| CW
|-
| OWASP Presentation at [http://cfp2009.org/ CFP Con 2009]
| 1 Jun 2009
| Outreach
| Closed
| Deliver presentation on web threats and countermeasures. See [http://www.cfp2009.org/wiki/index.php/Tutorials/Workshops CFP tutorial page] grep OWASP for more info.
| DC
|-
| ENISA [http://www.enisa.europa.eu/pages/02_03_news_2009_02_19_who_is_who.html Who-Is-Who Directory]
| -
| Outreach
| Closed
| Contact ENISA regarding OWASP inclusion in directory (in progress). Encourage European chapter leaders to contact their ENISA liaison officers (completed). Contact UK liaison officer on behalf of London, Leeds and Scotland chapters.
| CW
|-
| IIL [http://www.iilondon.co.uk/ Insurance Institute of London]
| 2 Jun 2009
| Outreach
| Closed
| Contact IIL regarding future input to their publication [http://www.iilondon.co.uk/XtraCart/store/comersus_viewItem.asp?idProduct=187 Insurance Aspects of E-Commerce]
| CW
|-
| [[Industry:Draft NIST SP 800-118|Draft NIST SP 800-118]]
| 29 May 2009
| Standards
| Closed
| Provide response to "Draft NIST Special Publication 800-118 Guide to Enterprise Password Management"
| CW/EK/RB/DC
|-
| German IT Industry Association
| 15 May 2009
| Outreach
| Closed
| Presentation on OWASP
| GH
|-
| [http://docs.google.com/Present?docid=ddkr62qv_171cd7gh5fb&skipauth=true Outreach Presentation to Frontier Airlines]
| 7 May 2009
| Outreach
| Closed
| Provide outreach presentation covering fundamentals of AppSec and Intro to OWASP
| DC
|-
| [[Industry:DPC BS 10012|DPC BS 10012]]
| 31 Mar 2009
| Standards
| Closed
| Provide response to "BS 10012 Specification for the management of personal information in compliance with the Data Protection Act 1998" Draft for Public Comment (DPC)
| CW
|-
| [[Industry:Draft NIST SP 800-53 Revision 3|Draft NIST SP 800-53 Revision 3]]
| 27 Mar 2009
| Standards
| Closed
| Provide response to "Draft NIST Special Publication 800-53 (Revision 3) Recommended Security Controls for Federal Information Systems and Organizations"
| RB
|-
| [[Industry:Draft NIST SP 800-122|Draft NIST SP 800-122]]
| 13 Mar 2009
| Standards
| Closed
| Provide response to "Draft NIST Special Publication 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)"
| CW
|-
| [[London]]
| 12 Mar 2009
| Outreach
| Closed
| Presentation about the Global Industry Committee, its role and recent activities (presentation slides [[Image:Owasp-london-industry-committee-march-2009.ppt]] and written notes [[Image:Owasp-london-industry-committee-march-2009-notes.pdf]])
| CW
|-
| [[Industry:Digital Britain Interim Report|Digital Britain Interim Report]]
| 11 Mar 2009
| Legislation
| Closed
| Provide response to UK Government's "Digital Britain Interim Report Jan 2009"
| CW
|-
| [http://www.owasp.org/index.php/Front_Range_OWASP_Conference_2009 SnowFROC Front Range]
| 5 Mar 2009
| Outreach
| Closed
| Conference organisation
| DC
|-
| US [http://www.commerce.gov/ Department of Commerce]
| 25 Feb 2009
| Outreach
| Closed
| Presentation about OWASP to Economic Security Working Group
| RB
|-
| [[Industry:DPC BS 8878:2009|DPC BS 8878:2009]]
| 31 Jan 2009
| Standards
| Closed
| Provide response to "BS 8878:2009 Web accessibility. Building accessible experiences for disabled people" Draft for Public Comment (DPC)
| Puneet/CW
|-
| AppSec Presentation Delivered to Infragard, Dec 2008
| Dec 2008
| Outreach
| Closed
| [http://www.infragard.net/ Infragard] is a collaboration between the US FBI and maintainers of critical infrastructure. [http://docs.google.com/Present?docid=ddkr62qv_0cn7km4c3&skipauth=true Presentation here]. Email DC for full PPT with speaker notes
| DC
|-
| The Register [http://www.theregister.co.uk/2008/11/22/google_analytics_as_security_risk/ Google Analytics — Yes, it is a security risk]
| Nov 2008
| Outreach
| Closed
| Co-ordination of response and provision of comments from OWASP leaders about risk of JavaScript on Barack Obama's website
| DC
|-
|}

=== General Presentations and Reports ===

[[Summit_2009]]
* Global Industry Committee Presentation [[Image:Owasp-summit2009-industry-committee.ppt]]

Summaries (for inclusion into other full OWASP presentations):
* Sep 2009 [[Image:Owasp-industry-committee-summary-september-2009.ppt]]
* Jul 2009 [[Image:Owasp-industry-committee-summary-july-2009.ppt]]
* May 2009 [[Image:Owasp-industry-committee-summary-may-2009.ppt]]
* Apr 2009 [[Image:Owasp-industry-committee-summary-april-2009.ppt]]
* Mar 2009 [[Image:Owasp-industry-committee-summary-march-2009.ppt]]

Other [http://www.owasp.org/index.php/Global_Committee_Pages Global Committees]

Global Industry Committee

2010-01-04T15:25:08Z

Dan Philpott: /* Completed Items */ Adding NIST SP 800-37r1 FPD Review Project to completed projects list.

'''The Global Industry Committee was created during the OWASP EU Summit in Portugal. The primary purpose of the Global Industry Committee is to work with industry executives to gather requirements from industry, work with Membership, Projects and others.'''

==Mission Statement==

''To expand awareness of and promote the inclusion of software security best practices in Industry, Government, Academia and regulatory agencies and be a voice for industry. We will accomplish this through outreach; including presentations, development of position papers and collaborative efforts with other entities.'' [https://www.owasp.org/index.php/Global_Industry_Committee#General_Presentations_and_Reports Powerpoint of Accomplishments]

==Committee Plan==

Step 1:
[[Industry:Organizations_for_Outreach|Identify specific organizations]] worth working with to spread the OWASP gospel

Step 2:
Prioritize the proposed liasons based on potential impact, and also realistic likelihood of the organization actively working with us

Step 3:
Execute, leveraging global OWASP resources as much as possible to maximize impact

Step 4:
Evaluate progress & repeat Step 1-3

==Committee Members==

Board Member Rep: [mailto:tomb@owasp.org Tom Brennan]

Committee Members:

{| class="prettytable"
! Name
! Email
! Location
|-
| Joe Bernik
|
| US
|-
| Rex Booth
| rex.booth 'at' gt dot com
| US
|-
| David Campbell
| dcampbell 'at' owasp dot org
| US
|-
| Alexander Fry
| alexander.fry 'at' owasp dot org
| US
|-
| Georg Hess
| georg.hess 'at' artofdefence dot com
| Germany
|-
| Eoin Keary
| eoin.keary 'at' owasp dot org
| Ireland
|-
| Yiannis Pavlosoglou
| yiannis 'at' owasp dot org
| UK
|-
| Colin Watson
| colin.watson 'at' owasp dot org
| UK
|-
|}

OWASP Employees:
* Alison
* Kate Hartman

==Getting Involved==

=== Mailing List ===

[http://lists.owasp.org/mailman/listinfo/global_industry_committee Join our mailing list]

=== Meetings ===

The next Global Industry Committee meeting will be:

* TBC (Conference Bridge: 1-866-534-4754)

Host Code: check calendar invite

Guest Code: 192341

Previous meeting minutes are:

* [[Industry:Minutes 2009-01-23|23 Jan 2009]]

=== Membership ===

[[Membership]] explains how to become an OWASP organization supporter or individual member.

You don't have to be an OWASP Member or Committee Member to contribute - the current committee members joined for a 12 month term - see [[How to Join a Committee]] and [[Global Committee Pages]].

=== Other ongoing initiatives ===

* [http://www.owasp.org/index.php/Global_Industry_Committee-SIG Special Interest Groups] - Outreach to sector-specific critical infrastructures worldwide.
* [http://www.owasp.org/index.php/Category:India OWASP India Advisory Board] - Regional panel contributing to the software outsourcing industry.
* [http://www.owasp.org/index.php/Industry:Citations OWASP Citations] - References to OWASP in official, or otherwise important, documents.

==Current Activity==

=== Work in Progress ===

The current activities being undertaken:

{| class="prettytable"
! Task
! Deadline
! Type
! Status
! Description
! Who
|-
| [http://www.enisa.europa.eu/ ENISA] Cloud Computing Common Assurance Metrics
| 2010
| Standards
| New
| Work with [[:Category:OWASP Cloud ‐ 10 Project]] to contribute to the development of Common Assurance Metrics for ENISA's [http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-information-assurance-framework?searchterm=cloud Cloud Computing Information Assurance Framework]. See also the [http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-assessment Cloud Computing Risk Assessment] report.
| CW
|-
| [[Industry:Personal Information Online Code of Practice|Personal Information Online COP]]
| 5 Mar 2010
| Legislation
| In Progress
| Provide response to UK Information Commissioner's Office draft "Personal Information Online Code of Practice"
| CW
|-
| [[:Industry:Draft_NIST_SP_800-37_Revision_1|NIST SP 800-37 Revision 1 FPD]]
| 31 Dec 2009
| Standards
| In Progress
| Provide response to "NIST SP 800-37 Revision 1 Final Public Draft: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach"
| RB
|-
| [http://www.spva.org Secure POS Vendor Alliance (SPVA)]
| -
| Outreach
| In Progress
| Begin dialogue about possibility of working together
| DC
|}

=== Completed Items ===

{| class="prettytable"
! Task
! Completed
! Type
! Status
! Description
! Who
|-
| [[:Industry:Draft_NIST_SP_800-37_Revision_1|NIST SP 800-37 Revision 1 FPD]] Review Project
| 30 Dec 2009
| Standards
| Closed
| Provide response to "NIST SP 800-37 Revision 1 Final Public Draft, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach"
| RB
|-
| [http://www.crest-approved.org/ CREST] CRESTCon
| 15 Dec 2009
| Outreach
| Closed
| Already an oversubscribed event, YP & CW have been placed on the reserve list. Update: Positions secured for the 15th.
| YP
|-
| [http://msdn.microsoft.com/en-us/security/cc448177.aspx SDL Pro Network]
| 30 Nov 2009
| Outreach
| Closed
| Contact SDL Pro Network to discuss if there are opportunities for OWASP to become involved or connected in some way
| CW
|-
| [[Industry:Draft NIST IR 7628|Draft NIST IR 7628]]
| 25 Nov 2009
| Standards
| Closed
| Provide response to "NIST IR 7628 Draft Smart Grid Cyber Security Strategy and Requirements"
| CW
|-
| [http://www.owasp.org/index.php/OWASP_AppSec_DC_2009 Appsec DC 2009]
| 10-13 Nov 2009
| Outreach
| Closed
| Conference organisation - special effort to engage with US Federal sector
| RB
|-
| [http://www.justice.gov.uk/ UK Ministry of Justice]
| -
| Legislation
| Closed
| Ask to be added to official consultation list
| CW
|-
| [http://www.it-sa.de/ IT-SA]
| 13-15 Oct 2009
| Outreach
| Closed
| OWASP booth at trade show
| GH
|-
| [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009]
| 13 Oct 2009
| Outreach
| Closed
| Conference organisation
| GH
|-
| US [http://www.loc.gov Library of Congress]
| 28 Sep 2009
| Outreach
| Closed
| Presentation about OWASP
| RB
|-
| [http://www.owasp.org/index.php/OWASP_Ireland_AppSec_2009_Conference OWASP Ireland AppSec 2009]
| 10 Sep 2009
| Outreach
| Closed
| Conference organisation
| EK
|-
| OWASP Citations
| 7 Sep 2009
| Other
| Closed
| Identify and record the most important references to OWASP in official, or otherwise important, documents. Page created at: [[Industry:Citations]]
| CW
|-
| US [http://www.loc.gov Library of Congress]
| 26 Aug 2009
| Outreach
| Closed
| Presentation about OWASP
| RB
|-
| OWASP webcast at Brighttalk [http://www.brighttalk.com/summit/dataprivacy2 Data and Privacy in Web 2.0 Summit]
| 13 Aug 2009
| Outreach
| Closed
| Deliver [http://www.brighttalk.com/webcasts/4767/attend OWASP presentation on XSS, client side exploitation, and countermeasures].
| DC
|-
| [[Industry:SAFECode Secure Development Practices (update to Oct 2008 version)|SAFECode Secure Development Practices (update to Oct 2008 version)]]
| 31 Jul 2009
| Standards
| Closed
| Response to [http://www.safecode.org/ SAFECode] "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today."
| CW
|-
| [http://www.owasp.org/index.php/Category:OWASP_CSA_Project OWASP CSA Project]
| 8 Jul 2009
| Standards
| Closed
| Response to RFC [http://www.cloudsecurityalliance.org/guidance/csaguide.pdf Cloud Security Alliance Guidance v1.0]
| TB
|-
| [[Scotland]]
| 25 Jun 2009
| Outreach
| Closed
| Presentation about the Global Industry Committee, its role and recent activities (presentation slides [[Image:Owasp-scotland-industry-committee-june-2009.ppt]] and written notes [[Image:Owasp-scotland-industry-committee-june-2009-notes.pdf]])
| CW
|-
| OWASP Presentation at [http://cfp2009.org/ CFP Con 2009]
| 1 Jun 2009
| Outreach
| Closed
| Deliver presentation on web threats and countermeasures. See [http://www.cfp2009.org/wiki/index.php/Tutorials/Workshops CFP tutorial page] grep OWASP for more info.
| DC
|-
| ENISA [http://www.enisa.europa.eu/pages/02_03_news_2009_02_19_who_is_who.html Who-Is-Who Directory]
| -
| Outreach
| Closed
| Contact ENISA regarding OWASP inclusion in directory (in progress). Encourage European chapter leaders to contact their ENISA liaison officers (completed). Contact UK liaison officer on behalf of London, Leeds and Scotland chapters.
| CW
|-
| IIL [http://www.iilondon.co.uk/ Insurance Institute of London]
| 2 Jun 2009
| Outreach
| Closed
| Contact IIL regarding future input to their publication [http://www.iilondon.co.uk/XtraCart/store/comersus_viewItem.asp?idProduct=187 Insurance Aspects of E-Commerce]
| CW
|-
| [[Industry:Draft NIST SP 800-118|Draft NIST SP 800-118]]
| 29 May 2009
| Standards
| Closed
| Provide response to "Draft NIST Special Publication 800-118 Guide to Enterprise Password Management"
| CW/EK/RB/DC
|-
| German IT Industry Association
| 15 May 2009
| Outreach
| Closed
| Presentation on OWASP
| GH
|-
| [http://docs.google.com/Present?docid=ddkr62qv_171cd7gh5fb&skipauth=true Outreach Presentation to Frontier Airlines]
| 7 May 2009
| Outreach
| Closed
| Provide outreach presentation covering fundamentals of AppSec and Intro to OWASP
| DC
|-
| [[Industry:DPC BS 10012|DPC BS 10012]]
| 31 Mar 2009
| Standards
| Closed
| Provide response to "BS 10012 Specification for the management of personal information in compliance with the Data Protection Act 1998" Draft for Public Comment (DPC)
| CW
|-
| [[Industry:Draft NIST SP 800-53 Revision 3|Draft NIST SP 800-53 Revision 3]]
| 27 Mar 2009
| Standards
| Closed
| Provide response to "Draft NIST Special Publication 800-53 (Revision 3) Recommended Security Controls for Federal Information Systems and Organizations"
| RB
|-
| [[Industry:Draft NIST SP 800-122|Draft NIST SP 800-122]]
| 13 Mar 2009
| Standards
| Closed
| Provide response to "Draft NIST Special Publication 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)"
| CW
|-
| [[London]]
| 12 Mar 2009
| Outreach
| Closed
| Presentation about the Global Industry Committee, its role and recent activities (presentation slides [[Image:Owasp-london-industry-committee-march-2009.ppt]] and written notes [[Image:Owasp-london-industry-committee-march-2009-notes.pdf]])
| CW
|-
| [[Industry:Digital Britain Interim Report|Digital Britain Interim Report]]
| 11 Mar 2009
| Legislation
| Closed
| Provide response to UK Government's "Digital Britain Interim Report Jan 2009"
| CW
|-
| [http://www.owasp.org/index.php/Front_Range_OWASP_Conference_2009 SnowFROC Front Range]
| 5 Mar 2009
| Outreach
| Closed
| Conference organisation
| DC
|-
| US [http://www.commerce.gov/ Department of Commerce]
| 25 Feb 2009
| Outreach
| Closed
| Presentation about OWASP to Economic Security Working Group
| RB
|-
| [[Industry:DPC BS 8878:2009|DPC BS 8878:2009]]
| 31 Jan 2009
| Standards
| Closed
| Provide response to "BS 8878:2009 Web accessibility. Building accessible experiences for disabled people" Draft for Public Comment (DPC)
| Puneet/CW
|-
| AppSec Presentation Delivered to Infragard, Dec 2008
| Dec 2008
| Outreach
| Closed
| [http://www.infragard.net/ Infragard] is a collaboration between the US FBI and maintainers of critical infrastructure. [http://docs.google.com/Present?docid=ddkr62qv_0cn7km4c3&skipauth=true Presentation here]. Email DC for full PPT with speaker notes
| DC
|-
| The Register [http://www.theregister.co.uk/2008/11/22/google_analytics_as_security_risk/ Google Analytics — Yes, it is a security risk]
| Nov 2008
| Outreach
| Closed
| Co-ordination of response and provision of comments from OWASP leaders about risk of JavaScript on Barack Obama's website
| DC
|-
|}

=== General Presentations and Reports ===

[[Summit_2009]]
* Global Industry Committee Presentation [[Image:Owasp-summit2009-industry-committee.ppt]]

Summaries (for inclusion into other full OWASP presentations):
* Sep 2009 [[Image:Owasp-industry-committee-summary-september-2009.ppt]]
* Jul 2009 [[Image:Owasp-industry-committee-summary-july-2009.ppt]]
* May 2009 [[Image:Owasp-industry-committee-summary-may-2009.ppt]]
* Apr 2009 [[Image:Owasp-industry-committee-summary-april-2009.ppt]]
* Mar 2009 [[Image:Owasp-industry-committee-summary-march-2009.ppt]]

Other [http://www.owasp.org/index.php/Global_Committee_Pages Global Committees]

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

2009-12-24T21:39:23Z

Dan Philpott:

{| align="right"
| __TOC__
|}

PARTNERSHIPS, OUTSOURCING ARRANGEMENTS, SUPPLY CHAIN EXCHANGES

For Appendix I, my major comment is that it did not seem to have covered issues with outsourced application development, which happens a lot. In this scenario, you could provide the service provider with your security requirements and standards. But you may have to rely on the service provider to choose and implement the security controls. It is probably necessary to conduct a review of the chosen security controls before they are implemented. And eventually, the steps of "assess security controls" and "authorize information systems" would need to be conducted by internal people. Furthermore, security code review need to be conducted if the service provider has development software code that is deemed critical from a security perspective. -William Zhang

== APPENDIX I SECURITY CONTROLS IN EXTERNAL ENVIRONMENTS ==

[https://buildsecurityin.us-cert.gov/swa/downloads/ContractLanguage_ID_DH_090806.pdf Software Assurance in Acquisition and Contract Language] Version 1.1 July 31, 2009.
Integrating software security in the acquisition life cycle promotes the acquisition of secure software. This version includes sample SwA Request for Proposal (RFP)/ Contract language. Buyers and evaluators of software and suppliers can gain security risk-based insight. They can put suppliers on notice that consumers are concerned about software security and the risks to their organizations that are attributable to exploitable software.

[https://buildsecurityin.us-cert.gov/swa/downloads/DueDiligenceMWV12_01AM090909.pdf Software Supply Chain Risk Management and Due Diligence] Version 1.2 June 16, 2009.
Software security enhanced due-diligence is a critical element of software supply chain risk management. Buyers and evaluators of software and services can gain security risk-based insight. They can put suppliers on notice that consumers are concerned about software security and the risks to their organizations that are attributable to exploitable software.

[https://buildsecurityin.us-cert.gov/swa/downloads/SwA_in_Acquisition_102208.pdf Software Assurance in Acquisition: Mitigating Risks to the Enterprise] "... provides information on how to incorporate SwA considerations in key decisions and how to exercise due diligence throughout the acquisition process relative to potential risk exposures that could be introduced by the supply chain."

[http://www.sans.org/appseccontract/ Application Security Procurement Language]. These guidelines incorporate substantial language from the [https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex OWASP Secure Software Contract Annex]. These ... enable buyers of custom software to more explicitly focus on the responsibilities of code writers for checking the code and for fixing security flaws before software is delivered. The sample procurement language ... addresses:

*Personnel, Security Training, Background Checks of Developers, Vulnerabilities, Risks and Threats, and Application Development.
*Development environment: Secure Coding, Configuration Management, Distribution, Disclosure, and Evaluation.
*Testing: test planning, source code reviews, as well as vulnerability and penetration tests.
*Patches and Updates, along with notification and testing of those modifications to the software.
*Tracking Security Issues. - vendor ... “certification package” that establishes the security requirements, design, implementation, and test results were properly completed and all security issues were resolved appropriately. Its provisions include specifying that the developer is to warrant that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code. It offers procurement language for how security issues will be investigated."

See Software Assurance [https://buildsecurityin.us-cert.gov/swa/acqwg.html Acquisition and Outsourcing Working Group].

 --[[User:Walter Houser|Walter Houser]] 23:22, 19 December 2009 (UTC)

[[Category:GIC-NISTSP80037r1FPD]]

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

2009-12-24T20:55:02Z

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

{| align="right"
| __TOC__
|}

<big>APPENDIX F</big>

<big>'''SECURITY AUTHORIZATION'''</big>

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". [[User:Dan Philpott|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. [[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)

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

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-24T20:39:29Z

Dan Philpott: /* Supplemental Guidance */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

:Playing Devil's Advocate here, how can an "appropriate level of trust" be considered to be more of a "known" factor than knowing your degree of assurance? Either measure requires trusting the entity providing the "assurance" to have done their due diligence and thoroughly, at that. Taking this into consideration, the solution doesn't really change anything. - Jack Mannino

::You're right of course, neither is anything like an objective measure. The only difference is that level of trust is a concept woven into FISMA guidance and has guidance available for establishing a subjective 'level of trust' or 'chain of trust'. NIST SP 800-53r3 even includes a control called Trustworthiness (SA-13). I'm not a fan of either of these subjective measures but at least with the level of trust there is some guidance to work with. [[User:Dan Philpott|Dan Philpott]] 20:35, 24 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC)

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

"Organizations may choose to defer common control identification and security control selection until later in the system development life cycle."
While it is stated that organizations can defer identification of common controls and security controls until later in the development life cycle, the guidance does not state whether finite points in the development life cycle exist as to when this activity can be deferred. Recommend consideration of the ramifications of this language, with the inclusion of language mandating when this activity must be performed (example- prior to implementation in a production environment). -Jack Mannino

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

Within this section, there is a great deal of language highlighting the reliance (or over-reliance) on the use of automation to monitor security controls implementation. While automation does indeed permit the average organization to increase the frequency and efficiency of monitoring, automation cannot be fully trusted as a foolproof measure to identifying security deficiencies or non-compliance in any way, shape, or form. Recommend the inclusion of a requirement to identify target areas that cannot be fully automated, and to develop manual processes and the frequencies in which they will be performed, within levels of effort proportionate to an organization's alloted resources. Also recommend that a reference be made to performing gap-analysis to identify areas relevant to an organization that cannot be adequately addressed via automated means, which has the potential to lead to a greater level of accountability as well as more a more holistic overall approach to security. -Jack Mannino

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line: "Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function)." The word 'key' implies that the list of organizational officials the authorizing official can receive input from are limited to those defined in Appendix D/listed as primary or supporting roles. This unnecessarily limits the resources authorizing officials can draw upon to inform their decision. An example of where this would be a problem would be if an authorizing official did not sufficiently understand a technology or policy issue and consulted with anyone outside of the defined list of roles for background information. Limiting this kind of interaction would lower the quality of authorization decisions with a likely outcome of poorer security being implemented. Recommend removal of the word 'key' from the sentence. [[User:Dan Philpott|Dan Philpott]] 04:09, 23 December 2009 (UTC)

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-24T20:39:01Z

Dan Philpott: /* Supplemental Guidance */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

:Playing Devil's Advocate here, how can an "appropriate level of trust" be considered to be more of a "known" factor than knowing your degree of assurance? Either measure requires trusting the entity providing the "assurance" to have done their due diligence and thoroughly, at that. Taking this into consideration, the solution doesn't really change anything. - Jack Mannino

::You're right of course, neither is anything like an objective measure. The only difference is that level of trust is a concept woven into FISMA guidance and has guidance available for establishing a subjective 'level of trust' or 'chain of trust'. NIST SP 800-53r3 even includes a control called Trustworthiness (SA-13). I'm not a fan of either of these subjective measures but at least with the level of trust there is some guidance to work with. [[User:Dan Philpott|Dan Philpott]] 20:35, 24 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC)

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

"Organizations may choose to defer common control identification and security control selection until later in the system development life cycle."
While it is stated that organizations can defer identification of common controls and security controls until later in the development life cycle, the guidance does not state whether finite points in the development life cycle exist as to when this activity can be deferred. Recommend consideration of the ramifications of this language, with the inclusion of language mandating when this activity must be performed (example- prior to implementation in a production environment). -Jack Mannino

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line: "Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function)." The word 'key' implies that the list of organizational officials the authorizing official can receive input from are limited to those defined in Appendix D/listed as primary or supporting roles. This unnecessarily limits the resources authorizing officials can draw upon to inform their decision. An example of where this would be a problem would be if an authorizing official did not sufficiently understand a technology or policy issue and consulted with anyone outside of the defined list of roles for background information. Limiting this kind of interaction would lower the quality of authorization decisions with a likely outcome of poorer security being implemented. Recommend removal of the word 'key' from the sentence. [[User:Dan Philpott|Dan Philpott]] 04:09, 23 December 2009 (UTC)

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-24T20:36:16Z

Dan Philpott: /* APPLICATION OF THE RISK MANAGEMENT FRAMEWORK */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

:Playing Devil's Advocate here, how can an "appropriate level of trust" be considered to be more of a "known" factor than knowing your degree of assurance? Either measure requires trusting the entity providing the "assurance" to have done their due diligence and thoroughly, at that. Taking this into consideration, the solution doesn't really change anything. - Jack Mannino

::You're right of course, neither is anything like an objective measure. The only difference is that level of trust is a concept woven into FISMA guidance and has guidance available for establishing a subjective 'level of trust' or 'chain of trust'. NIST SP 800-53r3 even includes a control called Trustworthiness (SA-13). I'm not a fan of either of these subjective measures but at least with the level of trust there is some guidance to work with. [[User:Dan Philpott|Dan Philpott]] 20:35, 24 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC)

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line: "Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function)." The word 'key' implies that the list of organizational officials the authorizing official can receive input from are limited to those defined in Appendix D/listed as primary or supporting roles. This unnecessarily limits the resources authorizing officials can draw upon to inform their decision. An example of where this would be a problem would be if an authorizing official did not sufficiently understand a technology or policy issue and consulted with anyone outside of the defined list of roles for background information. Limiting this kind of interaction would lower the quality of authorization decisions with a likely outcome of poorer security being implemented. Recommend removal of the word 'key' from the sentence. [[User:Dan Philpott|Dan Philpott]] 04:09, 23 December 2009 (UTC)

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-24T20:35:50Z

Dan Philpott: /* APPLICATION OF THE RISK MANAGEMENT FRAMEWORK */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

:Playing Devil's Advocate here, how can an "appropriate level of trust" be considered to be more of a "known" factor than knowing your degree of assurance? Either measure requires trusting the entity providing the "assurance" to have done their due diligence and thoroughly, at that. Taking this into consideration, the solution doesn't really change anything.
- Jack Mannino

::You're right of course, neither is anything like an objective measure. The only difference is that level of trust is a concept woven into FISMA guidance and has guidance available for establishing a subjective 'level of trust' or 'chain of trust'. NIST SP 800-53r3 even includes a control called Trustworthiness (SA-13). I'm not a fan of either of these subjective measures but at least with the level of trust there is some guidance to work with. [[User:Dan Philpott|Dan Philpott]] 20:35, 24 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC)

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line: "Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function)." The word 'key' implies that the list of organizational officials the authorizing official can receive input from are limited to those defined in Appendix D/listed as primary or supporting roles. This unnecessarily limits the resources authorizing officials can draw upon to inform their decision. An example of where this would be a problem would be if an authorizing official did not sufficiently understand a technology or policy issue and consulted with anyone outside of the defined list of roles for background information. Limiting this kind of interaction would lower the quality of authorization decisions with a likely outcome of poorer security being implemented. Recommend removal of the word 'key' from the sentence. [[User:Dan Philpott|Dan Philpott]] 04:09, 23 December 2009 (UTC)

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-23T04:09:08Z

Dan Philpott: /* Supplemental Guidance */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC)

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line: "Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function)." The word 'key' implies that the list of organizational officials the authorizing official can receive input from are limited to those defined in Appendix D/listed as primary or supporting roles. This unnecessarily limits the resources authorizing officials can draw upon to inform their decision. An example of where this would be a problem would be if an authorizing official did not sufficiently understand a technology or policy issue and consulted with anyone outside of the defined list of roles for background information. Limiting this kind of interaction would lower the quality of authorization decisions with a likely outcome of poorer security being implemented. Recommend removal of the word 'key' from the sentence. [[User:Dan Philpott|Dan Philpott]] 04:09, 23 December 2009 (UTC)

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T04:46:08Z

Dan Philpott: /* Supplemental Guidance */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the lines "Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself. " This is confused and adds little of value beyond the statement that some dynamic subsystems may not be able to complete all registration information. As most dynamic subsystems are likely to be part of better defined systems the inclusion of a description of the issue may not be useful to include here. Recommend providing guidance to organizations that says dynamic subsystems should be registered either as a subset of a better defined complex system or that a method of dynamic registration for dynamic subsystems be implemented which includes as much information as feasible. [[User:Dan Philpott|Dan Philpott]] 04:46, 22 December 2009 (UTC)

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T04:35:57Z

Dan Philpott: /* References */

{| align="right"
| __TOC__
|}

<big>CHAPTER THREE</big>

<big>'''THE PROCESS'''</big>

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS

As an overall comment I find that the blocks of text making up these tasks are too dense and need to be broken up into shorter, more targetted segments. NIST SP 800-53r3 made excellent use of exploding out lists which had previously been embedded in paragraphs (e.g., (i) ..., (ii) ..., etc.). Reading security documents is often difficult for people who feel overwhelmed trying to link the different data elements into a comprehensive picture. Good writing practice and formatting can make reading dense guidance wording easier, much as good writing and formatting can make reading source code easier. [[User:Dan Philpott|Dan Philpott]] 04:10, 8 December 2009 (UTC)

=== APPLICATION OF THE RISK MANAGEMENT FRAMEWORK ===

In the line "Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance." The issue here is the reference to a known degree of assurance. How is the degree of assurance known? Often organizations have no insight into the security operations of a common control provider or information system from which controls are inherited. To state that the degree of assurance is known may not be accurate. At best the degree of assurance can be estimated based on the level of trust one has in the controls provider, but trust is an inherently unmeasurable quality. Recommend restating "common controls can be inherited by information system owners with an appropriate level of trust." [[User:Dan Philpott|Dan Philpott]] 03:28, 22 December 2009 (UTC)

== 3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM ==

=== TASK 1-1 SECURITY CATEGORIZATION ===

==== TASK ====

The task "Categorize the information system and document the results of the security categorization in the security plan." varies the order of activities slightly from the NIST SP 800-18r1 description of the process, "Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems." In general the security categorization is separately documented and then eventually recorded in the security plan. Recommend including in the Supplemental Guidance that recording the categorization does not have to initially be done in the security plan but it should be included in the security plan eventually. [[User:Dan Philpott|Dan Philpott]] 03:42, 22 December 2009 (UTC)

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture." The wording of this line may cause confusion and impose an unnecessary burden on those with primary responsibility for conducting security categorization. The categorization process has organization-wide influences and impacts but for systems is conducted primarily at the system level. It may later be reviewed and adjusted by others but the activity of the categorization is local. By stating it is an organization-wide activity the burden is then to have all those listed with primary responsibility and supporting roles involved in all levels of the activity. Recommend the sentence be changed to "The security categorization process takes potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation as well as organization-wide guidance into consideration including the enterprise architecture and the information security architecture." This would also obviate the need for the final sentence of this Supplemental Guidance. [[User:Dan Philpott|Dan Philpott]] 04:03, 22 December 2009 (UTC)

==== References ====

=== TASK 1-2 INFORMATION SYSTEM DESCRIPTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

Inclusion of the Risk Executive (Function) may be indicated. As grouping of systems in the organizational inventory into an information system is often a function of determining which have related risks the organizational function which coordinates the holistic assessment of risk may play a role. Recommend considering whether the Risk Executive (Function) should be included in the Supporting Roles for Task 1-2. [[User:Dan Philpott|Dan Philpott]] 04:11, 22 December 2009 (UTC)

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

In the line "A typical system description may include, for example:". Use of the word typical in this instance implies that all of the below should be included to be 'typical'. The later modifiers, 'may include' and 'for example' indicate this is not the case. Recommend rephrasing the line to "A system description may include, for example:". [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

In the bullet point, "- Cross domain devices/requirements; " The term 'cross domain' is a term that may not be familiar to many FISMA practitioners and may be a reference to multi-level security. Recommend including an entry for 'Cross Domain' in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

As organizations implement dynamic subsystems it will be more important to include a reference to the data resource that contains all of the system's inventory of subsystems instead of trying to include that highly dynamic data in the information system description itself. Recommend including a bullet point indicating a reference to a real-time inventory of subsystems resource be included in the system description where appropriate. [[User:Dan Philpott|Dan Philpott]] 04:27, 22 December 2009 (UTC)

==== References ====

=== TASK 1-3 INFORMATION SYSTEM REGISTRATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

A reference to NIST SP 800-53 Revision 3 may be worth including here. This task appears related to the Program Management family's PM-5 control (Information System Inventory) in Appendix G. Also, OMB's yearly guidance on FISMA reporting requires an inventory of systems and this is a task directly related to the creation of an inventory of systems. Recommend considering inclusion of these documents as references. [[User:Dan Philpott|Dan Philpott]] 04:35, 22 December 2009 (UTC)

=== Milestone Checkpoint #1 ===

== 3.2 RMF STEP 2 - SELECT SECURITY CONTROLS ==

=== TASK 2-1 SECURITY CONTROL SELECTION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-2 COMMON CONTROL IDENTIFICATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-3 MONITORING STRATEGY ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 2-4 SECURITY PLAN APPROVAL ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #2 ===

== 3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS ==

=== TASK 3-1 SECURITY CONTROL IMPLEMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 3-2 SECURITY CONTROL DOCUMENTATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #3 ===

== 3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS ==

=== TASK 4-1 ASSESSMENT PREPARATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-2 SECURITY CONTROL ASSESSMENT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 4-3 SECURITY ASSESSMENT REPORT ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #4 ===

== 3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM ==

=== TASK 5-1 REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-2 PLAN OF ACTION AND MILESTONES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-3 SECURITY AUTHORIZATION PACKAGE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-4 RISK DETERMINATION ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 5-5 RISK ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #5 ===

== 3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS ==

=== TASK 6-1 INFORMATION SYSTEM AND ENVIRONMENT CHANGES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-2 ONGOING SECURITY CONTROL ASSESSMENTS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-3 ONGOING REMEDIATION ACTIONS ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-4 CRITICAL UPDATES ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-5 SECURITY STATUS REPORTING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-6 ONGOING RISK DETERMINATION AND ACCEPTANCE ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== TASK 6-7 INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING ===

==== TASK ====

==== Primary Responsibility ====

==== Supporting Roles ====

==== System Development Life Cycle Phase ====

==== Supplemental Guidance ====

==== References ====

=== Milestone Checkpoint #6 ===

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T04:27:58Z

Dan Philpott: /* Supplemental Guidance */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T04:11:01Z

Dan Philpott: /* Supporting Roles */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T04:03:08Z

Dan Philpott: /* Supplemental Guidance */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T03:42:22Z

Dan Philpott: /* TASK */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T03:42:00Z

Dan Philpott: /* TASK */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T03:28:20Z

Dan Philpott: /* APPLICATION OF THE RISK MANAGEMENT FRAMEWORK */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

2009-12-22T03:28:01Z

Dan Philpott: /* APPLICATION OF THE RISK MANAGEMENT FRAMEWORK */

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 1

2009-12-16T04:26:33Z

Dan Philpott: /* 1.2 PURPOSE AND APPLICABILITY */

{| align="right"
| __TOC__
|}

<big>CHAPTER ONE</big>

<big>'''INTRODUCTION'''</big>

Lines which reads: "Information systems can include a range of diverse computing platforms from high-end supercomputers to personal digital assistants and cellular telephones. Information systems can also include very specialized systems and devices (e.g., telecommunications systems, industrial/process control systems, testing and calibration devices, weapons systems, command and control systems, and environmental control systems)." The phrasing here doesn't clearly indicate that these are not systems in and of themselves. Given widespread confusion regarding how to determine boundaries every effort should be made to prevent any confusion on this matter. Recommend sentences begin with a phrase like, "Information systems can include as constituent elements ..." [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

: Is it really necessary to spell this out for readers of the document? Shouldn't we expect them to be able to ascertain what we meant from what we said? [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

:: No, assuming that a reader starting at the beginning isn't going to have their understandings colored by a misinterpretation here depends on an expectation that is unlikely to be met. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

== 1.1 BACKGROUND ==

Bullet point which reads: "Promotes the concept of near real-time risk management and ongoing information system authorization through the implementation of robust continuous monitoring processes;". The continuous monitoring described later in this document does not rise to the level of a robust continuous monitoring process which can support real-time risk management. Additional technical detail in support of continuous monitoring for real-time risk management needs to be included to support this concept later in this document. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

Line which reads: "... changes the traditional focus from the stove-pipe, organization-centric, static-based approaches to C&A ..." C&A was previously very system-centric and lacked the organization-centric functions of the new Risk Management Hierarchy. The adjective fest here seems a little out of place. It might be more accurate to describe C&A as a static, procedural activity which provided inadequate guidance to support ongoing risk based decisions. Recommend dropping dramatic flourishes and have a simple statement that RMF moves the process of FISMA compliance away from a procedural, documentation of C&A focus to a process focused on risk management that leads to FISMA compliance. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

== 1.2 PURPOSE AND APPLICABILITY ==

Bullet point which reads: "To ensure that managing risk from the operation and use of federal information systems is consistent with the organization's mission/business objectives and overall risk strategy established by the senior leadership through the risk executive (function);" The concept of mission/business objectives is not well defined in the RMF or SP's 800-30, 800-37 or 800-39. Recommend that as this mission/business objective concept is central to understanding the risk posed from a failure in the security objectives for a system a clear process for establishing the mission/business objectives for an organization in the context of information systems security should be described as part of the risk strategy established by senior leadership. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

Bullet point which reads: "To support consistent, well-informed, and ongoing security authorization decisions (through continuous monitoring), transparency of security and risk-related information, and reciprocity of authorization results; and". The focus on security authorization decision deemphasizes awareness of and acceptance of risk. Speaking to the authorization decision emphasizes the process. Speaking to awareness of and acceptance of risk in consideration of whether to grant a security authorization emphasizes the management of risk. Recommend that as RMF is trying to place the emphasis on risk management and away from the empty process of making a decision this should be reworded to emphasize awareness of and acceptance of risk and relate the authorization decision only as a consequent of this awareness and acceptance. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

== 1.3 TARGET AUDIENCE ==

== 1.4 ORGANIZATION OF THIS SPECIAL PUBLICATION ==

==Footnotes==

A recurring problem with footnotes is that the definitions used here do not match the definitions provided by the glossary. Variation in definitions leads to confusion and the possibility of misinterpretation. The use of a single definition should be standard practice. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 5: An information system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information." Recommend either referring readers to glossary for full definition or using full definition here "Information System [44 U.S.C., Sec. 3502] A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [Note: Information systems also include specialized systems such as industrial/process controls systems, telephone switching and private branch exchange (PBX) systems, and environmental control systems.]" [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 6: A federal information system is defined as an information system used or operated by a federal agency, or by a contractor of a federal agency or by another organization on behalf of a federal agency." This definition varies a great deal from the definition in the glossary. Also, as no other footnoted definition uses 'is defined as' it is not recommended for use here. Recommendation: use definition from glossary as it uses the correct reference to executive agency and is a legal definition: "Federal Information System [40 U.S.C., Sec. 11331] An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency." [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 7: Adverse impacts to the Nation include, for example, compromises to information systems that support critical infrastructure applications or are paramount to government continuity of operations as defined by the Department of Homeland Security." This phrase should be included in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 8: OMB Circular A-130, Appendix III, describes adequate security as security commensurate with risk. This risk includes both the likelihood and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information." The definition should be the same as the A-130 definition as the implication by reference is that this is the A-130 definition.

The glossary definition: "Adequate Security [OMB Circular A-130, Appendix III] Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information."

The A-130 definition: "adequate security" means security commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of information. This includes assuring that systems and applications used by the agency operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost-effective management, personnel, operational, and technical controls. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 9: Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of the likelihood of the circumstance or event occurring and of the resulting adverse impacts." Again the definition varies slightly from the definition in the glossary. This disparity can cause confusion and misinterpretation. The glossary definition also includes a modifying footnote detailing information system-related security risks which is what is intended to be discussed in this footnote. Recommendation is to stick with the glossary definition or come up with a hybrid definition including all the elements described and used both here and in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 10: Security categorization methodologies are described in CNSS Instruction 1253 for national security systems and in FIPS 199 for other than national security systems." Recommend rewording this for clarity, "Security categorization methodologies for national security systems are described in CNSS Instruction 1253. Security categorization methodologies for non-national security systems are described in FIPS 199. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 12: Reciprocity of security authorization results is the mutual agreement among participating organizations to accept each other's security assessments in order to reuse information system resources and/or to accept each other's assessed security posture in order to share information. Reciprocity is best achieved by promoting the concept of transparency (i.e., making sufficient evidence regarding the security state of an information system available, so that an authorizing official from another organization can use that evidence to make credible, risk-based decisions regarding the operation and use of that system or the information it processes, stores, or transmits)." Different term is used in glossary and in this footnote, enterprise and organization respectively. Organization is more accurate but reciprocity is defined in NIST SP 800-53r3 with the enterprise term. Recommend changing the glossary definition to use organization.

Also, the parts of the Defense Security Service Glossary definition for reciprocity might be worth including in the definition as the term will be used in IC. "Recognition and acceptance, without further processing of: (1) security background investigations and clearance eligibility determinations. (2) accreditations of information systems; and (3) facility accreditations. Reciprocity is obligatory in the Intelligence Community when there are no waivers, conditions, or deviations to the Director of National Intelligence." [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 14: A federal information system is an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency." Recommend 'federal information system' should be italicized as it is a defined term. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 16: At the agency level, this position is known as the Senior Agency Information Security Officer. Organizations may also refer to this position as the Chief Information Security Officer." Recommendation: Drop the word "may" from second sentence as it implies NIST is allowing organizations to this. "Organizations also refer" works. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

[[Category:GIC-NISTSP80037r1FPD]]

Talk:Industry:Project Review/NIST SP 800-37r1 FPD Chapter 1

2009-12-16T04:26:08Z

Dan Philpott: Added first run of detailed comments for chapter.

{| align="right"
| __TOC__
|}

<big>CHAPTER ONE</big>

<big>'''INTRODUCTION'''</big>

Lines which reads: "Information systems can include a range of diverse computing platforms from high-end supercomputers to personal digital assistants and cellular telephones. Information systems can also include very specialized systems and devices (e.g., telecommunications systems, industrial/process control systems, testing and calibration devices, weapons systems, command and control systems, and environmental control systems)." The phrasing here doesn't clearly indicate that these are not systems in and of themselves. Given widespread confusion regarding how to determine boundaries every effort should be made to prevent any confusion on this matter. Recommend sentences begin with a phrase like, "Information systems can include as constituent elements ..." [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

: Is it really necessary to spell this out for readers of the document? Shouldn't we expect them to be able to ascertain what we meant from what we said? [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

:: No, assuming that a reader starting at the beginning isn't going to have their understandings colored by a misinterpretation here depends on an expectation that is unlikely to be met. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

== 1.1 BACKGROUND ==

Bullet point which reads: "Promotes the concept of near real-time risk management and ongoing information system authorization through the implementation of robust continuous monitoring processes;". The continuous monitoring described later in this document does not rise to the level of a robust continuous monitoring process which can support real-time risk management. Additional technical detail in support of continuous monitoring for real-time risk management needs to be included to support this concept later in this document. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

Line which reads: "... changes the traditional focus from the stove-pipe, organization-centric, static-based approaches to C&A ..." C&A was previously very system-centric and lacked the organization-centric functions of the new Risk Management Hierarchy. The adjective fest here seems a little out of place. It might be more accurate to describe C&A as a static, procedural activity which provided inadequate guidance to support ongoing risk based decisions. Recommend dropping dramatic flourishes and have a simple statement that RMF moves the process of FISMA compliance away from a procedural, documentation of C&A focus to a process focused on risk management that leads to FISMA compliance. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

== 1.2 PURPOSE AND APPLICABILITY ==

Bullet point which reads: "To ensure that managing risk from the operation and use of federal information systems is consistent with the organization's mission/business objectives and overall risk strategy established by the senior leadership through the risk executive (function);" The concept of mission/business objectives is not well defined in the RMF or SP's 800-30, 800-37 or 800-39. Recommend that as this mission/business objective concept is central to understanding the risk posed from a failure in the security objectives for a system a clear process for establishing the mission/business objectives for an organization in the context of information systems security should be described as part of the risk strategy established by senior leadership. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

Bullet point which reads: "To support consistent, well-informed, and ongoing security authorization decisions (through continuous monitoring), transparency of security and risk-related information, and reciprocity of authorization results; and". The focus on security authorization decision deemphasizes awareness of and acceptance of risk. Speaking to the authorization decision emphasizes the process. Speaking to awareness of and acceptance of risk in consideration of whether to grant a security authorization emphasizes the management of risk. Recommend that as RMF is trying to place the emphasis on risk management and away from the empty process of making a decision this should be reworded to emphasize awareness of and acceptance of risk and relate the authorization decision only as a consequent of this awareness and acceptance.

== 1.3 TARGET AUDIENCE ==

== 1.4 ORGANIZATION OF THIS SPECIAL PUBLICATION ==

==Footnotes==

A recurring problem with footnotes is that the definitions used here do not match the definitions provided by the glossary. Variation in definitions leads to confusion and the possibility of misinterpretation. The use of a single definition should be standard practice. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 5: An information system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information." Recommend either referring readers to glossary for full definition or using full definition here "Information System [44 U.S.C., Sec. 3502] A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [Note: Information systems also include specialized systems such as industrial/process controls systems, telephone switching and private branch exchange (PBX) systems, and environmental control systems.]" [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 6: A federal information system is defined as an information system used or operated by a federal agency, or by a contractor of a federal agency or by another organization on behalf of a federal agency." This definition varies a great deal from the definition in the glossary. Also, as no other footnoted definition uses 'is defined as' it is not recommended for use here. Recommendation: use definition from glossary as it uses the correct reference to executive agency and is a legal definition: "Federal Information System [40 U.S.C., Sec. 11331] An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency." [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 7: Adverse impacts to the Nation include, for example, compromises to information systems that support critical infrastructure applications or are paramount to government continuity of operations as defined by the Department of Homeland Security." This phrase should be included in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 8: OMB Circular A-130, Appendix III, describes adequate security as security commensurate with risk. This risk includes both the likelihood and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information." The definition should be the same as the A-130 definition as the implication by reference is that this is the A-130 definition.

The glossary definition: "Adequate Security [OMB Circular A-130, Appendix III] Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information."

The A-130 definition: "adequate security" means security commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of information. This includes assuring that systems and applications used by the agency operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost-effective management, personnel, operational, and technical controls. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 9: Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of the likelihood of the circumstance or event occurring and of the resulting adverse impacts." Again the definition varies slightly from the definition in the glossary. This disparity can cause confusion and misinterpretation. The glossary definition also includes a modifying footnote detailing information system-related security risks which is what is intended to be discussed in this footnote. Recommendation is to stick with the glossary definition or come up with a hybrid definition including all the elements described and used both here and in the glossary. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 10: Security categorization methodologies are described in CNSS Instruction 1253 for national security systems and in FIPS 199 for other than national security systems." Recommend rewording this for clarity, "Security categorization methodologies for national security systems are described in CNSS Instruction 1253. Security categorization methodologies for non-national security systems are described in FIPS 199. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 12: Reciprocity of security authorization results is the mutual agreement among participating organizations to accept each other's security assessments in order to reuse information system resources and/or to accept each other's assessed security posture in order to share information. Reciprocity is best achieved by promoting the concept of transparency (i.e., making sufficient evidence regarding the security state of an information system available, so that an authorizing official from another organization can use that evidence to make credible, risk-based decisions regarding the operation and use of that system or the information it processes, stores, or transmits)." Different term is used in glossary and in this footnote, enterprise and organization respectively. Organization is more accurate but reciprocity is defined in NIST SP 800-53r3 with the enterprise term. Recommend changing the glossary definition to use organization.

Also, the parts of the Defense Security Service Glossary definition for reciprocity might be worth including in the definition as the term will be used in IC. "Recognition and acceptance, without further processing of: (1) security background investigations and clearance eligibility determinations. (2) accreditations of information systems; and (3) facility accreditations. Reciprocity is obligatory in the Intelligence Community when there are no waivers, conditions, or deviations to the Director of National Intelligence." [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 14: A federal information system is an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency." Recommend 'federal information system' should be italicized as it is a defined term. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

"Footnote 16: At the agency level, this position is known as the Senior Agency Information Security Officer. Organizations may also refer to this position as the Chief Information Security Officer." Recommendation: Drop the word "may" from second sentence as it implies NIST is allowing organizations to this. "Organizations also refer" works. [[User:Dan Philpott|Dan Philpott]] 04:26, 16 December 2009 (UTC)

[[Category:GIC-NISTSP80037r1FPD]]

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

2009-12-16T03:29:48Z

Dan Philpott:

{| align="right"
| __TOC__
|}

<big>APPENDIX I</big>

<big>'''SECURITY CONTROLS IN EXTERNAL ENVIRONMENTS'''</big>

PARTNERSHIPS, OUTSOURCING ARRANGEMENTS, SUPPLY CHAIN EXCHANGES

==Footnotes==

[[Category:GIC-NISTSP80037r1FPD]]

Category:GIC-NISTSP80037r1FPD

2009-12-16T03:28:31Z

Dan Philpott:

{| align="right"
| __TOC__
|}
== Table of Contents ==

*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Front_Matter|FRONT MATTER]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Front_Matter|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Chapter_1|CHAPTER ONE INTRODUCTION]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Chapter_1|Discussion]])
**1.1 BACKGROUND
**1.2 PURPOSE AND APPLICABILITY
**1.3 TARGET AUDIENCE
**1.4 ORGANIZATION OF THIS SPECIAL PUBLICATION
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Chapter_2|CHAPTER TWO THE FUNDAMENTALS]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Chapter_2|Discussion]])
**2.1 INTEGRATED ENTERPRISE-WIDE RISK MANAGEMENT
**2.2 SYSTEM DEVELOPMENT LIFE CYCLE
**2.3 INFORMATION SYSTEM BOUNDARIES
**2.4 SECURITY CONTROL ALLOCATION
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Chapter_3|CHAPTER THREE THE PROCESS]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Chapter_3|Discussion]])
**3.1 RMF STEP 1 – CATEGORIZE INFORMATION SYSTEM
**3.2 RMF STEP 2 – SELECT SECURITY CONTROLS
**3.3 RMF STEP 3 – IMPLEMENT SECURITY CONTROLS
**3.4 RMF STEP 4 – ASSESS SECURITY CONTROLS
**3.5 RMF STEP 5 – AUTHORIZE INFORMATION SYSTEM
**3.6 RMF STEP 6 – MONITOR SECURITY CONTROLS
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_A|APPENDIX A REFERENCES]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_A|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_B|APPENDIX B GLOSSARY]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_B|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_C|APPENDIX C ACRONYMS]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_C|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_D|APPENDIX D ROLES AND RESPONSIBILITIES]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_D|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_E|APPENDIX E SUMMARY OF RMF TASKS]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_E|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_F|APPENDIX F SECURITY AUTHORIZATION]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_F|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_G|APPENDIX G CONTINUOUS MONITORING]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_G|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_H|APPENDIX H OPERATIONAL SCENARIOS]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_H|Discussion]])
*[[Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_I|APPENDIX I SECURITY CONTROLS IN EXTERNAL ENVIRONMENTS]] ([[Talk:Industry:Project_Review/NIST_SP_800-37r1_FPD_Appendix_I|Discussion]])

<center>
== Prologue ==
</center>

<center>"...''Through the process of risk management, leaders must consider risk to U.S. interests from adversaries using cyberspace to their advantage and from our own efforts to employ the global nature of cyberspace to achieve objectives in military, intelligence, and business operations''..."</center>

<center>"...''For operational plans development, the combination of threats, vulnerabilities, and impacts must be evaluated in order to identify important trends and decide where effort should be applied to eliminate or reduce threat capabilities; eliminate or reduce vulnerabilities; and assess, coordinate, and deconflict all cyberspace operations''..."</center>

<center>"...''Leaders at all levels are accountable for ensuring readiness and security to the same degree as in any other domain''..."</center>

-- THE NATIONAL STRATEGY FOR CYBERSPACE OPERATIONS
:OFFICE OF THE CHAIRMAN, JOINT CHIEFS OF STAFF, U.S. DEPARTMENT OF DEFENSE

==Footnotes==
<references />

== Sources ==

* [http://csrc.nist.gov/publications/drafts/800-37-Rev1/SP800-37-rev1-FPD.pdf NIST SP 800-37 Rev. 1 DRAFT Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach]

[[Category:GIC-NISTSP80037r1FPD]]

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

2009-12-16T02:35:47Z