david-waltermire
commented
2 years ago @erikjohnson2 There is a lot to unpack here. I think some of this can be handled by existing OSCAL capabilities (i.e., leveraged authorizations, component targeted assessment plans). I am happy to discuss this with you in a higher-bandwidth medium, such as a phone call.
For now, we are currently focusing on features for OSCAL 1.1 (i.e., mapping #87, shared responsibility #722). Once we have most of that work drafted, we can start wading into this.
I'll add this notionally to the OSCAL 1.2 release milestone, although we may need to consider breaking some of this up across multiple subsequent releases.
In the mean time, I am going to work on some slides to break this all down to drive a constructive conversation with the OSCAL community during a future model meeting.
iMichaela
erikjohnson2
aj-stein-nist
User Story:
As an OSCAL user/consumer and Orion workgroup team member, I would like to be able to define and manage cloud subsystems throughout the NIST RMF lifecycle (using OSCAL wherever possible) to be able to define, scope and provide efficient and well-structured lifecycle support for significant portions of cloud ISBs that have different SSP control responses, different POAMs and different SCA test plans and results, and different ConMon regimes for significant parts of the technical scope of the ISB.
Goals:
Develop, implement, communicate and operationalize a cloud subsystem model, starting off with a clearconceptual model, then define the OSCAL implementation in detail and provide guidance on how subsystems should be treated at different steps in the RMF lifecycle. Presumably this would start with some sort of definition and identification of the subsystem to name and scope it and would require the need to be able to subset the components in an ISB into subsystems (add a subsystem attribute to the inventory data model? and define a parent/child relationship between the overall ISB and its constituent subsystems).
· If we follow the model of NIST (V4) CM-8 (5) Information System Component Inventory | No Duplicate Accounting of Components, then we could propose the constraint that any given component can only be in one and only one subsystem. · Then the next step is to delineate which controls are common across all subsystems (we call them boundary level controls) and which ones vary at the subsystem level (sub-system level controls) so that a ‘sub-system security plan` can be developed based on the SSP model. · Once we have a model for sub-system security plans then we can proceed to define a subsystem assessment (and continuous monitoring) model and along with some associated guidance. Subsystem specs from our recent GRC RFI are included below for reference.
Cloud ISB Subsystem Support Requirements There is a need to be able to provide efficient and well-structured lifecycle support for major portions of ISBs that have different SSP control responses, different POAMs and different SCA test plans and results for significant parts of the technical scope of the ISB (i.e. “ISB Subsystems”). Specific examples and related details are as follows:
a. CSP “Megaservices” like Office 365 have several large but significantly different component services (e.g. Teams, SharePoint Online, Exchange Online, Skype). The sheer size of these Megaservices makes them difficult to implement in a single large release, therefore the component services generally have different implementation and authorization schedules. While these services share many common elements and supporting services (e.g. Azure AD for IAM, Azure IaaS, common logging services, etc.), they also have significant differences in key compliance and operational areas, including the following (for example) – key elements of which need to be captured as part of ISB scoping in Step 1: · Different information types that they store and process; · Different user roles and access management procedures, and in some cases they can have different sets of users; · Different architecture and types of information flows (ports, protocols, and external communications partners/endpoints); · Different types of information access controls and methods for encryption at rest; · Different change management cycles and procedures.
b. To properly address such scenarios in automation, a parent/child object relationship capability is need between (overall) ISBs and ISB Subsystems for selected ISBs. The applicable control baseline needs to be partitionable between parent ISB and child Subsystems (or at least support partitioning the different control responses for different component services/subsystem), along with separate (or suitable qualified) lifecycle activities and information such as POAMs and assessment data, as follows: · A significant number of controls (typically technical controls) vary in their implementation (both technically and timing/status) from one component service (subsystem) to the next. As such the system should accommodate differentiated (Subsystem level) control responses and lifecycle activities for these controls; · Controls that are standard (common) across the ISB should therefore be maintained at the ISB (parent) level. These generally include a) those that are CSP-Owned and b) those that are met organizationally (e.g. personnel screening, security awareness training). The latter are generally also those that are independently shared with the CSP.
Acceptance Criteria
{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}