Skip to main content
Version: 2.14.1

AWS Security Hub Integration

Free integration setupWe’ll install and validate this for you.
Book a setup call

Support Statement

DISCLAIMER

This documentation is provided "as is" without support for 3rd party software. The level of support for this integration guide is best effort without any SLA on response time. No 3rd party product support can be provided by Superna directly. 3rd party components require support contracts. See EULA for more details.


Overview

Customers using AWS Security Hub to aggregate cloud alarms and on-premises security events can integrate Superna products with the native AWS Security Hub API to translate Zero Trust API alerts sent by webhooks into native Findings within the Security Console. This guide walks through how to set up a real-time Zero Trust to AWS Security Hub finding sync process.

Limitations

The UpdateFindings API method is not supported in this integration. The last Zero Trust alert sent for an event creates the Finding that Security Hub uses for incident tracking.

Solution Overview

Superna Defender Zero Trust API is the cornerstone technology used to integrate with SIEM, SOAR, and XDR platforms. Automation begins with data that summarizes the threat and places that information into a security tool to be acted on by SecOps, and to run playbooks to protect corporate IT assets from vulnerabilities and insider or external attackers. This guide covers the basic field mapping used to push Zero Trust Defender alerts into AWS Security Hub.

What Is AWS Security Hub?

Suggested reading:

Integration Architecture

note

The integration architecture diagram is available in the legacy portal.

Solution Configuration in AWS Security Hub and Defender Zero Trust

Prerequisites

  • Installed Ransomware Defender and/or Easy Auditor or Defender for AWS
  • Eyeglass OS appliance version 15.5 — verify with cat /etc/os-release
  • License key for the Zero Trust API
  • AWS Security Hub service activated in your AWS account

Configuration in AWS Security Hub

Once the Security Hub service is activated, decide on a home region. This is the region where Zero Trust API findings are sent. Security Hub allows aggregation of findings across different regions, but the main region is where third parties should integrate custom findings.

  1. Create the custom ARN used to identify the Findings created by Superna Defender. Replace the following values:

    • Account ID — replace 123456 with your AWS account ID where Security Hub is activated
    • Primary region — replace us-east-2 with your target region
    arn:aws:securityhub:us-east-2:123456:product/123456/default

    Record this value — you will use it in the configuration steps below.

  2. Create a minimum-permissions IAM user in the main region for the integration application. The built-in AWSSecurityHubFullAccess role can be used, or apply the following minimum permissions policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"securityhub:ImportFindingsForProduct",
"securityhub:UpdateFindings",
"securityhub:GetFindings",
"securityhub:EnableImportFindingsForProduct",
"securityhub:BatchImportFindings",
"securityhub:DescribeProducts"
],
"Resource": "*"
}
]
}

Configuration Steps on Eyeglass Virtual Machine

High-Level Steps

  1. Create the Python location to run the application on the Eyeglass VM.
  2. Create the Python main application script.
  3. Create the Linux systemd service and set it to auto-start.
  4. Create the Zero Trust configuration in Defender.
  5. Update the main script to customize it with the AWS Security Hub custom findings ARN.
  6. Test the script is running as a service.
  7. Create a test event in Defender to validate alerts appear as Findings in AWS Security Hub.

Configure the Service Start and Python Integration Files

Log in to the Eyeglass VM via SSH as the admin user:

ssh admin@<your-vm-ip>

Become root:

sudo -s

mkdir -p /opt/superna/cgi-bin

chown -R sca:users /opt/superna/cgi-bin

chmod -R u+rwX,g+rwX /opt/superna/cgi-bin

Switch to the SCA user:

sudo -u sca -s

cd /opt/superna/cgi-bin

Create a Python virtual environment for the integration:

python3 -m venv venv-aws

source venv-aws/bin/activate

Install required Python packages:

pip install flask boto3 requests logging

deactivate

Create integration script files:

touch aws.py

touch aws.sh

chmod +x aws.py

chmod +x aws.sh

Create the aws.sh launch script:

nano /opt/superna/cgi-bin/aws.sh

Paste the following content into the file:

#!/bin/bash

export PATH="/opt/.pyenv/bin:$PATH"

source /opt/superna/cgi-bin/venv-aws/bin/activate

exec python /opt/superna/cgi-bin/aws.py

Make the script executable:

chmod +x /opt/superna/cgi-bin/aws.sh

Exit back to root:

exit

whoami # confirm you are root

Create the systemd service unit file:

nano /etc/systemd/system/aws.service

Paste the following content into the file:

[Unit]
Description=Webhook listener for Zero Trust API translations and integrations
After=network.target

[Service]
Type=simple
User=sca
Group=users
WorkingDirectory=/opt/superna/cgi-bin
ExecStart=/bin/bash /opt/superna/cgi-bin/aws.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Reload systemd to register the new service:

systemctl daemon-reload

Enable the service to start on boot (do not start it yet):

systemctl enable aws

Configure Python Packages and Customize the Integration Code

  1. Download the Python template code from the link to download (right-click, save as).

  2. Open the Python template file in a text editor. Only replace the values — do not delete any commas.

  3. Locate the AWS credentials section and replace the placeholder values:

    • Replace xxxx with your AWS access key ID
    • Replace yyyy with your AWS secret access key
    • Replace us-east-2 in both locations with your selected main region
  4. Locate the product ARN section and replace 123456 with your AWS account ID and update the region to match your selected main region.

  5. Save the file as ztWebhook.py.

    note

    The file name must match the exact case and spelling shown for the documented steps to work correctly.

  6. Open the production file on the Eyeglass VM:

    nano /opt/superna/cgi-bin/ztWebhook.py
  7. Open the template file locally in Notepad, select all (Ctrl+A), and copy.

  8. Paste the clipboard into the SSH terminal session with the open nano editor.

  9. Save the file:

    • Press Ctrl+X
    • Answer Yes to save and exit
  10. Start the service and verify it is running:

    systemctl start ztWebhook

    systemctl status -l ztWebhook

    Verify the service returns "active and running". If the service does not start, do not proceed — double-check the steps above.

Configure Defender Zero Trust Webhooks

  1. Configure the Zero Trust endpoint in the Ransomware Defender Zero Trust tab.

    Recommended Configuration

    Send only Critical and Major events, and only webhooks that set lockout or delayed lockout. The goal is to send findings rather than a list of alarms that do not pinpoint a security incident. Customers can customize based on specific requirements.

  2. The endpoint URL uses localhost and sends webhooks to the application service listening on port 5000:

    http://localhost:5000/awssechub
  3. Add the Content-Type header with value application/json to complete the webhook configuration.

  4. Click Save to commit the configuration.

  5. Click Save on the main Webhook configuration page.

How to Test the Integration with AWS Security Hub

  1. Download the curl command template and open it with a text editor.
  2. Copy all the text.
  3. SSH to the Eyeglass VM as the admin user.
  4. Paste the entire CLI command to the SSH prompt to send sample data to the running Zero Trust application. This sends test data directly to the application to be processed and sent to AWS Security Hub.

A successfully processed webhook test returns the following text in the SSH terminal:

done sending AWS secops API call check for http 200 and success count in response

To review the process logs from the web application:

sudo -s

journalctl -f -u ztWebhook

To log to a file and review with nano, showing only the most recent 250 lines:

journalctl -f -n 250 -u ztWebhook > /tmp/ztwebhook.log

nano /tmp/ztwebhook.log

The response code from the AWS Security Hub API call should show HTTP 200 status code and successCount 1 to indicate the Finding was successfully created.

note

To repeat the test, mark the Finding as resolved in AWS Security Hub first, then increment the Finding unique ID value in the curl command before running it again. Each Finding requires a unique ID. In production, Defender auto-increments this value — in a test scenario you must update it manually.

Log in to the AWS Security Hub main dashboard to view the new Finding.

AWS Security Hub SecOps Integration Experience

Once the integration is complete, SecOps administrators can view new Findings generated by critical security incidents in Defender for AWS or Ransomware Defender.

Click on Superna Ransomware Defender Security Finding to see additional Finding details mapped to the Standard Finding field schema.

Click on Cyber Storage Event to view the fully customized section that leverages rich data available in Superna Zero Trust webhook payloads. SecOps teams can use this data to triage and action the Finding with specific information such as:

  • AD user affected
  • Protocol detected
  • Number of files involved in the incident
  • Source IP address of the affected host
  • SMB shares containing infected data
  • Status of the incident
  • Detection time
  • Device type and cluster name affected

SecOps teams can use AWS Security Hub features to integrate Cyberstorage-protected on-premises storage threats and cloud threats into a single aggregation view.