CompTIA Security+ Risk Assessment Frameworks - NIST RMF, ISO 31000, OCTAVE

CompTIA Security+ Risk Assessment Frameworks: NIST RMF, ISO 31000, OCTAVE

Zero-fluff, hands-on guide for real-world risk assessments

1. What This Is & Why It Matters

You’re a security analyst at a mid-sized healthcare SaaS company. Your CISO just handed you a new HIPAA-compliant cloud deployment and said: "We need a risk assessment before go-live. Use a framework—NIST, ISO, or OCTAVE. I don’t care which, but it has to be defensible in an audit."

Why this matters in production: - Audits fail without documentation. If you can’t show a structured risk assessment, regulators (HIPAA, PCI DSS, GDPR) will fine you—or worse, shut you down. - You’ll miss critical risks. Without a framework, you’ll focus on the loudest threats (e.g., ransomware) and ignore silent killers (e.g., misconfigured IAM roles, unpatched legacy APIs). - Wasted time & money. Ad-hoc risk assessments lead to over-engineering (e.g., encrypting everything at rest and in transit when only one is needed) or under-engineering (e.g., no MFA for admin accounts).

Real-world scenario: You inherit a legacy on-prem Active Directory with 500+ users, no documentation, and a history of breaches. Your task:
1. Identify risks (e.g., weak password policies, unpatched domain controllers).
2. Prioritize fixes (e.g., "Patch DC first, then enforce MFA").
3. Document everything for the next audit.

This guide gives you battle-tested frameworks to do this systematically.

2. Core Concepts & Components

? NIST Risk Management Framework (RMF)

• What it is: A 6-step process (from NIST SP 800-37) used by U.S. federal agencies (and many private companies) to manage risk in IT systems.
• Production insight: If you work with government contracts (FedRAMP, DoD), NIST RMF is mandatory. Even if you don’t, it’s the gold standard for structured risk management.
• Key steps:
• Categorize the system (e.g., "High impact for confidentiality").
• Select security controls (e.g., NIST SP 800-53).
• Implement controls (e.g., enable AWS GuardDuty).
• Assess controls (e.g., run a penetration test).
• Authorize the system (e.g., CISO signs off).
• Monitor continuously (e.g., SIEM alerts for anomalies).

? ISO 31000

• What it is: A generic risk management standard (not IT-specific) used globally for enterprise risk (e.g., financial, operational, cyber).
• Production insight: If your company is ISO 27001-certified, ISO 31000 is often used alongside it. It’s less prescriptive than NIST RMF but more flexible for non-IT risks (e.g., supply chain, natural disasters).
• Key principles:
• Risk is uncertainty that affects objectives.
• Risk management should be integrated into all processes.
• Decisions should be informed by risk appetite (e.g., "We accept medium risk for cost savings").

? OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

• What it is: A self-directed risk assessment methodology (from Carnegie Mellon) designed for small/medium businesses or teams without dedicated security staff.
• Production insight: If you’re a startup or SMB, OCTAVE is faster and cheaper than NIST RMF. It focuses on workshops (not paperwork) and prioritizes risks based on business impact.
• Key phases:
• Build asset-based threat profiles (e.g., "Our customer database is critical").
• Identify infrastructure vulnerabilities (e.g., "No MFA on admin accounts").
• Develop security strategy (e.g., "Implement MFA in 30 days").

? Risk Assessment vs. Risk Management

• Risk Assessment = Identifying and evaluating risks (e.g., "Our API has no rate limiting-risk of DDoS").
• Risk Management = Deciding what to do about risks (e.g., "We’ll implement AWS WAF to mitigate DDoS").
• Production insight: Many teams skip assessment and jump straight to "fixes," leading to wasted effort (e.g., buying a $50K firewall when a $500 WAF rule would suffice).

? Risk Appetite vs. Risk Tolerance

• Risk Appetite = How much risk the company is willing to take (e.g., "We accept medium risk for cost savings").
• Risk Tolerance = The acceptable deviation from appetite (e.g., "We’ll tolerate a 5% increase in risk if it saves $100K").
• Production insight: If leadership says, "We can’t afford downtime," but then refuses to fund backups, their risk appetite doesn’t match reality.

? Qualitative vs. Quantitative Risk Assessment

? Common Risk Assessment Tools

Tool	Use Case	Example
Nessus	Vulnerability scanning	nessuscli scan new --policy "Basic Network Scan" --targets 192.168.1.0/24
AWS Inspector	Cloud vulnerability assessment	aws inspector start-assessment-run --assessment-template-arn arn:aws:inspector:us-east-1:123456789012:target/0-12345678/template/0-12345678
OWASP ZAP	Web app security testing	zap-baseline.py -t https://example.com -r report.html
Risk Matrix	Prioritizing risks

3. Step-by-Step Hands-On: Running a NIST RMF Risk Assessment

Scenario: You’re assessing a new AWS-based patient portal for a healthcare client. They need HIPAA compliance, and the CISO wants a NIST RMF-based risk assessment before go-live.

Prerequisites

• AWS account with admin IAM permissions.
• NIST SP 800-53 (security controls) and NIST SP 800-37 (RMF steps) downloaded.
• Nessus or AWS Inspector for vulnerability scanning.
• Jira or Excel for tracking risks.

Step 1: Categorize the System (NIST RMF Step 1)

Goal: Determine the impact level (Low/Medium/High) for confidentiality, integrity, and availability (CIA).

How to do it:
1. Identify data types: - Patient records (PHI)-High confidentiality. - Appointment scheduling-Medium availability.
2. Use NIST FIPS 199 to categorize: | Impact Level | Confidentiality | Integrity | Availability | |------------------|---------------------|---------------|------------------| | Low | Unauthorized disclosure has limited impact. | Unauthorized modification has limited impact. | Disruption has limited impact. | | Medium | Unauthorized disclosure has serious impact. | Unauthorized modification has serious impact. | Disruption has serious impact. | | High | Unauthorized disclosure has severe/catastrophic impact. | Unauthorized modification has severe/catastrophic impact. | Disruption has severe/catastrophic impact. |
3. Document the categorization:

"The patient portal is categorized as High for confidentiality (PHI), Medium for integrity (appointment data), and Medium for availability (downtime acceptable for <4 hours)."

Verification: - Check with the legal/compliance team to confirm impact levels. - If unsure, default to High (better safe than sorry).

Step 2: Select Security Controls (NIST RMF Step 2)

Goal: Choose baseline controls from NIST SP 800-53 based on the system’s impact level.

How to do it:
1. Find the baseline controls: - For High-impact systems, use NIST SP 800-53 Rev. 5, Appendix D (High Baseline). - For Medium-impact, use Appendix C.
2. Map controls to AWS services: | NIST Control | AWS Implementation | Example | |------------------|------------------------|-------------| | AC-2 (Account Management) | IAM | aws iam create-user --user-name "auditor" | | SC-7 (Boundary Protection) | Security Groups, NACLs | aws ec2 create-security-group --group-name "WebApp-SG" --description "Allow HTTPS" | | SI-4 (System Monitoring) | CloudTrail, GuardDuty | aws cloudtrail create-trail --name "ComplianceTrail" --s3-bucket-name "audit-logs" | | CP-9 (System Backup) | AWS Backup | aws backup create-backup-plan --backup-plan file://backup-plan.json |
3. Document the controls:

"Control AC-2 (Account Management) is implemented via AWS IAM with MFA enforcement. See IAM policy MFA-Enforce."

Verification: - Run aws iam list-users and check if MFA is enabled for all users. - Run aws cloudtrail describe-trails to confirm CloudTrail is enabled.

Step 3: Implement Controls (NIST RMF Step 3)

Goal: Deploy the selected controls in AWS.

Example: Enforcing MFA for IAM Users

# 1. Create an IAM policy requiring MFA
aws iam create-policy --policy-name "MFA-Enforce" --policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}'

# 2. Attach the policy to all users
aws iam attach-user-policy --user-name "auditor" --policy-arn "arn:aws:iam::123456789012:policy/MFA-Enforce"

Example: Enabling AWS GuardDuty

# Enable GuardDuty in us-east-1
aws guardduty create-detector --enable

# Verify it's running
aws guardduty list-detectors

Verification: - Try logging in without MFA—you should get access denied. - Check GuardDuty findings: bash aws guardduty list-findings

Step 4: Assess Controls (NIST RMF Step 4)

Goal: Test if the controls are working as intended.

How to do it:
1. Run a vulnerability scan: bash # Using AWS Inspector aws inspector create-assessment-target --assessment-target-name "PatientPortal" aws inspector create-assessment-template --assessment-target-arn "arn:aws:inspector:us-east-1:123456789012:target/0-12345678" --assessment-template-name "HIPAA-Compliance" --duration-in-seconds 3600 aws inspector start-assessment-run --assessment-template-arn "arn:aws:inspector:us-east-1:123456789012:template/0-12345678"
2. Check for misconfigurations: - Use AWS Config to check for unencrypted S3 buckets: bash aws configservice get-compliance-details-by-config-rule --config-rule-name "s3-bucket-server-side-encryption-enabled"
3. Document findings:

"AWS Inspector found 3 medium-severity vulnerabilities in the EC2 instances (CVE-2023-1234). Mitigation: Patch instances within 7 days."

Verification: - Check AWS Config for non-compliant resources. - Review GuardDuty findings for anomalies.

Step 5: Authorize the System (NIST RMF Step 5)

Goal: Get formal approval from the Authorizing Official (AO) (e.g., CISO).

How to do it:
1. Compile the security package: - System categorization (Step 1). - Security controls (Step 2). - Assessment results (Step 4). - Plan of Action & Milestones (POA&M) for unresolved risks.
2. Submit for approval: - Example POA&M entry: | Risk | Mitigation | Owner | Due Date | |----------|----------------|-----------|--------------| | Unpatched EC2 instances (CVE-2023-1234) | Patch within 7 days | DevOps Team | 2023-10-15 |
3. Get sign-off: - The AO reviews and either: - Authorizes the system (go-live approved). - Denies authorization (fix issues first).

Verification: - Confirm the AO has signed the authorization letter. - Store the authorization package in a secure, auditable location (e.g., AWS S3 with versioning).

Step 6: Monitor Continuously (NIST RMF Step 6)

Goal: Ensure controls stay effective over time.

How to do it:
1. Set up automated monitoring: - CloudWatch Alarms for failed logins: bash aws cloudwatch put-metric-alarm --alarm-name "FailedLogins" --metric-name "FailedLoginAttempts" --namespace "AWS/IAM" --statistic "Sum" --period 300 --threshold 5 --comparison-operator "GreaterThanThreshold" --evaluation-periods 1 --alarm-actions "arn:aws:sns:us-east-1:123456789012:SecurityAlerts" - AWS Config Rules for compliance drift: bash aws configservice put-config-rule --config-rule file://config-rule.json
2. Schedule quarterly reviews: - Re-run vulnerability scans. - Update the POA&M.
3. Document changes: - If a new CVE is published, assess its impact and update controls.

Verification: - Check CloudWatch Alarms for triggered alerts. - Review AWS Config for non-compliant resources.

4.-Production-Ready Best Practices

? Security

• Least privilege for risk assessments:
• Only security team + compliance should have access to risk assessment docs.
• Use AWS KMS to encrypt sensitive findings: bash aws kms encrypt --key-id "alias/RiskAssessmentKey" --plaintext fileb://risk-report.pdf --output text --query CiphertextBlob | base64 --decode > risk-report.enc
• Automate compliance checks:
• Use AWS Config + Lambda to auto-remediate non-compliant resources.
• Store risk docs in a secure, versioned location:
• AWS S3 with versioning + MFA delete for audit trails.

? Cost Optimization

• Start with qualitative risk assessments (cheaper, faster) before investing in quantitative (expensive, slow).
• Use free/open-source tools first:
• Nessus Essentials (free for <16 IPs).
• OWASP ZAP (free web app scanner).
• Prioritize risks by ROI:
• Example: Fixing MFA enforcement ($0) is cheaper than buying a new firewall ($50K).

? Reliability & Maintainability

• Use a risk register (Excel/Jira): | Risk ID | Description | Likelihood | Impact | Mitigation | Owner | Status | |-------------|----------------|----------------|------------|----------------|-----------|------------| | RISK-001 | Unpatched EC2 instances | High | High | Patch within 7 days | DevOps | Open |
• Tag AWS resources for risk tracking: bash aws ec2 create-tags --resources i-1234567890abcdef0 --tags Key=RiskID,Value=RISK-001
• Document everything in a wiki (Confluence/Notion):
• Include screenshots of controls (e.g., "MFA is enforced—see IAM policy").

? Observability

• Track key risk metrics:
• # of open high-risk findings (target: <5).
• Time to remediate critical risks (target: <7 days).
• Set up dashboards:
• AWS Security Hub for compliance status.
• Grafana for custom risk metrics.
• Alert on risk drift:
• Example: If AWS Config detects a new public S3 bucket, trigger a Slack alert.

5. Common Mistakes & Traps