Security Information and Event Management (SIEM) integration lets you capture security events generated in Protector instances and analyze them in your favorite SIEM application.

Depending on your data residency requirements and network architecture, App & API Protector Hybrid offers two methods for collecting and forwarding SIEM data:

Akamai SIEM Open API (Protector v1.4.0+)

This method forwards your security events to Akamai's platform, where they are exposed through the SIEM OPEN API. SIEM connectors then use this API to retrieve your event data.

  • Configuration. You can configure this integration directly from App & API Protector Hybrid Security Configuration > Advanced Settings > Logging > Data collection for SIEM Integration.
  • Connectors. You can use built-in connectors for Splunk or CEF. All connectors retrieve event data through the SIEM OPEN API. Learn more about connectors.

Local SIEM (Protector v1.6.0+)

If you prefer to keep your security data strictly within your own infrastructure, you can configure a local SIEM integration. This setup allows Protector to redirect the security events directly to your local SIEM system.

Configuration is fully automated with the use of AWS Secrets Manager. By securely storing your exporter configuration as a secret, Protector automatically detects it and manages the collector lifecycle on your behalf. After your local SIEM is configured, security events will automatically flow to both your internal SIEM system and Akamai's systems simultaneously.

If your organization's security policies require you to keep all data entirely in-house, you can optionally disable data forwarding to Akamai. You can prevent event logs from leaving your environment by toggling off the Logging switch in your Security Configuration > Advanced Settings > Logging. Disabling this setting blocks Protector from sending attack data to Akamai, ensuring your security events remain exclusively on your local network.

Local SIEM statuses

After you configure local SIEM, you can monitor the operational state of your in the App & API Protector Hybrid Connection Configurations dashboard. Open your Connection Configuration and check the Local SIEM status in the Connection details section:

  • On. Local SIEM is active. Security events generated in Protector instances are forwarded to your local SIEM collector.
  • Off. Local SIEM is inactive. Security events generated in Protector instances are not forwarded to your local SIEM collector. Either configure your local SIEM or make sure if the Logging switch is toggled to ON in your Security Configuration.
  • Conflict. Local SIEM is active on only some Protector instances. Verify your instances to ensure a uniform configuration.
📘

Monitor your local SIEM integration

If you have your local SIEM configured, Protector forwards logs to it but does not monitor its availability or confirm that logs are successfully received. Regularly verify that your SIEM continues to receive logs.

🚧

The SIEM integration for App & API Protector Hybrid follows the same core principles as the universal SIEM guide used across Akamai’s security portfolio. The functional differences include:

  • App & API Protector Hybrid does not support including the JA4 client TLS fingerprint in SIEM events.
  • When configuring exceptions, App & API Protector Hybrid supports the following categories: Rate Limiting, Custom Rules, and Web Application Firewall.

Automatic SIEM configuration via Secrets Manager in Amazon Web Services

Security Information and Event Management (SIEM) integration lets you capture security events generated in Protector instances and analyze them in your favorite SIEM application. This event forwarding is an opt-in feature that layers on top of your existing App & API Protector Hybrid reverse proxy deployment.

When an attack is detected, the Protector container generates a detection record. It then forwards this detection record over the OpenTelemetry Protocol (OTLP) to an OTel Collector container running on the same EC2 instance. Finally, that local collector ships the events directly to your SIEM.

Prerequisites

Before you begin configuring local SIEM event forwarding, ensure you have the following prerequisites in place:

  • Protector v1.6.0 or later.
  • Exporter definitions. Create an exporters.yaml file containing one or more OTel Collector exporter definitions tailored for your specific SIEM.
  • Network access. Verify that your network egress is configured to allow the EC2 instance to communicate directly with your SIEM endpoint.
  • Ingestion pipeline. Ensure your own SIEM ingestion pipeline, properly configured on the collector side to receive the forwarded events.
👍

Deployment control methods

You only need to supply the exporter configuration. Akamai management services automatically handle the rest of the integration.

Use AWS Secrets Manager to securely store your exporter configuration as a secret. Protector will automatically poll for this secret and manage the collector's lifecycle without manual intervention.

Integration steps

If you’ve deployed App & API Protector Hybrid on AWS, you can fully automate your SIEM configuration using AWS Secrets Manager. SIEM integration lets you capture security events generated in Protector instances and analyze them in your favorite SIEM application.

By storing your exporter configuration as a secret, the Protector’s secret poller will automatically detect it and manage the collector lifecycle on your behalf, which means that no manual CLI commands are required.

Step 1. Create the secret

In the AWS Secrets Manager console, create a new secret configured with the following values:

FieldValue
Secret nameaaph-siem-exporter-config
TagsKey: aaph-rp
Value: aaph-rp-secrets

Step 2. Define the secret content

Set your secret's value as plaintext to match your specific exporter definitions. You can use any OTel Collector contrib exporter (such as Datadog, or a generic OTLP, or others) as long as you follow standard exporters: formatting rules described in Step 3 below.

Here’s an example configuration using Splunk HEC:

exporters:
  splunk_hec:
    token: "<your-splunk-hec-token>"
    endpoint: "https://<your-splunk-endpoint>:8088/services/collector"
    tls:
      insecure_skip_verify: true
    source: owaap-engine
    sourcetype: akamai:owaap:dlr
    index: main
    timeout: 15s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s
    sending_queue:
      enabled: true
      num_consumers: 4
      queue_size: 5000

Step 3. Understand the automatic lifecycle

After your secret is created and properly tagged, Protector handles the integration natively:

  • Enable. Protector detects the new secret on its next poll (approximately every 60 seconds). It then automatically starts the aaph-otel-collector container, injects the required OTLP environment variables, and initiates a self-restart to apply the new configuration.
  • Update. To change your configuration, edit the secret in AWS. On the next poll, Protector atomically rewrites the exporter configuration and sends a SIGHUP signal to reload it. This results in zero downtime and does not require a Protector restart.

Step 4. Verify the integration

Completing the steps below ensures that the aaph-otel-collector container in EC2 instance is successfully running and that your security events, generated in Protector instances, are captured and forwarded to your SIEM application.

4.1. Verify the SIEM status in the Akamai Control Center

Finally, confirm that the Akamai services recognize your local SIEM integration. From the Control Center menu, select Security > App & API Protector Hybrid > Connection Configurations. Locate your instance and check the SIEM enabled column. The status should show as On.

4.2 Trigger a test event

Validate the end-to-end data flow by sending a simulated request that intentionally matches a WAF rule through your reverse proxy.

If you included the debug exporter in your configuration, check the recent Protector logs:

docker logs aaph-otel-collector --tail=50

Expected output:

  • You should see the detection logs for the blocked request appear in the container logs.
  • Check your chosen SIEM dashboard to confirm that this same event successfully populated in your system.

Disable the local SIEM integration on AWS

To remove the integration, delete the secret in AWS. After three consecutive polls without detecting the secret, Protector stops the collector and strips the OTLP environment variables. This intentional grace period prevents false positives from AWS propagation delays. Allow 4 to 5 minutes for this grace period to elapse before verifying that the collector has stopped.

Troubleshoot local SIEM integration issues (AWS)

If your local SIEM integration is not functioning as expected on your EC2 instances, use the table below to diagnose and resolve the most common configuration and container issues.

SymptomHow to confirmResolution
Collector container fails to start.
  • Verify container status: SSH into your EC2 instance and run: docker ps --filter name=aaph-otel-collector Expected output: Container status shows Up X minutes.
  • Inspect collector logs: docker logs aaph-otel-collector --tail=20 Expected output: Logs end without YAML parsing errors or missing keys, showing the active pipeline status.

There is likely a syntax or formatting error in the exporter YAML configuration stored in AWS Secrets Manager.

Correct the YAML syntax in your local exporter file, then upload the updated secret to AWS Secrets Manager. The Protector instance will automatically pull and apply the changes.

Collector configuration errors.Run docker logs aaph-otel-collector --tail=20. The logs display parsing errors or missing keys, and you do not see the message: Everything is ready. Begin running and processing data.

The logs display parsing errors or missing keys instead of the startup confirmation, indicating a syntax or formatting error in your exporter secret.

Verify the YAML syntax in your local configuration file. Once corrected, update the corresponding secret in AWS Secrets Manager. The Protector instance will automatically pull the updated secret and reload the collector pipeline.

OTLP variables missing in ProtectorIf you run: docker inspect aaph-protector | grep -i otel the console does not display the OTEL_EXPORTER_OTLP_ENDPOINT alongside related OTel configuration variables.Verify the YAML syntax in your local configuration file. Once corrected, update the corresponding secret in AWS Secrets Manager. The Protector instance will automatically pull the updated secret and reload the collector pipeline.

Telemetry configuration file locations (EC2 instances)

For administrators who need to audit the system or investigate advanced routing behaviors, here is a reference guide to the OpenTelemetry (OTel) configuration files stored directly on your virtual machine instances.

FilePathManaged by
Base configuration/opt/akamai/aaph/otel/otel-base.ymlAkamai. Defines core telemetry receivers and processors. Do not edit this file directly.
Exporters configuration/opt/akamai/aaph/otel/exporters.ymlProtector. Auto-generated and dynamically updated based on your defined exporter configuration.
Pipeline wiring/opt/akamai/aaph/otel/exporters-pipe.ymlProtector. Auto-generated internal bridge that dynamically wires all active exporters into the telemetry pipeline.

Did this page help you?