Highlights:
- An IATT is used to permit testing of a system in an operational environment with live data.
- All applicable security controls should be tested and satisfied before testing in an operational environment or with live data except for those that can only be tested in an operational environment.
- The Army has implemented a security controls overlay to streamline the IATT assessment process. The IATT overlay is designed to reduce the amount of time and resources necessary to assess the security state of the system under test. The AO will determine if use of the IATT Overlay is acceptable or unacceptable.
- RMF Steps 1 and 2 (categorization and selection) must be completed prior to initiating the IATT process.
- Documentation must be uploaded to eMASS to reflect the initial/test design. The final design may be different (and thus the revised design will be assessed if an ATO is pursued).
- System details section of eMASS must be accurately completed.
- Hardware list
- Software list
- Authorization boundary diagram
- Data flow diagram (depict how specific data types are transmitted in/out/within the accreditation boundary). This should probably include CAL boundaries as well as ports and protocols.
- System Enterprise and Information Security Architecture that describes how the system is/ will be integrated into the enterprise architecture and information security architecture. This should include enterprise services such as Defense Enterprise Email (DEE) as well as services to be provided by the Cybersecurity Security Service Provider (CSSP).
- Other documentation: rack diagrams, connection diagrams, physical blueprints, process flow diagrams, build guides, or operational guides which fully describe the system and its configuration to an unfamiliar reviewer. These documents may be bundled together in a Functional Architecture.
- A documented test plan must be provided, which includes a test timeline, test purpose, and test scope (locations, networks, connectivity). References include Test and Evaluation Master Plan at DAU and Operational Test and Evaluation (TEMP) Guidebook. Our best business practice is to include a Word document which describes the test purpose, scope, and tests to be performed along with a Microsoft Project file which more clearly defines the test timeline and phases if applicable.
- Third party assessment performed by a SCA-V is not required (but can be done if desired).
- All STIGs (and SRGs) must be applied, assessed, and reviewed. The ISO may follow the sample rate guidance documented in Appendix C of the Security Control Assessor - Validator (SCA-V) Tactics, Techniques, and Procedures (TTP) to keep the STIG review files to a manageable number. Full STIG checklists must be utilized, not just the benchmarks. STIG and SRG assessment results (.ckl) must be provided in the eMASS record.
- The hardware and software vulnerabilities must be assessed and remediated or mitigated after performing a vulnerability scan (ACAS). A copy of the vulnerability scan must be provided in the eMASS record.
- The STIG and vulnerability analysis must identify and describe:
- False positives, false negatives
- Vulnerabilities that cannot be remediated due to operational requirements/technical limitations.
- Vulnerabilities that cannot be remediated due to limitations of the testing environment, test configuration of the system, or testing schedule.
- Specific mitigations in place for vulnerabilities.
- Security controls that have ongoing vulnerabilities mapped to them that have been tailored by the IATT overlay.
- If STIG or ACAS scan results import vulnerabilities that do not map to controls (e.g. controls were remove by the IATT overlay), the ISO must manually add these controls (e.g. tailor).
- The ISO performs a self-assessment and provide appropriate test results for each CCI within each control.
- The ISO must complete the Risk Assessment within the eMASS record by completing the Risk Assessment tab for all non-compliant security controls. eMASS will automatically filter the Risk Assessment tab for controls marked non-compliant. Information on completing the Risk Assessment can be found on the RMF Knowledge Service (RMFKS): https://rmfks.osd.mil/rmf/RMFImplementation/AssessControls/Pages/ResidualRisk.aspx
- The ISO must create a POA&M item in eMASS for all ongoing vulnerabilities (including any that cannot be remediated) as well as vulnerabilities present in the STIG/SRG and ACAS scans that cannot be remediated.
- Vulnerabilities that will be remediated at a later time must include at least one milestone documenting the steps needed for remediation and will be marked as "Ongoing"
- Vulnerabilities that cannot be remediated must have a valid justification and must be marked as "Risk Accepted". When the AO completes the authorization decision, all Risk Accepted POA&M items will be marked as "Approved"
- Vulnerabilities present in the scans that have since been remediated must include a reference to evidence tht hat vulnerability is address (evidence must be uploaded as an artifact) and must be marked as "Completed."
- When the self-assessment is completed, the ISO initiates an Assess and Authorize (A&A) Package Approval Chain (PAC). Scans must be no older than 30 calendar days. The statements below must be included as a comment in the submission:
- "Seeking an IATT for the dates [dates in the test plan]." The ISO may include additional detail about the dates as necessary (for example if the IATT will cover multiple connection periods).
- (If the IATT overlay is used) "The Authorizing Official [or Authorizing Official Designated Representative, whichever is accurate] has approved the use of the IATT overlay [describe approval method]." The intent of this statement is to guide reviewers to the document, package history, or other evidence recording the AO / AODR's approval of the IATT overlay.
- Once the IATT is approved, the ISO must remove the IATT overlay if it has been applied. This will re-add security controls removed by the IATT overlay so that they can be assessed. Security controls that remain in the baseline when the IATT is removed will return to the baseline as Not Applicable. The ISO just add new test results for these controls to mark the Compliant or Not Compliant.
No comments:
Post a Comment