Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cloud ISB Subsystem Support #1024

Open
3 tasks
erikjohnson2 opened this issue Sep 24, 2021 · 8 comments
Open
3 tasks

Cloud ISB Subsystem Support #1024

erikjohnson2 opened this issue Sep 24, 2021 · 8 comments
Labels
Aged A label for issues older than 2023-01-01 enhancement Model Engineering An issue to be discussed during the bi-weekly Model Engineering Meeting Research User Story

Comments

@erikjohnson2
Copy link

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 david-waltermire added the Model Engineering An issue to be discussed during the bi-weekly Model Engineering Meeting label Jan 21, 2022
@david-waltermire david-waltermire self-assigned this Feb 24, 2022
@david-waltermire
Copy link
Contributor

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

@david-waltermire david-waltermire added this to the OSCAL 1.2.0 milestone Feb 24, 2022
@iMichaela
Copy link
Contributor

iMichaela commented Feb 25, 2022 •
edited
Loading

@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
Copy link
Author

erikjohnson2 commented Feb 28, 2022 via email

@david-waltermire
Copy link
Contributor

@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
Copy link
Author

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
Copy link
Author

erikjohnson2 commented Mar 24, 2022 via email

@iMichaela iMichaela mentioned this issue Mar 24, 2022
Open
3 tasks
@david-waltermire
Copy link
Contributor

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 aj-stein-nist removed this from the v1.2.0 milestone Jul 27, 2023
@aj-stein-nist
Copy link
Contributor

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

@Arminta-Jenkins-NIST Arminta-Jenkins-NIST added the Aged A label for issues older than 2023-01-01 label Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Aged A label for issues older than 2023-01-01 enhancement Model Engineering An issue to be discussed during the bi-weekly Model Engineering Meeting Research User Story
Projects
NIST OSCAL Work Board
Status: DEFINE Research Needed
Milestone
No milestone
Development

No branches or pull requests
5 participants
@david-waltermire @iMichaela @erikjohnson2 @aj-stein-nist @Arminta-Jenkins-NIST