AWS Security Hub Integration
Support Statement
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
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.
-
Create the custom ARN used to identify the Findings created by Superna Defender. Replace the following values:
- Account ID — replace
123456with your AWS account ID where Security Hub is activated - Primary region — replace
us-east-2with your target region
arn:aws:securityhub:us-east-2:123456:product/123456/defaultRecord this value — you will use it in the configuration steps below.
- Account ID — replace
-
Create a minimum-permissions IAM user in the main region for the integration application. The built-in
AWSSecurityHubFullAccessrole 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
- Create the Python location to run the application on the Eyeglass VM.
- Create the Python main application script.
- Create the Linux systemd service and set it to auto-start.
- Create the Zero Trust configuration in Defender.
- Update the main script to customize it with the AWS Security Hub custom findings ARN.
- Test the script is running as a service.
- 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
-
Download the Python template code from the link to download (right-click, save as).
-
Open the Python template file in a text editor. Only replace the values — do not delete any commas.
-
Locate the AWS credentials section and replace the placeholder values:
- Replace
xxxxwith your AWS access key ID - Replace
yyyywith your AWS secret access key - Replace
us-east-2in both locations with your selected main region
- Replace
-
Locate the product ARN section and replace
123456with your AWS account ID and update the region to match your selected main region. -
Save the file as
ztWebhook.py.noteThe file name must match the exact case and spelling shown for the documented steps to work correctly.
-
Open the production file on the Eyeglass VM:
nano /opt/superna/cgi-bin/ztWebhook.py -
Open the template file locally in Notepad, select all (Ctrl+A), and copy.
-
Paste the clipboard into the SSH terminal session with the open nano editor.
-
Save the file:
- Press Ctrl+X
- Answer Yes to save and exit
-
Start the service and verify it is running:
systemctl start ztWebhook
systemctl status -l ztWebhookVerify 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
-
Configure the Zero Trust endpoint in the Ransomware Defender Zero Trust tab.
Recommended ConfigurationSend 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.
-
The endpoint URL uses localhost and sends webhooks to the application service listening on port 5000:
http://localhost:5000/awssechub -
Add the Content-Type header with value application/json to complete the webhook configuration.
-
Click Save to commit the configuration.
-
Click Save on the main Webhook configuration page.
How to Test the Integration with AWS Security Hub
- Download the curl command template and open it with a text editor.
- Copy all the text.
- SSH to the Eyeglass VM as the admin user.
- 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.
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.