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-...")
 
(7 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 ===
 
* 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.


Enabling TLS 1.3 is not enough - the underlying software / hardware must be approved.


The cypher suite must also be enforced.
How it works:


{| class="wikitable sortable"
* Tools scan the code acting as a security gate
! Protocol Version
* Violations are caught: Buckets not encrypted / * actions / Open security groups
! NIST Priority
* The violations causes the comit to fail.
! 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
|}






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.
= NIST 800-53 Rev 5 =
= NIST 800-53 Rev 5 =
= GovRAMP/StateRAMP =
= GovRAMP/StateRAMP =
= 3PAO =
= 3PAO =

Revision as of 18:05, 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.

NIST 800-53 Rev 5

GovRAMP/StateRAMP

3PAO

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