Detection Use Cases and False-Positive Handling

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Detection Use Cases and False-Positive Handling

Key Takeaways Explain This Topic AI

A detection use case documents the threat behavior, data sources, logic, severity, triage, response, and tuning notes for a scenario.

False-positive handling improves signal quality without blinding the team to real attacks.

Tuning must be evidence-driven (allowlists, thresholds, suppression) rather than reactions to analyst fatigue.

Useful detections map to realistic behaviors: impossible travel, suspicious PowerShell, exfiltration, privilege escalation, beaconing.

Detection engineering requires testing, documentation, ownership, and periodic review to stay reliable.

Last updated: June 2026

What a Detection Use Case Is

A detection use case is a documented monitoring scenario. It states what behavior the team wants to catch, which data sources it needs, how the logic works, why it matters, and what an analyst should do when the alert fires. Treating detections as engineered, owned artifacts — rather than ad-hoc rules — is the modern practice the SY0-701 Security Operations domain expects you to recognize.

A Reusable Use-Case Template

• Field Example
• Use-case name Suspicious PowerShell from an Office process
• Threat behavior A malicious document launches a script interpreter
• Data sources EDR process logs, user identity, file reputation
• Logic Parent is winword.exe, child is powershell.exe with an encoded command
• Severity HIGH when the host is managed and the command is encoded
• Triage steps Review the command, parent document, user activity, network connections
• Response Isolate the host if malicious behavior is confirmed
• Tuning notes Exclude approved macro automation signed by the internal team
• Owner / review SOC detection engineer; reviewed quarterly
• A Library of Common Use Cases

• Use case Useful data Likely false-positive source
• Impossible travel IdP login logs, geolocation VPN egress location changes
• Suspicious PowerShell EDR process telemetry Approved admin or deployment scripts
• Data exfiltration Proxy, firewall, DLP, storage logs Large approved backup or data migration
• Privilege escalation Directory and cloud audit logs Approved access-change ticket
• Malware beaconing DNS, proxy, EDR network events Software update or telemetry check-in
• False, Benign, and True Positives

A false positive fires when the activity is not actually suspicious or the logic matched the wrong condition. A benign positive fires accurately but on expected, authorized activity. A true positive is a real malicious or policy-violating event. The goal of handling is never to silence alerts as fast as possible — it is to raise accuracy while preserving the ability to catch real attacks.

Example alert: 2026-06-14T01:15:00Z alert name="Large outbound transfer" host=FIN-SQL-02 bytes_out=48000000000 dst=203.0.113.210 severity=high

Investigation context found during triage: 2026-06-14T01:00:00Z backup job=quarterly_finance_archive host=FIN-SQL-02 dst=203.0.113.210 ticket=CHG-771 approved=true

If the rule claimed "possible exfiltration" and the transfer was an approved 48 GB backup to a known destination during a change window, the analyst should document the rationale and tune. Good tuning checks for approved backup job names, known backup destinations, the change-ticket window, and the expected service account — narrow conditions that exempt this traffic without blinding the rule to a genuine 48 GB theft to an unknown host.

Tuning Methods and Their Risks

• Method Use carefully because
• Threshold adjustment A higher threshold may miss smaller, low-and-slow attacks
• Allowlist Attackers may abuse a trusted tool or destination you exempted
• Time-window suppression Attacks can deliberately hide inside maintenance windows
• Asset-based severity Low-value assets are still valid attacker entry points
• User/role context Privileged users get compromised too

Notice the recurring danger: every tuning lever that reduces noise can also create a blind spot an attacker mimics. Tune with the narrowest possible condition and document the trade-off.

Detection Quality Checklist

Does the detection map to a realistic threat behavior?

Are the required logs actually available and reliable?

Does the alert carry enough context for triage on its own?

Are exceptions documented, owned, and periodically reviewed?

Is there a test event or simulation confirming the rule still fires?

Is the response proportional to confidence and impact?

False Positives vs. False Negatives

Every detection sits on a trade-off the exam states in confusion-matrix terms. A false positive is a benign event flagged as malicious — it wastes analyst time and, in volume, causes alert fatigue that leads people to ignore alerts. A false negative is a malicious event the detection missed entirely — far more dangerous, because nobody is even looking. Aggressive tuning that crushes false positives almost always raises false negatives. The mature goal is to maximize true positives while keeping false negatives near zero, accepting some manageable false-positive volume rather than blinding the rule.

• Reality \ Alert Alert fired No alert
• Actually malicious True positive (good) False negative (dangerous)
• Actually benign False positive (noisy) True negative (good)
• Mapping Detections to Adversary Behavior

Strong detection engineering anchors each use case to a known adversary technique rather than a single indicator. A hash or IP blocklist is brittle — attackers rotate those cheaply. Behavior-based detections (an Office app spawning a script interpreter, a non-admin creating a cloud access key) survive indicator changes because they target how attacks work, not which artifact was used last time. This is why behavioral use cases dominate the table above.

Common Traps

Disabling a noisy rule without first understanding what it was meant to catch.

Creating permanent allowlists for entire administrator groups.

Treating every false positive as a reason to reduce logging .

Over-tuning until false positives vanish but false negatives quietly rise.

Measuring detection success by raw alert volume instead of true-positive yield.

Forgetting to retest detections after changing log sources or agent policies — a silent rule looks identical to a healthy one until an attack slips through.