Cloud ISB Subsystem Support

[erikjohnson2]

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

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{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.}

[david-waltermire]

@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]

@david-waltermire-nist - Please note that Erik left FRB around Dec 2021, and might no longer monitor this issue. But one important aspect to note, an issue Erik mentioned several times during our ATARC discussions, is the importance to keep the ISB under one authorization boundary because this is how FedRAMP package is maintained for each CSP and this is how a P-ATO is issued. So, the leveraged authorization concept (authorization to use per RMF v2) cannot be applied in Erik's case because the leveraged system is a system that has its own ATO and a separate/distinct authorization boundary. The mechanism used to provide support for leveraged authorizations could be useful but will have to be implemented/supported as something else for the type of 'subsystems' as the ones described by Erik.

This issue has some overlap with #590

[erikjohnson2]

NONCONFIDENTIAL // EXTERNAL Thanks to both of you for following up on this important yet potentially complicated subject. I haven’t actually left the Federal Reserve yet; I’m just out of the country on personal business. I’ll respond in more detail soon and would definitely welcome some in depth discussion. Regards, Erik Johnson On February 25, 2022 at 1:15:32 AM GMT+1, Michaela Iorga ***@***.***> wrote: NONCONFIDENTIAL // EXTERNAL PLEASE NOTE: This email is not from a Federal Reserve address. Do not click on suspicious links. Do not give out personal or bank information to unknown senders. @david-waltermire-nist<https://github.com/david-waltermire-nist> - Please note that Erik left FRB around Dec 2021, and might no lonfer monitor this issue. But one important aspect to note, an issue Erik mentioned several times during our ATARC discussions, is the importance to keep the ISB under one authorization boundary because this is how FedRAMP package is maintained for each CSP and this is how a P-ATO is issued. So, the leveraged authorization concept (authorization to use per RMF v2) cannot be applied in Erik's case because the leveraged system is a system that has its own ATO and a separate/distinct authorization boundary. The mechanism used to provide support for leveraged authorizations could be useful but will have to be implemented/supported as something else for the type of 'subsystems' as the ones described by Erik. — Reply to this email directly, view it on GitHub<#1024 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVY4KKXG3ATFM4IJGK6F2GLU43CXXANCNFSM5EWOUC4A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[david-waltermire]

@iMichaela Keep in mind that FedRAMP assesses systems as a whole and requires the same for continuous monitoring. Like the ISB, agencies will likely have a more decomposed view of the system as well.

What @erikjohnson2 is identifying are needs that exist for ISBs at the provider level, but also needs that might exist for agencies at the leveraging level. This puts the FedRAMP authorization in the middle. Thus, FedRAMP is looking at the system holistically as the meat of the sandwich, while the bread of the sandwich (i.e. ISB, agency) is looking at the system decomposed. This means we need to come up with an approach that works for the ISB, FedRAMP, and agency use cases as different parts of the sandwich.

A method may be needed that can convey decomposed information through the FedRAMP process to the agency. This has the potential to get complicated quickly, so I want to break this down into more manageable parts to drive the conversation more productively.

I believe a larger conversation needs to happen to work out requirements on OSCAL from the perspective of each stakeholder group. I believe a requirements-driven approach is ideal here, since there can be multiple implementation paths, some of which already exists in OSCAL today. How we approach this can also affect FedRAMP, so we need to understand what the options are.

@erikjohnson2 When you get back in the country, I'd like to setup a call with you to clarify some aspects of your use case. Please PM me on Gitter when you are ready. We can then coordinate a call with you, @iMichaela, and some of the NIST team. Safe travels.

[erikjohnson2]

I am finally back in the US and would love to meet with you to discuss all this further. When are you all available? If you want to try to meet this week I'm fairly open on Thursday (except 11-1:30) and Friday (before 2:300PM). Lots of openings next week too. Just let me know,

I agree with Michaela that leveraged authorizations will probably not be very helpful in addressing the needs of this use case, however they may be applicable to subsystem candidate ISBs, e.g. Office365 leveraging Azure.

I also agree that the constraint of keeping the subsystem-based ISB under one authorization boundary is important (at least for this use case) because this is how FedRAMP boundary is defined and package maintained by each CSP and the PMO.
Some of the key aspects of this use case as I've described it are primarily from the customer (agency) perspective. However I'm seeing a number of CSPs aggregating their FedRAMP services into mega-boundaries (e.g. Palo Alto) and growing them incrementally by adding new individual or sets of component services over time (e.g. as Significant Changes or New Services piggybacked on the FedRAMP annual assessment cycle). I expect this trend will continue on both sides of the SSRM. Therefore I'd suggest that we look at both in formulating an approach.

Thanks again for a great OSCAL workshop BTW.

[erikjohnson2]

NONCONFIDENTIAL // EXTERNAL NONCONFIDENTIAL // EXTERNAL I am back home and would love to meet with you to discuss all this further whenever you’re ready and available. When do you think that might be? I agree with Michaela that leveraged authorizations will probably not be very helpful in addressing the needs of this use case, however they may be applicable to subsystem candidate ISBs, e.g. Office365 leveraging Azure. I also agree that the constraint of keeping the subsystem-based ISB under one authorization boundary is important (at least for this use case) because this is how FedRAMP boundary is defined and package maintained by each CSP and the PMO. Some of the key aspects of this use case as I've described it are primarily from the customer (agency) perspective. However I'm seeing a number of CSPs aggregating their FedRAMP services into mega-boundaries (e.g. Palo Alto) and growing them incrementally by adding new individual or sets of component services over time (e.g. as Significant Changes or New Services piggybacked on the FedRAMP annual assessment cycle). I expect this trend will continue on both sides of the SSRM. Therefore I'd suggest that we look at both in formulating an approach. Thanks again for a great OSCAL workshop BTW. Best regards, Erik Johnson Sr. Enterprise Cloud Security Specialist (CISSP, CCSP, CSA CCSK V4, PMP, ITIL V3, SAFR) National Information Security Assurance (NISA) Office of the Federal Reserve CISO FRB FedRAMP PMO Liaison Phone: 804.697.2543 Mobile: 804-385-0347 Email: ***@***.******@***.***> From: David Waltermire ***@***.***> Sent: Monday, February 28, 2022 5:12 PM To: usnistgov/OSCAL ***@***.***> Cc: Johnson, Erik ***@***.***>; Mention ***@***.***> Subject: [External] Re: [usnistgov/OSCAL] Cloud ISB Subsystem Support (#1024) NONCONFIDENTIAL // EXTERNAL PLEASE NOTE: This email is not from a Federal Reserve address. Do not click on suspicious links. Do not give out personal or bank information to unknown senders. @iMichaela<https://github.com/iMichaela> Keep in mind that FedRAMP assesses systems as a whole and requires the same for continuous monitoring. Like the ISB, agencies will likely have a more decomposed view of the system as well. What @erikjohnson2<https://github.com/erikjohnson2> is identifying are needs that exist for ISBs at the provider level, but also needs that might exist for agencies at the leveraging level. This puts the FedRAMP authorization in the middle. Thus, FedRAMP is looking at the system holistically as the meat of the sandwich, while the bread of the sandwich (i.e. ISB, agency) is looking at the system decomposed. This means we need to come up with an approach that works for the ISB, FedRAMP, and agency use cases as different parts of the sandwich. A method may be needed that can convey decomposed information through the FedRAMP process to the agency. This has the potential to get complicated quickly, so I want to break this down into more manageable parts to drive the conversation more productively. I believe a larger conversation needs to happen to work out requirements on OSCAL from the perspective of each stakeholder group. I believe a requirements-driven approach is ideal here, since there can be multiple implementation paths, some of which already exists in OSCAL today. How we approach this can also affect FedRAMP, so we need to understand what the options are. @erikjohnson2<https://github.com/erikjohnson2> When you get back in the country, I'd like to setup a call with you to clarify some aspects of your use case. Please PM me on Gitter when you are ready. We can then coordinate a call with you, @iMichaela<https://github.com/iMichaela>, and some of the NIST team. Safe travels. — Reply to this email directly, view it on GitHub<#1024 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVY4KKRI3GY2GSL6YV2TQ6DU5PXMXANCNFSM5EWOUC4A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[david-waltermire]

Issue #1190 will be an attempt to develop some concrete examples of how to represent (re)use of select services from a cloud-based system in OSCAL. These examples should provide for more concrete discussion around the specifics of how to do this in OSCAL.

[aj-stein-nist]

Given the questions around core requirements for this issue and existing comments and labels, I will align the status with "DEFINE Research Needed."