25. DRAFT - Template_DHA RMF Security Control Plan_Implementation Guidance.xlsx
XLSX spreadsheet 59 KB Posted
- Attached to
- Charleston Consolidated Storage Distribution Center Federal contract opportunity
- Solicitation number
- Not on record
About this file
This Special Notice from the USACE Little Rock District provides details about an upcoming solicitation for an initial outfitting project for the Charleston Consolidated Storage and Distribution Center. The project has an estimated value between $1.5-2 million and will use simplified acquisition procedures under FAR Parts 12 and 13. A request for quote solicitation will be issued and responses are due by September 2nd, 2022. The requirement is set aside for small businesses with a NAICS code of 337127 and size standard of 500 employees. A site visit is scheduled for August 23rd and questions will be accepted through ProjNet until August 25th. Potential award and order dates are January 19th and March 19th, 2023 respectively. The Special Notice informs potential contractors of the forthcoming solicitation and provides preliminary information prior to issuance of the RFQ.
View the file
Other files for this federal contract opportunity
Show all 37
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sample Security Plan
| SAMPLE DHA RMF SECURITY PLAN (SP) |
| SYSTEM INFORMATION |
This is just a template. The SP is generated in eMASS. Comments/guidance appear In red text.
Enter System specific information in eMASS. The ISSM must submit the SP via the eMASS Package Approval Chain (PAC).
| Overview | |||
| System Name (1): | eMASS Tier III Support System | ||
| System Acronym (3): | eMASS Tier III Support System | ||
| System Identification (2): | 1070 [Auto populated with the DHA eMASS unique ID. Each system record has an eMASS ID that is unique to that instance only] | DITPR ID: | Provide Unique System Identifier (typically number or code) used by DHA to uniquely identify the system. If the system is registered in DITPR, the DITPR ID should be used. |
| Version / Release Number (6): | eMASS Tier III Support System | System Type (4): | IS Major Application |
| National Security System: | No [Determined within the System Management System Details tab] | ||
| Authorization Status: | Not Yet Authorized | Authorization Date: | [This field will be automatically blank if the record does not have an active RMF authorization] |
| AO: | N/A [This field is auto-populated with "N/A" under most conditions. If the record has an active Security Plan Approval packagae, this field will display "Package under Review". If approved by the AO, the field will auto-populate with the AO's name (or AO Group)] | Authorization Termination Date: | N/A [Will be automatically "N/A" if not yet authorized] |
| Financial Management System: | No [Populate Yes or No if financial management system] |
| Public Facing Component/Presence: | No [Determined within the System Management - System Details tab] | ||
| Reciprocity System: | Yes | ||
| System Description (18): | [Provide summary of system, function, and use] | ||
| System User Categories (30) | |||
| Contractors: | General users and system administators [Explain as appropriate. If not applicable, enter "N/A"] | Coalition Partners: | N/A [If the question does not apply, then enter N/A rather than leaving the field blank] |
| DoD Personnel: | General users [read access only] and system administrators [upload, modify, write, delete] [Describe access right and privileges per user category for the system] | Fed / State / Local: | N/A |
| Foreign Nationals: | N/A | General Public: | N/A |
| Organization: | N/A | ||
| Ports / Architecture | |||
| PPSM Registry Number (8): | 0x12d3jy [If the PPSM Registry Number is unknown, contact the DHA Ports, Protocols, and Services Team for assistance] | System Authorization Boundary (21): | eMASS Tier III Support System authorization boundary is defined within the "Tier III Support System Authorization Boundary June 2016" artifact. [Ensure that the relevant document is attached to the field and include document name] |
| Hardware / Software / Firmware (22): | The eMASS Tier III Support System is hosted at DISA DECC Montgomery - all hardware is provided by DISA as described in the DHA DISA SLA June 2016 artifact. [Ensure that the relevant document is attached to the field and include name of document] | System Enterprise and Information Security Architecture (23): | eMASS Tier III Support System operating environment is provided by DISA. Tier 1 and 2 support services are provided by DISA under the DHA DISA SLA June 2016. More information is detailed in the "Detailed Architecture Diagram" artifact. [Ensure that the relevant document is attached to the field and include document name] |
| Information Flows / Paths (24): | eMASS Tier III Support System information flows are detailed in the "Detailed Architecture Diagram" artifact. Data flows specify data traffic, ports, and protocols used and method of access. [If applicable, ensure that the relevant documeent is attached to the field and include document name] | Network Connection Rules (25): | Network connection rules are identified within the eMASS Tier III Support System Ports, Protocols, and Services Memo artifact. |
[Ensure that the relevant document is attached to the field and include document name]
| Interconnected Information Systems and Identifiers (26): | The eMASS Tier III Support System does not establish connenction to other systems. [If applicable, identify the interconnected information systems] | ||
| Encryption | |||
| Encryption Techniques (27): | eMASS Tier III Support System utilizes Common Access Card (CAC) credentialing. [Identify the encryption techniques used for information processing, storage, and transmission] | Cryptographic Key Management Information (28): | eMASS Tier III Support System utilizes FIPS 140-2 encrypted algorithms. |
[Identify the cryptographic key management information: NSA approved encryption techniques for all systems processing classified information, or NSA approved for unclassified national security information, or FIPS validated for unclassified information.]
| Location | ||||
| System Location (14): | Single Location [If multiple locations are selected within the Deployment Location table, eMASS will require that the Baseline Location be completed] | Type Authorization: | No [If "Yes" is selected, new fields for Reportable to FISMA and Reportable to ERS will appear in the System Details FISMA section. The Responsible Entities in the Implementation Plan will also become open for manual editing] | |
| Depolyment Location: | VA - Falls Church | |||
| Physical Location (16) | ||||
| Installation or Owning Type Authorization: | N/A | Country: | United States | |
| Street Address: | 7700 Arlington Blvd | State: | Virginia | |
| Building Number: | N/A | City: | Falls Church | |
| APO / FPO: | N/A | Zip Code: | 22040 | |
| FISMA | ||||
| Security Review Completed: | No | |||
| Security Review Date: | If Security Review, insert the date of review. [This field can only be populated if the system record has an existing Authorization. If "Not Yet Authorized", this field remains blank within the Security Plan.] | Contingency Plan Required: | Yes | |
| Contingency Plan Tested: | Yes | Contingency Plan Test Date: | 4-Jun-18 | |
| Incident Response Plan Required: | Yes | Disaster Recovery Plan Required: | Yes | |
| Privacy Threshold Analysis: | Yes | Privacy Threshold Analysis Date: | 17-Apr-17 | |
| Privacy Impact Assessment Required: | No [If "Yes" is selected, eMASS will require the date of the Privacy Impact Assessment and the relevant supporting document to be directly uploaded] | Privacy Impact Assessment Date: | N/A | |
| Privacy Act System of Records Notice Required: | No | |||
| Privacy Impact Assessment Required (31): | No [If "Yes" is selected, eMASS will require the date of the Privacy Impact Assessment and the relevant supporting document to be directly uploaded] | Privacy Act System of Records Notice Required (32): | No | |
| E-authentication Risk Assessment Required (33): | No [If "Yes" is selected, eMASS will requrie the date of the E-authentication Risk Assessment] | Security Review Date (13): | [This field can only be populated if the system record has an existing Authorization. If "Not Yet Authorized", this field remains blank within the Security Plan.] | |
| Business | ||||
| Mission Criticallity (20): | Mission Support (MS) | Governing Mission Area (12): | Business MA (BMA) | |
| DoD Components (7): | DHA | System Life Cycle / Acquisition Phase (5): | Post-Full Rate Production/Deployment Decision (Operations & Support) | |
| Software Category (19): | Government Off-The-Shelf Software (GOTS) | System Ownership / Controlled (29): | DoD Owned and DoD Operated IS and PIT System | |
| Other Information (34): | None | |||
| External Security Services (35) | ||||
| External Security Services: | [Provide the security service name and identify provider. These are security services provided by sources external to the DoD. If not applicable, enter N/A in these fields] | Service Description: | [List all security services provided by external providers, include specific source. Any relevant documents should be uploaded as Artifacts] | |
| Security Requirements Description: | [List all security requriements or reference appropriate artifact] | Risk Determination: | [Is the external provider compliant with federal laws, or is the external service provider under contract to provide a security level commensurate with the system's security categorization] | |
| System Categorization | ||||
| DoD Security Control Set (15): | NIST SP 800-53 Revision 4 | |||
| Applied Information Type(s) |
| System Categorization: | Recommended Categorization from Applied Information Type(s): | ||||||||
| Confidentiality: | Moderate | Confidentiality: | [This field will populate based upon the record's identified Information Types during system registration within eMASS . Based upon the selected types, eMASS will populate a recommended value for each security category. That recommended value will be displayed here and is not open to manual editing.] | ||||||
| Integrity: | High | Integrity: | See above | ||||||
| Availability: | High | Availability: | See above | ||||||
| Impact: | High | ||||||||
| Rationale for Categorization of each security objective decision: | |||||||||
| Rationale For Categorization: [Reference the Security Categorization Memo that should be uploaded as an artifact] | |||||||||
| Overlays (37) | |||||||||
| Applied Overlays: | Privacy [Ensure appropriate Overlays (e.g. Privacy) are applied to the system record] | ||||||||
| RMF POCs, Names, and Contact Information | |||||||||
| RoleTitle | User Name | User Phone | User E-mail | ||||||
| Program Office/ISSM | [Automatically populated based on the Personnel section under System Management. The appropriate system personnel (ISSM/ISSO) should be listed for this role] | [Automatically populated by eMASS based upon selections, If a Group is applied, this section will display "N/A"] | [Automatically populated by eMASS based upon selections. If a Group is applied, this section will be display "N/A".] | ||||||
| SCA Rep | Group(DHA SCA Representatives) [Automatically populated based on the Personnel section under System Management. The "DHA_CA/SCA Representative Group" should be listed for this role] | [Automatically populated by eMASS based upon selections, If a Group is applied, this section will display "N/A"] | [Automatically populated by eMASS based upon selections. If a Group is applied, this section will be display "N/A".] | ||||||
| SCA | Group(DHA Security Control Assessor) [Automatically populated based on the Personnel section under System Management. The "DHA_CA/SCA Group" should be listed for this role] | [Automatically populated by eMASS based upon selections, If a Group is applied, this section will display "N/A"] | [Automatically populated by eMASS based upon selections. If a Group is applied, this section will be display "N/A".] | ||||||
| AO | Group(DHA Authorizing Official) [Automatically populated based on the Personnel section under System Management. The "DHA DAA/AO Group" should be listed in this role] | [Automatically populated by eMASS based upon selections, If a Group is applied, this section will display "N/A"] | [Automatically populated by eMASS based upon selections. If a Group is applied, this section will be display "N/A".] | ||||||
| Validator | [Automatically populated based on the Personnel section under System Management. The appropriate IV&V individuals or Groups should be listed in this role] | [Automatically populated by eMASS based upon selections, If a Group is applied, this section will display "N/A"] | [Automatically populated by eMASS based upon selections. If a Group is applied, this section will be display "N/A".] |
SP General Instructions
| SAMPLE DHA eMASS RMF SECURITY PLAN (SP) | ||
| GENERAL INSTRUCTIONS | SAMPLE DHA eMASS RMF SECURITY PLAN (SP) |
GENERAL INSTRUCTIONS
| Per the DoD RMF Knowledge Service, the RMF Security Plan is "the formal document prepared by the information system owner (ISO) (or common security controls owner for inheritable controls) that provides an overview of the security requirements for the system and describes the security controls in place or planned for meeting those requirements. The SP should include implementation status, responsible entities, resources, and estimated completion dates. The plan also contains, as supporting appendixes or as references, other key security-related documents such as a risk assessment, privacy impact assessment, system interconnection agreements, contingency plan, security configurations, configuration management plan, and incident response plan." | |
| The ISSM must place a comment that the Security Plan has been reviewed by ISSM. The ISSM must submit the SP via the PAC. Please note the following when preparing to submit an RMF Security Plan for approval within eMASS: | |
| 1. Please ensure that the various sections of the SP have adequate responses. The eMASS SP Report pulls data primarily from the Implementation Plan and System Details tabs. | |
| 2. If there are certain fields that are not applicable, please enter "N/A" rather than leaving it blank. | |
| 3. Where available, attach the supporting document and include artifact name/location (where possible, avoid simply stating "see attachment") | 3. Where available, attach the supporting document and include artifact name/location (where possible, avoid simply stating "see attachment") |
| 4. When the Privacy Overlay is applied, all supporting documents must be uploaded as Artifacts. | |
| 5. If the "Public Facing Component/Presence" field within System Details is not answered, eMASS will block all package submissions. | |
| 6. When preparing an RMF Security Plan, load a Security Plan Approval package within the Package tab (but do not submit). eMASS will perform a series of verification checks - if "RMF Implementation Plan is incomplete" warning is displayed, please review fields. | |
| 7. If eMASS warns that the "RMF Implementation Plan is incomplete" but user has verified that all fields have been answered - most likely scenario are incomplete inputs for inherited Controls. Contact the Providing Records to ensure that they have adequately answered all appropriate fields for their inheritable Controls. | |
| 8. Ensure that all appropriate NIST SP 800-60 Information Types are added to the system record. Records can add Information Types via System Management tab, then System Details, then Categorization. | |
| 9. The "Common Control Provider" field for a Control in the Implementation Plan tab will only appear for those Controls that have an Implementation Status of "Inherited" or "Manually Inherited". | |
| 10. The Implementation Status within the Implementation Plan tab, if not manually filled, will be automatically filled by eMASS. For example, if a control is set to “Compliant Official”, the Implementation Status will be automatically set to “Implemented”. | |
| 11. Users can continue to make changes to both the Implementation Plan and System Details tabs even if there is an active Security Plan Approval package under review. Changes will not be included in the package until the Security Plan is approved. | |
| 12. Setting a Control to "Not Applicable" within the Implementation Plan tab does not automatically set the Control itself to a compliance status of N/A. Accordingly, please ensure that the number of N/A Controls in the Implementation Plan corresponds to the number of Controls that have a compliance status of N/A, as displayed within the System Dashboard or Control Summary. | |
| 13. Note that not all Privacy Controls/CCIs are necessarily inherited from the DHA Privacy Office - some of those are the responsibility of the Program Office. | |
| 14. The Implementation Plan in eMASS is applied to the overall Control-level and does not allow for information tailored to the CCI level. Accordingly, it is not possible to enter status information for each individual CCI - rather, a consolidated input must be applied against the overall Control. | |
| For any eMASS-related questions or concerns, especially issues affecting the RMF Security Plan, please contact the DHA eMASS System Administrators (dha.ncr.cyber.mbx.emass-administrators@mail.mil). |
Generated On: &"Arial"&8 31 May 2016 as of 11:09 AM Generated By: SABATINI, RICHARD &"Arial"&8 UnClassified//For Official Use Only Page &"Arial"&8 1 of 2
System Information Instructions
| DHA eMASS SYSTEM DETAILS INSTRUCTIONS |
| Please find below instructions for filling out the System Details page of a system record in eMASS. |
The information within the System Details page will populate the first section of the RMF Security Plan.
| Item # | Field Name | Field Description/Instructions |
| 1 | System Name | Full descriptive name of the system. |
| 2 | System Identification | Auto-populated with the DHA eMASS unique ID. |
| 3 | Acronym | Provide the official acronym of the system. |
| 4 | System Type | Identify the DoD IT type: |
- IS Major Application
- IS Enclave
- Platform IT System If Assess Only is selected in Field #1, the Assess Only sub-types will populate instead here 5 System Life Cycle /Acquisition Phase Identify the current System Acquisition Phase:
- Pre-Milestone A (Material Solution Analysis)
- Post-Milestone A (Technology Development)
- Post-Milestone B (Engeinnering and Manufacturing Development)
- Post-Milestone C (Production and Deployment)
- Post-Full Rate Production/Deployment Decision (Operations and Support)
| 6 | Version/Release Number | List the version or release number for the IT system. |
| 7 | DoD Component | Auto-populated by eMASS. |
| 8 | Ports, Protocols, & Services Management (PPSM) Registry Number: | Identify PPSM registry number IAW DoDI 8551.01 – Ports, Protocols, & Services Management. |
| 9 | Authorization Status | Identify the authorization status of the system.* |
[Check Boxes] Not yet authorized
ATO
IATT
DATO
| 10 | Authorization Date and Signatures | Identifies the date of the current authorization decision (ATO, IATT, DATO). The AO or AODR can review and approve the SP. The explicit acceptance of risk is the responsibility of the AO and cannot be delegated to other officials within the organization. |
| 11 | Authorization Termination Date | Identifies the date that the current authorization (ATO, IATT) will expire. |
12 Governing Mission Area Select from the drop-down list:
Enterprise Information Environment MA (EIEMA) Business MA (BMA) Warfighting MA (WMA) DoD portion of the Intelligence MA (DIMA) 13 Security Review Date List the date of the last annual security review for systems with an ATO or the latest testing date if this is the first time being authorized.*
Example: 1-Apr-2007
| 14 | System Location |
| Location Description [Check Boxes] |
Single Location Multiple Locations (Type Authorization: Yes/No)
For multiple locations, identify if this is a "type authorization" which is used to deploy identical copies of a IS or PIT system in specified environment.
15 DoD Security Control Set Identify what version of NIST SP 800-53 was used for this security authorization package. Please note that the DoD security control set is based on the baseline within CNSSI 1253 and should reflect the same list.
| 16 | Physical Location | Identify the physical location of the system. If the system is deployed in multiple locations, list the home (baseline) record for the system. |
| 17 | Financial Management System | Is the IS a financial management system? Answer Yes or No. |
| 18 | System Description | Provide a narrative description of the system, its function, and uses. Indicate if the system is stand-alone and if it is directly or indirectly connected to the GIG. |
| 19 | Software Category | Identify if the system software is: |
- Commercial off-the-shelf (COTS)
- Government off-the-shelf (GOTS) 20 Mission Criticality Identify the mission criticality of the system: [Check Boxes]
- Mission Critical (MC)
- Mission Essential (ME)
- Mission Support (MS)
| 21 | System Authorization Boundary | Define the system authorizaton boundary. |
| 22 | Hardware/ Software/ Firmware | List the hardware, software, and firmware within the system authorization boundary. |
| 23 | System Enterprise and Information Security Architecture | Provide a brief architectural description of how the system is integrated into the enterprise architecture and information security architecture, including topology. |
| 24 | Information Flows/Paths | Identify the information flows and paths to/from the system (including inputs and outputs). |
| 25 | Network Connection Rules | If possible, provide a link or list the network connection rules for communicating with external systems. |
| 26 | Interconnected Information Systems and Identifiers | Identify the interconnected information systems by their unique identifiers. |
| 27 | Encryption Techniques | Identify the encryption techniques used for information processing, storage, and transmission. |
| 28 | Cryptographic key management information | Identify the cryptographic key management information (e.g. public key infrastructures, certificate authorities, etc..) Examples: PKI, EKMS, KMI. |
| 29 | System Ownership/Controlled | Ownership/operation of the system. Select from the drop down list containing: |
DoD Owned and DoD Operated IS and PIT System DoD Owned and Non-DoD Operated IS and PIT System DoD Controlled/Non-DoD Owned and Operated IS and PIT System DoD-Partnered System 30 System User Categories Description of users and their access right and privileges for the system.
Description of users [Check Box - Check All That Apply] Include access rights and privileges for each checked box.
DoD Personnel Contractors Federal/State/Local Organization Foreign Nationals Coalition Partners General Public
31 Privacy Impact Assessment Required: Indicate whether a privacy impact assessment is required for a new or previously existing IS or PIT System.
Answer Yes or No. If yes, enter in Privacy Impact Assessment Date and upload PIA Artifact 32 Privacy Act System of Records Notice Required: Indicate whether a Privacy Act System of Record Notice is required by DoD 5400.11-R, "Department of Defense Privacy Program" Answer Yes or No.
33 E-Authentication Risk Assessment Required: Indicate whether an E-Authentication Risk Assessment has been performed for the system IAW OMB M-04-04 Answer Yes or No. If yes, enter in E-Authentication Risk Assessment Date.
| 34 | Other Information | |
| Include any additional information that is required by the organization. Security-related information may include, for example, other information that the owning organization may have discerned in the use or assessment of the information system that is not reflected in the authorization package. | ||
| 35 | External Security Services | Provide the security service name and identify the provider. These are security services provided by external sources (e.g. through contracts, interagency agreements, lines of business arrangements, licensing agreements, CNDSP, and / or supply chain arrangements. |
| 35 | Service Description | List all of the security services provided by external providers, include specific source (e.g. through contracts, interagency agreements, lines of business arrangements, licensing agreements, CNDSP, and / or supply chain arrangements.) |
| 35 | Security Requirements Description | Describe how the external services are protected in accordance with the security requirements of the organization. |
| 35 | Risk Determination | Document that the necessary assurances have been obtained stating the risk to organizational operations and assets, individuals, other organizations, and the nation arising from the use of the external services is accessible. Is the external provider compliant with federal laws, or is the external service provider under contract to provide a security level commensurate with the system's security categorization. |
| 36 | Confidentiality/Integrity/Availability | Select appropriate security categorization impact levels and information type.* |
Low Moderate High
| 37 | Overlays | Select the applicable overlay(s) via the radio buttons. The name of the overlay(s) that has added any controls to the list will be automatically updated in the "Overlay(s)" column within the Implementation Status/Security Control Status table. |
| 38 | DITPR ID | Provide Unique System Identifier (typically number or code) used by DHA to uniquely identify the system. If the system is registered in DITPR, the DITPR ID should be used. |
| 39 | National Security System | Check box if the system is a National Security System. |
| 40 | Public Facing Component/Presence | Does the IS have a public facing component and/or presence? |
Answer Yes or No.
| 41 | Reciprocity System | The system is eligible for reciprocity |
| 42 | Contingency Plan Required | Is there a Contingency Plan in place for this system that addresses disruptions in operations? |
Answer Yes or No. If yes, enter in Contingency Plan Test Date.
43 Contingency Plan Tested Has this system’s Contingency Plan been tested within the past year?
Answer Yes or No.
| 44 | Contingency Plan Date | Date of Contingency Plan Testing Example: 1-Apr-2007 |
| 45 | Incident Response Plan Required | Is there an Incident Response Plan in place for this system that addresses disruptions in operations? |
Answer Yes or No.
46 Disaster Recovery Plan Required Is there a Disaster Recovery Plan in place for this system that addresses disruptions in operations?
Answer Yes or No.
| 47 | Privacy Threshold Analysis | Is there a Privacy Threshold Analysis? Answer Yes or No |
| 48 | Privacy Threshold Analysis Date | Enter the date of the Privacy Threshold Analysis |
| 49 | Reportable to FISMA | Indicate whether or not this system should be included in FISMA reports. (Only appears if "Type Authorization" was set to yes) |
| 50 | Reportable to ERS | Indicate whether or not this system data should be pushed to Enterprise Reporting Service (ERS). (Only appears if "Type Authorization" was set to yes) |
Sample Implem. Plan (Type Auth)
| SAMPLE IMPLEMENTATION STATE / SECURITY CONTROL STATUS |
| This is just a template. The Implementation Plan is completed in eMASS. Comments/guidance appear In red text. |
The Implementation Plan entries will populate the second section of the RMF Security Plan.
Security Control # (Common Control Provider) Security Control Name Overlay(s) / Tailored Implementation Description Security Control Designation Estimated Completion Date AC-1 Access Control Policy And Procedures [Field is blank unless the Control is provided by an Overlay] [If a Control is manually added to the system baseline, "Tailored" will appear in this field] Planned Common 15 Aug 2019 [If Control is set to planned, input future completion date (use proposed authorization date)]
| Comments | [If Implementation Status is either 'Implemented' or 'Planned', inputs to this field are not required. If you wish to indicate detailed information pertaining to specific CCIs, use this field. Ensure that the CCI listed here does not appear within in the list of CCIs listed AP Numbers (CCI) field below.] |
| Responsible Entities: | DISA |
[The Responsible Entities in the Implementation Plan is only open for manual editing if "Type Authorization" is set to "Yes". Otherwise, eMASS auto-populates the Responsible Entities field based upon the Personnel assignments to the Control Approval Chain roles.]
| AP Numbers(CCI): | [This section is automatically populated by eMASS and simply displays the various CCIs allocated within each Control.] AC-1.1(002107), AC-1.2(002108), AC-1.3(000001), AC-1.4(000002), AC-1.5(000004), AC-1.6(000005), AC-1.7(000003), AC-1.8(001545), AC-1.9(000006), AC-1.10(001546) |
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |
| Criticality | CRWG White Criticality Control |
| Frequency | Quarterly |
| Method | Manual |
| Reporting | via telephone, or email, the system-level ISSM resolves the situation in due course, keeping the cybersecurity chain advised via e-mail or normal tracking tools (e.g., eMASS); the AO is contacted for an authorization/connection decision only if the risk cannot be reduced back to the accepted level in a reasonable time |
| Tracking | POAM |
| Comments | Attributes for Criticality, Frequency, Method, Reporting, and Tracking are selected per guidance from DoD Guide for Developing a System-Level Continuous Monitoring Strategy and the DHA System-Level Continuous Monitoring of Security Controls Guide |
| AC-2 | Account Management | Not Applicable | System-Specific | [If Control is N/A, no date is required] | |
| N/A Justification | This Control is outside the eMASS Tier III Support System boundary [Controls set to N/A should have appropriate justifications] | ||||
| Comments | N/A [If Control is N/A, enter "N/A" into Comments field] | ||||
| Responsible Entities: | N/A |
[If Control is N/A, enter "N/A"]
| AP Numbers(CCI): | AC-2.1(002110), AC-2.2(002111), AC-2.3(002112), AC-2.4(000008), AC-2.5(002113), AC-2.6(002115), AC-2.7(002116), AC-2.8(002117), AC-2.9(002118), AC-2.10(002119), AC-2.11(000010), AC-2.12(002120), AC-2.13(000011), AC-2.14(002121), AC-2.15(002122), AC-2.16(002123), AC-2.17(002124), AC-2.18(002125), AC-2.19(002126), AC-2.20(002127), AC-2.21(002128), AC-2.22(000012), AC-2.23(001547), AC-2.24(002129) |
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |
| Criticality | CRWG Yellow Criticality Control |
| Frequency | Annually |
| Method | Manual |
| Reporting | via telephone or e-mail, the system-level ISSM reports to the cybersecurity chain of command, and after appropriate (but not prolonged) investigation into the severity/urgency of the situation, the AO is advised and provided an authorization/connection decision recommendation |
| Tracking | POAM |
| Comments | Attributes for Criticality, Frequency, Method, Reporting, and Tracking are selected per guidance from DoD Guide for Developing a System-Level Continuous Monitoring Strategy and the DHA System-Level Continuous Monitoring of Security Controls Guide |
| AC-2(2) [eMASS will continue to display Common Control Provider inputs here if the Control is changed away from "Inherited" or "Manually Inherited". To prevent the CCP input from appearing, revert back to Inherited/Manually Inherited and set the CCP field to blank. Then change Implementation Status and click "Save".] | Removal Of Temporary / Emergency Accounts | Implemented [note that if any of the associated CCIs are non-compliant, the Control should be marked as "planned"] | Hybrid | 10/10/2018 [If status of Implemented, Control should have past completion date] | |
| Comments | |||||
| Responsible Entities: | DISA and eMASS Tier III Support System (instead of system, can also note specific Program Office) |
[Hybrid Controls should have at least two Responsible Entities listed]
| AP Numbers(CCI): | AC-2(2).1(000016), AC-2(2).2(001361), AC-2(2).3(001365), AC-2(2).4(001682) |
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |
| Criticality | CRWG White Criticality Control. |
| Frequency | Monthly |
| Method | Semi-Automated |
| Reporting | Managing and reporting of security controls is performed by the Program Office and documented in eMASS. |
Tracking All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS.
Comments System undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS.
| AC-4 (Inherited, Enclave) | |||||
| [if "inherited" or "Manually Inherited" are selected for Implemenation Status, the "Common Control Provider" field inputs will appear here] | Information Flow Enforcement | +Privacy | Manually Inherited | Common | 06 Jun 2016 |
| Comments | [For any Control marked as "manually inherited", ensure that a corresponding service level agreement (SLA) is uploaded as an artifact] | ||||
| Responsible Entities: | DISA | ||||
| AP Numbers(CCI): | AC-4.1(001368), AC-4.2(001414), AC-4.3(001548), AC-4.4(001549), AC-4.5(001550), AC-4.6(001551) | ||||
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |||||
| Criticality | CRWG Yellow Criticality Control. |
| Frequency | Monthly |
| Method | Semi-Automated |
| Reporting | Managing and reporting of security controls is performed by the Program Office and documented in eMASS. |
Tracking All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS.
Comments System undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS.
| CM-6 | ||||
| Configuration Settings | Not Implemented - Non Compliant security control that is not planned to be implemented. | Hybrid | Input Authorization Termination Date if applicable. If ATD is not established, add 3 years to the CSTAR timeline ATO completion date. | |
| Comments | Non-Compliant security control that is not planned to be implemented. A POA&M Item asking for Risk Acceptance must be submitted for AO Approval. Example: All system servers run Linux, which is not typically configured with anit-virus due to performance issues. Virus scanning software is installed which uses signatures to search for presence of viruses on the filesystem. Request Risk acceptance of finding | |||
| Responsible Entities: | DoD, Program Office, and eMASS Tier III support system | |||
| AP Numbers(CCI): | CM-6.1(000363), CM-6.2(000364), CM-6.3(000365), CM-6.4(001588), CM-6.5(000366), CM-6.6(000367), CM-6.7(000368), CM-6.8(000369), CM-6.9(001755), CM-6.10(001756), CM-6.11(001502), CM-6.12(001503) | |||
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | ||||
| Criticality | CRWG Yellow Criticality Control. Type Authorization system. | |||
| Frequency | Monthly | |||
| Method | Semi-Automated | |||
| Reporting | Managing and reporting of security controls is performed by the Program Office are documented in eMASS. | |||
| Tracking | All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS. | |||
| Comments | System undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS. |
| AU-3 | ||||
| Content Of Audit Records | +Privacy | Compensated | Hybrid | If control is compensated, the date should have the compensating implementation date |
| Comments | The compensating control ID must be listed (ie AU-3(1)) within the compensated control's comments field. |
Within the compensated control's comments field, a detailed statement must explain how the compensating control ID fulfills the requirements of the compensated control.
ALSO list the compensated control ID within the compensating control's comments field for traceability Example: The information system has implemented AU-3(1) as a compensating control. Information system includes full text recording of privileged commands and identifies the individual identities of group account users. The information system limits the additional audit information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails/logs by not including information that could make it more difficult to locate information of interest.
NOTE: Compensating Controls can come from any control family that will satisfy the security requirements
| Responsible Entities: | Program Office and eMASS Tier III Support System |
| AP Numbers(CCI): | AU-3.1(000130), AU-3.2(000131), AU-3.3(000132), AU-3.4(000133), AU-3.5(000134), AU-3.6(001487) |
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |
| Criticality | CRWG White Criticality Control. . MHSG2 is a Type Authorization system. |
| Frequency | Monthly |
| Method | Semi-Automated |
| Reporting | Managing and reporting of security controls is performed by the Program Office and LPDH and documented in eMASS. |
| Tracking | All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS. |
| Comments | MHSG2 undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS. |
Sample Implem. Plan (Non-Type)
| SAMPLE IMPLEMENTATION STATE / SECURITY CONTROL STATUS | |||||
| The Responsible Entities in the Implementation Plan is only open for manual editing if "Type Authorization" is set to "Yes". For non-Type Authorization records, eMASS auto-populates the Responsible Entities field based upon the Personnel assignments to the Control Approval Chain roles. | |||||
| Security Control Name | Overlay(s) / Tailored | Implementation Description | Security Control Designation | Estimated Completion |
Date AC-1 Access Control Policy And Procedures +Privacy Planned Common 15 Aug 2016
| Comments | |
| Responsible Entities: | Program Office:SMITH,JOHN(john.a.smith.ctr@mail.mil - 123456789), Validator:DOE,JANE(jane.a.doe.ctr@mil.mil - 987654321) |
[This will be auto-populated for non-Type Authorization records based upon Personnel assignments in the Control Approval Chain.]
| AP Numbers(CCI): | [This section is automatically populated by eMASS and simply displays the various CCIs allocated within each Control.] AC-1.1(002107), AC-1.2(002108), AC-1.3(000001), AC-1.4(000002), AC-1.5(000004), AC-1.6(000005), AC-1.7(000003), AC-1.8(001545), AC-1.9(000006), AC-1.10(001546) |
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |
| Criticality | CRWG White Criticality Control. |
| Frequency | Monthly |
| Method | Semi-Automated |
| Reporting | Managing and reporting of security controls is performed by the Program Office and documented in eMASS. |
Tracking All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS.
Comments System undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS.
| AC-2 | Account Management | +Tailored | Planned | Common | 15 Aug 2016 |
| Comments | |||||
| Responsible Entities: | Program Office:SMITH,JOHN(john.a.smith.ctr@mail.mil - 123456789), Validator:DOE,JANE(jane.a.doe.ctr@mil.mil - 987654321) | ||||
| AP Numbers(CCI): | AC-2.1(002110), AC-2.2(002111), AC-2.3(002112), AC-2.4(000008), AC-2.5(002113), AC-2.6(002115), AC-2.7(002116), AC-2.8(002117), AC-2.9(002118), AC-2.10(002119), AC-2.11(000010), AC-2.12(002120), AC-2.13(000011), AC-2.14(002121), AC-2.15(002122), AC-2.16(002123), AC-2.17(002124), AC-2.18(002125), AC-2.19(002126), AC-2.20(002127), AC-2.21(002128), AC-2.22(000012), AC-2.23(001547), AC-2.24(002129) | ||||
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |||||
| Criticality | CRWG Yellow Criticality Control. |
| Frequency | Monthly |
| Method | Semi-Automated |
| Reporting | Managing and reporting of security controls is performed by the Program Office and documented in eMASS. |
Tracking All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS.
Comments System undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS.
| SI-16 | Memory Protection | Manually Inherited | Common | 06 Jun 2016 | |
| Comments | [For any Control marked as "manually inherited", ensure that a corresponding service level agreement (SLA) is uploaded as an artifact] | ||||
| Responsible Entities: | Program Office:SMITH,JOHN(john.a.smith.ctr@mail.mil - 123456789), Validator:DOE,JANE(jane.a.doe.ctr@mil.mil - 987654321) | ||||
| AP Numbers(CCI): | SI-16.1(002823), SI-16.2(002824) | ||||
| CONTINUOUS MONITORING STRATEGY [Use DHA System-Level Continuous Monitoring of Security Controls Plan to complete] | |||||
| Criticality | CRWG Yellow Criticality Control. | ||||
| Frequency | Monthly | ||||
| Method | Semi-Automated | ||||
| Reporting | Managing and reporting of security controls is performed by the Program Office and documented in eMASS. | ||||
| Tracking | All non-compliant controls are managed through the use of POA&Ms. All artifacts and evidences are submitted to the validators for approval before marking the controls compliant on eMASS. | ||||
| Comments | System undergoes a monthly scan using ACAS. The scan results are uploaded into the Asset Manager module in eMASS. All non-compliant controls and their associated POA&Ms are managed and tracked through eMASS. |
Document History Document Revision and History Page
DOCUMENT VERSION # REVISION DATE DESCRIPTION OF CHANGE SECTION/ PARAGRAPH PAGE
| 1.0.0 | Jul-16 | Original Release | - | - |
| 1.1 | Sep-16 | Minor updates to better capture eMASS automatic data population nuances for the Implementation Plan. | Sample Imp. Plan types | |
| 1.2 | Jan-17 | Updates across all sections to align with RMF Knowledge Service (KS) guidance. | All | |
| 1.3 | 21-Feb | Updated to reflect language change from "Externally Inherited" to "Manually Inherited". Also removed date requirement for N/A Controls. | Sample Imp. Plan types | |
| 2 | April 19 2019 | Updated to reflect eMASS version 5.6.2 | Sample Security Plan, Instructions, Examples | |
| 2.1 | 24-Mar-20 | Included examples for Not Implemented and Compensated | Sample Security Plan Examples |
File details come from the government source that posted it. Updated .