Terminology Index

Glossary

2953 terms

Sensor Health Signal

Evidence that a telemetry source is configured, current, delivering, parsing, and producing required fields - not merely installed or alive.

Sensor Health Validation

Sensor health validation confirms that required events continue to be generated, forwarded, parsed, indexed, and queryable for the intended population.

Separate Admin Accounts (Tiered Admin Model)

Separate admin accounts keep a person's daily productivity identity distinct from identities used for privileged administration.

Separate Administrative Identities

Separate administrative identities keep routine email, browsing, and collaboration activity away from credentials and sessions used for privileged operations.

Separation of Duties

An IAM principle that splits high-impact tasks across people so no single individual can complete them alone, reducing fraud, error, and abuse by requiring collaboration.

Sequence Detection

Detecting attacker activity by chaining ordered events that, individually benign, indicate compromise together, written as multi-step detection logic that fires only when the sequence completes.

Server-Side Authorization

Enforcing authorization decisions on the server, not just in client UI, so what a user can actually do is determined by trusted server checks rather than client-side controls an attacker can bypass.

Server-Side Request Testing

Server-side request testing verifies how an application fetches supplied or derived destinations for webhooks, imports, previews, renderers, callbacks, and metadata.

Serverless Anti-Patterns

Common mistakes in securing serverless workloads, over-permissioned functions, sensitive data in environment variables, missing monitoring, that undermine the security benefits serverless can otherwise offer.

Serverless Detection

Detecting malicious activity in serverless environments, abuse of functions, anomalous invocation patterns, suspicious permissions use, given the short-lived, event-driven nature of serverless workloads.

Serverless workloads run as short-lived, event-triggered functions, which complicates detection: there's no long-running process to watch, and behavior must be inferred from invocations, logs, and IAM activity. Serverless detection focuses on invocation anomalies, suspicious function changes, unexpected permission use, and event-source abuse. As a cloud-workload-protection skill, it differs from traditional host detection and depends heavily on platform-provided telemetry and serverless-aware tooling.

Introduced in: Cloud Workload Protection

Examples

Detecting an anomalous spike in invocations of a sensitive function.
Alerting on unexpected use of broad IAM permissions by a function.
Catching suspicious changes to function code or configuration.

Serverless Observabilityrelates_to Serverless Security Modelrelates_to Service Control Policies (SCPs)relates_to Service Endpointsrelates_to Service Meshrelates_to Service Mesh Attacksrelates_to Service Mesh Securityrelates_to Service Mesh Telemetryrelates_to Serverless Securityrelates_to Anomaly Detectionrelates_to Detection engineeringrelates_to Runtime Securityrelates_to Serverless Observabilityprerequisite_of Serverless Observabilityrelates_to Serverless Securityrelates_to

Serverless Event Security Assessment

Serverless event security assessment maps runtime identity, event sources, invocation authorization, validation, destinations, retries, dead letters, concurrency, timeouts, secrets, networks, dependencies, logs, and deployment power.

Serverless Observability

Gaining visibility into serverless workloads, invocations, durations, errors, traces across functions and services, so security and operations can both see and reason about what's happening.

Serverless Responsibility Boundary

A serverless responsibility boundary separates provider infrastructure and runtime duties from customer code, dependencies, triggers, authorization, identity, data, telemetry, and recovery.

Serverless Security

The discipline of securing serverless workloads, function permissions, code, dependencies, secrets, observability, that adapts cloud-security practice to the event-driven, provider-managed runtime.

Serverless Security Model

The conceptual model for how security responsibilities and risks apply to serverless, distinguishing what the provider handles from what the customer must do, and identifying the unique risks serverless introduces.

Serverless Shared Responsibility

Serverless shared responsibility distinguishes provider operation of underlying compute from customer responsibility for code or image, supported runtime, update mode, dependencies, identity, invocation, data, configuration, telemetry, recovery, and retirement.

Serverless Supply Chain

A serverless supply chain includes source, dependencies, build service, layers, packages, artifact or image, deployment identity, configuration, and runtime version.

Serverless Telemetry Design

Serverless telemetry design combines structured application events, correlation, invocation metrics, traces, identity and data audit, configuration history, event-source records, deployment provenance, and cost signals.

Serverless Threat Modeling

Threat modeling applied to serverless workloads, examining function permissions, event sources, dependencies, and inter-function trust, to surface risks unique to the architecture.

Service Account

An account used by software or systems rather than a human user.

Service Account Governance

Managing non-human service accounts through a PAM-aligned program, ownership, scope, rotation, monitoring, since service accounts are often privileged, long-lived, and poorly tracked.

Service Account Modernization

Replacing legacy service-account patterns (static passwords, broad rights, no rotation) with modern alternatives, managed identities, workload identity federation, short-lived credentials, that are more secure by design.

Service Account Remediation Plan

A concrete plan to bring an organization's service accounts under control, inventory, scoping, rotation, modernization, that capstone IAM work produces to address service-account risk systematically.

Service Accounts

Non-human accounts used by applications, scripts, and services to authenticate and access resources. Numerous, often privileged, and frequently neglected, they are a major identity-security focus.

Service Control Policies

AWS Organizations policies that set maximum available permissions for principals in affected member accounts; they do not grant permissions and have documented scope and exceptions.

Service Control Policies (SCPs)

Organization-level policies in cloud (AWS-style) that set the maximum permissions any account in scope can have, used as guardrails to enforce limits across many accounts at once.

Service Endpoints

Cloud network features that connect a customer network to a provider service over the provider's private network, avoiding public-internet exposure of those connections.

Service Hardening

Reduction of a service's attack surface through supported configuration, least privilege, patching, interface restriction, secret protection, logging, and removal of unnecessary features.

Service Mesh

Infrastructure that handles service-to-service communication for microservices, mTLS, routing, observability, policy, transparently via sidecars or proxies, common in cloud-native architectures.

Service Mesh Attacks

Attacks that target the service mesh itself, control-plane compromise, sidecar exploitation, policy bypass, that defenders must consider since the mesh is critical infrastructure attackers also pursue.

Service Mesh Security

The security capabilities and concerns of a service mesh, mTLS, identity, authorization, observability, plus protecting the mesh itself, treated as a coherent security-architecture topic.

Service Mesh Telemetry

The metrics, traces, and logs the service mesh produces about service-to-service traffic, used by both operations and security for visibility, detection, and investigation.