User or Developer story:

The FedRAMP team is planning to adopt ACS in the GovCloud boundary to use for scanning and vulnerability remediation. To ensure long-term supportability of ACS, we'd like to get some analysis of the following requirements so we can better evaluate how to maintain compliance and availability over the years:

• Documentation for how to get bug fixes or CVE remediations of the ACS code-base into the backlog. Additionally what the timeframes are for delivery of those hotfixes or CVE fixes
• Documentation on Feature Releases and the overall lifecycle of ACS's releases throughout a year
• Details on points of data egress from ACS - what can we expect to find when we run the tool if/when it tries to call home or utilize some external APIs
• Any details on FIPS compliance for the services that make up ACS
• Any information you can share about the security posture of the ACS service that we could reference when building out the System Security Plan (SSP) for FedRAMP. Generally this provides data and evidence to support all the various control families established for FedRAMP.
  • We have people in ProdSec's compliance team that facilitate the gathering of this data and evidence. You won't need to review the entire SSP control family and give details about ACS for each - we'll reach out if we see anything missing in our documentation if/when it's asked by our auditors
• It's not clear to me if there will ever be a need to have an ACS engineer available and cleared to work on the FedRAMP deployment. Maybe we also need a general statement or historical info that would suggest there's never been a case where an ACS developer needed to log-in to a customer deployment to fix something?

Acceptance Criteria

In general, we want to ensure that we're ready to speak to the impact ACS has on the FedRAMP environment in GovCloud when we meet with auditor's next. There will likely be a requirement that we review these details stated above in the User Story when we officially push ACS into production. Our FedRAMP partners and auditors will want to know more about the service, so it's important that we come prepared to those conversations.

Additionally as engineers will be supporting the service, having some quick reference for how we can get support from your team will be vital to the long-term success of the tooling. 

If we feel we can confidently do both of those things, we'd be happy to call this Story complete!

Not in Scope (Optional):

We don't need to focus on any specific attestation of the ACS tooling for FedRAMP. In other words, I don't believe this will be any effort to try and certify the tool specifically with the FedRAMP board. If your team and Red Hat are interested in trying to get the ACS tool officially certified, that may require a different story. 

Also to clearly call out - for now this is just an effort to get ACS running internally for Red Hat engineers, and not any effort to provide ACS to GovCloud customers. That work (should we want to pursue it) should be tracked separately.

Engineering Details (Optional):

We have a few engineers within HCM/ProdSec focused on delivering the ACS tool in FedRAMP. They are currently running some Proof of Concepts in GovCloud, but there's no specific engineering details that we should call out here. Here's the names of those engineers for reference:

• rh-ee-andremil 
• rh-ee-clusk 
• dmace@redhat.com 
• jmosco 
• rh-ee-stharris 
• sadams-insights