Runtime Threat Detection

Runtime threat detection observes executing workloads to identify behavior associated with compromise. Depending on the platform and collection method, evidence can include process creation, command execution, file access, network connections, and interactions with operating-system components. Detection engines evaluate this evidence using threat intelligence, behavioral rules, or anomaly models. A finding indicates activity that warrants investigation; it does not necessarily prove that an attacker has succeeded.

The central distinction is between a vulnerability and an active threat. Vulnerability scanning identifies weaknesses, such as a library version associated with a known Common Vulnerabilities and Exposures identifier. Runtime detection identifies suspicious activity, such as a web application spawning a shell that downloads and executes an unfamiliar binary. A workload can contain vulnerabilities without showing evidence of exploitation, and an attacker can misuse valid credentials or legitimate tools without exploiting a known software vulnerability.

In cloud environments, runtime visibility depends on the workload and its execution model. Virtual machines and supported container platforms can expose operating-system events through security agents or other sensors. Managed serverless environments generally provide less direct access to the underlying host, so detection may instead rely on provider-managed telemetry. Engineers must distinguish direct process-level observation from indirect evidence in network or audit records; these sources provide different coverage.

On AWS, Amazon GuardDuty Runtime Monitoring analyzes runtime events from supported Amazon EC2 instances, Amazon EKS workloads, and Amazon ECS workloads, including supported AWS Fargate configurations. Support depends on factors such as operating system, architecture, Region, and deployment configuration. GuardDuty Lambda Protection uses network activity associated with Lambda functions to identify threats; it is not the same as deploying the Runtime Monitoring security agent inside a Lambda execution environment.

Amazon Inspector serves a complementary purpose: it scans supported EC2 resources, container images in Amazon ECR, and Lambda functions for vulnerabilities. Lambda standard scanning assesses supported package dependencies, while optional Lambda code scanning identifies certain code-level security issues. For an exam scenario asking for known vulnerabilities in container images or Lambda dependencies, choose vulnerability scanning. For suspicious behavior in an executing workload, choose threat detection with the appropriate telemetry coverage.

For example, a container image scan might identify a vulnerable application library before deployment. After deployment, runtime monitoring might detect an unexpected shell or a connection to infrastructure associated with malware. Investigators should correlate the finding with the image digest, deployment history, workload identity, and relevant audit records. Preserve evidence and use a tested response procedure to isolate or replace the workload, revoke compromised credentials, and correct the underlying weakness.

Operational trade-offs include agent overhead, telemetry costs, privacy considerations, and false positives from legitimate administrative activity. Verify sensor deployment, permissions, connectivity, and coverage health rather than assuming that enabling a service protects every resource. Missing findings do not establish that a workload is safe. Runtime detection also does not inherently block attacks: containment requires separate preventive controls or explicitly configured response automation, ideally with safeguards against disrupting legitimate production activity.