infrastructure-notes/MDR FedRAMP.txt

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. 
MDR employs configuration scanning software (Qualys) that, using SCAP compliant checklists, produces SCAP compliant output. 
MDR employs c

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 MDR engineers through the change management process. Only members of the MDR 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.