Cybersecurity/Goverment: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This is the one page "cheat sheet" for | This is the one page "cheat sheet" for government regulation in the US and how it relates to cybersecurity. | ||
= SSP = | = SSP = | ||
| Line 5: | Line 5: | ||
SSP - System Security plan | SSP - System Security plan | ||
Think of this as the master | Think of this as the master blueprint for the system. | ||
* It's a living document | * It's a living document | ||
* Describes | * Describes authorization boundaries / data flows / protocols etc | ||
| Line 35: | Line 35: | ||
* Data at rest and in transit | * Data at rest and in transit | ||
** S3 Bucket | ** S3 Bucket policies and encryption | ||
** TLS Enforcement | ** TLS Enforcement | ||
*** TLS 1.3 is a | *** TLS 1.3 is a mandatory baseline | ||
*** TLS 1.2 can be used with approval | *** TLS 1.2 can be used with approval | ||
*** TLS 1.0 and 1.1 Should not be used | *** TLS 1.0 and 1.1 Should not be used | ||
[[Cybersecurity/ | [[Cybersecurity/Government/TLS_and_cyphers|🤔More about TLS]] | ||
=== | === Infrastructure as code === | ||
* Maintaining baselines by | * Maintaining baselines by integrating policies in to cloud formation and terraform | ||
* Automated pre- | * Automated pre-commit code analysis | ||
| Line 59: | Line 59: | ||
* Tools scan the code acting as a security gate | * Tools scan the code acting as a security gate | ||
* Violations are caught: Buckets not encrypted / * actions / Open security groups | * Violations are caught: Buckets not encrypted / * actions / Open security groups | ||
* The violations causes the | * The violations causes the commit to fail. | ||
| Line 77: | Line 77: | ||
* IL2 | * IL2 | ||
** Non- | ** Non-sensitive public data | ||
** Must meet FedRAMP moderate baseline | ** Must meet FedRAMP moderate baseline | ||
* IL4 | * IL4 | ||
** Controlled | ** Controlled unclassified information | ||
** Can run in | ** Can run in commercial cloud regions but must meet FedRAMP+ controls & Logical VPC separation | ||
** | ** Requires background checks | ||
** An example could be a NASA system | ** An example could be a NASA system | ||
* IL5 | * IL5 | ||
** High | ** High sensitivity / Mission critical unclassified data / National security systems | ||
** Must be isolated from non federal tenants / use of GovCloud | ** Must be isolated from non federal tenants / use of GovCloud | ||
** US person only | ** US person only | ||
| Line 96: | Line 96: | ||
* IL6 | * IL6 | ||
** Data classified to the secret level | ** Data classified to the secret level | ||
** | ** Personal must hold secret clearance | ||
Where is Top Secret in this? - Top Secret is | Where is Top Secret in this? - Top Secret is governed 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. | This is for IL4 and below - designed for cloud systems. | ||
Used in situations where a data breach would cause " | Used in situations where a data breach would cause "catastrophic effects" in national security or human life. | ||
NIST SP 800-53 is used for this | NIST SP 800-53 is used for this | ||
Continues monitoring (3PAO) is | Continues monitoring (3PAO) is required. | ||
=== FedRAMP requires | === FedRAMP requires artifacts === | ||
These are documents: | These are documents: | ||
| Line 120: | Line 120: | ||
* System Security Plan - SSP | * System Security Plan - SSP | ||
** Details system boundaries and | ** Details system boundaries and architecture, see above ⬆️ | ||
* Control Implementation Summary | * Control Implementation Summary | ||
** | ** Outlines what controls are shared and what must be configured by the federal entity. | ||
* Customer | * Customer Responsibility Matrix | ||
** Dictates the security tasks and configurations that the agency must implement. | ** Dictates the security tasks and configurations that the agency must implement. | ||
* | * Information security policies and procedures | ||
** Documentation covering all NIST contil families | ** Documentation covering all NIST contil families | ||
| Line 135: | Line 135: | ||
==== Independent assessment ==== | ==== Independent assessment ==== | ||
These are validated by an | These are validated by an accredited FedRAMP 3PAO proving the controls are implemented. | ||
* Security | * Security Assessment Plan (SAP) | ||
** Developed before the 3PAO testing | ** Developed before the 3PAO testing | ||
** Defines the scope, methods | ** Defines the scope, methods schedule and testing tools | ||
* Security | * Security Assessment Report (SAR) | ||
** After 3PAO testing | ** After 3PAO testing | ||
** | ** identifies vulnerabilities and configuration gaps | ||
* Plan of Action with Milestones (POA&M) | * Plan of Action with Milestones (POA&M) | ||
| Line 191: | Line 191: | ||
== In a cloud DoD | == In a cloud DoD environment focus should be placed on == | ||
* AC - Access control | * AC - Access control | ||
* IA - Identification and Authentication | * IA - Identification and Authentication | ||
* AU - Audit and | * AU - Audit and accountability | ||
* SC - System communications and protection | * SC - System communications and protection | ||
* CM - | * CM - Configuration management | ||
== Maintaining a | == Maintaining a authorization to operate == | ||
Required to keep the system operating: | Required to keep the system operating: | ||
| Line 208: | Line 208: | ||
* Continious Monitoring (ConMon) | * Continious Monitoring (ConMon) | ||
** | ** Vulnerability scanning | ||
** 30 days POA&M inventory | ** 30 days POA&M inventory | ||
* Remediation SLA's | * Remediation SLA's | ||
** Timeline for patching | ** Timeline for patching vulnerabilities based on the required timeline | ||
= Deviation requests = | = Deviation requests = | ||
These are used in situations where a CVE is identified but it is not exploitable due to design decisions - | These are used in situations where a CVE is identified but it is not exploitable due to design decisions - defense in depth. | ||
Two types of DR can be used: | Two types of DR can be used: | ||
| Line 225: | Line 225: | ||
* False positive | * False positive | ||
** | ** Scanner flags something that is not present or complied. | ||
The key here is not just to track the SLA deadline, it is to | The key here is not just to track the SLA deadline, it is to provide something is valid or invalid through review to the SSP and real world testing (if possible). | ||
= GovRAMP/StateRAMP = | = GovRAMP/StateRAMP = | ||
| Line 259: | Line 259: | ||
= 3PAO = | = 3PAO = | ||
This stands for Third Party Assessment Organization and is a third party independent organization tasked with evaluating a cloud providers security controls during an annual assessment. | |||
== Core of the 3PAO == | |||
* SAP (Security Assessment Plan) and SAR (Security Assessment Report) | |||
** During annual assessments | |||
* Deviation requests | |||
** If something cannot be patched | |||
* Providing compensating controls | |||
** Used to get a risk assessment approved. | |||
** Technical proof that controls lower the exploitability. | |||
* Significant changes | |||
** Before making major changes a 3PAO is required. | |||
Under GovRamp requirements | |||
A PMO is required at: | |||
* Ready Verification - 80 controls | |||
* Authorized / Provisionally authorized - 300 controls | |||
* Core validation - Only needs PMO validation | |||
Latest revision as of 02:05, 24 October 2026
This is the one page "cheat sheet" for government regulation in the US and how it relates to cybersecurity.
SSP
SSP - System Security plan
Think of this as the master blueprint for the system.
- It's a living document
- Describes authorization boundaries / data flows / protocols etc
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 policies and encryption
- TLS Enforcement
- TLS 1.3 is a mandatory baseline
- TLS 1.2 can be used with approval
- TLS 1.0 and 1.1 Should not be used
Infrastructure as code
- Maintaining baselines by integrating policies in to cloud formation and terraform
- Automated pre-commit 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 commit 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-sensitive public data
- Must meet FedRAMP moderate baseline
- IL4
- Controlled unclassified information
- Can run in commercial cloud regions but must meet FedRAMP+ controls & Logical VPC separation
- Requires background checks
- An example could be a NASA system
- IL5
- High sensitivity / Mission critical unclassified data / National security systems
- Must be isolated from non federal tenants / use of GovCloud
- US person only
- IL6
- Data classified to the secret level
- Personal must hold secret clearance
Where is Top Secret in this? - Top Secret is governed 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 "catastrophic effects" in national security or human life.
NIST SP 800-53 is used for this
Continues monitoring (3PAO) is required.
FedRAMP requires artifacts
These are documents:
Core Design
- System Security Plan - SSP
- Details system boundaries and architecture, see above ⬆️
- Control Implementation Summary
- Outlines what controls are shared and what must be configured by the federal entity.
- Customer Responsibility Matrix
- Dictates the security tasks and configurations that the agency must implement.
- Information security policies and procedures
- Documentation covering all NIST contil families
Independent assessment
These are validated by an accredited FedRAMP 3PAO proving the controls are implemented.
- Security Assessment Plan (SAP)
- Developed before the 3PAO testing
- Defines the scope, methods schedule and testing tools
- Security Assessment Report (SAR)
- After 3PAO testing
- identifies vulnerabilities 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
- Contains security and privacy controls.
- Contains over 1,100 controls in 20 families
New families include:
- Supply chain risk management.
- PII Monitoring and transparency.
Worded to be technology neutral.
In a cloud DoD environment focus should be placed on
- AC - Access control
- IA - Identification and Authentication
- AU - Audit and accountability
- SC - System communications and protection
- CM - Configuration management
Maintaining a authorization to operate
Required to keep the system operating:
- System Security Plan (SSP) - Blueprint of the system design.
- SPP shows how the controls are implemented
- Continious Monitoring (ConMon)
- Vulnerability scanning
- 30 days POA&M inventory
- Remediation SLA's
- Timeline for patching vulnerabilities based on the required timeline
Deviation requests
These are used in situations where a CVE is identified but it is not exploitable due to design decisions - defense in depth.
Two types of DR can be used:
- Risk Adjustment
- Used where deign prevents real world exploitation.
- False positive
- Scanner flags something that is not present or complied.
The key here is not just to track the SLA deadline, it is to provide something is valid or invalid through review to the SSP and real world testing (if possible).
GovRAMP/StateRAMP
StateRAMP was rebranded to GovRAMP giving it two names. This is rebranded built on the same concepts at FedRAMP however this is expanded for local, tribal and educational - think of it as an extension of FedRAMP.
GovRAMP uses NIST SP 800-53 Rev 5 as its foundation ensuring a mapping to FedRAMP standards.
- Core Validation
- 60 Prioritized NIST controls
- Validated by the GovRAMP Project Management office (PMO) - no 3PAO
- Ready Validation
- Independently assessed - compliance with 80 NIST controls
- 3PAO and PMO validation
- Authorized / Provisionally authorized
- 3PAO assessment of over 300 NIST controls
- Aligns with FedRAMP high / moderate baselines
- Continuous monitoring
- Vendors must submit monthly vulnerability scans and POA&Ms to maintain their status.
GovRAMP CJIS-Assigned task force steak holders
- Brings together state and local steak holders to develop a CJIS overlay
- This allows CSP to meet FBI and CJIS (Criminal Justice Information Systems) requirements.
- Involves advanced biometrics / MFA - Can be applied directly on top of GovRAMP to eliminate duplicate audits.
3PAO
This stands for Third Party Assessment Organization and is a third party independent organization tasked with evaluating a cloud providers security controls during an annual assessment.
Core of the 3PAO
- SAP (Security Assessment Plan) and SAR (Security Assessment Report)
- During annual assessments
- Deviation requests
- If something cannot be patched
- Providing compensating controls
- Used to get a risk assessment approved.
- Technical proof that controls lower the exploitability.
- Significant changes
- Before making major changes a 3PAO is required.
Under GovRamp requirements
A PMO is required at:
- Ready Verification - 80 controls
- Authorized / Provisionally authorized - 300 controls
- Core validation - Only needs PMO validation