Lab 03 Vulnerability Assessment and Remediation

Mission Information

Difficulty: Beginner → Intermediate
Estimated Time: 75–90 Minutes
Lab Type: Vulnerability Management
Primary Focus: Vulnerability Assessment, Risk Prioritization & Remediation
Certification: CompTIA Security+

Mission Objective

Organizations may discover hundreds or thousands of vulnerabilities across their environments.

The security team’s responsibility is not simply to produce a vulnerability list.

Your mission is to determine:

What is vulnerable, what actually matters, what should be fixed first, and how should the organization reduce the risk?

You will work through:

Asset Identification → Vulnerability Discovery → Validation → Risk Analysis → Prioritization → Remediation → Verification

By completing this lab, you should understand how vulnerability management works as an ongoing enterprise security process.

Scenario

GoHackersCloud Financial Services recently completed a scheduled vulnerability assessment across its enterprise environment.

The security team identified weaknesses affecting:

• Employee workstations

• Public-facing applications

• Internal servers

• Databases

• Network infrastructure

• Cloud workloads

• Administrative systems

The initial assessment produced many findings.

Management does not want a simple vulnerability list.

They want to know:

1. Which vulnerabilities represent the greatest risk?

2. Which systems are most important?

3. Which vulnerabilities should be remediated first?

4. What should happen when immediate remediation is impossible?

5. How will the organization verify that vulnerabilities have actually been resolved?

You have been assigned to create the Vulnerability Remediation Plan.

Phase 1 — Understand Vulnerability Management

Begin by understanding the overall process.

A mature vulnerability-management lifecycle follows:

Discover

↓

Assess

↓

Validate

↓

Prioritize

↓

Remediate

↓

Verify

↓

Monitor

This process repeats continuously.

A vulnerability assessment is therefore not a one-time activity.

New vulnerabilities appear as:

• Software changes.

• Systems are deployed.

• New threats emerge.

• Configurations change.

• New vulnerabilities are discovered.

• Business environments evolve.

Phase 2 — Identify the Assets

Before evaluating vulnerabilities, understand the systems being protected.

Create an asset inventory.

Asset	Business Function	Exposure	Criticality
Customer Portal	Customer Services	Internet	Critical
Customer Database	Customer Information	Internal	Critical
Identity Platform	Authentication	Internal	Critical
Employee Workstation	Employee Productivity	Internal	Medium
File Server	Business Documents	Internal	High
Development Server	Development	Internal	Medium

Asset context is important because identical vulnerabilities can represent very different risks on different systems.

Phase 3 — Determine Asset Criticality

Classify assets according to their importance.

Critical

Compromise could significantly affect the organization.

Examples:

• Identity systems

• Customer databases

• Payment systems

• Critical business applications

High

Important systems with substantial business impact.

Medium

Systems supporting normal business operations.

Low

Systems with limited organizational impact.

Ask:

What would happen to the business if this asset were compromised or unavailable?

This becomes an important part of vulnerability prioritization.

Phase 4 — Review Vulnerability Findings

Review the simulated vulnerability assessment.

Your findings may include:

• Missing security updates

• Unsupported software

• Weak configurations

• Unnecessary services

• Excessive permissions

• Weak encryption

• Exposed management interfaces

• Default configurations

• Application vulnerabilities

• Cloud configuration weaknesses

For each finding, identify:

Affected Asset

Where does the weakness exist?

Vulnerability

What security problem exists?

Exposure

Who could potentially reach it?

Severity

How serious is the technical weakness?

Business Context

How important is the affected system?

Phase 5 — Understand Vulnerability Sources

Vulnerabilities may be discovered through several activities.

Examples include:

Vulnerability Assessments

Identify known weaknesses across systems.

Configuration Reviews

Identify insecure system settings.

Patch Reviews

Identify missing security updates.

Application Assessments

Identify software security weaknesses.

Cloud Security Reviews

Identify insecure cloud configurations.

Penetration Tests

Demonstrate whether weaknesses can realistically be exploited.

Security Monitoring

May reveal previously unknown exposure.

Security+ learners should understand that vulnerability management combines information from multiple sources.

Phase 6 — Separate Vulnerabilities from Threats and Risks

These concepts are closely related but different.

Asset

Something the organization values.

Threat

Something capable of causing harm.

Vulnerability

A weakness that could potentially be exploited.

Risk

The potential impact when a threat can take advantage of a vulnerability affecting an asset.

A simple model is:

Asset + Threat + Vulnerability → Risk

For example:

Critical Customer Application

External Attacker

Security Weakness

=

Business Risk

Understanding these relationships is important for Security+.

Phase 7 — Review Technical Severity

Vulnerability findings often include a technical severity rating.

Typical classifications include:

• Critical

• High

• Medium

• Low

• Informational

Technical severity helps determine how serious a vulnerability may be.

However:

Technical severity alone should not determine remediation priority.

Business context must also be considered.

Phase 8 — Understand CVSS

The Common Vulnerability Scoring System (CVSS) provides a standardized method for describing vulnerability severity.

Scores generally range from:

0.0 → 10.0

Higher scores indicate greater technical severity.

CVSS considers characteristics related to factors such as:

• Attack requirements

• Complexity

• Required privileges

• User interaction

• Security impact

Students do not need to treat the score as the complete risk decision.

CVSS provides technical context.

The organization still needs to determine business risk.

Phase 9 — Add Business Context

Consider two systems with the same vulnerability.

System A

Public customer application containing sensitive information.

System B

Isolated internal test system containing no production information.

Even if the technical vulnerability is identical, the business risk may differ substantially.

Consider:

• Asset criticality

• Internet exposure

• Data sensitivity

• Business function

• Existing controls

• Exploitability

• Regulatory requirements

This produces more meaningful prioritization.

Phase 10 — Evaluate Exposure

Determine how accessible each vulnerable system is.

Classify exposure as:

Internet-Facing

Potentially reachable by external attackers.

Partner-Accessible

Reachable through trusted external relationships.

Internal

Accessible from organizational networks.

Restricted

Available only through controlled environments.

Isolated

Minimal connectivity.

Generally, greater exposure increases potential risk.

However, exposure must still be considered alongside vulnerability severity and asset importance.

Phase 11 — Evaluate Exploitability

Determine how realistically the vulnerability could be abused.

Consider:

• Is exploitation known to occur?

• Is the weakness easy to reach?

• Are privileges required?

• Is user interaction necessary?

• Are effective security controls already present?

• Is exploitation practical within the environment?

Classify exploitability as:

High

Relatively straightforward to exploit.

Medium

Requires additional conditions.

Low

Difficult or highly constrained.

This helps distinguish theoretical vulnerabilities from immediate operational risks.

Phase 12 — Consider Threat Intelligence

Security teams should also consider what is happening outside their organization.

A vulnerability may become significantly more important when:

• Attackers are actively exploiting it.

• Exploitation is increasing.

• Similar organizations are being targeted.

• The affected technology is widely attacked.

• Security authorities recommend urgent remediation.

This is why vulnerability prioritization should evolve as the threat landscape changes.

Phase 13 — Identify False Positives

Not every vulnerability report is necessarily correct.

A scanner might incorrectly report a vulnerability because of:

• Incorrect service identification

• Unusual configuration

• Incomplete information

• Compensating controls

• Version-detection problems

Classify findings as:

Confirmed

The weakness exists.

Probable

Evidence strongly suggests it exists.

False Positive

The reported vulnerability does not apply.

Needs Validation

Additional investigation is required.

Do not waste remediation resources on findings that are not genuine.

Phase 14 — Prioritize the Vulnerabilities

Now combine the information.

For each vulnerability consider:

Technical Severity

Asset Criticality

Exposure

Exploitability

Threat Activity

Existing Controls

=

Remediation Priority

For example:

Finding	Severity	Asset	Exposure	Priority
Critical Application Weakness	Critical	Critical	Internet	Immediate
Missing Server Update	High	Critical	Internal	High
Workstation Misconfiguration	Medium	Medium	Internal	Medium
Test System Finding	High	Low	Isolated	Lower

This demonstrates why severity and priority are not always identical.

Phase 15 — Build the Vulnerability Risk Register

Create a central vulnerability register.

ID	Asset	Finding	Severity	Business Risk	Priority
VULN-01	Customer Portal	Critical Security Weakness	Critical	Critical	Immediate
VULN-02	Identity Platform	Missing Update	High	Critical	Immediate
VULN-03	File Server	Weak Configuration	Medium	High	High
VULN-04	Workstation	Outdated Software	Medium	Medium	Medium
VULN-05	Test Server	Configuration Issue	Low	Low	Planned

The register becomes the central tracking mechanism for vulnerability remediation.

Phase 16 — Determine the Appropriate Risk Response

Organizations have several ways to respond to risk.

Security+ commonly expects students to understand:

Mitigate

Implement controls to reduce risk.

Avoid

Stop the activity creating the risk.

Transfer

Shift part of the financial or operational risk to another party.

Accept

Formally acknowledge and retain the risk.

For vulnerability management, remediation is generally a form of risk mitigation.

However, organizations may legitimately use another response depending on business requirements.

Phase 17 — Develop the Remediation Strategy

For each confirmed vulnerability, determine the appropriate corrective action.

Possible remediation approaches include:

Patch

Apply a vendor security update.

Upgrade

Move to a supported and secure software version.

Reconfigure

Correct insecure settings.

Disable

Remove unnecessary functionality.

Remove

Decommission unnecessary systems or software.

Restrict

Reduce network or user access.

Replace

Move away from unsupported technology.

Implement Additional Controls

Reduce risk when direct remediation cannot occur immediately.

The remediation should address the underlying security problem, not simply hide the finding.

Phase 18 — Understand Compensating Controls

Sometimes a vulnerability cannot immediately be fixed.

Possible reasons include:

• Business-critical application dependencies

• Legacy systems

• Vendor limitations

• Operational requirements

• Maintenance restrictions

In these cases, implement compensating controls.

Examples include:

• Additional access restrictions

• Network isolation

• Stronger authentication

• Increased monitoring

• Application protection

• Reduced privileges

A compensating control does not necessarily remove the vulnerability.

It reduces the associated risk.

Phase 19 — Establish Remediation Timeframes

Define remediation expectations based on organizational risk.

For example:

Critical

Immediate or emergency remediation.

High

Priority remediation.

Medium

Scheduled remediation.

Low

Planned improvement.

Actual timelines should follow organizational policy and business requirements.

The important principle is:

Higher-risk vulnerabilities should normally receive faster remediation.

Phase 20 — Assign Ownership

Every vulnerability should have an owner.

Possible owners include:

• Infrastructure team

• Application team

• Cloud team

• Network team

• Endpoint team

• Security team

• Business system owner

A finding without ownership can remain unresolved indefinitely.

Your register should therefore include:

Finding → Owner → Action → Target Date → Status

Phase 21 — Track Remediation Status

Use consistent statuses.

Open

No remediation completed.

In Progress

Remediation is underway.

Pending Validation

The team reports that remediation is complete.

Remediated

Independent verification confirms resolution.

Risk Accepted

Authorized management has accepted the remaining risk.

False Positive

The vulnerability was determined not to apply.

This provides accountability throughout the lifecycle.

Phase 22 — Verify Remediation

Do not assume a vulnerability has disappeared simply because someone says it was fixed.

Verification should determine:

Does the original weakness still exist?

The process becomes:

Original Finding

↓

Remediation

↓

Reassessment

↓

Validation

↓

Closure

If the weakness remains, return the finding to the remediation process.

Phase 23 — Check for Remediation Impact

Security changes can sometimes affect business operations.

After remediation, consider whether:

• Applications still function correctly.

• Users retain legitimate access.

• Business processes continue.

• Security monitoring remains operational.

• New weaknesses were introduced.

Security improvements should reduce risk without unnecessarily disrupting legitimate business activity.

Phase 24 — Review Exceptions

Some vulnerabilities may remain unresolved for legitimate business reasons.

Document:

• Vulnerability

• Business justification

• Remaining risk

• Compensating controls

• Responsible owner

• Approval

• Review date

Exceptions should not remain permanent simply because they were once approved.

They require periodic review.

Phase 25 — Measure Vulnerability Management

Organizations should measure whether the vulnerability-management program is improving.

Useful metrics might include:

• Number of critical findings

• Number of overdue findings

• Average remediation time

• Percentage of vulnerabilities remediated

• Recurring vulnerabilities

• Vulnerabilities by asset type

• Vulnerabilities by business unit

Metrics should help answer:

Are we reducing meaningful security risk over time?

Phase 26 — Create the Remediation Roadmap

Organize remediation into practical stages.

Immediate

Address:

• Critical internet-facing vulnerabilities

• Critical identity weaknesses

• Actively exploited vulnerabilities

• Major sensitive-data exposure

Short Term

Address:

• High-risk server vulnerabilities

• Important configuration weaknesses

• Excessive exposure

• Unsupported critical software

Planned

Address:

• Medium-risk findings

• Hardening improvements

• Lower-risk software updates

Continuous

Improve:

• Asset management

• Patch management

• Configuration standards

• Vulnerability monitoring

• Security metrics

Phase 27 — Build the Final Vulnerability Remediation Plan

Your final plan should contain:

Executive Summary

Describe the overall vulnerability posture.

Scope

Identify the systems assessed.

Asset Criticality

Identify important business systems.

Vulnerability Summary

Summarize findings by severity.

Risk Prioritization

Explain which vulnerabilities matter most and why.

Remediation Actions

Document corrective actions.

Compensating Controls

Identify temporary risk-reduction measures.

Ownership

Assign responsible teams.

Verification

Explain how remediation will be validated.

Metrics

Define how progress will be measured.

Lab Deliverables

Students should complete:

1. Asset Criticality Register

Identify and classify important systems.

2. Vulnerability Findings Register

Document the vulnerabilities discovered.

3. Vulnerability Validation Review

Separate confirmed findings, false positives, and findings requiring additional investigation.

4. Risk Prioritization Matrix

Combine technical severity with business context.

5. Vulnerability Remediation Plan

Determine how each significant weakness should be addressed.

6. Compensating Control Plan

Document risk reduction for vulnerabilities that cannot immediately be remediated.

7. Remediation Tracking Register

Assign ownership, priority, target status, and verification requirements.

8. Final Vulnerability Assessment Report

Summarize the organization’s vulnerability posture and recommended actions.

Security+ Exam Perspective

For CompTIA Security+, understand these distinctions:

Vulnerability

A weakness.

Threat

Something capable of exploiting a weakness.

Risk

The potential loss or impact resulting from a threat exploiting a vulnerability.

Vulnerability Assessment

Identifies and evaluates potential weaknesses.

Penetration Test

Attempts to validate whether weaknesses can be exploited within an authorized scope.

Patch Management

Manages security and software updates.

Compensating Control

Reduces risk when the preferred control cannot currently be implemented.

False Positive

A vulnerability reported as present when it does not actually apply.

Risk Acceptance

Management formally acknowledges and accepts remaining risk.

Remediation

Corrects or reduces the identified weakness.

Verification

Confirms that remediation actually resolved the issue.

Security+ Scenario Practice

Scenario 1

A critical vulnerability exists on an internet-facing customer system.

The same vulnerability exists on an isolated test system.

Which should normally receive priority?

The internet-facing production system because its exposure and business importance increase the risk.

Scenario 2

A critical server cannot immediately be patched because the update would disrupt an essential application.

What should the organization consider?

Implement compensating controls while planning permanent remediation.

Scenario 3

The infrastructure team reports that a vulnerability has been patched.

What should happen before closing the finding?

Verify that the vulnerability has actually been remediated.

Scenario 4

A vulnerability scanner reports a weakness that does not actually exist on the target.

What is this?

A false positive.

Scenario 5

Management decides to retain a known low-level risk after reviewing its impact.

Which risk response is being used?

Risk acceptance.

Key Takeaway

Vulnerability management is not:

Scan → Patch Everything

A mature approach is:

Know Your Assets

→ Discover Weaknesses

→ Validate Findings

→ Understand Business Context

→ Prioritize Risk

→ Remediate

→ Apply Compensating Controls Where Necessary

→ Verify

→ Continuously Monitor

The most important Security+ lesson is:

The highest technical score is not automatically the organization’s highest business risk.

A security professional must understand both the vulnerability and the environment in which that vulnerability exists.

What’s Next?

➡️ Lab 04 — Security Monitoring and Threat Investigation

In the next lab, students move from finding vulnerabilities proactively to detecting suspicious activity in the operational environment. They will work through alert triage, evidence review, event correlation, incident classification, escalation, and the creation of a structured Security Investigation Report.