Prolog

I needed to come up with a detection for an AWS environment, that is cheap, will take custom detection (preferably Sigma rule for easier maintenance) and somewhat flexible/ customizable. I ended up using with the Lambda that consume sigma and CloudTrail, called CTDE.

Now the next hurdle is deploying detection as a code (kinda) for CTDE. Just like CTDE before, we need to draw up requirement for this pipeline. Which are version control, audit log, verification of the rules, re-usability (this is taken care of, since CTDE consume Sigma rules).

Setup

The pipeline setup consist of a repository, Github action to verify Sigma and another one to push to S3 rule bucket of the CTDE. in the AWS side, the action was limited by a role that uses Github OIDC to authenticate and a policy to limit that role permission.

To set this up, you will need to:

1. Create an OIDC Provider in IAM

   • Go to the IAM console → Identity Providers → Add provider.

   • Select OpenID Connect.

   • For Provider URL, enter https://token.actions.githubusercontent.com.

   • For Audience, enter sts.amazonaws.com.

2. Create IAM role for deployment

   • Select Web identity for the trusted entity type.

   • For Identity provider, select the OIDC provider you created (e.g., token.actions.githubusercontent.com).

   • For Audience, choose sts.amazonaws.com

3. Attach permission policy: use permission boundary to limit it to the S3 rules bucket or use custom permission policy

4. Setup Github secrets: as you might’ve seen from the Github action, you’ll need secrets setup in Github AWS_OIDC_ROLE_ARN, S3_BUCKET_NAME, and AWS_REGION.

We’ll go through each of the component below.

Github Action and Repository

The setup consist of two Github actions. One to verify the Sigma rules and will run if changes happens to repository and the second one to sync to S3 rule bucket when verification is successful. This ensure that all synced (and later loaded) rules are verified. While the use of repository ensure a version control and audit log is available.

name: Validate Sigma Rules

on: [push, pull_request, merge_group, workflow_dispatch]

jobs:
  sigma-rules-validator:
    runs-on: ubuntu-latest
    steps:
      - name: Validate Sigma rules
        uses: SigmaHQ/sigma-rules-validator@v1
        with:
          paths: ./rules

The rule tester uses SigmaHQ rules validator, but can also takes custom Sigma rules schema. Custom schema can be useful later when correlation between Sigma rules are introduced to CTDE.

name: Deploy Sigma Rules to AWS S3 (OIDC)

on:
  workflow_run:
    workflows: ["Validate Sigma Rules"] 
    branches: [main]
    types: 
      - completed

# Required: Define permissions for the OIDC token
permissions:
  id-token: write # This is required for OIDC to fetch the token
  contents: read  # Required to checkout the repository code

jobs:
  deploy_rules:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:d
      - name: Checkout repository code that have been validated
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.workflow_run.head_sha }}

      - name: Configure AWS Credentials with OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_OIDC_ROLE_ARN }} # Uses the ARN of the secure role
          aws-region: ${{ secrets.AWS_REGION }}
          role-session-name: GitHubAction-SigmaDeployment 

      - name: Sync Sigma Rules to S3 Bucket
        # The AWS CLI command now runs using the temporary credentials it assumed
        run: |
          aws s3 sync ./rules/ s3://${{ secrets.S3_BUCKET_NAME }}/ --delete

The second Github action then syncs the repository, once the workflows “Validate Sigma Rules” complete, as you can see in the code above. The Github action connects to S3 rules bucket by assuming a role and authentication is handled by OIDC.

Testing and Validation

If you read Practical Detection Engineering, you might be a bit confused because of the wording “validation” used in the github action portion previously. To be clear, the particular github action is actually doing validation strictly for schema of the sigma rule. This has little to do with detection validation I talked about before.

As part of the pipeline, I also do some detection testing to ensure the detection definition (rule/code) is implemented correctly and accurately reflects its intent in the production environment. I did this by running stratus and grimoire, depends on which rule I am trying to test. Findings can be summarized to these points:

1. Most of the Sigma rule fare well, this is expected since at phase 2, CTDE still consume simple Sigma rule.

2. A portion of the Sigma will rule takes longer to consume, hence Lambda timeout need to be extended. This feeds back to the CTDE projects. This is also something to be expected as we developed more complicated rules.

3. Some of the stratus terraform is not working. A workaround I did was to research what the stratus trying to emulate and conduct them via ClickOps, or better, run grimoire with AWS CLI.

IAM Role and Policy

After setting up role with the steps listed above, your IAM role trust policy should looked like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
                    "token.actions.githubusercontent.com:sub": "repo:repo-org/repo-name:ref:refs/heads/main" 
                }
            }
        }
    ]
}

I used custom AWS policy that looked like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ObjectManagement",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::bucket-name/*"
        },
        {
            "Sid": "AllowS3BucketListing",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::bucket-name"
        }
    ]
}

Both are pretty self explanatory.

More

More reading if you plan to setup something similar:

https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/

https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws

https://medium.com/@integrationninjas/authenticate-github-actions-with-aws-using-oidc-16f90f54f104

Epilog

A secure, automated, and auditable detection pipeline for a CloudTrail Detection Engine (CTDE) can be effectively implemented by combining GitHub Actions with AWS OIDC (OpenID Connect) authentication.