CSY399 Week 07 Capstone

Week Content

Cybersecurity Capstone

Track your progress through this week's content

Mental Model

"Risk is the language executives understand. CVSS scores tell them severity; business impact tells them why they should care." — Security Leadership Principle

You've identified vulnerabilities across infrastructure, web applications, and cloud environments. Now comes the critical transition: transforming technical findings into business-relevant risk assessments. A Critical CVSS vulnerability on an isolated test server isn't the same risk as a Medium finding on a payment processing system. Context determines priority.

Learning Outcomes

By the end of this week, you will be able to:

  • LO1: Apply risk assessment frameworks to contextualize technical vulnerability findings
  • LO2: Calculate risk scores using likelihood and impact factors relevant to the organization
  • LO3: Prioritize vulnerabilities based on business context, asset criticality, and threat landscape
  • LO4: Create a risk register that maps technical findings to business risks
  • LO5: Communicate risk in terms meaningful to non-technical stakeholders

Introduction: The Risk Analysis Phase

Over the past four weeks, you've accumulated substantial findings:

  • Infrastructure vulnerabilities from Week 3
  • Web application vulnerabilities from Week 4
  • Exploitation proof-of-concepts from Week 5
  • Cloud misconfigurations from Week 6

Raw findings alone don't drive remediation. NovaTech's leadership needs to understand which issues demand immediate attention, which can wait, and how to allocate limited security resources effectively. This week transforms your technical findings into a prioritized risk register that enables informed decision-making.

Engagement Phase

┌─────────────────────────────────────────────────────────────────┐
│                    ENGAGEMENT PROGRESS                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  WEEKS 1-2        WEEKS 3-6          WEEK 7           WEEKS 8-12│
│  ─────────        ─────────          ──────           ──────────│
│  Engagement       Security           Risk             Remediation│
│  Setup            Assessment         Analysis         & Reporting│
│                                      ◄─────                     │
│  ✓ Complete       ✓ Complete         YOU ARE          Upcoming  │
│                                      HERE                       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

1. Risk Fundamentals

Risk in cybersecurity combines the likelihood of a threat exploiting a vulnerability with the resulting business impact. Understanding this relationship is essential for effective prioritization.

The Risk Equation

┌─────────────────────────────────────────────────────────────────┐
│                     THE RISK EQUATION                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│                                                                 │
│         RISK  =  LIKELIHOOD  ×  IMPACT                          │
│                                                                 │
│                                                                 │
│  LIKELIHOOD factors:              IMPACT factors:               │
│  ───────────────────              ───────────────               │
│  • Vulnerability severity         • Data sensitivity            │
│  • Exploit availability           • System criticality          │
│  • Attacker motivation            • Regulatory implications     │
│  • Exposure (internet-facing?)    • Financial consequences      │
│  • Existing controls              • Reputational damage         │
│  • Historical attack patterns     • Operational disruption      │
│                                                                 │
│                                                                 │
│  EXAMPLE:                                                       │
│  ─────────                                                      │
│  Critical CVSS vuln (high likelihood) on isolated test server   │
│  (low impact) = MEDIUM RISK                                     │
│                                                                 │
│  Medium CVSS vuln (moderate likelihood) on payment system       │
│  (high impact) = HIGH RISK                                      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Risk vs. Vulnerability

These terms are often confused. Understanding the distinction is critical for accurate risk communication:

Concept Definition Example
Vulnerability A weakness that could be exploited SQL injection in search function
Threat A potential cause of unwanted impact External attacker, insider threat
Exploit Method of leveraging a vulnerability SQLMap attack extracting data
Risk Potential for loss when threat exploits vulnerability Customer data breach via SQL injection
Control Measure that modifies risk WAF blocking SQL injection patterns

Risk Assessment Frameworks

Several frameworks provide structured approaches to risk assessment:

NIST Risk Management Framework

Federal standard (SP 800-37) defining a comprehensive approach to organizational risk management. Emphasizes continuous monitoring and iterative assessment.

FAIR (Factor Analysis of Information Risk)

Quantitative risk framework that breaks risk into measurable factors. Enables financial quantification of cyber risk for business cases.

OWASP Risk Rating Methodology

Practical framework for rating application security risks. Considers threat agent factors, vulnerability factors, and business impact.

CVSS Environmental Metrics

Extension of CVSS base scores that incorporates organizational context. Adjusts severity based on security requirements and mitigation presence.

2. Likelihood Assessment

Likelihood evaluates how probable it is that a vulnerability will be exploited. This goes beyond CVSS scores to consider real-world factors.

Likelihood Factors

┌─────────────────────────────────────────────────────────────────┐
│                   LIKELIHOOD FACTORS                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  VULNERABILITY CHARACTERISTICS    THREAT LANDSCAPE              │
│  ─────────────────────────────    ────────────────              │
│  • CVSS exploitability metrics    • Known active exploitation   │
│  • Exploit code availability      • Attacker interest in sector │
│  • Skill level required           • Targeted vs opportunistic   │
│  • Authentication required        • Threat intelligence data    │
│                                                                 │
│  EXPOSURE                         EXISTING CONTROLS             │
│  ────────                         ─────────────────             │
│  • Internet-facing?               • WAF/IPS in place?           │
│  • Network segmentation           • Monitoring/detection        │
│  • Access restrictions            • Patch management maturity   │
│  • Attack surface breadth         • Security awareness          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Likelihood Rating Scale

Rating Score Description Indicators
Critical 5 Exploitation is imminent or occurring Active exploitation in the wild, public exploit, no controls
High 4 Exploitation is highly likely Exploit publicly available, internet-facing, minimal controls
Medium 3 Exploitation is possible Exploit exists, some barriers (auth required, internal only)
Low 2 Exploitation is unlikely but possible No public exploit, significant controls, limited exposure
Minimal 1 Exploitation is theoretically possible Theoretical vulnerability, strong controls, isolated system

Exploitability Intelligence Sources

Use these sources to assess real-world exploitability:

Source Information Provided URL
CISA KEV Known Exploited Vulnerabilities catalog cisa.gov/kev
Exploit-DB Public exploit code database exploit-db.com
Metasploit Modules Framework-integrated exploits search cve:YYYY-XXXXX
NVD CVSS scores, references nvd.nist.gov
EPSS Exploit Prediction Scoring System first.org/epss

EPSS (Exploit Prediction Scoring System)

EPSS provides a probability score (0-1) estimating the likelihood that a vulnerability will be exploited in the wild within the next 30 days. This data-driven approach complements CVSS scores. 

# Query EPSS for a specific CVE
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228"

# Response example:
{
    "status": "OK",
    "data": [
        {
            "cve": "CVE-2021-44228",
            "epss": "0.97548",          # 97.5% probability of exploitation
            "percentile": "0.99996"     # Higher than 99.99% of all CVEs
        }
    ]
}

# Interpretation:
# EPSS > 0.7: Very high likelihood - prioritize immediately
# EPSS 0.4-0.7: High likelihood - address urgently
# EPSS 0.1-0.4: Moderate likelihood - planned remediation
# EPSS < 0.1: Lower likelihood - risk-based scheduling

3. Impact Assessment

Impact evaluates the consequences if a vulnerability is successfully exploited. This requires understanding NovaTech's business context, data classification, and regulatory obligations.

Impact Categories

┌─────────────────────────────────────────────────────────────────┐
│                     IMPACT CATEGORIES                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  CONFIDENTIALITY                  INTEGRITY                     │
│  ───────────────                  ─────────                     │
│  • Customer data exposure         • Data modification           │
│  • Intellectual property theft    • System tampering            │
│  • Credential compromise          • Transaction manipulation    │
│  • PII/PHI disclosure             • Code injection              │
│                                                                 │
│  AVAILABILITY                     FINANCIAL                     │
│  ────────────                     ─────────                     │
│  • Service disruption             • Direct monetary loss        │
│  • Business process impact        • Regulatory fines            │
│  • Recovery time/cost             • Remediation costs           │
│  • SLA violations                 • Lost revenue                │
│                                                                 │
│  REGULATORY/LEGAL                 REPUTATIONAL                  │
│  ────────────────                 ────────────                  │
│  • GDPR breach notification       • Customer trust              │
│  • SOC 2 audit findings           • Market perception           │
│  • Contractual violations         • Competitive position        │
│  • Legal liability                • Media coverage              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Asset Criticality Assessment

Impact depends heavily on which assets are affected. NovaTech's assets should be classified by criticality:

Criticality Description NovaTech Examples
Critical Core business operations; breach causes severe damage WorkflowPro production, customer database, payment processing
High Important business functions; breach causes significant damage CI/CD pipeline, internal authentication, email systems
Medium Supporting functions; breach causes moderate damage Development environments, internal wikis, monitoring systems
Low Non-essential functions; breach causes minimal damage Test environments, archived data, marketing sites

Impact Rating Scale

Rating Score Business Impact Description
Critical 5 Existential threat; regulatory action, massive breach, business failure
High 4 Major damage; significant data breach, substantial financial loss, major compliance failure
Medium 3 Moderate damage; limited data exposure, manageable financial impact, operational disruption
Low 2 Minor damage; minimal data exposure, limited financial impact, temporary disruption
Minimal 1 Negligible damage; no sensitive data, trivial financial impact, no operational effect

NovaTech Business Context

Understanding NovaTech's specific context is essential for accurate impact assessment:

Business Model

B2B SaaS platform processing customer workflow data. Enterprise customers with strict security requirements. Revenue directly tied to platform availability and trust.

Data Classification

  • Critical: Customer workflow data, authentication credentials, payment information
  • Sensitive: Customer PII, internal business data, API keys
  • Internal: Employee information, operational metrics
  • Public: Marketing content, documentation

Regulatory Requirements

  • SOC 2 Type II: Target certification; security findings affect audit
  • GDPR: EU customer data; 72-hour breach notification, potential 4% revenue fines
  • CCPA: California customer data; breach liability

Contractual Obligations

Enterprise customers have SLAs requiring 99.9% uptime, security questionnaires on file, and breach notification clauses. Major customers conduct periodic security audits.

4. Risk Calculation and Prioritization

Combining likelihood and impact produces a risk score that enables prioritization.

Risk Matrix

┌─────────────────────────────────────────────────────────────────┐
│                        RISK MATRIX                              │
│                                                                 │
│              │  Minimal │   Low   │  Medium │   High  │Critical │
│    IMPACT    │    (1)   │   (2)   │   (3)   │   (4)   │   (5)   │
├──────────────┼──────────┼─────────┼─────────┼─────────┼─────────┤
│ Critical (5) │    5     │   10    │   15    │   20    │   25    │
│              │   LOW    │  MEDIUM │  HIGH   │ CRITICAL│ CRITICAL│
├──────────────┼──────────┼─────────┼─────────┼─────────┼─────────┤
│ High     (4) │    4     │    8    │   12    │   16    │   20    │
│              │   LOW    │  MEDIUM │  HIGH   │  HIGH   │ CRITICAL│
├──────────────┼──────────┼─────────┼─────────┼─────────┼─────────┤
│ Medium   (3) │    3     │    6    │    9    │   12    │   15    │
│              │   LOW    │   LOW   │ MEDIUM  │  HIGH   │  HIGH   │
├──────────────┼──────────┼─────────┼─────────┼─────────┼─────────┤
│ Low      (2) │    2     │    4    │    6    │    8    │   10    │
│              │   LOW    │   LOW   │   LOW   │ MEDIUM  │ MEDIUM  │
├──────────────┼──────────┼─────────┼─────────┼─────────┼─────────┤
│ Minimal  (1) │    1     │    2    │    3    │    4    │    5    │
│              │   LOW    │   LOW   │   LOW   │   LOW   │   LOW   │
└──────────────┴──────────┴─────────┴─────────┴─────────┴─────────┘
                         L I K E L I H O O D

Risk Score Interpretation

Risk Score Risk Level Remediation Timeline Management Attention
20-25 Critical Immediate (24-48 hours) Executive notification; emergency response
12-19 High Urgent (1-2 weeks) CISO attention; priority remediation
6-11 Medium Planned (30-90 days) Security team tracking; scheduled remediation
1-5 Low As resources permit Documented; addressed opportunistically

Worked Example: Risk Calculation

Finding: SQL Injection in Customer Search

Likelihood Assessment
CVSS Exploitability: High (network-accessible, no auth required)
Exploit Availability: Yes (SQLMap works reliably)
Exposure: Internet-facing production endpoint
Existing Controls: WAF present but not blocking injection
Likelihood Score: 4 (High)
Impact Assessment
Data at Risk: Customer database (PII, workflow data)
Asset Criticality: Critical (production customer data)
Regulatory: GDPR breach notification, SOC 2 failure
Business: Customer trust, enterprise contracts at risk
Impact Score: 5 (Critical)
Risk Calculation

Risk Score = Likelihood × Impact = 4 × 5 = 20 (Critical)

Remediation Timeline: Immediate (24-48 hours)

5. Building the Risk Register

The risk register consolidates all findings with risk assessments, creating a single source of truth for remediation prioritization.

Risk Register Structure

┌─────────────────────────────────────────────────────────────────┐
│                    RISK REGISTER COLUMNS                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  IDENTIFICATION          TECHNICAL DETAILS     RISK ASSESSMENT  │
│  ──────────────          ─────────────────     ───────────────  │
│  • Risk ID               • Vulnerability       • Likelihood     │
│  • Finding Reference     • CVE/CWE             • Impact         │
│  • Date Identified       • Affected Assets     • Risk Score     │
│  • Assessment Phase      • Evidence Reference  • Risk Level     │
│                                                                 │
│  BUSINESS CONTEXT        REMEDIATION           TRACKING         │
│  ────────────────        ───────────           ────────         │
│  • Asset Criticality     • Recommendation      • Owner          │
│  • Data Classification   • Alternatives        • Due Date       │
│  • Compliance Impact     • Effort Estimate     • Status         │
│  • Business Impact       • Dependencies        • Notes          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Sample Risk Register Entries

Risk ID Finding Asset L I Score Level Owner Due Date
R-001 Log4Shell RCE on Jenkins jenkins.novatech 5 5 25 Critical DevOps Immediate
R-002 SQL Injection in Search API api.workflowpro 4 5 20 Critical AppDev 48 hours
R-003 Public S3 Bucket (customer data) novatech-uploads 5 4 20 Critical Cloud Immediate
R-004 IAM Users Without MFA AWS Account 3 4 12 High IT Ops 1 week
R-005 Stored XSS in Workflow Names app.workflowpro 3 4 12 High AppDev 2 weeks
R-006 SSH Open to Internet (Bastion) bastion-prod 4 3 12 High IT Ops 1 week
R-007 Missing Security Headers app.workflowpro 2 3 6 Medium AppDev 30 days
R-008 Outdated TLS on Internal Service internal-api 2 3 6 Medium IT Ops 30 days
R-009 Version Disclosure in Headers Various 2 1 2 Low IT Ops 90 days

Risk Register Best Practices

Consolidate Related Findings

If multiple systems have the same vulnerability, create one risk entry with multiple affected assets rather than separate entries. This helps identify systemic issues.

Assign Clear Ownership

Every risk needs an owner responsible for remediation. Use team names rather than individuals to survive personnel changes.

Set Realistic Due Dates

Due dates should reflect both risk urgency and remediation complexity. Immediate timelines for critical findings; 30-90 days for medium issues.

Track Status Updates

The register should be a living document. Status options: Open, In Progress, Remediated, Accepted (risk acknowledged), Transferred (to third party).

6. Communicating Risk to Stakeholders

Different audiences need different levels of detail and framing. Effective risk communication translates technical findings into business terms.

Audience-Specific Communication

┌─────────────────────────────────────────────────────────────────┐
│              RISK COMMUNICATION BY AUDIENCE                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  EXECUTIVE / BOARD                CISO / SECURITY LEADERSHIP    │
│  ─────────────────                ──────────────────────────    │
│  • Business impact focus          • Risk-based prioritization   │
│  • Financial implications         • Resource requirements       │
│  • Regulatory/legal exposure      • Timeline and milestones     │
│  • Competitive risk               • Metrics and trending        │
│  • 1-2 page summary               • Detailed risk register      │
│                                                                 │
│  TECHNICAL TEAMS                  COMPLIANCE / AUDIT            │
│  ───────────────                  ─────────────────             │
│  • Specific vulnerabilities       • Control deficiencies        │
│  • Remediation steps              • Compliance mapping          │
│  • Technical evidence             • Evidence documentation      │
│  • Testing verification           • Audit trail requirements    │
│  • Detailed findings report       • Gap analysis                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Executive Risk Summary Example

NovaTech Security Assessment - Executive Risk Summary

Overall Risk Posture: HIGH

The security assessment identified 3 critical, 5 high, 8 medium, and 12 low severity findings across infrastructure, applications, and cloud environments.

Key Business Risks
  1. Customer Data Breach Risk: Vulnerabilities in the WorkflowPro application could allow unauthorized access to customer data, triggering GDPR notification requirements and potential fines up to 4% of annual revenue.
  2. Supply Chain Compromise: The CI/CD pipeline (Jenkins) contains critical vulnerabilities that could allow attackers to inject malicious code into customer deployments.
  3. SOC 2 Certification Risk: Multiple findings represent control deficiencies that could impact the upcoming SOC 2 Type II audit.
Recommended Actions
  • Immediate: Address 3 critical findings within 48 hours
  • Urgent: Remediate 5 high findings within 2 weeks
  • Allocate engineering resources for security remediation sprint
  • Engage with SOC 2 auditor regarding identified control gaps
Resource Requirements

Estimated remediation effort: 2-3 engineering sprints. Critical and high findings require immediate attention; medium findings can be incorporated into normal development cycles.

Risk Communication Tips

Lead with Business Impact

Don't start with "we found SQL injection." Start with "customer data is at risk of exposure due to a vulnerability that could result in GDPR fines and customer notification requirements."

Quantify Where Possible

"Potential GDPR fine of up to €4M" is more impactful than "regulatory risk." "50,000 customer records at risk" contextualizes better than "database exposure."

Provide Actionable Recommendations

Executives want to know what to do. "Allocate 2 engineering sprints to security remediation" is actionable. "Fix the vulnerabilities" is not.

Use Comparisons and Analogies

"This is similar to the vulnerability that caused the Equifax breach" provides context for non-technical stakeholders.

7. Risk Acceptance and Exceptions

Not every risk will be remediated immediately. Organizations may accept certain risks based on business constraints. Document these decisions formally.

When Risk Acceptance May Be Appropriate

Risk Acceptance Documentation

Risk Acceptance Form Template

Field Content
Risk ID R-010
Finding Description TLS 1.0 enabled on legacy internal API
Risk Level Medium (Score: 6)
Business Justification Legacy ERP integration requires TLS 1.0; vendor does not support newer protocols. System scheduled for replacement in Q3.
Compensating Controls System isolated on separate VLAN; access restricted to specific IP ranges; additional monitoring enabled.
Acceptance Duration Until Q3 system replacement (6 months)
Review Date Quarterly review required
Accepted By Marcus Webb, CISO
Date 2025-01-25

Critical Risks Should Rarely Be Accepted

Risk acceptance is generally not appropriate for Critical-level risks. If stakeholders push to accept a critical risk, document your professional recommendation against acceptance and escalate to appropriate leadership.

Self-Check Questions

Test your understanding of risk analysis concepts:

Question 1

A vulnerability scanner reports a Critical (CVSS 9.8) finding on an isolated test server that contains no sensitive data and is only accessible from the internal network. How would you rate this risk, and why might it differ from the CVSS score?

Reveal Answer

This would likely be rated as Medium or Low risk despite the Critical CVSS score:

  • Likelihood adjustment: Internal-only access significantly reduces exploitability (attacker needs network access first)
  • Impact adjustment: No sensitive data means breach consequences are limited
  • Asset criticality: Test server is low criticality

Risk calculation:

  • Likelihood: 2 (Low) - requires internal access, limited exposure
  • Impact: 2 (Low) - no sensitive data, non-critical system
  • Risk Score: 2 × 2 = 4 (Low)

This illustrates why contextual risk assessment matters more than raw CVSS scores for prioritization.

Question 2

NovaTech's marketing website has a Medium severity XSS vulnerability (CVSS 5.4). The production WorkflowPro application has the same vulnerability with the same CVSS score. Should these be prioritized equally? Why or why not?

Reveal Answer

No, they should not be prioritized equally. The WorkflowPro vulnerability is significantly higher risk:

Marketing website XSS:

  • Impact: Low - no sensitive data, no authentication, no customer data
  • Risk: Low to Medium

WorkflowPro XSS:

  • Impact: High - authenticated users, customer data access, potential session hijacking, trust relationship with enterprise customers
  • Risk: High

Key difference: Asset criticality and data sensitivity dramatically change impact assessment, even for identical technical vulnerabilities.

Question 3

You've calculated a risk score of 16 (High) for a finding. The development team says they can't address it for 3 months due to a product launch. What options should you present?

Reveal Answer

Present these options to management:

  1. Temporary compensating controls: WAF rules, additional monitoring, access restrictions that reduce likelihood while permanent fix is developed
  2. Risk acceptance: Formal documentation of accepted risk with business justification, compensating controls, and mandatory review date. Requires CISO or executive approval.
  3. Prioritization discussion: Escalate the conflict between security risk and business timeline to appropriate leadership for decision
  4. Partial remediation: Quick fixes that reduce (but don't eliminate) the vulnerability while full fix is developed

Document everything: Your recommendation, the business decision, and the rationale. This protects everyone if an incident occurs.

Question 4

How would you explain the difference between a CVSS score of 9.8 and a risk score of 20 (Critical) to NovaTech's CEO?

Reveal Answer

Executive-friendly explanation:

"The CVSS score (9.8) is like a car's crash test rating—it tells us how dangerous this type of vulnerability could be in general. But risk score (20) is like asking 'how dangerous is this specific car, driven by this driver, on these roads?'"

"CVSS says 'this vulnerability is technically severe.' Our risk score says 'this vulnerability, on our customer-facing system, holding customer data, with attackers actively exploiting it elsewhere, represents a critical business risk to NovaTech specifically.'"

"The risk score incorporates what's unique to us: our business, our data, our customers, and our regulatory obligations."

Question 5

Your risk register has 28 findings. How would you present this to NovaTech's board in a way that's actionable without overwhelming them?

Reveal Answer

Structure the board presentation as:

  1. One-slide summary:
    • Overall risk posture (Critical/High/Medium/Low)
    • Finding count by severity: "3 Critical, 5 High, 8 Medium, 12 Low"
    • One-sentence business impact summary
  2. Top 3-5 business risks: Not technical findings, but business risks (data breach, regulatory penalty, customer trust)
  3. Recommended actions: Resource requirements, timeline, expected outcomes
  4. Decision points: What do you need from the board? Budget approval? Timeline acceptance?

Supporting materials: Full risk register available in appendix for those who want details.

Key principle: Executives need to make decisions, not understand technical details. Focus on "what should we do?" not "what did we find?"

Question 6

Explain how EPSS complements CVSS in risk prioritization. When might EPSS lead you to prioritize differently than CVSS alone?

Reveal Answer

CVSS measures: Theoretical severity (how bad could it be?)

EPSS measures: Exploitation probability (how likely is it to be exploited?)

Scenarios where EPSS changes prioritization:

  1. High CVSS, Low EPSS: Complex vulnerability requiring specialized skills, no public exploit. May deprioritize despite severity.
  2. Medium CVSS, High EPSS: "Easy" vulnerability being actively exploited by automated tools. Prioritize over higher CVSS findings.
  3. Old vulnerabilities: CVSS doesn't change, but EPSS reflects current threat landscape. Old CVE with new exploit kit inclusion shows EPSS spike.
✓ Best practice

Use CVSS for impact understanding, EPSS for likelihood refinement, and organizational context for final prioritization.

Lab: Building NovaTech's Risk Register

Objective

Create a comprehensive risk register from your accumulated assessment findings, applying business context to calculate risk scores and developing executive-ready risk communication materials.

Deliverables

Time Estimate

4-5 hours

Lab Tasks

Part 1: Consolidate Findings (LO1)

  1. Gather all findings from previous weeks:
    • Infrastructure vulnerabilities (Week 3)
    • Web application vulnerabilities (Week 4)
    • Exploitation results (Week 5)
    • Cloud misconfigurations (Week 6)
  2. Create master finding list with unique identifiers
  3. Eliminate duplicates and consolidate related findings
  4. Verify CVSS scores for all CVE-based findings

Part 2: Likelihood Assessment (LO2)

For each finding, assess likelihood considering:

  1. Check CISA KEV catalog for known exploitation
  2. Research EPSS scores where available
  3. Verify exploit availability (Exploit-DB, Metasploit)
  4. Assess exposure (internet-facing vs internal)
  5. Consider existing controls (WAF, segmentation)
  6. Document likelihood score (1-5) with justification

Part 3: Impact Assessment (LO2, LO3)

For each finding, assess impact considering:

  1. Identify affected assets and their criticality
  2. Determine data classification at risk
  3. Assess regulatory implications (GDPR, SOC 2)
  4. Evaluate business operation impact
  5. Consider reputational consequences
  6. Document impact score (1-5) with justification

Part 4: Risk Calculation and Prioritization (LO3)

  1. Calculate risk score (Likelihood × Impact) for each finding
  2. Assign risk level (Critical/High/Medium/Low)
  3. Rank findings by risk score
  4. Assign remediation timelines based on risk level
  5. Identify risk owners (by team/role)

Part 5: Build Risk Register (LO4)

  1. Create risk register spreadsheet with all required columns
  2. Populate with all findings and risk assessments
  3. Add remediation recommendations
  4. Include evidence references
  5. Apply conditional formatting by risk level

Part 6: Executive Communication (LO5)

  1. Create 1-2 page executive summary including:
    • Overall risk posture assessment
    • Top 3-5 business risks
    • Resource requirements
    • Recommended actions
  2. Create risk visualization (pie chart by severity, trend over time if applicable)
  3. Prepare talking points for board presentation

Self-Assessment Checklist

Risk Register Quality

  • ☐ All findings from Weeks 3-6 included
  • ☐ Likelihood scores justified with evidence
  • ☐ Impact scores reflect business context
  • ☐ Risk scores correctly calculated
  • ☐ Remediation timelines appropriate for risk level

Business Context

  • ☐ Asset criticality considered
  • ☐ Data classification factored in
  • ☐ Regulatory requirements addressed
  • ☐ Business impact articulated

Executive Summary

  • ☐ Business-focused language (not technical jargon)
  • ☐ Actionable recommendations included
  • ☐ Resource requirements specified
  • ☐ Appropriate length (1-2 pages)

Visualization

  • ☐ Risk distribution clearly shown
  • ☐ Charts are professional quality
  • ☐ Key insights highlighted

Portfolio Integration

Save your risk analysis deliverables:

The risk register will be a key input to your remediation roadmap (Week 8) and final technical report (Week 10).

🎯 Hands-On Capstone Activities

Week 7 capstone activities - Risk Analysis & Prioritization

🎯 Risk Analysis & Prioritization Lab

Deliverable: Professional capstone component ready for portfolio
Time estimate: 4-8 hours

💡 Capstone Strategy: This work becomes your portfolio—make it job-interview ready.

Resources

Required

NIST SP 800-30: Guide for Conducting Risk Assessments

Federal guidance on risk assessment methodology, including threat identification, vulnerability analysis, and risk determination.

NIST SP 800-30 60 minutes (Chapters 2-3)
Required

OWASP Risk Rating Methodology

Practical framework for calculating risk in application security assessments, with worked examples.

OWASP Risk Rating 45 minutes
Optional

FAIR Institute Resources

Introduction to quantitative cyber risk analysis using the FAIR framework for financial risk quantification.

fairinstitute.org 30 minutes

Weekly Reflection

Prompt

Reflect on the transition from technical assessment to risk analysis. How did applying business context change your perception of which findings are most important? Were there cases where a "lower severity" technical finding became higher priority due to business impact, or vice versa?

Consider the challenges of communicating risk to non-technical stakeholders. How would you explain your risk register to NovaTech's CEO compared to their development team? What language and framing changes are necessary for effective communication across these audiences?

Target length: 250-350 words

Week 07 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz