CSY399 Week 07 - Week 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

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.
Supply Chain Compromise: The CI/CD pipeline (Jenkins) contains critical vulnerabilities that could allow attackers to inject malicious code into customer deployments.
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

Compensating controls: Other controls sufficiently mitigate the risk
Business constraints: System cannot be changed due to business requirements
Temporary acceptance: Remediation planned but timeline extended
Cost-benefit: Remediation cost exceeds potential loss (rare for high risks)
End of life: System being decommissioned; remediation not worth investment

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:

Temporary compensating controls: WAF rules, additional monitoring, access restrictions that reduce likelihood while permanent fix is developed
Risk acceptance: Formal documentation of accepted risk with business justification, compensating controls, and mandatory review date. Requires CISO or executive approval.
Prioritization discussion: Escalate the conflict between security risk and business timeline to appropriate leadership for decision
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:

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
Top 3-5 business risks: Not technical findings, but business risks (data breach, regulatory penalty, customer trust)
Recommended actions: Resource requirements, timeline, expected outcomes
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:

High CVSS, Low EPSS: Complex vulnerability requiring specialized skills, no public exploit. May deprioritize despite severity.
Medium CVSS, High EPSS: "Easy" vulnerability being actively exploited by automated tools. Prioritize over higher CVSS findings.
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

Complete Risk Register: All findings with risk scores and prioritization
Executive Risk Summary: 1-2 page summary for NovaTech leadership
Risk Visualization: Charts/graphs showing risk distribution

Time Estimate

4-5 hours

Lab Tasks

Part 1: Consolidate Findings (LO1)

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

Part 2: Likelihood Assessment (LO2)

For each finding, assess likelihood considering:

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

Part 3: Impact Assessment (LO2, LO3)

For each finding, assess impact considering:

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

Part 4: Risk Calculation and Prioritization (LO3)

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

Part 5: Build Risk Register (LO4)

Create risk register spreadsheet with all required columns
Populate with all findings and risk assessments
Add remediation recommendations
Include evidence references
Apply conditional formatting by risk level

Part 6: Executive Communication (LO5)

Create 1-2 page executive summary including:
- Overall risk posture assessment
- Top 3-5 business risks
- Resource requirements
- Recommended actions
Create risk visualization (pie chart by severity, trend over time if applicable)
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:

07-risk-analysis/
- risk-register-novatech.xlsx — Complete risk register
- executive-summary.pdf — Board-ready summary
- risk-visualization.pdf — Charts and graphs
- risk-methodology.pdf — Documentation of your approach

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