Requirement Traceability Matrix Manager
- Have CIA levels selected for the client
- Rebuild the CCI Rater
- Mark CCIs
- Rebuild the Control Rater
Click the Rebuild button any time:
- The Client CIA levels or RMF overlays change
- The Control Rater is rebuilt
- Updates are made to the Control Rater comments, ratings, or review dates
- Technical data is marked or changed
Data will be fully preserved across a rebuild. After a rebuild, you can filter on the updated date range to location items which were recently changed.
The first time you access the RTM Manager, the RTM Settings will be displayed. These settings can be changed later by clicking the Settings button at the top of the RTM. Settings include:
- Include SSP Controls section: If enabled, a section listing every applicable RMF control will be included in the RTM. This may be disabled to remove the controls section from the RTM—any edited rows will still be in the database and will reappear if this sections is enabled again, so no data is lost.
- SSP Controls Traced From: This name will be included in the top-level of the generated RTM, indicating the underlying contractual requirement for needing to fulfill these controls.
- SSP Controls Requirement Description: This comment will be included in the top-level of the generated RTM and typically summarizes the “control traced from” requirement.
- Include benchmarks section: If enabled, a section listing every applicable benchmark check will be included in the RTM. This may be disabled to remove the benchmarks section from the RTM—any edited rows will still be in the database and will reappear if this sections is enabled again, so no data is lost.
- Benchmarks Requirement Traced From: This name will be included in the top-level of the generated RTM, indicating the underlying contractual requirement for needing to fulfill these benchmarks/checks.
- Benchmarks Requirement Description: This comment will be included in the top-level of the generated RTM and typically summarizes the “benchmarks requirement traced from” requirement.
- Benchmarks: Because the RTM will often be needed early in a system’s life cycle, benchmarks to appear can be manually selected. All checks of these benchmarks will be included in the RTM, plus any benchmarks assigned to machines in a client be automatically included.
- Objectives: Automatically generated based on the section of the row.
- Requirement Number: Automatically generated based on the section of the row and the order. Not guaranteed to be stable across rebuilds, but is unique to a particular build.
- Requirement Text: For controls, displays the RMF control text. For benchmarks, displays the check title and vulnerability number.
- Tech Vol Ref: For controls, references NIST 800.53, the control name, and the underlying CCIs. For benchmarks, displays the benchmark ID (what DISA calls the STIG internally) and the vulnerability/STIG check number.
- SOO Paragraph: Ties to the top-level section objective number. I.E., the yellow control requirements section objective or the benchmark requirement objective rows.
- Requirement Owner: Manually assigned by reviewer. Should be a comma-separated list of roles or people who are in charge of meeting this requirement.
- Verification Phase: Manually assigned by reviewer. Should be the phase of the project in which this requirement will be verified as being accomplished/correct.
- Verification Method: Denotes how this requirement will be verified. This is always marked as inspection.
- Verification Artifact: For controls, points to the Security Assessment Report generated by Xylok. For benchmarks, points to the CKL files Xylok can produce based on technical analysis.
- Verification Date: For controls, pulled from the last review date for the corresponding Control Rater row. For benchmarks, pulled from the latest scan date (regardless if that particular scan tied to this check—it’s simply assumed that the existing data is current).
- Comment: For controls, pulls the Control Rater comment. For benchmarks, either notes no findings were identified under this check or lists the first non-compliant comment. The comment chosen is random and simply serves to denote an example of why this row has an issue.
- Traced From: For controls, lists the system’s CIA level. For benchmarks, shows the underlying CCI of this check.
- Requirement Validation Date: Always displayed as the day the RTM was rebuilt.
This report generates the RTM as an Excel spreadsheet for distribution to stakeholders. Click the “Export” button at the top of the page to download.