SAP, SAR and PO&M Syntax Diagrams and Mock-Up #617
Comments
|
Updated March 11, 2020. Added "Objectives" section. Moved Controls and Control Objectives from "Assessment Subject" to "Objectives" for SAP and SAR.
|
20-Feb-2020 StatusStill catching up from extended illness. Made some progress on this. Expect to make up time and complete by end of month as originally scheduled. Will post detailed diagrams and mock-ups when I have a little more progress to show. |
27-Feb-2020 StatusNearly finished with diagrams and syntax mock-ups. Expect to be finished this task early next week. (Still a little behind after more than a week of illness.) Providing work-to-date below. |
SAP, SAR, and POA&M Relationship DiagramUpdated March 11, 2020. Added "Objectives" section. Moved Controls and Control Objectives from "Assessment Subject" to "Objectives" for SAP and SAR.
Identification and Summary of Risks in FedRAMP SAR
|
Security Assessment Plan (SAP) Syntax Mock-UpUpdated March 11, 2020 @ 4:30 PM EDT Top Level AssembliesCardinality NotesCardinality is in brackets. Example: [0 or 1 / 1] means the cardinality for OSCAL syntax is 0 or 1; however, FedRAMP the FedRAMP cardinality is exactly 1. MetadataThe following are handled using existing OSCAL Metadata syntax, thus are not re-modeled here: Also Users, Roles, and Locaitons are modeled with standard Metadata syntax. This includes: ImportFor SAP, only the SSP is imported Assessment ObjectivesIn the SAP, this identifies the controls and control objectives to be assessed. All controls in the linked profile (SAP -> SSP -> Profile) may be specified using the Adding to the SAP in this way is equivalent to adding rows in the test case workbook. Assessment SubjectIn the SAP, this dentifies the system elements to be assessed, and which to avoid. This can include system components, inventory items, locations, and users. Assessment Subject has three sub-assemblies:
Assessment Subject sub-assemblies reference content in the SSP. To explicitly identify an item to exclude from testing, use For items not appropriately defined in the SSP, or where the linkage is unclear, the local-definitions assembly can be used to define components, inventory items, and users here. The syntax is identical to the SSP. AssetsIn the SAP, these are the (teams and tools) intended to perform the assessment. If the assessor is conducting scans or penetration test attacks, not only must the tools be provided, but the origination address must be listed below for any scans or attacks intended by the assessor. In order to facililitate a machine-readable Rules of Engagement, or express similar terms, such as disclosures and limitations, the following prop and annotation fields are used. __These are likely to be treated as FedRAMP extensions unless the cybersecurity community believes FedRAMP's ROE elements are more broadly applicable. __ ActivitiesIn the SAP, these are the planned activities, including any planned deviations from the catalog-prescribed TEST, INSPECT, INTERVIEW actions for each in-scope control. As with scope, activities can have two types. To declare off-limit activities from the assessment, such as excluding social engineering, the same activities syntax is used. Related TopicsNotes on the Rules of Engagement (ROE)The ROE can be generated from the above convent as described below; however, in early OSCAL adoption stakeholders are encouraged to accept the ROE as an attached docuemnt that is still produced in MS Word. Even an ROE generated from the above content may still require assessor and system owner signatures, thus even a generated ROE may still need to be attached with cryptographic signatures, or as a scan of a hard-copy signed document. A FedRAMP ROE is generated as follows:
Laws/Regulations/Standards/Guidance (LRSG)The SAP inherits those cited in the SSP, and only includes additional LRSG as needed. |
Security Assessment Report (SAR) Syntax Mock-UpUpdated March 11, 2020 @ 9:10 PM EDT Top Level AssembliesCardinality NotesCardinality is in brackets. Example: [0 or 1 / 1] means the cardinality for OSCAL syntax is 0 or 1; however, FedRAMP the FedRAMP cardinality is exactly 1. MetadataThe following are handled using existing OSCAL Metadata syntax, thus are not re-modeled here: Also Users, Roles, and Locations are modeled with standard Metadata syntax. This includes: ImportFor SAR, only the SAP is imported. Assessment ObjectivesIn the SAR, this identifies the controls that were actually assessed, along with their control objectives. All controls in the linked profile (SAR -> SAP -> SSP -> Profile) may be specified using the Adding to the SAR in this way is equivalent to adding rows in the test case workbook. Assessment SubjectIn the SAR, this dentifies the system elements actually assessed, and which were avoided. This can include system components, inventory items, locations, and users. Assessment Subject has three sub-assemblies:
** NOTE:** In the SAR, See the SAP Syntax Mock-Up for details. NOTE: A tool could duplicate the SAP NOTE: Local definitions in the SAP are addressable via the import-sap link, and should not be duplicated to the SAR. AssetsIn the SAR, these are the (teams and tools) actually involved in the performance of the assessment. ActivitiesIn the SAR, these are the actual activities, including any actual deviations from the SAP. Assessment ResultsIn the SAR, results take on different forms. All of which are represented in this structure and presented as different views. All findings appear as entries in the test case workbook. The assessment team collects evidence in the form of inspections (notes of observations, screen shots, inspection tool output), interview notes, and tests performed (tools, scripts, and manual tests - each intended to observe a result). Evidence can demonstrate that an assessment objective is satisfied. If the evidence demonstrates an objective is not satisfied, risk information becomes relevant. FedRAMP follows NIST in that it assigns qualitative values (High, Moderate, Low) to impact and likelihood, as well as in the calculation of risk (impact x likelihood); however, OSCAL must support compliance frameworks that accept both qualitative and quantitative values. As such, these fields must support both. It may be possible to have both qualitative and quantitative entries for the same risk. Risks discovered during testing have a status of "open". If closed during testing, status may be changed to "closed", only if the closure-actions field explains how the risk was addressed. OJBECTIVE SATISFACTION The With most frameworks, the degree of control satisfaction is based on the degree to which all of its objectives are satisfied. In some cases, a control is only fully satisfied if every objective is fully stisfied. Below that could be pass/fail, scored, or some qualitative assignment. The The NOTE: Link to control-objectives when possible. Only link to an entire control when linking to a control-objective is not possible or not appropriate. NOTE: One control objective per OBSERVATIONS RISK FedRAMP uses likelihood and impact to "calculate" risk exposure, using qualitative values (high, moderate, and low). ** See the OSCAL-based CVSS Scoring Table. NOTES ON RISK FIELDS For calculated risk values, a FedRAMP values are represented as follows: This approach allows risk values from different systems to be present within the same OSCAL file, including both qualitative and quantitative approaches. Related TopicsNotes on documenting SAP deviaitons in the SARThe FedRAMP SAR requires assessors to document deviations from the SAP in the SAR. The SAP is intended for system owners and authorizing officials (AOs) to know in advance whether planned assessment testing is acceptable. For this reason, it is important to know when the actual assessment deviates from the plan. Under OSCAL, the SAP captures the intended objectives, subjects, assets, and activities. The SAR catpures the actual objectives, subjects, assets, and activities using the same OSCAL syntax. This enables automated comparision of the SAP and SAR to identify the differences with no additional effort on the part of the assessor. SSP Implementation Statement DifferentialFor each instances of an assessor finding an SSP implementation statement that does not match the actual observed implementation, this is treated as an Laws/Regulations/Standards/Guidance (LRSG)The SAR inherits those cited in the SSP and SAP, and only includes additional LRSG as needed. EvidenceSAR evidence is attached or embedded within back-matter. This may include interview notes, photos, screen shots, tool output, raw scan results, and other files as needed. |
|
SAP, SAR and POA&M are mapped to mocked-up OSCAL syntax HERE |
Plan of Action and Milestones (POA&M) Syntax Mock-UpUpdated March 12, 2020 @ 9:50 AM EDT Top Level AssembliesCardinality NotesCardinality is in brackets. Example: [0 or 1 / 1] means the cardinality for OSCAL syntax is 0 or 1; however, FedRAMP the FedRAMP cardinality is exactly 1. MetadataThe following are handled using existing OSCAL Metadata syntax, thus are not re-modeled here: Also Users, Roles, and Locaitons are modeled with standard Metadata syntax. This includes: Import and SystemFor POA&M, only the SSP is imported. Rationale: POA&Ms are updated frequently, and shared far more often than an SSP. There are use cases for a POA&M to be imported into a repository that already has information about the system, thus only a unique system identifier (such as the FedRAMP assigned ID) is necessary in the POA&M. OR POA&M EntriesPOA&M Evidence and POA&M Results uses the same syntax as the SAR. Also, see the SAR Syntax Mock-up for details on the Evidence and Results assemblies. |
5-Mar-2020 StatusThis is greater than 90% complete and should be wrapped up in the next few days. Updated SAR "results" assembly significantly. Still waiting on some feedback from senior FedRAMP JAB reviewers and authorization leads. Also need to discuss some issues with NIST. Please view the TCW-RET-POA&M Mapping Spreadsheet to see how the same structure is used for these three key risk tables, plus other sources and tables. |
|
Above syntax mock-up is now 100% draft. It is likely to be tweaked as it gets reviewed and as we begin translating it to metaschema. |
12-Mar-2020 StatusHave refined the diagrams and mock-ups in this issue several times over the past week as I've started modeling this content in OSCAL. Details are covered in Issue #621 (SAP, SAR, and POA&M Metaschema Modeling) |
|
Going forward, diagram updates will be added to Issue #621, so that this issue can be frozen and closed. Updates to the mock-ups in this issue will no longer be made now that the syntax work is nearly complete and under refinement. This issue should be closed, pending final review. |
User Story:
As an OSCAL syntax modeler, I need to understand the groupings and relationships of information necessary to model a security assessment plan (SAP), security assessment report (SAR), and plan of actions and milestones (POA&M), so that I can create preliminary OSCAL syntax for these artifacts.
Goals:
Dependencies:
Issue #588
Acceptance Criteria
The text was updated successfully, but these errors were encountered: