"Lab 15 — Vulnerability Prioritization with CVSS, EPSS and Threat Intelligence"

Mission Information

Item	Details
Lab	15
Lab Name	Vulnerability Prioritization with CVSS, EPSS and Threat Intelligence
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / Vulnerability Analyst
Environment	CySA+ Vulnerability Management Lab
Primary Systems	Analyst Workstation + Vulnerability Scanner + SIEM
Primary Data Sources	Vulnerability Scan Results, CVE Records, CVSS, EPSS, CISA KEV, Threat Intelligence, Asset Inventory
Skills	Vulnerability Prioritization, CVSS Analysis, EPSS Interpretation, Threat Intelligence, Exploitability Assessment, Asset Criticality, Risk-Based Remediation

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

In Lab 14, you completed a vulnerability assessment and identified multiple vulnerabilities across the environment.

The vulnerability scanner produced findings such as:

Critical: 4
High:     17
Medium:   38
Low:      26

The infrastructure team responds:

We cannot patch everything today. Which vulnerabilities should we remediate first?

Simply selecting every vulnerability with the highest CVSS score is not enough.

Consider:

Vulnerability A

CVSS: 9.8
EPSS: Very Low
Internal System
No known exploitation
Strong compensating controls

versus:

Vulnerability B

CVSS: 8.1
EPSS: High
Internet-Facing
Known Exploitation
Critical Business System

Which one should receive immediate attention?

Potentially:

Vulnerability B

even though its CVSS score is lower.

Your mission is to transform raw vulnerability findings into a risk-based remediation queue.

Mission Objective: Enrich vulnerability findings with exploitability, threat intelligence, exposure, asset criticality, and business context to determine which vulnerabilities should be remediated first.

Mission Objectives

By completing this lab, you will be able to:

explain vulnerability prioritization
interpret CVSS scores
understand CVSS vector information
understand EPSS
interpret EPSS probability and percentile
investigate known exploited vulnerabilities
use threat intelligence during vulnerability assessment
evaluate public exploit availability
assess asset criticality
assess network exposure
identify compensating controls
distinguish severity from organizational risk
create a vulnerability prioritization model
build a remediation queue
justify remediation decisions
document risk-based vulnerability findings

1. Why Vulnerability Prioritization Matters

Modern organizations may identify:

Hundreds
Thousands
or
Millions

of vulnerability findings.

Trying to remediate everything simultaneously is unrealistic.

Security teams therefore need to answer:

What matters most?

A basic scanner workflow provides:

Finding
   ↓
Severity

A mature vulnerability-management workflow provides:

Finding
   ↓
Technical Severity
   ↓
Exploit Probability
   ↓
Threat Activity
   ↓
Exposure
   ↓
Asset Importance
   ↓
Business Impact
   ↓
Remediation Priority

2. Severity Is Not the Same as Risk

Consider:

CVSS 10.0

This indicates very high technical severity.

It does not automatically tell you:

Is the asset exposed?

Is exploitation occurring?

Is the vulnerable feature enabled?

Is the system business-critical?

Are compensating controls present?

Is exploitation probable?

Therefore:

CVSS is an important input to prioritization, not the complete prioritization strategy.

3. Build the Lab Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB15/{CVSS,EPSS,KEV,ThreatIntel,Assets,Prioritization,Screenshots,Reports}

Create:

touch ~/CySA-Lab/Investigations/LAB15/investigation-notes.md

Use:

Assessment ID:
LAB15-PRIORITY-001

4. Import Findings from Lab 14

Select approximately:

5–10 vulnerabilities

from your previous vulnerability assessment.

Create:

~/CySA-Lab/Investigations/LAB15/Prioritization/vulnerabilities.csv

Example structure:

ID,Asset,CVE,CVSS,ScannerSeverity,Port,Service
VULN-001,WEB01,CVE-EXAMPLE-0001,9.8,Critical,443,HTTPS
VULN-002,APP01,CVE-EXAMPLE-0002,8.8,High,8080,HTTP
VULN-003,DB01,CVE-EXAMPLE-0003,7.5,High,5432,PostgreSQL

Use actual CVEs from your authorized lab findings.

5. Review the Initial Scanner Priority

Start by sorting findings using:

CVSS

Example:

Finding	CVSS	Initial Priority
VULN-001	9.8	Critical
VULN-002	8.8	High
VULN-003	7.5	High
VULN-004	6.5	Medium

This represents the scanner-centric view.

You will now enrich it.

6. Review CVSS

CVSS stands for:

Common Vulnerability Scoring System

CVSS communicates technical characteristics of a vulnerability.

Typical base-score ranges:

Score	Severity
0.0	None
0.1–3.9	Low
4.0–6.9	Medium
7.0–8.9	High
9.0–10.0	Critical

7. Understand the CVSS Vector

A CVSS score has more information behind it than the final number.

Depending on the CVSS version, relevant characteristics can include concepts such as:

Attack Vector
Attack Complexity
Privileges Required
User Interaction
Impact

Review the complete vector published for one of your CVEs.

Do not record only:

9.8

Record the characteristics that explain why it received that severity.

8. Investigate Attack Vector

Ask:

Can exploitation occur remotely?

Does the attacker need local access?

Does the attacker need adjacent-network access?

Does exploitation require physical access?

A remotely exploitable vulnerability on an exposed service may warrant greater attention.

9. Investigate Attack Complexity

Determine whether exploitation requires:

Special Conditions
Race Conditions
Specific Configuration
Complex Preparation

Lower attack complexity generally makes exploitation easier.

10. Investigate Privileges Required

Ask:

Does the attacker need authentication?

Does the attacker need a normal account?

Does the attacker already need elevated privileges?

A remotely exploitable vulnerability requiring no prior account can represent significant risk.

11. Investigate User Interaction

Determine whether exploitation requires:

Victim opens file
Victim clicks link
Victim visits page
No user interaction

This changes the exploitation scenario.

12. Understand EPSS

EPSS stands for:

Exploit Prediction Scoring System

EPSS estimates the probability that a published vulnerability will be exploited in the wild within a near-term prediction window.

Conceptually:

CVE
 ↓
EPSS Model
 ↓
Probability of Exploitation

This provides a different perspective from CVSS.

13. CVSS vs EPSS

Think of them as answering different questions.

CVSS:
How technically severe could exploitation be?

EPSS:
How likely is exploitation to occur in the near term?

A vulnerability can therefore have:

High CVSS
Low EPSS

or:

Medium/High CVSS
High EPSS

14. Investigate EPSS Scores

For each CVE, retrieve:

EPSS Score
EPSS Percentile

Record them.

Example:

CVE	CVSS	EPSS	Percentile
CVE-A	9.8	0.02	61st
CVE-B	8.1	0.74	98th
CVE-C	7.5	0.41	95th

Values shown here are illustrative.

Use current data for your actual lab CVEs.

15. Understand EPSS Probability

Suppose:

EPSS:
0.72

Conceptually this indicates a much higher predicted probability of near-term exploitation than:

EPSS:
0.001

Do not interpret EPSS as:

72% of organizations will be compromised.

It is a vulnerability-level exploitation prediction.

16. Understand EPSS Percentile

Percentile provides relative ranking.

Example:

EPSS Percentile:
98%

means the vulnerability has a higher EPSS score than approximately 98% of scored vulnerabilities.

This helps identify vulnerabilities with unusually high exploitation probability.

17. Add EPSS to the Vulnerability Register

Extend your table:

ID	CVE	CVSS	EPSS	EPSS Percentile
VULN-001	CVE-A	9.8	0.02	61%
VULN-002	CVE-B	8.1	0.74	98%
VULN-003	CVE-C	7.5	0.41	95%

Now compare the ranking.

You may discover that:

Highest CVSS

is not:

Highest EPSS

18. Understand Known Exploitation

Predictive scores are valuable.

Observed exploitation can be even more important.

Ask:

Is this vulnerability known to be actively exploited?

One important defensive source is the:

CISA Known Exploited Vulnerabilities Catalog

commonly called:

CISA KEV

19. Check for KEV Inclusion

For each CVE, determine:

KEV:
Yes / No

Add it to the register.

CVE	CVSS	EPSS	KEV
CVE-A	9.8	0.02	No
CVE-B	8.1	0.74	Yes
CVE-C	7.5	0.41	No

A KEV entry provides strong evidence that exploitation has been observed.

20. Understand What KEV Does Not Mean

If:

KEV = No

do not conclude:

The vulnerability is not exploited.

Absence from the catalog is not proof of safety.

Use multiple intelligence sources.

21. Investigate Exploit Availability

Determine whether:

Public Proof of Concept Exists

Exploit Framework Module Exists

Reliable Exploit Is Public

Technical Exploitation Details Exist

For this lab, research availability only.

Do not execute exploit code.

Record:

Exploit Availability:
None Known / PoC / Public Exploit / Unknown

22. Threat Intelligence Enrichment

For important CVEs, investigate whether threat intelligence identifies:

Active Exploitation
Ransomware Association
Threat Actor Usage
Botnet Activity
Mass Scanning
Malware Campaigns
Sector Targeting

Record only information relevant to your environment.

23. Build Threat Context

Example:

CVE:
CVE-XXXX-YYYY

Known Exploitation:
Yes

EPSS:
High

KEV:
Yes

Threat Intelligence:
Observed in ransomware campaigns

This vulnerability should probably receive greater attention than its CVSS score alone suggests.

24. Add Asset Context

Now identify where each vulnerability exists.

For each affected asset, document:

Asset Name
Asset Type
Business Function
Data Sensitivity
Business Criticality
Environment
Owner

Example:

Asset	Function	Criticality
WEB01	Public Website	High
DEV01	Development	Low
DB01	Customer Database	Critical

25. Create an Asset Criticality Scale

For the lab, use:

1 — Low
2 — Moderate
3 — High
4 — Critical

Example:

Developer Workstation:
2

Internal Application Server:
3

Identity Infrastructure:
4

Customer Database:
4

Document why the asset received the rating.

26. Evaluate Network Exposure

For each vulnerability, determine:

Internet-Facing
Partner-Facing
Internal Network
Restricted Segment
Local Only

Exposure can significantly change priority.

Example:

Vulnerability A:
CVSS 9.8
Internal isolated system

Vulnerability B:
CVSS 8.1
Internet-facing service

Vulnerability B may deserve faster remediation.

27. Validate Whether the Vulnerable Service Is Reachable

Use existing evidence from Lab 14.

For authorized lab systems, you may confirm:

nmap -sV -p <port> <target>

Record:

Service Reachable:
Yes / No

Source Network:
<network>

Authentication Required:
Yes / No

Do not exploit the service.

28. Investigate Vulnerable Feature Usage

Sometimes a product is installed, but the vulnerable feature is:

Disabled
Not Exposed
Not Configured
Not Used

This can affect practical risk.

Record:

Vulnerable Feature:
Enabled / Disabled / Unknown

29. Identify Compensating Controls

Determine whether controls reduce exploitation likelihood or impact.

Examples:

Firewall
WAF
Network Segmentation
MFA
EDR
Application Allowlisting
IPS
Restricted Administrative Access
Zero Trust Access Controls

Record:

Compensating Controls:
Present / Partial / None

30. Understand Compensating-Control Limitations

A compensating control may reduce risk.

It does not necessarily remove the vulnerability.

For example:

Vulnerable Server
      +
Firewall Restriction

means:

Underlying Vulnerability Still Exists

but exposure may be reduced.

31. Consider Business Impact

Ask:

What happens if this system is compromised?

Could sensitive data be exposed?

Could business services stop?

Could the attacker gain privileged access?

Could compromise enable lateral movement?

Could regulatory obligations be affected?

Classify:

Low
Moderate
High
Critical

32. Consider Vulnerability Age

Record:

CVE Publication Date

Older vulnerabilities can remain dangerous, especially when:

Exploit Code Is Mature
Attackers Understand It Well
Patches Have Long Been Available

But vulnerability age alone should not determine priority.

33. Consider Patch Availability

Record:

Patch Available:
Yes / No

Also consider:

Vendor Fix
Upgrade
Configuration Workaround
Mitigation
No Fix Available

34. Consider Remediation Complexity

Rate:

Low
Medium
High

Examples:

Low:
Simple package update

Medium:
Application update requiring testing

High:
Major platform upgrade affecting business services

Do not reduce the risk rating simply because remediation is difficult.

Instead, use difficulty when planning remediation.

35. Build the Enriched Vulnerability Register

Your register should now include:

Field	Purpose
CVE	Vulnerability identity
CVSS	Technical severity
EPSS	Exploitation probability
EPSS Percentile	Relative exploit likelihood
KEV	Known exploitation
Exploit Availability	Exploitation accessibility
Asset Criticality	Business importance
Exposure	Reachability
Threat Intelligence	Current threat context
Compensating Controls	Existing protection
Business Impact	Potential organizational effect
Remediation Complexity	Operational effort

This is significantly more useful than a basic scanner report.

36. Create a Simple Prioritization Model

For this lab, create a transparent scoring model.

Example:

CVSS Severity           → 1–4
EPSS Priority           → 1–4
Known Exploitation      → 0 or 4
Asset Criticality       → 1–4
Exposure                → 1–4
Threat Intelligence     → 0–3

Then calculate:

Priority Score =
CVSS
+ EPSS
+ Known Exploitation
+ Asset Criticality
+ Exposure
+ Threat Context

This is a training model, not an industry-standard formula.

37. Create CVSS Priority Values

Example:

CVSS	Points
Low	1
Medium	2
High	3
Critical	4

38. Create EPSS Priority Values

For your lab model, you could use:

EPSS	Points
Very Low	1
Low	2
Elevated	3
High	4

Document the thresholds you choose.

The important requirement is consistency.

39. Add Known Exploitation Weight

For example:

KEV = No
0 points

KEV = Yes
4 points

This intentionally increases the priority of vulnerabilities with observed exploitation evidence.

40. Add Asset Criticality

Use:

Asset	Points
Low	1
Moderate	2
High	3
Critical	4

41. Add Exposure

Example:

Exposure	Points
Local / Highly Restricted	1
Internal	2
Partner / Broad Internal	3
Internet-Facing	4

42. Add Threat Intelligence

Example:

Threat Context	Points
No relevant activity	0
Limited reports	1
Active campaigns	2
Directly relevant active exploitation	3

43. Calculate Priority Scores

Example:

Vulnerability A

CVSS Critical       = 4
EPSS Very Low       = 1
KEV No              = 0
Asset Moderate      = 2
Internal            = 2
Threat Context      = 0

Total:
9

Vulnerability B

CVSS High           = 3
EPSS High           = 4
KEV Yes             = 4
Asset Critical      = 4
Internet-Facing     = 4
Threat Context      = 3

Total:
22

Despite the lower CVSS:

Vulnerability B

is clearly the more urgent remediation candidate in this example.

44. Create Priority Bands

For your training model, define bands appropriate to the scoring range.

Example:

Critical Priority
High Priority
Medium Priority
Routine Priority

Document the thresholds used.

The specific numbers matter less than having a repeatable and explainable process.

45. Create the Remediation Queue

Sort vulnerabilities by:

Priority Score

Example:

Rank	CVE	CVSS	EPSS	KEV	Asset	Priority
1	CVE-B	8.1	High	Yes	Critical	Critical
2	CVE-C	7.5	High	No	Critical	High
3	CVE-A	9.8	Low	No	Moderate	Medium

Now you have a risk-based remediation queue.

46. Compare Scanner Priority with Risk Priority

Create:

CVE	Scanner Rank	Risk Rank
CVE-A	1	3
CVE-B	2	1
CVE-C	3	2

Ask:

Why did the rankings change?

Document the answer.

47. Identify Immediate-Action Vulnerabilities

Look for combinations such as:

Known Exploited
      +
Internet-Facing
      +
Critical Asset

or:

High EPSS
      +
Public Exploit
      +
No Compensating Controls

These often deserve accelerated remediation.

48. Identify Lower Immediate-Priority Findings

A vulnerability may be temporarily lower priority when:

Low Exploit Probability
Restricted Network
Non-Critical Asset
Vulnerable Feature Disabled
Strong Compensating Controls
No Relevant Threat Activity

This does not mean:

Ignore It Forever

It means:

Schedule Based on Risk

49. Determine Remediation Actions

For each prioritized vulnerability, recommend:

Patch
Upgrade
Configuration Change
Disable Service
Remove Software
Restrict Access
Apply Vendor Mitigation
Implement Compensating Control

Include a target timeframe.

50. Create Remediation SLAs

For the lab, define example service-level targets such as:

Critical Priority:
Immediate / Emergency Change Process

High Priority:
Accelerated Remediation

Medium Priority:
Standard Patch Cycle

Routine:
Planned Maintenance

Real organizations should define exact timelines based on their own policies and regulatory requirements.

51. Prioritize When a Patch Is Unavailable

If:

Patch Available:
No

consider:

Disable Vulnerable Feature
Restrict Network Access
Deploy WAF/IPS Rule
Increase Monitoring
Segment Asset
Remove Service
Vendor Workaround

Document:

Temporary Mitigation

and:

Permanent Remediation

separately.

52. Identify Risk Acceptance Candidates

Sometimes an organization may accept vulnerability risk temporarily.

Possible reasons:

Very Low Exposure
Very Low Exploitability
Non-Critical Asset
Strong Compensating Controls
Remediation Would Cause Disproportionate Business Impact

Risk acceptance should be:

Documented
Approved
Time-Bounded
Reviewed

The analyst should not independently declare business risk accepted unless authorized.

53. Build a Prioritization Decision Record

For every top vulnerability, document:

Why is this vulnerability prioritized?

What evidence supports the decision?

What is the business impact?

What is the exploitability?

What controls already exist?

What remediation is recommended?

This makes the prioritization defensible.

54. Create an Executive Vulnerability View

Leadership usually does not need every scanner detail.

Create:

Priority	Count	Required Action
Critical	2	Immediate
High	5	Accelerated
Medium	14	Scheduled
Routine	25	Standard cycle

Then identify:

Top 5 Vulnerabilities Requiring Action

55. Create a Technical Vulnerability View

Technical teams need more detail.

Include:

CVE
Asset
Service
Port
CVSS
EPSS
KEV
Exploit Availability
Exposure
Asset Criticality
Patch
Mitigation
Owner
Due Date

Different audiences require different reporting.

56. Mission Challenge — Prioritize the Queue

Your security manager provides five findings:

Finding A
CVSS: 9.8
EPSS: Low
KEV: No
Asset: Internal Test Server
Exposure: Restricted

Finding B
CVSS: 8.1
EPSS: High
KEV: Yes
Asset: Internet-Facing Production Server
Exposure: Internet

Finding C
CVSS: 7.5
EPSS: High
KEV: No
Asset: Identity Infrastructure
Exposure: Internal

Finding D
CVSS: 9.0
EPSS: Very Low
KEV: No
Asset: Development Workstation
Exposure: Internal

Finding E
CVSS: 6.5
EPSS: Elevated
KEV: Yes
Asset: Business Application
Exposure: Partner-Facing

Your task is to:

Rank all five findings.
Explain why each received its position.
Identify which requires immediate remediation.
Identify which can enter the standard patch cycle.
Identify required compensating controls.
Determine whether any require emergency change.
Document the reasoning.

There is no useful answer based on CVSS alone.

57. Build the Final Prioritization Table

Create:

Rank	Finding	CVSS	EPSS	KEV	Asset Criticality	Exposure	Final Priority
1	B	8.1	High	Yes	High	Internet	Critical
2	C	7.5	High	No	Critical	Internal	High
3	E	6.5	Elevated	Yes	High	Partner	High
4	A	9.8	Low	No	Low	Restricted	Medium
5	D	9.0	Very Low	No	Low	Internal	Medium

Your final ordering should follow the scoring methodology you documented.

58. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB15/investigation-notes.md

Use:

# LAB15 Vulnerability Prioritization

## Assessment ID

LAB15-PRIORITY-001

## Vulnerability Dataset

Document the findings imported from Lab 14.

## CVSS Analysis

For each vulnerability document:
- CVSS score
- severity
- important vector characteristics

## EPSS Analysis

Document:
- EPSS probability
- EPSS percentile

## Known Exploitation

Document:
- CISA KEV status
- other confirmed exploitation evidence

## Exploit Availability

Document:
- no known public exploit
- PoC
- public exploit
- unknown

## Threat Intelligence

Document relevant:
- campaigns
- threat actors
- ransomware
- mass exploitation
- sector targeting

## Asset Context

Document:
- asset
- business function
- criticality
- data sensitivity

## Exposure

Document:
- internet
- partner
- internal
- restricted
- local

## Compensating Controls

Document existing controls.

## Business Impact

Low / Moderate / High / Critical

## Remediation

Document:
- patch
- upgrade
- mitigation
- compensating controls
- owner
- target timeframe

## Final Priority

Critical / High / Medium / Routine

## Analyst Rationale

Explain why the vulnerability received its final position in the remediation queue.

59. Example Analyst Findings

A lab assessment might resemble:

Assessment:
LAB15-PRIORITY-001

Highest Technical Severity:
VULN-001
CVSS 9.8

Highest Risk-Based Priority:
VULN-002
CVSS 8.1

Reason:
VULN-002 has substantially higher predicted exploitation probability, evidence of known exploitation, external exposure, and affects a critical business asset.

VULN-001:
Although technically critical, the vulnerable system is restricted, exploitation probability is lower, and compensating controls reduce immediate exposure.

Priority Decision:
VULN-002 should be remediated first.

Recommended Action:
Apply the vendor remediation through the accelerated change process.

Temporary Controls:
Restrict exposure and increase monitoring until remediation is complete.

Key Finding:
Technical severity alone would have produced a different remediation order than risk-based prioritization.

60. Evidence to Capture

Capture:

01-lab14-findings.png
02-initial-cvss-ranking.png
03-cvss-details.png
04-cvss-vector.png
05-epss-score.png
06-epss-percentile.png
07-kev-check.png
08-exploit-availability.png
09-threat-intelligence.png
10-asset-criticality.png
11-network-exposure.png
12-compensating-controls.png
13-enriched-register.png
14-priority-scoring.png
15-scanner-vs-risk-ranking.png
16-remediation-queue.png
17-executive-summary.png
18-technical-summary.png
19-final-prioritization.png
20-analyst-rationale.png

61. Validation Checklist

Vulnerabilities from Lab 14 were imported
Initial scanner ranking was documented
CVSS scores were reviewed
CVSS characteristics were investigated
EPSS was understood
EPSS scores were collected
EPSS percentiles were reviewed
CVSS and EPSS were compared
KEV status was investigated
Known exploitation was considered
Public exploit availability was researched
Threat-intelligence context was collected
Asset criticality was assigned
Network exposure was evaluated
Vulnerable service reachability was reviewed
Vulnerable feature usage was considered
Compensating controls were documented
Business impact was assessed
Patch availability was reviewed
Remediation complexity was considered
Enriched vulnerability register was created
Prioritization methodology was documented
Priority scores were calculated
Scanner ranking was compared with risk ranking
Remediation queue was created
Immediate-action vulnerabilities were identified
Remediation actions were recommended
Executive view was created
Technical view was created
Analyst rationale was documented
Evidence was captured

62. Mission Review

In this mission, you moved beyond:

CVSS 9.8
=
Patch First

and built a more realistic vulnerability-management approach.

You followed:

Vulnerability
      ↓
CVSS
      ↓
EPSS
      ↓
Known Exploitation
      ↓
Threat Intelligence
      ↓
Asset Criticality
      ↓
Exposure
      ↓
Compensating Controls
      ↓
Business Impact
      ↓
Risk-Based Priority
      ↓
Remediation Queue

The critical lesson is:

The most severe vulnerability is not always the vulnerability that presents the greatest immediate risk to the organization.

Effective prioritization combines:

Technical Severity
        +
Exploit Probability
        +
Observed Exploitation
        +
Threat Context
        +
Asset Criticality
        +
Exposure
        +
Business Impact
        =
Remediation Priority

Skills Developed

After completing this mission, you should be able to:

interpret CVSS beyond the base score
understand EPSS
interpret exploitation probability
investigate known exploited vulnerabilities
incorporate threat intelligence into vulnerability management
assess exploit availability
evaluate asset criticality
assess network exposure
evaluate compensating controls
distinguish severity from risk
create risk-based prioritization models
build remediation queues
define remediation urgency
communicate vulnerability priorities to technical teams
create executive vulnerability summaries
justify remediation decisions with evidence

What’s Next?

Lab 16 — Threat Intelligence and IOC Enrichment

You have now used threat intelligence to improve vulnerability prioritization.

The next mission expands that capability beyond CVEs.

You will take raw indicators from security investigations and determine:

What do we know about this indicator?

You will investigate:

IP addresses
domains
URLs
file hashes
threat-intelligence sources
indicator reputation
WHOIS and registration context
DNS context
passive intelligence concepts
malware associations
threat actor associations
confidence levels
false-positive considerations
IOC relationships
enrichment workflows
SIEM pivoting
threat-intelligence reporting

The workflow progresses from:

Raw IOC
   ↓
IP / Domain / Hash / URL

to:

Raw IOC
   ↓
Threat Intelligence
   ↓
Context
   ↓
Relationships
   ↓
Confidence
   ↓
SIEM Correlation
   ↓
Analyst Decision

➡️ Next: Lab 16 — Threat Intelligence and IOC Enrichment