Security+ Vulnerability Management, SIEM, and Enterprise Defense

Introduction

This lesson continues Domain 4, Security Operations (28% of SY0-701), and covers three objectives: 4.3, explaining various activities associated with vulnerability management; 4.4, explaining security alerting and monitoring concepts and tools; and 4.5, modifying enterprise capabilities to enhance security. Together they describe how a security team finds weaknesses, decides what to fix first, watches the environment for signs of attack, and tunes the tools that block or detect it.

Security+ vulnerability management and monitoring scenarios test practical decisions. A scan reports hundreds of findings and you must prioritize. A SIEM shows an alert and you must decide whether it is real. A firewall rule needs to be written, an IDS needs to become an IPS, or an email gateway must be configured to stop spoofing. Know what each tool sees, what it can do about it, and what it cannot do.

Learning objectives

After this lesson you will be able to:

• Describe vulnerability identification methods and analyze findings using CVSS, CVE, false positive and false negative concepts, and risk context.
• Choose remediation actions: patching, segmentation, compensating controls, exceptions, and validation.
• Explain monitoring and alerting: logging, SIEM, agents, NetFlow, SNMP, and alert tuning.
• Compare firewalls, IDS, IPS, web filters, DNS filtering, and email security controls.
• Apply operating system, file integrity, DLP, NAC, and EDR/XDR controls appropriately.

1. The vulnerability management life cycle

Vulnerability management is a repeating loop, not a project:

1. Identify: discover vulnerabilities.
2. Analyze: confirm, score, and prioritize them.
3. Remediate: fix, mitigate, or formally accept them.
4. Validate: confirm the fix worked.
5. Report: communicate status and trends to owners and management.

Identification methods

A credentialed scan logs in to the target, so it sees installed software versions and local configuration, and can reduce version-guessing false positives compared with a non-credentialed scan. Effective permissions, failed authentication, vendor backports, and scanner coverage still affect accuracy. An unauthenticated scan shows exposure from its particular network position, not every attacker’s view. Use both: the second shows exposure, the first shows depth. Agent-based scanning works well for roaming laptops that are rarely on the network during a scheduled scan. Scan with care on fragile systems such as legacy medical or industrial devices, where an intrusive scan may cause outages; use non-intrusive or passive methods there.

Analysis: CVE, CVSS, and context

• CVE (Common Vulnerabilities and Exposures) is the identifier for a known vulnerability, such as CVE-2021-44228.
• CVSS (Common Vulnerability Scoring System) gives a severity score from 0 to 10: 0.0 none, 0.1–3.9 low, 4.0–6.9 medium, 7.0–8.9 high, 9.0–10.0 critical. The base score reflects intrinsic characteristics (attack vector, complexity, privileges, impact); CVSS v3.1 uses Temporal and Environmental metric groups. CVSS v4.0 uses Base, Threat, Environmental, and Supplemental groups; Supplemental metrics add context without changing the numeric score. Record the version and vector alongside a score. CVSS measures severity, not a complete business-risk probability.
• False positive: the scanner reports a vulnerability that is not present. False negative: a real vulnerability is not reported. False negatives can create false confidence, while false positives consume effort and can trigger disruptive responses. Assess both against the operational impact.
• Exposure factor, asset value, exploitability (is a public exploit available, is it exploited in the wild), and environmental factors (is the system internet-facing, is the vulnerable feature enabled) all influence priority.
• Risk tolerance of the organization sets how much residual risk is accepted.
• Use CISA’s Known Exploited Vulnerabilities (KEV) catalog as evidence of exploitation in the wild. FIRST EPSS estimates the probability of exploitation of a published CVE over the next 30 days; it is not proof of exploitation or the probability that your specific asset will be compromised. Combine both with local exposure and asset impact.

Example 1: why the 9.8 is not always first

A scan reports 600 findings. Two stand out: a CVSS 9.8 flaw in a print server on an isolated lab VLAN with no internet path, and a CVSS 7.5 flaw in the public web server's TLS library that appears in the CISA KEV catalog with active exploitation. The 7.5 flaw on an internet-facing, business-critical asset with known exploitation should be fixed first. The 9.8 flaw is still scheduled but reduced in urgency by its isolation. Prioritization combines score, exploitability, exposure, and asset criticality, not the base score alone.

Connect findings to secure baselines and asset inventory so each vulnerable asset has an accountable owner.

2. Remediation and validation

Options for a confirmed vulnerability:

• Patching: the direct fix for many software flaws; configuration weaknesses may instead require a configuration change. Test, deploy through change management, and use a rollback plan. Prioritize by risk and give emergency treatment to actively exploited flaws.
• Insurance: transfer part of the financial impact (a risk response, not a fix).
• Segmentation / isolation: restrict the network path to the vulnerable system.
• Compensating controls: alternative controls when the vulnerability cannot be fixed, such as a web application firewall rule, an intrusion prevention signature, or disabling the vulnerable feature.
• Exceptions and exemptions: documented, time-limited, approved by the risk owner when remediation is not feasible. Typically requires a compensating control and a review date.
• Decommissioning of end-of-life systems.

After remediation, validate: rescan to confirm the finding is gone, verify the system still works (to catch patch side effects), and perform audit checks where required. Reporting closes the loop with dashboards for owners: open findings by severity, age, mean time to remediate, and exceptions outstanding.

Worked example: unpatchable legacy system

Scenario. A manufacturer's 15-year-old CNC controller runs an unsupported operating system. A scan finds a critical remote code execution flaw. The vendor will not issue a patch and the machine cannot be replaced for 18 months. What should the security team do?

Reasoning.

1. Patching is not possible, so the risk must be reduced another way.
2. The flaw is reachable over the network, so cutting the path reduces likelihood: place the controller in an isolated VLAN, allow only the engineering workstation and required ports through a firewall, and block internet access.
3. Add detection: IDS signatures for the exploit and logging on the firewall rules.
4. Document a formal exception with an expiry date, the compensating controls, an accountable owner, and a replacement project.
5. With operations and vendor approval, verify denied paths from untrusted segments and necessary allowed flows from approved sources. Use non-disruptive methods for the controller; a reachable permitted engineering path does not prove that the flaw has been removed.

Solution. Segmentation plus compensating controls under a time-limited exception, followed by validation. Why not ignore it? Risk acceptance requires approval and documentation. Why not take the machine offline? That may be disproportionate to the business impact; the question asks for the best option consistent with operations.

For the mitigation choices, review segmentation, patching, and configuration enforcement.

3. Logging, monitoring, and alerting

You cannot detect what you do not collect. Typical data sources include operating system logs (Windows Event Log, syslog), authentication logs, firewall and proxy logs, DNS logs, application logs, endpoint telemetry, cloud audit logs, vulnerability scan results, and packet captures.

Key concepts:

• Log aggregation: forward logs from many sources to a central collector, with independent access controls so a local compromise need not erase the central copy and can be searched in one place.
• SIEM (security information and event management): collects, normalizes, correlates, and retains logs, raises alerts from correlation rules, and supports investigation and reporting. Correlation joins events across sources: for example, a VPN login from one country followed by a login from another country within minutes.
• SOAR (security orchestration, automation, and response): automates response playbooks (covered in the next lesson).
• Time synchronization (NTP) matters because correlation depends on accurate timestamps.
• NetFlow / IPFIX commonly export flow records such as endpoints, ports, times, and byte counts. sFlow uses sampled packets and interface counters rather than the same flow-record model. Sampling, exporter settings, and collection gaps affect completeness and volume estimates.
• SNMP traps: devices push event notifications to a manager; configure SNMPv3 authentication and privacy (authPriv) when both are required; merely choosing version 3 does not enable both.
• Agents / agentless collection: agents run on hosts and forward richer data; agentless collection uses APIs, remote protocols, or source-side forwarding without a dedicated collection agent.
• Benchmarks and compliance: SCAP (Security Content Automation Protocol) lets tools check systems against standardized baselines.
• Alert tuning: adjust thresholds and rules to reduce low-value alerts while testing for lost coverage. Tune using labeled cases, replay tests, and review of suppressed events rather than assuming a threshold change cannot miss attacks.
• Alert response and remediation: quarantine a device (move it to an isolated network or disable its port), alert escalation by severity, and archiving logs per retention policy.
• Reporting and metrics: alert volume, mean time to detect, mean time to respond, and false positive rate.

Example 2: correlation catches what single logs miss

A finance user's mailbox shows a successful login at 02:10 from an unfamiliar IP address. By itself it might be travel. The SIEM correlates it with a new inbox rule that forwards mail to an external address at 02:12, then a bulk download of 3 GB from the document library at 02:15, and with threat-intelligence data that flags the IP as a known anonymizing proxy. The combined alert is high severity: the SOC revokes sessions, resets credentials, and enforces MFA. The combined evidence increases confidence, but a single sufficiently strong finding can also justify containment under an approved playbook. Review forwarding rules and token/MFA changes as part of account recovery.

4. Firewalls

A firewall enforces policy on traffic between zones. Core features:

• Rules / ACLs match source, destination, protocol, port, and action. First-match ordered policies are common, but evaluation differs by product; cloud security groups need not use ordered explicit-deny rules. Verify platform semantics and effective default-deny behavior.
• Stateless versus stateful: a stateless filter judges each packet alone; a stateful firewall tracks connections and allows return traffic for established sessions.
• Layer 4 versus layer 7: Layer 4 firewalls decide on IPs and ports; next-generation firewalls (NGFW) inspect applications (Layer 7), identify users, apply intrusion prevention, and do TLS inspection.
• Web application firewall (WAF): inspects web requests for suspicious application patterns, with HTTPS visibility at an appropriate decryption point. It supplements secure coding and parameterized queries; it does not repair application flaws.
• Screened subnet (DMZ): a separate network zone for public-facing servers, with firewalls controlling traffic between the internet, the screened subnet, and the internal network.
• Host-based versus network-based firewalls, and virtual/cloud security groups.
• Egress filtering (outbound rules) limits command-and-control and exfiltration.

Good rule practice: least privilege, document each rule's owner and purpose, review regularly to remove stale rules, and log denies and critical allows.

Worked example: ordering firewall rules

Scenario. A firewall has these rules, evaluated in order:

1. Allow any → web server 10.0.5.10 TCP 443
2. Deny any → any (all protocols)
3. Allow admin workstation 10.0.1.20 → web server 10.0.5.10 TCP 22

The administrator cannot reach SSH on the web server. Why, and what is the fix?

Reasoning. Rules are processed top to bottom and the first match decides. SSH traffic from the admin workstation does not match rule 1 (port 443 only), but it matches rule 2 (deny any), so processing stops. Rule 3 is never reached.

Solution. Move the SSH allow above the deny-all rule, ideally restricting the source to the admin workstation, which is already the case. The explicit deny-all stays last. Moving the deny to the top of the list makes things worse, and adding a second deny does nothing.

5. IDS, IPS, and related network controls

Detection methods: signature-based (patterns associated with known techniques; may miss variants or behavior outside the rule coverage), anomaly/behavior-based (deviation from a baseline; can detect unfamiliar behavior but may also flag legitimate changes), and heuristic methods. Trends can be monitored with statistical baselines.

Other enterprise capabilities in objective 4.5:

• Web filter: restricts access to websites by category, URL, reputation, or content; implemented via a proxy (agent-based or centralized), blocking malicious and non-business sites, and logging user activity. Content categorization, block rules, and reputation services drive decisions.
• DNS filtering: restricts resolution of listed domains through controlled resolvers. Roaming protection requires enforced resolver or endpoint policy; direct IP connections, cached answers, and alternate encrypted resolvers can bypass an unenforced design.
• Email security: SPF checks permitted senders for an envelope domain; DKIM validates signed message portions against a signing domain. DMARC passes when SPF or DKIM passes with alignment to the visible From domain. It publishes a requested disposition for failures and reporting; receivers retain local handling policy. None authenticates the individual author or guarantees benign content. A mail gateway also scans attachments, links, and applies sandboxing.
• File integrity monitoring (FIM): detects changes against a protected baseline, often using hashes. Correlate changes with approvals to decide whether they were unauthorized; protect the baseline from replacement.
• Data loss prevention (DLP): inspects content for sensitive patterns (card numbers, personal identifiers) and blocks or alerts on movement via email, web uploads, removable media, or cloud apps.
• Network access control (NAC): checks the identity and posture of devices (patch level, antivirus, certificate) before admitting them to the network, and can quarantine non-compliant devices to a remediation VLAN.
• EDR/XDR: endpoint and cross-domain behavioral detection and response (see the previous lesson).
• User behavior analytics (UBA/UEBA): baselines normal activity per user and flags anomalies, such as an accountant accessing source code.
• Operating system security: Group Policy for Windows, SELinux/AppArmor mandatory access control on Linux, and secure configuration of services.
• Secure protocols: replace Telnet with SSH, FTP with SFTP/FTPS, HTTP with HTTPS, and use encrypted DNS and SNMPv3 where possible.
• Allow/deny lists and restricting administrative access to management planes.

Example 3: DMARC rollout

A company discovers that criminals send invoices that appear to come from billing@contoso-example.com. The domain has SPF but no DKIM or DMARC. The team publishes DKIM signing for all legitimate senders, then DMARC with p=none and aggregate reporting to find forgotten legitimate senders (a marketing platform, an HR system). After fixing alignment, they move to p=quarantine, then p=reject. Participating receivers can now reject DMARC-failing mail under that requested policy. An aligned SPF or DKIM pass is sufficient; a compromised legitimate mailbox or look-alike domain can still deliver fraudulent mail. Moving straight to reject risks blocking legitimate mail, which is why monitoring comes first.

Escalate confirmed attacks through the incident response and evidence-handling process.

6. Comparison: choosing the right tool

7. Common pitfalls

• Prioritizing by CVSS base score alone and ignoring exposure and exploitation status.
• Running only non-credentialed scans and missing local vulnerabilities.
• Believing a clean scan means no risk; false negatives exist and scanner coverage is incomplete and newly discovered flaws or known attack behaviors may not have a matching vulnerability check.
• Closing a ticket after patching without rescanning.
• Leaving an IDS in place and expecting it to block attacks.
• Putting an IPS inline without tuning and causing outages through false positives.
• Placing a broad allow rule above a specific deny.
• Collecting logs but never reviewing or tuning alerts, which creates alert fatigue.
• Using MAC addresses or IP addresses alone as identity for NAC.

8. Exam tips

• "Detects but does not block" means IDS; "blocks" means IPS and inline.
• "Fewer false positives and local configuration visibility" means credentialed scan.
• "Cannot patch" means compensating control and a documented exception, not ignoring it.
• "Correlate events from multiple sources" means SIEM.
• "Verify the fix" means rescan or validation.
• "Spoofed sender domain" means SPF, DKIM, and DMARC.
• "Web attack against an application" means WAF.
• "Limit what leaves the network" means egress filtering, DLP, and DNS filtering.

9. Mini case study

Case. Northwind Clinics runs an internet-facing patient portal, 25 clinic networks, and a SIEM that currently ingests only firewall logs. The quarterly unauthenticated scan listed 40 criticals and the team patched 15, then closed the tickets. Last month, attackers used a known flaw in a portal library (listed in KEV) that was on the unpatched list. The email domain was also used in phishing against patients.

Tasks. Identify the failures and propose improvements.

Solution.

1. Prioritization: the team ranked by score only. Introduce prioritization that weighs KEV status, exposure, and data sensitivity, with documented urgency and escalation. A 72-hour target could be an illustrative internal policy, not a universal deadline; active exploitation may require immediate containment and a faster change.
2. Scanning: add credentialed and agent-based scans, choose a risk-based assessment cadence for internet-facing assets, including reassessment after material changes or new exploitation intelligence, and use application scanning for the portal and dependency monitoring for libraries.
3. Validation: require a rescan before closing any ticket and track exceptions with expiry dates.
4. Monitoring: add authentication, endpoint, DNS, and portal application logs to the SIEM with NTP synchronization, correlation rules, and tuned alerts.
5. Controls: place a WAF in front of the portal, an IPS at the perimeter, and DNS filtering for clinics.
6. Email: publish SPF, DKIM, and DMARC progressing to reject.
7. Reporting: report mean time to remediate and open critical findings monthly to leadership.

Key terms

• CVE / CVSS: vulnerability identifier and severity score.
• KEV: CISA list of vulnerabilities known to be exploited.
• Credentialed scan: authenticated scan with deeper visibility.
• False positive / false negative: incorrect alert and missed vulnerability.
• Compensating control / exception: alternative mitigation and approved deviation.
• SIEM: log collection, correlation, and alerting platform.
• NetFlow: summarized network conversation records.
• NGFW / WAF: application-aware firewall and web application firewall.
• IDS / IPS: detecting and preventing intrusion systems.
• SPF / DKIM / DMARC: email authentication standards.
• FIM / DLP / NAC: file integrity, data loss prevention, network access control.
• Screened subnet: segment hosting public-facing services.

Summary checklist

• I can walk through identify, analyze, remediate, validate, and report.
• I can prioritize findings using CVSS, exploitation, exposure, and asset value.
• I can pick remediation: patch, segment, compensate, or except, and then validate.
• I can explain what a SIEM, NetFlow, SNMP, and log aggregation each contribute.
• I can order firewall rules and explain implicit deny.
• I can distinguish IDS and IPS and signature versus anomaly detection.
• I can match web filter, DNS filter, email authentication, FIM, DLP, and NAC to needs.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 4.3–4.5.
• FIRST, CVSS specification: https://www.first.org/cvss/ (opens in a new tab)
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (opens in a new tab)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: https://csrc.nist.gov/pubs/sp/800/40/r4/final (opens in a new tab)
• NIST SP 800-92, Guide to Computer Security Log Management: https://csrc.nist.gov/pubs/sp/800/92/final (opens in a new tab)
• NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems: https://csrc.nist.gov/pubs/sp/800/94/final (opens in a new tab)
• RFC 7489: DMARC alignment and receiver policy (opens in a new tab)
• RFC 6376: DKIM signing identity (opens in a new tab)
• FIRST: CVSS v4.0 specification (opens in a new tab)
• FIRST: EPSS probability estimates (opens in a new tab)