RFC-0016 Collaborative Continuous Monitoring Standard #87
Replies: 11 comments 5 replies
-
Please NoteThis thread is for formal, public comment only; commenters may respond to each others comments, however FedRAMP's participation in this thread is limited and general Q&A and casual discussion intermixed in formal public comment creates complications. The primary purpose of public comment is for FedRAMP to receive information and opinions by giving "interested persons an opportunity to participate in the rule making through submission of written data, views, or arguments" (per the Administrative Procedures Act). Please do not ask questions in public comment unless the question is your commentFedRAMP is not able to respond to questions in public comments and they are the most difficult form of public comment to consider because the commenter's view, argument, or opinion can only be inferred. In most cases, FedRAMP is forced to interpret questions as simply a single opinion that FedRAMP should provide an answer to the question in final guidance or directives. For casual discussion about this RFC prior, during, or after public comment, please use this thread in the General RFC Discussion category: Q&A and Casual Discussion on Phase Two RFCs |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the opportunity to weigh in on RFC-0016, Collaborative Continuous Monitoring Standard. Wiz is supportive of a unified approach to AO visibility and updates, and particularly supports FRR-CCM-AG-06 and FRR-CCM-AG-07. Regarding FRR-CCM-AG-04, Wiz would recommend agencies have a firm obligation to share “significant concerns” that may lead the agency to remove the cloud service offering from operation with the provider directly. This will ensure vendors have the opportunity to address any concerns directly–as well as improve the product or resolve misunderstandings regarding security posture. For these reasons, we recommend replacing “SHOULD” with “MUST” in this clause. FRR-CCM-AG-05 outlines that agencies must notify FedRAMP if information disclosed causes significant concerns that may lead the agency to stop operation of the cloud service offering. It also notes this is derived from OMB policy requiring agencies under OMB Memorandum M-24-15 section IV (a). This suggests FedRAMP could potentially use this process to manage or adjudicate concerns regarding existing authorizations. Wiz would endorse FedRAMP’s involvement in such discussions about the security posture of FedRAMP authorized offerings. As part of that involvement, we would recommend FedRAMP commit to sharing and maintaining a public, transparent process for agencies and cloud service offerings that provides clarity on how these concerns may be adjudicated. This process can be dynamic and change over time without specific policy requirements, but establishing a transparent process for managing agency concerns around authorizations should be an expectation of the process. Finally, Wiz would strongly recommend revisions to FRR-CMM-QR-06, FRR-CMM-QR-07, FRR-CMM-QR-08, and FRR-CMM-QR-09. These clauses, taken together, create a significant predicament for Providers. Most FedRAMP authorized offerings are leveraged by private sector and public sector entities. Providers are expected to “record or transcribe Quarterly Reviews and make such available to all necessary parties with other authorization data” per FRR-CMM-09, but are not expected to "disclose feedback or questions from agencies during a Quarterly Review” per FRR-CMM-QR-08. This effectively creates a requirement where Providers would effectively need choose between: (1) maintaining separate quarterly reviews and documentation for varying agencies and private sector users; or (2) reading a legal statement at the beginning that everything on the call will be disclosed and recorded. Both of these seem to be at odds with the spirit of FedRAMP 20x. Instead, Wiz would recommend that Providers should identify mechanisms to prepare commenters appropriately so they may submit anonymous or named concerns to the Provider in advance of the session, during it, or following it. Whatever FedRAMP ultimately decides, it ideally endorses an approach that supports the security awareness of all users and limits bureaucratic hurdles to sharing risk concerns among providers and users. |
Beta Was this translation helpful? Give feedback.
-
|
My comments: |
Beta Was this translation helpful? Give feedback.
-
|
For public clarification, ADS is the Authorization Data Standard and FRR-ADS-01 refers to the first rule in that standard. The standard proposed in RFC-0016 is intended to align with all other FedRAMP 20x standards and will make the most sense in that context (for example, the 20x Vulnerability Detection and Response Standard eliminates the concept of deviation requests). |
Beta Was this translation helpful? Give feedback.
-
This requirement should apply to all cloud systems, not just those with a High Security Category. Each agency should have an information security official reviewing information systems at all levels. The decision to attend quarterly reviews should be based on the official's assessment of the Ongoing Authorization Report and the agency's internal processes. While the use of "SHOULD" provides flexibility, the phrasing could be improved to better reflect operational realities. Suggested edit
The transition from monthly to quarterly meetings is a welcome improvement that will enhance the value of FedRAMP ConMon meetings. The current monthly cadence has become repetitive, with most sessions covering the same topics without meaningful progression or actionable outcomes. A quarterly schedule will allow sufficient time for substantive developments between meetings, enable more focused discussions, and better align with the natural cadence of assessment and authorization activities, ultimately providing greater value to all stakeholders.
FRR-CCM-AG-06 & FRR-CCM-AG-07 are both great and this should cut down on random one-off requests that don’t add value and go against FedRAMP processes. Having to notify FedRAMP of these requests will also give signal to the FedRAMP PMO if the standards need to be updated to better the process for all agencies and CSPs. I might suggest updating “head of agency” to “Agency CIO” |
Beta Was this translation helpful? Give feedback.
-
I recommend that SHOULD be updated to MUST. Without this, the agency has no obligation to share signifigant concerns with the provider. |
Beta Was this translation helpful? Give feedback.
-
|
My understanding is that this can/should be documented as part of the contract with the agency and CSP. FedRAMP is using SHOULD here as it needs to cover every use case, but contractual documents can stipulate more specific terms. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received from Rubrik via email:
|
Beta Was this translation helpful? Give feedback.
-
20x authorizations do not require an agency sponsor and the FedRAMP PMO ultimately issues the FedRAMP authorization. As the authorizing entity, will the FedRAMP PMO have any involvement in continuous monitoring post-authorization? The PMO should consider clarifying their role / level of involvement post-authorization for 20x FedRAMP authorizations.
This may pose challenges as the standard does not define acceptable types of machine-readable authorization data. Further, it's not clear how authorization data would be filtered for criticality. If a system is authorized at Moderate, how would a CSP distinguish between Moderate and Low authorization data? Who would make the determination on criticality? In addition, how would they know what each agency with an ATO file would consider to be critical based on their unique use case? The PMO should consider defining a standard for machine-readable authorization data. Further, the PMO should consider clarifying who makes a determination on the criticality of authorization data, how is that criticality determined, and provide additional information on whether agency's will have any input based on their mission / unique use case.
If the FedRAMP PMO issues the FedRAMP authorization for 20x authorizations, would they also accept weaknesses (as noted in this standard)? Or would every agency with an ATO on file need to accept a weakness? The PMO should consider clarifying how a weakness would be accepted for a 20x authorization given that there is no agency partner.
It's not clear what would occur if a CSP failed to make an Ongoing Authorization Report available in accordance with the standard. The PMO should consider clarifying what agencies should do in the event that an Ongoing Authorization Report was not made available in accordance with the standard. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received from Salesforce via email: Section: FRR-CCM-02 Text: Providers SHOULD establish a regular 3 month cycle for Ongoing Authorization Reports that does not align with calendar quarters so that reports are spread out during the calendar quarter for agencies. Comment: Proposing that the dates are more strictly defined, such as a certain month window for all Low providers, then the next for Moderate, then the next for High (e.g. any time in January for Low, then any time in February for Moderate, then any time in March for High, then any time in April for Low, etc.) Section: FRR-CCM-04 Text: Providers MUST establish and share an asynchronous mechanism for all necessary parties to provide feedback or ask questions related to each Ongoing Authorization Report; all such feedback and questions from agencies, along with responses from the provider, MUST be available to FedRAMP Comment: We would like clarity on the communications that "MUST be available to FedRAMP" - is the expectation that all comms have FedRAMP cc'ed on them (e.g. for email), or that all comms during a certain time period can be provided, upon request, to FedRAMP? We propose that it is the latter - that we can provide all comms requested to FedRAMP as needed. Section: FRR-CCM-QR-01 Text: Providers SHOULD host a synchronous Quarterly Review every 3 months, open to all necessary parties, to review aspects of the most recent Ongoing Authorization Report that the provider determines are of the most relevance to agencies. Comment: Proposing that this is moved to MUST rather than SHOULD for systems at the Moderate and High levels. Section: FRR-CCM-QR-02 Text: Providers SHOULD regularly schedule Quarterly Reviews to occur at least 3 business days after releasing an Ongoing Authorization Report AND within 2 weeks of such release. Comment: Proposing this reads as "...within 10 business days..." for consistency. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comments have been submitted via the public google comment form:
|
Beta Was this translation helpful? Give feedback.
-
|
Below Gaps and corresponding recommendations:
|
Beta Was this translation helpful? Give feedback.
-
|
For public awareness, the Documentation Guidelines sections of this RFC explains that "FedRAMP-specific terms defined in FRD-ALL (FedRAMP Definitions) are italicized throughout this document for reference." all necessary parties is defined in FRD-ALL-18 as "All entities whose interests are affected directly by activity related to a specific cloud service offering in the context of a FedRAMP authorization. This always includes FedRAMP and any agency customer who is operating the cloud service offering, but may include additional parties depending on agreements made by the cloud service provider (such as consultants or third-party assessors). Potential agency customers or third-party cloud service providers should also be included in most cases but this is not a mandatory requirement under FedRAMP as ultimately the cloud service provider may choose who they wish to do business with." |
Beta Was this translation helpful? Give feedback.
-
|
My understanding of the goals of a continuous monitoring standard are:
This standard creates a much better balance in that direction than current practices. Thank you for ensuring a communication method and encouraging strong communication without unnecessarily dictating the how or the when. a 3 month cycle is much easier for parties to support than a 1 month cycle. Additionally, communication methods and channels may differ in effectiveness between agencies and offerings; thanks for considering flexibility in the approach. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was submitted to the Google Form by Cloudflare on 10/21:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi FedRAMP team, great stuff. I have a few comments.
Thanks for all your hard work. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
RFC-0016 Collaborative Continuous Monitoring Standard
RFC Front Matter
In addition to this markdown, this RFC is available in the following formats:
Where to Comment
Members of the public may submit multiple different comments on different issues during the public comment period. The public is asked to please refrain from including documents or spreadsheets (especially those with in-line comments or suggested changes) in public comment as this creates a significant additional review burden.
Formal public comment for official consideration by FedRAMP can be made via the following mechanisms in order of preference:
Note: FedRAMP will review and publicly post all public comments received via email, but will not otherwise respond. Email submissions from federal agencies will only be made public when requested by the agency.
Summary & Motivation
Fifteen years ago it was common for a single agency to be the only user of a cloud service for years, leading to the concept of a “sponsor” for FedRAMP - a single agency that would commit to performing expensive and burdensome oversight of a cloud service on behalf of the entire federal government.
Many different agencies with varying missions and use cases now operate the same shared commercial cloud services. Historically, relying on a single agency to oversee a cloud service on behalf of every agency user has created conflict and confusion between agencies, delayed access to new capabilities, and led to unexpected and undesirable security outcomes in some cases.
This proposed Collaborative Continuous Monitoring Standard continues implementing the vision of OMB Memorandum M-24-15 to redesign the government-wide continuous monitoring of cloud services to better align with the requirements of OMB A-130 and the NIST Risk Management Framework. This standard supplements the Significant Change Notification Standard, Vulnerability Detection and Response Standard, and Authorization Data Sharing Standard by adding the following additional requirements and recommendations:
This standard will apply firmly to FedRAMP 20x authorizations when formalized, however application to Rev5 will be optional and may require negotiation between cloud service providers and agencies based on existing customer agreements and expectations.
Effective Date(s) & Overall Applicability
This is a draft standard released for public comment; it does not apply to any FedRAMP authorization and MUST NOT be used in draft form.
Documentation Guidelines
The following FedRAMP documentation guidelines apply to this document:
Background & Authority
OMB Circular A-130: Managing Information as a Strategic Resource section 4 (c) states that agencies SHALL “conduct and document security and privacy control assessments prior to the operation of an information system, and periodically thereafter, consistent with the frequency defined in the agency information security continuous monitoring (ISCM) and privacy continuous monitoring (PCM) strategies and the agency risk tolerance”
The FedRAMP Authorization Act (44 USC § 3609 (a)(1)) directs the Administrator of the General Services Administration to “develop, coordinate, and implement a process … including, as appropriate, oversight of continuous monitoring of cloud computing products and services”
Purpose
Agencies are required to continuously monitor all of their information systems following a documented process integrated into their Information Security Continuous Monitoring (ISCM) strategy. These strategies are specific to each agency and may even vary at the bureau, component, or information system levels.
The concept behind collaborative continuous monitoring is unique to government customers and creates a burden for commercial cloud service providers. This standard attempts to minimize this burden by encouraging the use of automated monitoring and review of authorization data required by other FedRAMP standards and limiting the expected human interaction costs for cloud service providers and agencies. Agencies are expected to use information from the cloud service provider collaboratively in accordance with their agency ISCM strategy without blocking other agencies from making their own risk-based decisions about ongoing authorization.
Expected Outcomes
Definitions
FRD-CCM-01
Ongoing Authorization Report: A regular report that is supplied by FedRAMP Authorized cloud service providers to agency customers, aligned to the requirements and recommendations in the FedRAMP Collaborative Continuous Monitoring Standard.
FRD-CCM-02
Quarterly Review: A regular synchronous meeting hosted by a FedRAMP Authorized cloud service provider for agency customers, aligned to the requirements and recommendations in the FedRAMP Collaborative Continuous Monitoring Standard.
Requirements
FRR-CCM
These requirements and recommendations apply ALWAYS to ALL FedRAMP Authorized cloud services based on the current Effective Date(s) and Overall Applicability of this standard.
FRR-CCM-01
Providers MUST make an Ongoing Authorization Report available to all necessary parties every 3 months, in a consistent format that is human readable, covering the entire period since the previous summary; this report MUST include high-level summaries of at least the following information:
FRR-CCM-02
Providers SHOULD establish a regular 3 month cycle for Ongoing Authorization Reports that does not align with calendar quarters so that reports are spread out during the calendar quarter for agencies.
FRR-CCM-03
Providers MUST publicly include the target date for their next Ongoing Authorization Report with the authorization data required by FRR-ADS-01.
FRR-CCM-04
Providers MUST establish and share an asynchronous mechanism for all necessary parties to provide feedback or ask questions related to each Ongoing Authorization Report; all such feedback and questions from agencies, along with responses from the provider, MUST be available to FedRAMP.
FRR-CCM-05
Providers MUST NOT share feedback or questions from agencies publicly or with other parties than FedRAMP UNLESS the agency that submitted the feedback or question approves.
FRR-CCM-06
Providers MUST NOT irresponsibly disclose sensitive information in an Ongoing Authorization Report that would likely have an adverse effect on the cloud service offering.
FRR-CCM-07
Providers MAY responsibly share some or all of the information an Ongoing Authorization Report publicly or with other parties if the provider determines doing so will NOT likely have an adverse effect on the cloud service offering.
FRR-CCM-QR
This section includes requirements and recommendations for providers hosting synchronous Quarterly Reviews with all agencies.
FRR-CCM-QR-01
Providers SHOULD host a synchronous Quarterly Review every 3 months, open to all necessary parties, to review aspects of the most recent Ongoing Authorization Report that the provider determines are of the most relevance to agencies.
FRR-CCM-QR-02
Providers SHOULD regularly schedule Quarterly Reviews to occur at least 3 business days after releasing an Ongoing Authorization Report AND within 2 weeks of such release.
FRR-CCM-QR-03
Providers MUST NOT irresponsibly disclose sensitive information in a Quarterly Review that would likely have an adverse effect on the cloud service offering.
FRR-CCM-QR-04
Providers MUST include either a registration link or a downloadable calendar file with meeting information for Quarterly Reviews in the authorization data available to all necessary parties required by FRR-ADS-06 and FRR-ADS-07; providers who do not host Quarterly Reviews MUST clearly state this and explain this decision in the same authorization data.
FRR-CCM-QR-05
Providers hosting Quarterly Reviews MUST publicly include the target date for their next Quarterly Review with the authorization data required by FRR-ADS-01.
FRR-CCM-QR-06
Providers SHOULD include additional information in Quarterly Reviews that the provider determines are of interest, use, or otherwise relevant to agencies.
FRR-CCM-QR-07
Providers SHOULD NOT invite third parties to attend Quarterly Reviews intended for agencies unless it is of specific relevance; this is because agencies are less likely to actively participate in meetings with third parties.
FRR-CCM-QR-08
Providers MUST NOT disclose feedback or questions from agencies during a Quarterly Review with the public or third parties UNLESS the agency that submitted the feedback or question approves.
FRR-CCM-QR-09
Providers SHOULD record or transcribe Quarterly Reviews and make such available to all necessary parties with other authorization data as required by FRR-ADS-06 and FRR-ADS07.
FRR-CCM-QR-10
Providers MAY responsibly share recordings or transcriptions of Quarterly Reviews with the public or other parties ONLY if the provider removes all agency information (comments, questions, names, etc.) AND determines sharing will NOT likely have an adverse effect on the cloud service offering.
FRR-CCM-QR-11
Providers MAY share content prepared for a Quarterly Review with the public or other parties if the provider determines doing so will NOT likely have an adverse effect on the cloud service offering.
Agencies
This section includes requirements and recommendations for agencies who are using FedRAMP Authorized cloud services.
FRR-CCM-AG-01
Agencies MUST review each Ongoing Authorization Report to understand how changes to the cloud service offering may impact the previously agreed-upon risk tolerance documented in the agency’s Authorization to Operate of a federal information system that includes the cloud service offering in its boundary.
Note: This is required by 44 USC § 35, OMB A-130, FIPS-200, and M-24-15.
FRR-CCM-AG-02
Agencies SHOULD consider the Security Category noted in their Authorization to Operate of the federal information system that includes the cloud service offering in its boundary and assign appropriate information security resources for reviewing Ongoing Authorization Reports, attending Quarterly Reviews, and other ongoing authorization data.
FRR-CCM-AG-03
Agencies SHOULD designate a senior information security official to review Ongoing Authorization Reports and represent the agency at Quarterly Reviews for cloud service offerings included in agency information systems with a Security Category of High.
FRR-CCM-AG-04
Agencies SHOULD formally notify the provider if the information presented in an Ongoing Authorization Report, Quarterly Review, or other ongoing authorization data causes significant concerns that may lead the agency to remove the cloud service offering from operation.
FRR-CCM-AG-05
Agencies MUST notify FedRAMP by sending a notification to info@fedramp.gov if the information presented in an Ongoing Authorization Report, Quarterly Review, or other ongoing authorization data causes significant concerns that may lead the agency to stop operation of the cloud service offering.
Note: This is an OMB policy; agencies are required to notify FedRAMP in OMB Memorandum M-24-15 section IV (a).
FRR-CCM-AG-06
Agencies SHOULD NOT request additional information from cloud service providers that is not required by this FedRAMP standard UNLESS the head of the agency or an authorized delegate makes a determination that there is a demonstrable need for such.
Note: This is related to the Presumption of Adequacy directed by 44 USC § 3613 (e).
FRR-CCM-AG-07
Agencies MUST inform FedRAMP after requesting any additional information or materials from a cloud service provider beyond those required in this policy by sending a notification to info@fedramp.gov.
Note: This is an OMB policy; agencies are required to notify FedRAMP in OMB Memorandum M-24-15 section IV (a).
Beta Was this translation helpful? Give feedback.
All reactions