Send Azure Activity Logs To Amazon EventBridge

With TriggerMesh, you can accomplish the ingestion of security events from your multiple cloud providers (e.g GCP, AWS, Azure), transform the events in specific schemas and send those events to any destination (called Target in TriggerMesh lingo). The collection, transformation and dispatching of events in TriggerMesh is called a Bridge.

In this post we will be looking at a specific example of extracting audit log messages from Azure Activity Logs and sending them to AWS EventBridge from where they can be sent to AWS CloudWatch for example.  Throughout this example, keep in mind that you can change any piece of this bridge to suit your specific needs.  For example, the source could be Oracle Cloud Infrastructure (OCI) or Google Cloud Audit Logs, and the target could be your on-premises data center or a SaaS application like SecureWorks Taegis.

We will keep this straightforward with two parts:

• Getting the logs from Azure
• Sending them to AWS eventbridge

Transformation to the desired schema can be done with the TriggerMesh JSON transformation.

Get Azure Activity Logs

Azure Activity logs can be exported from Azure by routing them over Azure Event Hubs. This routing is done by registering Diagnostic Settings that automatically send a selected set of log categories to a dedicated Event Hub.  Then, once the logs are on the hub, TriggerMesh can subscribe to that hub to send the events on to the destination.  To set this up, you’ll need to create an Azure Service Principal, an Event Hubs namespace, an Event Hubs instance, and a Shared Access Policy.

Service Principal Creation

A Service Principal is required in order to authenticate the event source against the Azure tenant that has authority over the Azure Subscription to monitor. You can create a Service Principal by following the instructions at How to: Use the portal to create an Azure AD application and service principal that can access resources.

The section called “Assign a role to the application” describes how to assign permissions to the Service Principal. Make sure you select a role which has at least the following permissions:

• Microsoft.Insights/DiagnosticSettings/Read
• Microsoft.Insights/DiagnosticSettings/Delete
• Microsoft.Insights/DiagnosticSettings/Write
• Microsoft.EventHub/namespaces/authorizationRules/listkeys/action

Additionally, assign the role Azure Event Hubs Data Receiver to the Service Principal to allow it to receive events from Event Hubs. After the Service Principal is created and assigned suitable roles, take note of the following information:

• Tenant ID 
• Client ID
• Client secret 

Event Hubs Namespace

Follow the instructions at Quickstart: Create an Event Hub using Azure portal, and create a new Event Hubs namespace. This namespace will contain an Event Hubs instance which will be configured by the event source as the destination of Activity Logs originating from the Azure subscription.

Event Hubs Instance

When the Event Hub's name is omitted upon deployment of the event source, Azure creates an Event Hub with the name insights-activity-logs upon reception of the first log entry (which can take a few minutes).

If, however, you prefer to provide your own Event Hub for that purpose, follow the instructions at Quickstart: Create an Event Hub using Azure portal to create an Event Hubs instance. Take note of its resource ID, it is a required input to be able to run an instance of the Azure Activity Logs event source.

A resource ID for an Event Hub has the following format:

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.EventHub/namespaces/{namespaceName}/eventHubs/{eventHubName}

Shared Access Policy / Shared Access Signature (SAS)

The TriggerMesh Activity Logs event source requires a reference to the name of a Shared Access Policy (also called Shared Access Signatures). This policy contains a token that can be used to delegate permissions within an Event Hubs namespace, such as the management of Event Hub instances.

Open your Event Hubs namespace, then open the “Shared access policies” panel under the Settings section of the Event Hubs screen. By default, the namespace contains a pre-created policy called “RootManageSharedAccessKey” with Manage, Send, and Listen claims, which is perfectly suitable for the TriggerMesh Activity Logs event source. If you prefer to use your own policy instead, make sure it has the same Manage, Send, and Listen claims as the default policy.

TriggerMesh Setup

With the Event Hub configured, you can consume the audit logs using the TriggerMesh AzureActivityLogsSource event source. Below is a sample TriggerMesh API manifest that connects to your Azure service principal. This manifest is deployed on a Kubernetes cluster that runs the TriggerMesh platform:

apiVersion: sources.triggermesh.io/v1alpha1
kind: AzureActivityLogsSource
metadata:
  name: sample
spec:
  subscriptionID: 00000000-0000-0000-0000-000000000000
  categories:
  - Administrative
  - Security
  - Policy
  destination:
    eventHubs:
      namespaceID: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/MyGroup/providers/Microsoft.EventHub/namespaces/MyNamespace
  auth:
    servicePrincipal:
      tenantID:
        value: 00000000-0000-0000-0000-000000000000
      clientID:
        value: 00000000-0000-0000-0000-000000000000
      clientSecret:
        value: some_secret
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: default

Modify the relevant parts of the manifest based on what you created above, then any Azure Activity Logs should start getting sent to the TriggerMesh broker.

Send Logs to AWS EventBridge

Now that the logs are being sent from Azure to TriggerMesh, we can transform them with our transformation engine and we can send the events to AWS EventBridge using our AWSEventBridgeTarget API.  Here is the API manifest:

apiVersion: targets.triggermesh.io/v1alpha1
kind: AWSEventBridgeTarget
metadata:
  name: eb
spec:
  arn: arn:aws:events:us-west-1:043466334429:event-bus/foobar
  awsApiKey:
    secretKeyRef:
      name: awscreds
      key: aws_access_key_id
  awsApiSecret:
    secretKeyRef:
      name: awscreds
      key: aws_secret_access_key

The only thing you’ll need to change is the “arn”, “aws_access_key_id”, and “aws_secret_access_key”. Note that the authentication can also be done with a restricted scope IAM role with only access to EventBridge

In the EventBridge console you setup a rule to send events with the type `com.microsoft.azure.monitor.activity-log` to a target pointing to a CloudWatch log stream. In the snapshot below notice the event pattern specifying the TriggerMesh event type of the Activity Log source.

With the EventBridge rule in place, Azure Activity Logs consumed by TriggerMesh will be sent to AWS CloudWatch. The snapshot below shows an Azure Activity Logs log message in the CloudWatch console.

Conclusion

Multi-cloud scenarios are becoming more common. Cyber security events and the need to ingest them centrally before transformation and dispatching for analysis is a prime use-case. In this blog we showed you the steps to connect Azure Activity Logs to AWS CloudWatch. Similar bridges can easily be configured to send your security events to other endpoints like SecureWorks Taegis or Azure Sentinel.