An incident response playbook for satellite operations on AWS (Part-1): Detection and forensic readiness

Incident response (IR) for satellite operations demands a fundamentally different playbook than traditional IT environments. A satellite orbiting 400 kilometers overhead cannot be quarantined with a firewall rule or reimaged overnight. Contact windows last minutes, not hours. Bandwidth constraints prevent bulk forensic collection. And a single bad command can permanently destroy a spacecraft.

In this post, the first in a two-part series, we focus on the detection and forensic readiness side of satellite IR. This post walks through instrumenting your ground segment with Amazon Web Services (AWS) security services and AWS Ground Station so that threats surface before they cause damage, and forensic data is already flowing when an incident occurs. Part two of the series covers containment, recovery, automated runbooks, and tabletop exercises.

The framework is designed for security operations center (SOC) teams, satellite mission operators, and cloud architects responsible for protecting space assets. The patterns apply to single-satellite missions and multi-satellite constellations alike.

The challenge of satellite incident response

Satellite cyber incidents differ from traditional IT incidents in ways that break conventional IR playbooks. This section outlines the constraints that shape every subsequent phase of the framework.

A low Earth orbit (LEO) satellite is reachable only during scheduled contact windows with ground station antennas. A typical LEO spacecraft passes over a given ground station for approximately 8 minutes every 90-minute orbit.

If your worst-case gap between detecting a threat and taking action on the space segment is 82 minutes, your containment procedures must account for this delay. Pre-computing alternative ground stations across the AWS Ground Station global antenna network can shorten this gap.

Downlink bandwidth for LEO satellites typically ranges from tens of Mbps to several hundred Mbps depending on the radio frequency (RF) band, but with contact windows of only 5 to 10 minutes, operational data takes priority over forensic collection. Full memory dumps or extensive log pulls from the space segment compete directly with mission-critical data.

A bad command sent to a satellite can permanently degrade or destroy an asset worth hundreds of millions of dollars. Unlike a misconfigured server that can be reimaged, spacecraft damage is often irreversible.

Attribution adds another layer of complexity. A telemetry anomaly could be a radiation-induced single-event upset (SEU), thermal stress, hardware degradation, RF interference from a legitimate nearby emitter, intentional jamming, or an actual cyber intrusion. Distinguishing these causes requires correlating data across space weather, orbital mechanics, and cloud security domains simultaneously.

Regulatory frameworks are also shaping how satellite operators approach IR. The US Space Policy Directive 5 (SPD-5), issued in September 2020, establishes cybersecurity principles for space systems and emphasizes that IR capabilities must be integrated before launch. In Europe, the NIS2 Directive classifies space operators as essential entities subject to mandatory incident reporting within 24 hours (early warning), 72 hours (initial assessment), and one month (final report).

The proposed EU Space Act, still in legislative draft as of June 2026, introduces additional cybersecurity obligations specific to space services.

Real-world incidents highlight the stakes. In 2022, a cyberattack on a commercial satellite broadband network exploited a misconfigured VPN appliance to access the trusted management segment, pushing destructive commands that rendered tens of thousands of customer modems inoperable across Europe. The attack cascaded to disable remote monitoring for thousands of wind turbines and disrupt internet service in multiple countries, demonstrating how ground-segment compromises propagate into terrestrial critical infrastructure.

Forensic data collection architecture

The architecture consists of two distinct planes. The control plane captures all AWS Ground Station management operations (scheduling contacts, modifying dataflow endpoints, changing configurations) through AWS CloudTrail. CloudTrail stores these Application Programming Interface (API) logs in Amazon Simple Storage Service (Amazon S3). To achieve immutability, configure the destination S3 bucket with Object Lock in compliance mode, which prevents any principal from modifying or deleting log files until the retention period expires. You can query these logs with Amazon Athena during investigations. Operators, automation scripts, or mission planning software invoke these API calls; CloudTrail passively observes and records them.

The data plane handles the actual satellite downlink: RF data flows from AWS Ground Station antennas into Amazon Elastic Compute Cloud (Amazon EC2) instances running your processing software. This path produces Amazon Virtual Private Cloud (Amazon VPC) Flow Logs (network-level records), application logs (telemetry values your software extracts), and custom metrics published to Amazon CloudWatch for anomaly detection. VPC Flow Logs stream through Amazon Data Firehose into Amazon OpenSearch Service for network-level log correlation and search during investigations.

Both planes feed into a shared detection and response layer where Amazon GuardDuty (consuming CloudTrail logs and VPC Flow Logs) and Amazon CloudWatch (consuming telemetry metrics) generate findings and alarms that route through Amazon EventBridge to orchestrated response workflows. Figure 1 illustrates this architecture:

Figure 1: Forensic data collection architecture for satellite ground segment operations. The control plane (left) captures AWS Ground Station API activity through AWS CloudTrail, storing logs immutably in Amazon S3 for investigation with Amazon Athena. The data plane (right) processes satellite downlink data through Amazon EC2, producing VPC Flow Logs and telemetry metrics. Both planes feed into a detection and response layer where Amazon GuardDuty and Amazon CloudWatch surface findings that route through Amazon EventBridge to AWS Step Functions for orchestrated response.

Space-side indicators of compromise

On the satellite side, watch for unexpected command acknowledgments (commands your system did not send), telemetry values deviating from predicted orbital mechanics or thermal models, and unscheduled satellite mode transitions. Communication link anomalies outside known environmental factors and power consumption patterns inconsistent with the satellite’s operational state also warrant investigation. These indicators are most meaningful when compared against telemetry baselines stored in a time-series data store such as Amazon Timestream for InfluxDB.

Discriminating cyber events from space environment events

The hardest analytical problem in satellite IR is distinguishing adversarial activity from natural phenomena. This four-step decision tree provides a systematic approach:

1. Does the anomaly correlate with a known environmental condition? Check solar activity indexes (Kp, Dst), South Atlantic Anomaly transit timing, eclipse transitions, or known RF interference zones. If yes, the anomaly is likely environmental.
2. Does the anomaly correlate with a Ground Station API call or configuration change? Check CloudTrail. If yes, investigate the identity and authorization of that call.
3. Is the anomaly consistent with known adversary tactics, techniques, and procedures (TTPs) for satellite systems? Cross-reference with threat intelligence.
4. Is the anomaly localized or constellation-wide? A single-satellite anomaly is more likely hardware or environmental. Simultaneous anomalies across multiple satellites suggest a ground-side or systemic issue.

Use Amazon Detective to visualize entity relationships during an investigation. Detective correlates CloudTrail logs, VPC Flow Logs, and Amazon GuardDuty findings into an entity-relationship graph, surfacing which AWS Identity and Access Management (IAM) roles accessed Ground Station APIs in the hours preceding an anomaly and what other resources those roles touched.

Implementing detection with the AWS CLI

This section provides the specific commands that underpin the detection capabilities described above.

Prerequisites:

• An AWS account with AWS Ground Station access and at least one satellite onboarded (or access to the digital twin for testing)
• IAM permissions for AWS CloudTrail, Amazon GuardDuty, Amazon CloudWatch, Amazon EventBridge, and AWS Systems Manager
• AWS CLI v2 installed and configured with appropriate credentials
• jq installed for JSON parsing in investigation commands
• An Amazon VPC configured to receive AWS Ground Station dataflow endpoints

Querying CloudTrail for Ground Station activity

To retrieve all AWS Ground Station API calls from the past 24 hours, use cloudtrail lookup-events with the EventSource attribute:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=groundstation.amazonaws.com \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[*].{Time:EventTime,Name:EventName,User:Username}' \
  --output table

To filter specifically for contact scheduling events and extract fields critical to an investigation:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ReserveContact \
  --start-time 2026-06-01T00:00:00Z \
  --end-time 2026-06-11T23:59:59Z \
  --output json | jq '.Events[] | {time: .EventTime, user: .Username, event: (.CloudTrailEvent | fromjson | {ip: .sourceIPAddress, agent: .userAgent, identity: .userIdentity.arn, params: .requestParameters})}'

This command extracts four fields critical to an investigation. The sourceIPAddress reveals whether the call originated from your expected operations center or an unfamiliar location. The userAgent indicates what tool made the call (your mission planning software, a raw AWS CLI session, or an unfamiliar SDK client). The userIdentity.arn identifies the specific IAM role or user, letting you determine whether this is an authorized operator or a compromised credential. The requestParameters shows which satellite, ground station, and time window were requested, revealing the attacker’s intent if the call was unauthorized.

To list all contacts in a given time window for review during an investigation:

aws groundstation list-contacts \
  --status-list COMPLETED FAILED \
  --start-time 2026-06-01T00:00:00Z \
  --end-time 2026-06-11T23:59:59Z \
  --output table

To retrieve full details on a specific suspicious contact, including its mission profile, satellite, ground station, and dataflow configuration:

aws groundstation describe-contact \
  --contact-id <contact-uuid> \
  --output json

Compare the output against your expected contact schedule to identify unauthorized or unexpected activity.

Setting up CloudWatch anomaly detection for telemetry

If your ground segment application publishes custom metrics from satellite telemetry, you can apply Amazon CloudWatch anomaly detection to automatically baseline these values and alert on deviations. CloudWatch anomaly detection uses machine learning algorithms that account for hourly, daily, and weekly seasonality patterns, training on approximately two weeks of historical data to produce a band of expected values. The resulting model continuously retrains as new data arrives, adapting to evolving telemetry behavior over the satellite’s mission life. Alarms fire only when observed values fall outside this learned band by the number of standard deviations you specify, making the detection threshold explicit and tunable rather than opaque. Create an anomaly detector on a custom telemetry metric:

aws cloudwatch put-anomaly-detector \
  --namespace "SatelliteOps/Telemetry" \
  --metric-name "SignalToNoiseRatio" \
  --stat "Average" \
  --dimensions Name=SatelliteId,Value=SAT-001 \
  --configuration '{
    "ExcludedTimeRanges": [],
    "MetricTimezone": "UTC"
  }'

Then create an alarm that fires when the metric breaches the anomaly band. The --alarm-actions parameter specifies an Amazon Simple Notification Service (Amazon SNS) topic that delivers alerts to your SOC and satellite operations teams when the threshold is crossed:

aws cloudwatch put-metric-alarm \
  --alarm-name "SAT-001-SNR-Anomaly" \
  --evaluation-periods 3 \
  --comparison-operator LessThanLowerOrGreaterThanUpperThreshold \
  --threshold-metric-id ad1 \
  --metrics '[
    {"Id": "m1", "MetricStat": {"Metric": {"Namespace": "SatelliteOps/Telemetry", "MetricName": "SignalToNoiseRatio", "Dimensions": [{"Name": "SatelliteId", "Value": "SAT-001"}]}, "Period": 300, "Stat": "Average"}},
    {"Id": "ad1", "Expression": "ANOMALY_DETECTION_BAND(m1, 2)"}
  ]' \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:satellite-security-alerts \
  --alarm-description "Triggers when SNR deviates from learned baseline by more than 2 standard deviations"

The ANOMALY_DETECTION_BAND(m1, 2) expression tells CloudWatch to use a band width of 2 standard deviations from the learned baseline. A tighter band produces more alerts; a wider band reduces noise but may miss subtle manipulation. For satellite telemetry, start with 2 and adjust based on your false-positive rate. The model takes approximately two weeks of data to train an accurate baseline.

Cleaning up

If you created the Amazon CloudWatch anomaly detector and alarm for testing purposes, remove them to avoid incurring ongoing monitoring costs:

aws cloudwatch delete-anomaly-detector \
  --single-metric-anomaly-detector \
    Namespace="SatelliteOps/Telemetry",MetricName="SignalToNoiseRatio",Stat="Average",Dimensions=[{Name=SatelliteId,Value=SAT-001}]

aws cloudwatch delete-alarms \
  --alarm-names "SAT-001-SNR-Anomaly"

AWS CloudTrail and Amazon GuardDuty are ongoing services recommended for production use and should remain active on your Ground Station accounts.

Conclusion

This post walked through instrumenting a satellite ground segment for detection and forensic readiness using AWS security services. It covered logging AWS Ground Station API activity with AWS CloudTrail, applying machine learning-based threat detection with Amazon GuardDuty, building telemetry baselines with Amazon CloudWatch anomaly detection, and collecting forensic data into immutable storage.

The result is a ground segment that surfaces threats through multiple detection channels, discriminates cyber events from space environment anomalies using a structured decision tree, and continuously preserves evidence for investigation.

In part two of this series, we cover what to do when these detections fire: containment within contact-window constraints, eradication and recovery, automated runbooks with human decision gates, and tabletop exercise scenarios to prepare your team for the real thing.

To get started today, activate AWS CloudTrail and Amazon GuardDuty on your AWS Ground Station accounts. For deeper engagement, reach out to the AWS Aerospace and Satellite team or explore AWS Security Incident Response for integrated case management.

Related reading:

• An incident response playbook for satellite operations on AWS (Part-2): Automated response and recovery
• Test and integrate ground segment with AWS Ground Station digital twin
• Strengthen federal space resilience with AWS Ground Station
• NIST IR 8401: Satellite Ground Segment Cybersecurity Framework
• US Space Policy Directive 5: Cybersecurity Principles for Space Systems