MI-One Issue #27 - Integration with AWS Security

Bringing together endpoint data and threat intelligence for unified detection and response: CrowdStrike

Hi there, and welcome back to MI-One.

Did you know that the most common AWS security integration mistake we see is a subtle one? Sending the right data to the wrong place.

Security Hub and Security Lake both sit at the centre of AWS security architecture, but they are not interchangeable. Security Hub is built for findings while Security Lake is built for normalized telemetry. Blur that distinction, and you risk turning a useful integration into another source of noise.

For product managers, security leaders, and technical alliances teams, the real question is:

How do you decide where each AWS security signal should live?

To understand that, let’s jump right into this month’s issue.

Deep Dive: Rethinking AWS Security Integrations

When teams build AWS security integrations, two assumptions often come up:

AWS Security Hub should receive all security data.
Amazon Security Lake is simply a place to store logs.

Both ideas are completely understandable, but they miss how AWS security services are meant to work together.

Security Hub is built for findings. It uses ASFF to normalize findings from AWS services, third-party tools, and custom integrations, making it useful for prioritization and security operations. But it is not meant for every raw log, event, or high-volume data stream.

Security Lake is different. It is a normalized security data lake built around OCSF, where supported logs and events are stored in Amazon S3. Custom sources must also follow OCSF and Apache Parquet for consistent querying and correlation.

A better approach is:

Send findings to Security Hub using ASFF
Send data to Security Lake using OCSF
Use EventBridge or automation when signals need action

The real question then is not, “Where do we send AWS security data?” but “What kind of signal are we working with, and where will it create the most value?”

With that lens, let’s look at a real-world integration pattern that shows how AWS security signals can become actionable.

Featured Integration: AWS Security Lake + Cloud Native Threat Detection Platform

In this integration, Amazon Security Lake acts as the normalized security data layer, while a cloud-native threat detection platform contributes security findings and threat signals from AWS environments.

The threat detection service generates findings from AWS activity such as API behavior, network activity, DNS activity, and workload signals. Security Lake can collect supported AWS security data and convert it into OCSF and Apache Parquet, making it easier to query, analyze, and correlate with other security telemetry.

Once ingested, this data becomes part of the customer-owned Security Lake environment. From there, teams can analyze it alongside other AWS, third-party, and custom sources using downstream analytics, SIEM, or XDR tools.

The value of this integration is straightforward:

Cloud threat signals become usable for broader detection and investigation
OCSF normalization improves correlation across AWS and external telemetry
Investigations move faster because cloud context is available in a common data layer

To understand why this integration works, it helps to look at how AWS security evolved from visibility services into a broader detection and response ecosystem.

Platform Evolution: AWS Security Ecosystem

Fun Fact: Did you know AWS co-founded OCSF with Splunk before making it central to Amazon Security Lake?

Indeed: AWS co-announced OCSF in 2022 as an open framework for normalizing security telemetry across products and services. AWS named Splunk as a co-founder with AWS of the OCSF project, and Security Lake later adopted OCSF to normalize AWS and third-party security data.

As for the rest of the timeline, see for yourself:

Trending AWS Security Integrations

Tips & Tricks: Building AWS Security Integrations

Use ASFF when sending findings to AWS Security Hub; include account ID, region, resource ARN, severity, timestamps, remediation guidance, and workflow status.
Use OCSF when sending telemetry to Amazon Security Lake; custom sources must deliver OCSF-aligned data in Apache Parquet format.
Preserve AWS context in every record: account ID, region, resource ID, ARN, IAM principal, source IP, and event time.
Design for AWS Organizations from the start; enterprise deployments usually require multi-account and multi-region support.
Use EventBridge for response routing; findings can trigger Lambda, Step Functions, ticketing, or SOAR workflows.

These choices also shape how teams can take advantage of newer AWS security capabilities.

What's New AWS?

AWS recently announced updates that point to a broader shift toward governed AI workflows

Want to Learn More?

We’ve built a resource hub covering the integrations, architectures, and platforms that matter most to security teams. Each blog draws from hands-on experience implementing these systems at scale.

Explore more AWS Security topics:

Next Month in Focus:
Microsoft Security Ecosystem. Stay tuned!