5.4 Edge Integrations: Managed Rule Groups, OCSF Ingestion, IoT Policies & CORS

5.4 Edge Integrations: Managed Rule Groups, OCSF Ingestion, IoT Policies & CORS

SCS-C03 Skill 3.1.4 asks you to integrate AWS edge services with third-party services, for example by using third-party WAF rules and ingesting data in Open Cybersecurity Schema Framework (OCSF) format. Skill 3.1.2 also lists edge controls that don't fit neatly into CloudFront or AWS WAF alone: AWS IoT policies and Amazon S3 cross-origin resource sharing (CORS). This section covers those integrations.

---

Managed Rule Groups: AWS and Third-Party

AWS WAF web ACLs can combine your own rules with managed rule groups maintained by someone else.

Operating managed rule groups well:

• Test before blocking: Override a new rule group's rule actions to Count, review the WAF logs and labels, then switch to the vendor's actions.
• Use labels: Managed rules add labels (for example, awswaf:managed:aws:bot-control:bot:category:...). Later rules in the web ACL can match on labels to build logic such as "block this bot category only on the checkout path."
• Control versions: AWS managed rule groups can be pinned to a static version and subscribed to SNS notifications about new versions, so updates don't surprise production.
• Budget capacity: Every rule group consumes web ACL capacity units (WCUs). Vendor rule groups can't be edited, but individual rules can be overridden.
• Deploy centrally: AWS Firewall Manager can push a web ACL containing AWS and Marketplace rule groups to every account in an organization.

---

Client Fingerprinting at the Edge

AWS WAF can match the JA3 and JA4 TLS client fingerprints of requests to CloudFront distributions and Application Load Balancers. A fingerprint identifies the TLS client software regardless of the source IP address, so a botnet rotating through thousands of IP addresses can still be blocked if its client library produces a consistent fingerprint. Combine fingerprint matches with rate-based rules and Bot Control labels rather than relying on any single signal.

---

Sending Edge Data to Third-Party Tools and OCSF

Edge telemetry is most useful when it reaches the tools your security operations center already uses.

• AWS WAF logging destinations are a CloudWatch Logs log group, an S3 bucket, or an Amazon Data Firehose stream, and each destination name must start with aws-waf-logs-. Firehose can deliver to third-party SIEM destinations such as Splunk, Datadog, or an HTTP endpoint.
• Amazon Security Lake collects AWS WAF logs as a native source and converts them to OCSF, alongside CloudTrail, VPC Flow Logs, Route 53 Resolver query logs, and Security Hub findings. Subscribers such as a SIEM receive the normalized data through S3 access or Lake Formation-based query access.
• Third-party edge data, such as logs from a third-party CDN, WAF, or firewall, can be added to Security Lake as a custom source. The provider must write records in OCSF format as Apache Parquet files to the custom source's S3 location; Security Lake creates the Glue crawler and IAM role that register the data.
• CloudFront standard logs can be delivered to CloudWatch Logs, Firehose, or S3, which lets the same pipelines handle CDN access logs.

Normalizing to OCSF means a detection written against src_endpoint.ip works whether the event came from AWS WAF, a VPC Flow Log, or a partner firewall.

---

AWS IoT Core Policies

Internet of Things devices connect to AWS IoT Core at the edge of your environment, usually over MQTT with mutual TLS and an X.509 client certificate. AWS IoT Core policies (separate from IAM policies) are attached to the device certificate, a thing group, or an Amazon Cognito identity, and they authorize MQTT actions:

The key least-privilege technique is policy variables, which scope one policy to many devices:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": "arn:aws:iot:us-east-1:111122223333:client/${iot:Connection.Thing.ThingName}"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:us-east-1:111122223333:topic/devices/${iot:Connection.Thing.ThingName}/telemetry"
    }
  ]
}

Each device may connect only with its own thing name as the client ID and publish only to its own telemetry topic, so one stolen certificate can't impersonate other devices. AWS IoT Device Defender audits for overly permissive policies, shared certificates, and revoked or expiring certificates, and its detect feature flags unusual device behavior.

---

Amazon S3 Cross-Origin Resource Sharing (CORS)

Browsers block a web page on one origin from reading responses from another origin unless the response includes CORS headers. An S3 CORS configuration lists rules with AllowedOrigins, AllowedMethods, AllowedHeaders, ExposeHeaders, and MaxAgeSeconds.

Two security points matter for the exam:

1. CORS is not access control. It tells browsers which cross-origin reads to allow; it doesn't stop a direct request from a script or the AWS CLI. Protect the data with bucket policies, Block Public Access, CloudFront origin access control, and presigned URLs.
2. Keep origins specific. "AllowedOrigins": ["*"] combined with methods such as PUT lets any website drive a user's browser to upload using the user's own presigned URLs or cookies. List exact origins, such as https://app.example.com.

When CloudFront fronts the bucket, forward the Origin header through an origin request policy (or a managed CORS policy) and, if needed, add CORS headers with a response headers policy. Otherwise the cached response may not include the headers the browser expects.

---

Specialty Exam Pitfalls

1. Blocking with an untested vendor rule group: Start new managed rule groups in Count mode to avoid blocking legitimate traffic.
2. Wrong WAF log destination name: Log groups, buckets, and Firehose streams for AWS WAF logs must be named with the aws-waf-logs- prefix.
3. Custom Security Lake sources in raw JSON: Custom sources must provide OCSF data in Parquet.
4. One broad IoT policy for all devices: Use policy variables so each certificate can act only as its own thing.
5. Treating CORS as authorization: CORS relaxes browser restrictions; it never protects data from direct requests.