Terminology Index

Glossary

1801 terms

Showing 545-576 of 1801 terms

Deprovisioning

Removing a user's or entity's access when it is no longer needed, such as when an employee leaves or changes roles, by disabling accounts and revoking permissions. Prompt deprovisioning prevents orphaned access from becoming a security gap.

Detection Automation

Automating cloud detection and the response to it, so that suspicious activity is identified and acted on, alerting, enriching, or even containing, without waiting for manual intervention, reducing the time attackers have to operate.

Detection Backlog

The prioritized list of detections a detection-engineering team intends to build or improve, fed by coverage gaps, threat intelligence, hunt findings, and SOC feedback. It turns scattered detection needs into managed, prioritized work.

Detection Community

The broader community of detection engineers and defenders who share detection rules, techniques, and knowledge openly, through public rule repositories, formats like Sigma, and discussion, accelerating everyone's ability to detect threats.

Detection Confidence

A judgment of how reliably a given detection indicates real malicious activity, used in blue-team operations to weight alerts, prioritize response, and decide how much to trust an alert when one fires.

Detection Confidence Scoring

Assigning each detection a score reflecting how reliably it indicates a true threat, so a detection-engineering team and the SOC can prioritize, weight, and tune detections based on their proven trustworthiness.

Detection Coverage

How much of the relevant threat behavior an organization can actually detect, measured by which attacker techniques, log sources, and assets are covered by working detections. Gaps in coverage are blind spots attackers can exploit.

Detection Decay

The gradual loss of a detection's effectiveness over time, as environments change, attackers adapt, log sources shift, or allowlists accumulate, so a rule that once worked quietly stops catching what it should.

Detection Development Cycle

The repeatable process of creating a detection from an attacker technique: research the behavior, write the detection logic, test it against the technique, validate coverage, document it, and deploy, often organized around the MITRE ATT&CK framework.

Detection Documentation

The written record accompanying a detection, what it detects, the logic and data sources it uses, its assumptions, known false positives, and response guidance, so it can be understood, triaged, tuned, and maintained by others.

A detection without documentation is hard to triage, trust, or maintain. Good detection documentation captures the technique it targets (often mapped to ATT&CK), how the logic works, which log sources it needs, expected false positives, confidence, and what an analyst should do when it fires. This metadata is what lets the SOC act on alerts confidently, lets engineers tune without guesswork, and prevents detections from decaying into mysteries no one understands.

Introduced in: Writing Detections with ATT&CK, Detection Engineering

Examples

Recording which ATT&CK technique a detection covers and its data sources.
Documenting known false positives and response steps for an alert.
Capturing a detection's assumptions so others can maintain it.

soc intermediate detection-documentation

No related terms linked yet.

Detection Engineer

The role responsible for designing, building, testing, and maintaining the detections a SOC relies on, turning knowledge of attacker behavior into reliable, well-documented rules and analytics that surface threats.

Detection Engineering

The practice of designing, testing, and improving logic that identifies suspicious activity.

Detection Engineers

Detection engineers as a function within blue-team operations, the people who build and maintain detections, positioned alongside SOC analysts, threat hunters, and incident responders in the broader defensive organization.

Detection Hypothesis

A testable idea about how a specific attacker behavior would appear in available data, which a detection engineer forms before building a detection, stating what to look for and in which telemetry.

Detection Library Workflow

The process for managing a collection of detections as an organized, version-controlled library, adding, updating, retiring, and tracking detections so the whole set stays coherent, current, and mapped to coverage.

Detection Lifecycle

The full arc of a detection from idea to retirement, hypothesis, development, testing, deployment, tuning, monitoring, and eventual retirement, framing detection as something maintained over time rather than written once.

Detection Metadata

The structured attributes attached to a detection, such as the technique it covers, data sources, severity, confidence, false-positive notes, owner, and version, that make a detection manageable, searchable, and maintainable at scale.

Detection Prioritization

Deciding which detections to build first when writing detections with ATT&CK, focusing effort on the techniques that matter most given the organization's threats, the technique's prevalence, and the impact of catching it.

Detection Program Governance

The oversight and management structures that keep a detection capability aligned, measured, and improving at the program level, defining ownership, priorities, metrics, and how detection work ties to SOC strategy and risk.

Detection Research

The investigative work a detection engineer does to understand an attacker technique before building a detection, studying how it behaves, what telemetry it generates, and how attackers vary and evade it.

Detection Robustness

How resistant a detection is to evasion and to breaking, a robust detection keys on hard-to-change attacker behavior rather than superficial, easily altered indicators, so attackers cannot trivially bypass it.

Detection Specificity

How precisely a detection targets malicious activity without flagging benign behavior, high specificity means few false positives, because the detection fires narrowly on what is actually suspicious.

Detection Strategy

The overall plan guiding what a team detects and how, defining priorities, the balance of detection types, coverage goals, and how detection effort aligns with the organization's threats and risk.

Detection Testing

Verifying that a detection works by running the targeted technique, or a safe simulation of it, and confirming the detection fires as intended while gauging its false-positive behavior, before relying on it.

Detection and Analysis

The incident-response phase where a potential incident is detected, validated, and analyzed to understand its nature and scope, turning an initial signal into a confirmed, understood incident that response can act on.

Detection-as-Code

Managing detections like software, defined in code, version-controlled, peer-reviewed, tested in pipelines, and deployed automatically, so detection engineering gains the rigor, repeatability, and collaboration of modern software development.

Detective Controls

Security controls that identify and signal that an incident is happening or has happened, such as logging, monitoring, intrusion detection, and alerting. They do not prevent attacks but enable timely response.

Deterrent Controls

Security controls that discourage an attacker from attempting an attack by raising the perceived risk or effort, such as warning banners, visible monitoring, or signs of strong security, working through psychology rather than technical blocking.

DevSecOps Principles

The core ideas behind building security into software delivery: shift security left, automate it in the pipeline, share responsibility across dev, sec, and ops, give fast developer feedback, and treat security as a continuous part of building software.

Developer Security Feedback

Giving developers fast, clear, actionable security feedback within their existing workflow, in the IDE, pull request, or pipeline, so they can fix issues immediately rather than learning about them late from a separate security team.

Device Compliance Integration

Tying access decisions to a device's compliance state in zero trust, so that only devices meeting security requirements (patched, encrypted, managed, healthy) are allowed access, and non-compliant ones are blocked or restricted.

Device Trust in ZTA

The zero-trust principle that a device's identity and security posture must be established and continuously verified before it is trusted to access resources, so access depends on the device, not just the user.