Cybersecurity/Goverment: Difference between revisions
(→3PAO) |
(→3PAO) |
||
| Line 261: | Line 261: | ||
This stands for Thirdy Party Assesment Organization and are a third party independent organization tasked with evaluating a cloud providers security controlls during an annual assessment. | This stands for Thirdy Party Assesment Organization and are a third party independent organization tasked with evaluating a cloud providers security controlls 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. | |||
** Tehnical proof that controls lower the explotability. | |||
* Signifcant changes | |||
** Before making major changes a 3PAO is requied. | |||
Revision as of 18:12, 23 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
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
- 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 envioment focus should be placed on
- AC - Access control
- IA - Identification and Authentication
- AU - Audit and accoutability
- SC - System communications and protection
- CM - Configuraton management
Maintaining a authrorzaton 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)
- Vunerability scanning
- 30 days POA&M inventory
- Remediation SLA's
- Timeline for patching vinerabilties 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 - deffense in depth.
Two types of DR can be used:
- Risk Adjustment
- Used where deign prevents real world exploitation.
- False positive
- Scaner flags something that is not present or complied.
The key here is not just to track the SLA deadline, it is to provie something is valid or invalid through review ot 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 Thirdy Party Assesment Organization and are a third party independent organization tasked with evaluating a cloud providers security controlls 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.
- Tehnical proof that controls lower the explotability.
- Signifcant changes
- Before making major changes a 3PAO is requied.