Terminology Index

Glossary

2953 terms

Technique

In ATT&CK terms, the how of an adversary action, the specific method used to achieve a tactic, like Phishing for Initial Access or Process Injection for Defense Evasion.

Technology Dependency Mapping

A record of the applications, infrastructure, identities, networks, data, suppliers, people, and sequence dependencies required to deliver and recover a business service.

Telemetry

The data systems generate about their behavior, logs, metrics, traces, events, that defenders collect, store, and analyze to detect threats, investigate incidents, and run security operations.

Telemetry Backpressure

A condition in which telemetry arrives faster than downstream systems process it, causing delay, buffering, retry, dropping, or cost pressure.

Telemetry Collection Path

The documented route a record takes from producer through agents, APIs, queues, processors, and storage, including ownership and failure behavior.

Telemetry Cost Governance

Management of ingestion, storage, query, egress, and operational cost against documented security value and visibility trade-offs.

Telemetry Coverage Reconciliation

Comparison of authoritative eligible populations with sources that are configured, reporting, parsing, timely, and field-complete.

Telemetry Data Minimization

Collection of only the telemetry fields justified by security, operational, or legal needs while excluding unnecessary secrets and sensitive data.

Telemetry Evasion Hunting

Telemetry evasion hunting searches for disabling, weakening, excluding, deleting, bypassing, isolating, or tampering with sensors, logs, audit policy, diagnostic settings, and collection paths.

Telemetry Evidence Boundary

An explicit statement of what a telemetry source can and cannot establish about an event or actor.

Telemetry Gap

Missing, incomplete, delayed, untrusted, or unusable event data that prevents a security question or analytic from being answered for its claimed scope.

Telemetry Gaps

Areas where the data needed to detect or investigate isn't being collected, blind spots that limit what detections can see no matter how clever the rules are.

Telemetry gaps are where the SOC is blind: a system not sending logs, a field not captured, a layer (cloud, identity, network) underrepresented. They cap detection coverage because rules can't fire on data that doesn't exist. Identifying and closing telemetry gaps is a defining detection-engineering practice, often more impactful than writing more rules. As a discipline, it pairs with telemetry mapping to make the SOC see what it needs to see.

Introduced in: Detection Engineering

Examples

Discovering a category of cloud activity isn't logged at all.
Identifying a missing field that prevents a key detection from working.
Closing telemetry gaps as higher-priority than writing more rules.

Telemetryrelates_to Telemetry Mappingrelates_to Detection Coveragerelates_to Log Source Taxonomyrelates_to Detection engineeringrelates_to Telemetryrelates_to Telemetry Mappingrelates_to Visibility Gap Operationalizationrelates_to

Telemetry Improvement Action

An owned change tied to a telemetry requirement, risk, validation method, and evidence of completion.

Telemetry Mapping

Mapping the telemetry available to the detections and investigations it supports, so coverage gaps and surplus collection are both visible, and decisions about telemetry investment are evidence-based.

Telemetry Normalization

Documented mapping of source-specific event fields into a shared representation without hiding loss, ambiguity, or provenance.

Telemetry Pipeline Validation

Telemetry pipeline validation traces an expected event through generation, local recording, forwarding, transport, parsing, normalization, indexing, scheduling, suppression, enrichment, alerting, case routing, and responder access.

Telemetry Quality Metric

A precisely defined measure of telemetry usability such as coverage, field completeness, parse failures, duplicates, delay, or known-event success.

Telemetry Requirement

A telemetry requirement specifies the events, fields, entities, timestamps, population, retention, latency, quality, and privacy controls needed to implement and investigate a detection hypothesis.

Telemetry Volume

The amount of telemetry cloud-native workloads produce, which can grow far faster than traditional sources, forcing deliberate decisions about what to collect, store, and query.

Temporal Correlation

Temporal correlation links events only when their timing and order support a defined behavioral sequence within a bounded window.

Terraform Plan Scanning

Terraform plan scanning evaluates resolved proposed resource changes after modules, variables, and provider behavior have been applied.

Terraform Security

Securing Terraform-managed infrastructure: linting and scanning IaC, secret handling, state-file protection, module trust, and policy-as-code gates, so what Terraform deploys is safe by construction.

Test Coverage

How thoroughly the detection catalog has been tested against representative scenarios, so engineers know which detections are validated and which are unproven assumptions.

Test Data and Account Design

Test data and account design creates labeled synthetic users, roles, tenants, objects, messages, and transactions with known expected permissions for safe security comparisons.

Test Exception Evaluation

Test exception evaluation verifies a deviation and analyzes its population membership, criterion, objective, frequency, cause, consequence, compensating controls, and need for further testing.

Testable Requirements

Policy requirements written so compliance can be measured objectively, with clear, observable, evidence-supported criteria, rather than vague aspirations that can't be evaluated.

The Shared Responsibility Model

The foundational cloud-security concept that security obligations split between cloud provider and customer along defined lines, and that customer responsibilities differ across IaaS, PaaS, and SaaS.

Third Party BC Assessment

Assessing third parties' business continuity and disaster recovery capabilities, so the organization understands what to expect when a critical vendor has an outage or disaster.

Third-Party Assessment

From an audit and assurance lens, assessing the controls and risks of third parties (vendors, partners, providers), often using SOC 2 reports, questionnaires, or independent audits.

Third-Party Exit Readiness

Third-party exit readiness defines data return and deletion, transition support, access revocation, key handling, retention, evidence, continuity, replacement, and concentration reduction.

Third-Party Inherent Risk

Third-party inherent risk estimates supplier risk before supplier-specific controls using criticality, data, access, integration, concentration, geography, substitutability, fourth parties, and failure consequence.

Third-Party Residual Risk

Third-party residual risk evaluates supported supplier and customer controls, contracts, assurance limits, findings, dependencies, exceptions, and uncertainty after treatment.