Cybersecurity/Goverment: Difference between revisions

From Cramsession
Jump to navigationJump to search
✍️ Verified Author: Mflavell • Click to view professional profile & credentials
VisualWikitext
(Created page with "This is the one page "cheat sheet" for goverment regulation in the US and how it relates to cybersecurity. = SSP = SSP - System Security plan Think of this as the master bluprint for the system. * It's a living document * Describes autntoszation boundaires / data flows / protocols ect The SSP requires: * WHAT: A clear definition of what is protected * HOW: How it is protected and isolated Without a What and How it is not protected!!! How it relates to NIST 800-...")
 
 
(14 intermediate revisions by the same user not shown)
Line 26: Line 26:
== How SSP relates to AWS Gov Cloud ==
== How SSP relates to AWS Gov Cloud ==


Multi account governance:
=== Multi account governance ===


* Don't trust other accounts  
* Don't trust other accounts  
* Use AWS control tower to implement service control policies / lock down account boundaries.
* Use AWS control tower to implement service control policies / lock down account boundaries.


Data protection:
 
=== Data protection ===


* Data at rest and in transit
* Data at rest and in transit
Line 40: Line 41:
*** TLS 1.0 and 1.1 Should not be used
*** TLS 1.0 and 1.1 Should not be used


=== More about TLS ===
[[Cybersecurity/Goverment/TLS_and_cyphers|🤔More about TLS]]
 
 
=== Infrastrcutre as code ===


Enabling TLS 1.3 is not enough - the underlying software / hardware must be approved.
* Maintaining baselines by intergrating polcies in to cloud formation and terraform
* Automated pre-comit code analysis


The cypher suite must also be enforced.


{| class="wikitable sortable"
IAC has many major advantages:
! Protocol Version
! NIST Priority
! Standard RFC Cipher Name
! Key Exchange / Encryption Details
|-
| '''TLS 1.3'''
| style="background:#d4edda;" | 🌟 '''Preferred'''
| TLS_AES_128_GCM_SHA256
| AEAD / 128-bit AES-GCM (Mandatory baseline)
|-
| '''TLS 1.3'''
| style="background:#d4edda;" | 🌟 '''Preferred'''
| TLS_AES_256_GCM_SHA384
| AEAD / 256-bit AES-GCM (Mandatory baseline)
|-
| '''TLS 1.3'''
| style="background:#fff3cd;" | ✅ '''Acceptable'''
| TLS_AES_128_CCM_SHA256
| AEAD / 128-bit AES-CCM
|-
| '''TLS 1.2'''
| style="background:#d4edda;" | 🌟 '''Preferred'''
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
| ECDH Exchange + ECDSA Auth + 128-bit AES-GCM
|-
| '''TLS 1.2'''
| style="background:#d4edda;" | 🌟 '''Preferred'''
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
| ECDH Exchange + ECDSA Auth + 256-bit AES-GCM
|-
| '''TLS 1.2'''
| style="background:#d4edda;" | 🌟 '''Preferred'''
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
| ECDH Exchange + RSA Auth + 128-bit AES-GCM
|-
| '''TLS 1.2'''
| style="background:#d4edda;" | 🌟 '''Preferred'''
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
| ECDH Exchange + RSA Auth + 256-bit AES-GCM
|-
| '''TLS 1.2'''
| style="background:#f8d7da;" | ⚠️ ''Legacy Fallback''
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
| ECDH Exchange + ECDSA Auth + 128-bit AES-CBC
|-
| '''TLS 1.2'''
| style="background:#f8d7da;" | ⚠️ ''Legacy Fallback''
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
| ECDH Exchange + ECDSA Auth + 256-bit AES-CBC
|-
| '''TLS 1.2'''
| style="background:#f8d7da;" | ⚠️ ''Legacy Fallback''
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
| ECDH Exchange + RSA Auth + 128-bit AES-CBC
|-
| '''TLS 1.2'''
| style="background:#f8d7da;" | ⚠️ ''Legacy Fallback''
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
| ECDH Exchange + RSA Auth + 256-bit AES-CBC
|-
| '''TLS 1.2'''
| style="background:#f8d7da;" | ⚠️ ''Legacy Fallback''
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
| Finite Field DH + RSA Auth + 128-bit AES-GCM
|-
| '''TLS 1.2'''
| style="background:#f8d7da;" | ⚠️ ''Legacy Fallback''
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
| Finite Field DH + RSA Auth + 256-bit AES-GCM
|}


* Can be scanned for security issues - just like the scan of application code.




How it works:


* Tools scan the code acting as a security gate
* Violations are caught: Buckets not encrypted / * actions / Open security groups
* The violations causes the comit to fail.
This is a "Shift left" approach, catching issues before they make it to production.
An important caveat: This does not catch CVE's in code!
best approach is Trust but Verify:
* Trust IAC code has been scanned
* Verify the implementation




= DoD IL4/IL5 =
= DoD IL4/IL5 =
These are "Impact Levels"
* IL2
** Non-sensative public data
** Must meet FedRAMP moderate baseline
* IL4
** Controlled unvlassified infomration
** Can run in commeical cloud regious but must meet FedRAMP+ controls & Logical VPC seperation
** Requies background checks
** An example could be a NASA system
* IL5
** High sensitivitity / Mission critical unlcassified data / National security systems
** Must be isolated from non federal tenants / use of GovCloud
** US person only
* IL6
** Data classified to the secret level
** Personel must hold secret clearance
Where is Top Secret in this? - Top Secret is goverened by ICD 503 instead of a SRG and operate on dedicated air gapped networks.
= FedRAMP High =
= FedRAMP High =
This is for IL4 and below - designed for cloud systems.
Used in situations where a data breach would cause "castastropic effects" in national security or human life.
NIST SP 800-53 is used for this
Continues monitoring (3PAO) is reqired.
=== FedRAMP requires arifacts ===
These are documents:
==== Core Design ====
* System Security Plan - SSP
** Details system boundaries and arictecutre, see above ⬆️
* Control Implementation Summary
** Outilines what controls are shared and what must be configured by the federal entity.
* Customer Respoabiliy Matrix
** Dictates the security tasks and configurations that the agency must implement.
* Infomation securirty polocies and procedures
** Documentation covering all NIST contil families
==== Independent assessment ====
These are validated by an accredieted FedRAMP 3PAO proving the controls are implemented.
* Security Assesment Plan (SAP)
** Developed before the 3PAO testing
** Defines the scope, methods secedule and testing tools
* Security Assesmsnet Report (SAR)
** After 3PAO testing
** Ideifies vunerabilities and configuration gaps
* Plan of Action with Milestones (POA&M)
** Used to track and remediate vulnerabilities
==== Continious Monitoring ====
* Monthly scan reports
* POA&M Logs - showing remediation
* Annual Security Assessment - review of core controls and major changes to the system
ConMom SLAs based on CVSS score:
* 7.0 - 10  = 30 days
* 4.0 - 6.9 = 90 days
* 0.1 - 3.9 = 180 days
=== Incident Response ===
* Incidents must be reported to US-CERT or DOD in one hour
=== Crypto and Key Management ===
* Must use CMK - Customer managed keys
* Must use FIPS 140-2 / 140-3 Level 3 HSM
= NIST 800-53 Rev 5 =
= NIST 800-53 Rev 5 =
= GovRAMP/StateRAMP =
= GovRAMP/StateRAMP =
= 3PAO =
= 3PAO =

Latest revision as of 21:51, 22 October 2026

This is the one page "cheat sheet" for goverment regulation in the US and how it relates to cybersecurity.

SSP

SSP - System Security plan

Think of this as the master bluprint for the system.

  • It's a living document
  • Describes autntoszation boundaires / data flows / protocols ect


The SSP requires:

  • WHAT: A clear definition of what is protected
  • HOW: How it is protected and isolated

Without a What and How it is not protected!!!


How it relates to NIST 800-53:

  • Describes how every 800-53 control is technically implemented.


How SSP relates to AWS Gov Cloud

Multi account governance

  • Don't trust other accounts
  • Use AWS control tower to implement service control policies / lock down account boundaries.


Data protection

  • Data at rest and in transit
    • S3 Bucket polcies and encryption
    • TLS Enforcement
      • TLS 1.3 is a mandotary baseline
      • TLS 1.2 can be used with approval
      • TLS 1.0 and 1.1 Should not be used

🤔More about TLS


Infrastrcutre as code

  • Maintaining baselines by intergrating polcies in to cloud formation and terraform
  • Automated pre-comit code analysis


IAC has many major advantages:

  • Can be scanned for security issues - just like the scan of application code.


How it works:

  • Tools scan the code acting as a security gate
  • Violations are caught: Buckets not encrypted / * actions / Open security groups
  • The violations causes the comit to fail.


This is a "Shift left" approach, catching issues before they make it to production.

An important caveat: This does not catch CVE's in code!

best approach is Trust but Verify:

  • Trust IAC code has been scanned
  • Verify the implementation


DoD IL4/IL5

These are "Impact Levels"

  • IL2
    • Non-sensative public data
    • Must meet FedRAMP moderate baseline


  • IL4
    • Controlled unvlassified infomration
    • Can run in commeical cloud regious but must meet FedRAMP+ controls & Logical VPC seperation
    • Requies background checks
    • An example could be a NASA system


  • IL5
    • High sensitivitity / Mission critical unlcassified data / National security systems
    • Must be isolated from non federal tenants / use of GovCloud
    • US person only


  • IL6
    • Data classified to the secret level
    • Personel must hold secret clearance


Where is Top Secret in this? - Top Secret is goverened by ICD 503 instead of a SRG and operate on dedicated air gapped networks.

FedRAMP High

This is for IL4 and below - designed for cloud systems.

Used in situations where a data breach would cause "castastropic effects" in national security or human life.

NIST SP 800-53 is used for this

Continues monitoring (3PAO) is reqired.


FedRAMP requires arifacts

These are documents:

Core Design

  • System Security Plan - SSP
    • Details system boundaries and arictecutre, see above ⬆️
  • Control Implementation Summary
    • Outilines what controls are shared and what must be configured by the federal entity.
  • Customer Respoabiliy Matrix
    • Dictates the security tasks and configurations that the agency must implement.
  • Infomation securirty polocies and procedures
    • Documentation covering all NIST contil families


Independent assessment

These are validated by an accredieted FedRAMP 3PAO proving the controls are implemented.

  • Security Assesment Plan (SAP)
    • Developed before the 3PAO testing
    • Defines the scope, methods secedule and testing tools
  • Security Assesmsnet Report (SAR)
    • After 3PAO testing
    • Ideifies vunerabilities and configuration gaps
  • Plan of Action with Milestones (POA&M)
    • Used to track and remediate vulnerabilities


Continious Monitoring

  • Monthly scan reports
  • POA&M Logs - showing remediation
  • Annual Security Assessment - review of core controls and major changes to the system


ConMom SLAs based on CVSS score:

  • 7.0 - 10 = 30 days
  • 4.0 - 6.9 = 90 days
  • 0.1 - 3.9 = 180 days


Incident Response

  • Incidents must be reported to US-CERT or DOD in one hour


Crypto and Key Management

  • Must use CMK - Customer managed keys
  • Must use FIPS 140-2 / 140-3 Level 3 HSM

NIST 800-53 Rev 5

GovRAMP/StateRAMP

3PAO

Retrieved from "https://cramsession.net/index.php?title=Cybersecurity/Goverment&oldid=1931"