Question

• Is it possible to forward content from one Azure Log Analytics Workspace to another?

Note that I am not asking about multihoming the Log Analytics agent, such that it writes to two Workspaces. Rather, I would like to know whether, in the case where I already have two Workspaces, if one of them can send its content to the other on an ongoing basis.

Environment & Business Case

Sentinel

We are using Azure Sentinel to monitor logs for both our Azure-based and on-premises resources. We are using a single Sentinel instance, with a single Log Analytics Workspace. All of the resources we need to monitor store their logs in this one Workspace, per the recommendation of the Microsoft doc.

On-Prem Windows Hosts

For our on-prem Windows servers, we are using the Azure Log Analytics agent to send various logs to the Sentinel Workspace. One such log is the Windows Event Log, of which we are sending certain events from the Security, Application, and System logs to Azure. This is working fine.

Unmet Requirement

(Note: Don't let the mention of SQL Server scare you off; it is only incidental to the question at-hand.)

Some of our on-prem Windows hosts are running SQL Server. We have a compliance requirement to audit certain database events. We are using SQL Server Audit to write these events to the Windows Security Event Log.

The problem is that the Log Analytics agent is not sending the events that we care about from the Security Event Log to Sentinel's Log Analytics Workspace. This is expected, based on our configuration; see next.

Technical Issue

Concepts

We can configure which information from the Windows Event Log to store in Azure. This configuration is defined by the target Log Analytics Workspace.

Presently, however, Azure only allows relatively coarse configuration options. For the Security Event Log, we can store nothing, everything, or one of two groups of events: "Minimal" and "Common". Microsoft documents the list of Event IDs in each of these categories.

Problem

Unfortunately, the SQL Server related events that we care about are not included in either the Minimal or Common Event ID groups.

Options

I see several options for storing the specific Event IDs that we want, but each has a nontrivial drawback:

• Store all events. We can change the configuration of Sentinel's Workspace to store all events from the Security Event Log. The problem is that changing this setting will affect all of our Windows hosts (we only need to increase logging for the subset of hosts running SQL Server). If we did this, our data ingress and storage costs would increase dramatically, especially given our long retention requirements.

• Use the new Azure Monitor agent. The Azure Monitor agent will eventually replace the Log Analytics agent, and includes the ability to define granular event storage filters. Presently, however, this agent is in Preview status. Additionally, our schedule does not include enough time to replace our Log Analytics agents with the Azure Monitor agent, learn/write the filters, or update ancillary infrastructure like the Azure Policies that automatically deploy agents to new hosts.

• Create a second Sentinel instance. Using a second Sentinel, with its own Log Analytics Workspace, would allow us send logs from just the database servers there. In turn, we could configure the Workspace to store all events from the Security Event Log. This would allow us to store the events we need from those few database servers, without storing an overwhelming amount of noise from the other Windows servers. The problem is that we'll now have two, independent Sentinel instances which, if I understand correctly, would require additional configuration (e.g. cross-workspace queries for Analytics Rules, Workbooks, etc.) to correlate security events between the different tiers of our environment (e.g. databases, web apps, operating systems).

Solution?

I envision a possible solution where we use a second, "staging" Log Analytics Workspace for just the database servers. This Workspace would be configured to store all events from their Security Event Logs - and then forward those events to the Sentinel Workspace.

In this scenario, the two Workspaces would allow us to configure Event Log storage more granularly than with a single Workspace. But, we would still have a single Sentinel instance that could correlate events using a one, consolidated Workspace.

Admittedly, the second Workspace would be storing duplicate records, but we could configure a short retention period because they would be forwarded for long-term storage to the "real" Workspace that Sentinel is using. The extra cost would be tolerable.

I don't know if this is possible, though. I've read about Continuous Export from Log Analytics Workspaces, but it looks like the targets can only be Storage Accounts and Event Hubs, not other Workspaces.

So, I'm hoping that someone knows of an easy way to forward records from one Log Analytics Workspace to another (i.e. the original question).

Other Ideas?

Of course, if you have other suggestions to accomplish our business goal of sending the specific Windows Security Event Log Event IDs to our Sentinel instance, please feel free to recommend them. Note that we currently have limited access to Sentinel expertise, so anything that requires more than the most modest Sentinel reconfiguration is probably impractical for the moment.

Thank you in advance for your time and consideration.

Azure Log Analytics Workspace Limitations

Unfortunately, this is not currently possible. Azure does not yet support the following:

1. Send logs from one Workspace to another
2. Migrate logs from one Workspace to another

For cost-cutting purposes, we wanted to migrate a Workspace from a certain region, to East US region, because the cost is (EDIT: used to be lower. Somewhere in mid 2021, cost in other regions have reduced to be on par with EUS) 40% lower in EUS. Once we had setup the new Workspace, we tried to ask support for help in moving logs from the old Workspace to the new one but were told it's not possible and to just keep the old Log Analytics Workspace data long enough for the data to just get removed automatically, after the retention period expiry. We explored both options with the Azure team but were told that none of them were supported.

Considerations

1. Sending all event logs will definitely have an impact on the cost. Wouldn't recommend this approach. Instead you can try to filter the logs at source.

2. You're right LA data export is only for Event Hub, Storage Accounts. It does not support sending logs to another Workspace.

3. I just learnt about the new Azure Monitor agent - it looks promising but as you mentioned, is still in preview.

4. As a best practice, Azure recommends to keep the Sentinel Workspaces to one. Here are some pros and cons of this. The wordings here can be confusing. A Sentinel Workspace just refers to the LA Workspace attached to it, not an actual instance of Sentinel. However, depending on the business needs, more than one should be fine, with the other considerations in mind.

Solutions

Option 1

You could have a Powershell script filter and collect the logs locally, and then forward them to your LA Workspace via the Azure Monitor API. This is probably the best approach as it would avoid you changing your Azure setup but requires a bit of work.

Option 2

You can still consider the option of creating a second LA Workspace just for the limited SQL-related logs. You actually do not need to create a second Azure Sentinel instance for this. You only need to make sure your second Workspace is 'linked' to your single Sentinel instance. We're currently using two LA Workspaces attached to a single Sentinel instance. The downside as you mentioned is that you'll still need to do the cross-workspace queries to query data across Workspaces - this is not as tough as it sounds, but there could be some slight latency, amongst other limitations, when doing cross-workspace queries. See, use-case for multiple Sentinel Workspaces.

Option 3

Azure recommends to use Azure Lighthouse to consolidate Sentinel management in one interface. There is no additional cost for using Azure Lighthouse and although this is a product that targets service providers, enterprise customers can also leverage it. This option will still require you to have a second LA Workspace. I'm putting this as the last option as, although it can help with automation, it's also an extra step on top of Option 2.