FedRAMP Notes.md 2.6 KB
AWS artifacts provide insight into AWS fedramp package. Okta fedRAMP notes: https://www.okta.com/resources/whitepaper/configuring-okta-for-fedramp-compliance/
CM-6(a)-2 CIS SCAP Checklist Update parameter field to indicate the the CIS QA checklist is stored in Qualys and is SCAP compatible. XDR employs configuration scanning software (Qualys) that, using SCAP compliant checklists, produces SCAP compliant output.
Do we have an alternative to github? is gitlab FIPS certified? It doesn't look like it. https://gitlab.com/gitlab-org/gitlab-foss/issues/41463
Use Qualys as the CIS QA Checklist- input deviations to CIS
CM-6(c)-1 CIS deviations Add link to the CIS deviations wiki page to the SSP? Provide access to customers upon request. Copy and paste the wiki page into the SSP? Need to ask clarifing question. All Info sys components could have deviations, should we list every server? These are handled in the Qualys scanning tool.
FIPS Certificate numbers Red Hat SSH: 3538 Red Hat GnuTLS: 3571 Red Hat kernel: 3565 Okta mobile: 3344 Okta: 3353 Splunk: 3126
Whitelisting Applications Process
New applications are introduced into the production environment after they have been approved by at least two XDR engineers through the change management process. Only members of the XDR engineers are able to approve new software. Before the change to add the new software is approved, a hash of the software should be generated and documented. The hash should be compared to the vendors documented hash. To ensure the hash of the software doesn’t change, the Splunk app Process List Whitelisting is used to gather and verify the hashes have not changed. In the event that an unapproved hash is detected an email alert is sent.
DNSSEC https://nvd.nist.gov/800-53/Rev4/control/SC-20 https://nvd.nist.gov/800-53/Rev4/control/SC-21
SC-20 says (roughly) that your authoritative name servers should be publishing DNS records that are cryptographically signed using DNSSEC all the way back to the root. DNSSEC attempts to protect DNS data from being tampered in transit. Having a set of robust digital signatures on “my” DNS records, and on those of “my parent” and on those of “my grandparent” all the way back to the root of the DNS tree makes it possible to cryptographically “prove” that when someone looks up my domain – say www.accenturefederal.com – that there was no tampering with the responses to that query.
SC-21 says (roughly) that when your clients do a DNS lookup that those lookups are done in a way that the DNSSEC signatures are checked and validated, and if the results cannot be cryptographically validated they are not used.