CASp cheat sheet
CASp · Keep the key ideas within reach.
Information Security Risk Management Framework
Risk = f(Threat, Vulnerability, Impact, Likelihood); NIST SP 800-30 defines risk as a function of the likelihood of a threat event and its adverse impact.
Risk management has four components per NIST SP 800-39: framing, assessing, responding (accept/avoid/mitigate/share), and monitoring.
Risk assessment process (SP 800-30 Rev.1): prepare, conduct (identify threat sources/events, identify vulnerabilities, determine likelihood, determine impact, determine risk), communicate, maintain.
Risk framing establishes the organization's assumptions, constraints, risk tolerance, and priorities before any assessment begins.
Risk response options: accept, avoid, mitigate, transfer/share, or a combination; selection depends on risk tolerance and cost-benefit.
Likelihood and impact can be qualitative (low/medium/high), semi-quantitative, or quantitative; NIST allows any approach if documented.
Risk register records identified risks, owners, response decisions, and status; it is a living artifact updated during monitoring.
The RMF (SP 800-37 Rev.2) is a risk management process, not a checklist; it integrates security and privacy into the system development life cycle.
Authorization (risk acceptance) is made by a designated authorizing official based on the assessment of risk against organizational risk tolerance.
Categorization of Information Systems
FIPS 199 defines three security objectives: confidentiality, integrity, and availability (CIA).
Security categories are low, moderate, or high; the system category is the high-water mark of the three objectives (e.g., C:Moderate, I:Low, A:High → overall High).
Impact levels per FIPS 199: low = limited adverse effect; moderate = serious adverse effect; high = severe or catastrophic adverse effect.
NIST SP 800-60 Vol.1 and Vol.2 provide guidance and mappings from information types to provisional impact levels.
Categorization considers all information types processed, stored, or transmitted by the system, not just the primary mission.
The system security plan (SSP) documents the categorization and the rationale; categorization is reviewed and updated when the system changes.
Special factors (e.g., national security, life safety, privacy) can raise the categorization above the high-water mark; document the justification.
Categorization drives control baselines: low → SP 800-53B low baseline; moderate → moderate baseline; high → high baseline.
Selection of Security Controls
Start with the SP 800-53B baseline corresponding to the system's FIPS 199 categorization (low, moderate, high).
Tailoring: apply scoping guidance, compensate for common controls, and adjust parameters (organization-defined values) to fit the system.
Supplement the baseline with controls from other sources (e.g., privacy, OT, cloud) when the baseline does not address specific risks.
Control overlays (e.g., privacy, cloud, space) add or modify controls for specific communities or technologies.
Common controls are inherited from the organization; system-specific controls are implemented locally; hybrid controls are partly both.
Document control selection and tailoring decisions in the SSP, including rationale for any baseline controls not implemented.
SP 800-53 Rev.5 control families are organized by class (management, operational, technical) and include privacy controls (PT family).
The control selection process is iterative and risk-based; it is revisited during continuous monitoring and when the system changes.
Implementation of Security Controls
Implementation is documented in the SSP, including control description, responsible party, and implementation status.
Implementation status values include implemented, partially implemented, planned, alternative implementation, and not applicable.
Compensating controls are alternatives that provide equivalent protection when a baseline control cannot be implemented; document the rationale.
Common control providers document their controls in a common control catalog or SSP attachment; inheriting systems reference them.
Control implementation must be tested or verified before being marked implemented; evidence is retained for assessment.
Security engineering principles (e.g., least privilege, defense in depth, fail-safe defaults) guide implementation choices.
Configuration management (CM family) ensures implemented controls remain in place and changes are controlled.
Implementation gaps are recorded as findings and fed into the plan of action and milestones (POA&M).
Assessment of Security Controls
Assessment determines whether controls are implemented correctly, operating as intended, and producing the desired outcome.
SP 800-53A provides assessment procedures: examine, interview, and test (EIT) for each control.
Assessment methods: examine (review documents, logs, configurations), interview (discuss with personnel), test (exercise the control).
The assessment plan defines scope, methods, sampling, and schedule; it is approved before execution.
Assessment results are documented in a security assessment report (SAR) with findings, severity, and evidence.
Independent assessors (e.g., third-party assessment organizations) may perform assessments to increase objectivity.
Findings are categorized (e.g., high, moderate, low) and tracked in the POA&M with remediation milestones.
Assessment is not a one-time event; it recurs during continuous monitoring and after significant changes.
Authorization of Information Systems
Authorization (ATO) is the official management decision to accept risk of operating a system, made by the authorizing official (AO).
Authorization package typically includes the SSP, SAR, and POA&M; the AO reviews these to make a risk-based decision.
Authorization decisions: authorization to operate (ATO), authorization to operate with conditions, denial, or interim authorization to test (IATT).
IATT is time-limited and for testing only; it does not authorize production operation.
The AO considers organizational risk tolerance, mission impact, and the adequacy of the POA&M before authorizing.
Authorization is system-specific and time-bound; it must be reauthorized when significant changes occur or at the defined expiration.
Continuous monitoring results inform the AO's ongoing risk acceptance; significant findings can trigger reauthorization or revocation.
The AO can revoke an authorization if risk becomes unacceptable; the system must then be remediated or shut down.
Continuous Monitoring
Continuous monitoring (ConMon) maintains ongoing awareness of the security posture and informs risk-based decisions.
SP 800-137 defines the ConMon process: define strategy, establish program, implement, analyze/data, respond, and review/update.
Monitoring covers configuration management, vulnerability scanning, patch management, log review, and control assessments.
Metrics and reporting: status reports, dashboards, and escalation thresholds trigger response actions.
Significant changes (e.g., new interconnection, major upgrade) require reassessment and may require reauthorization.
Automated tools (e.g., SCAP, SIEM, continuous diagnostics and mitigation) support scalable monitoring.
The POA&M is updated with monitoring findings; unresolved high-risk findings may affect the authorization decision.
ConMon strategy is tailored to organizational risk tolerance and system criticality; it is documented and approved.