The ability to maintain a test SIEM has been a challenge for most SOCs. Test environments are typically inadequate as SOC teams cannot rely on a limited dataset to develop and test new rules and automation. At the same time, organizations maintaining a sizeable up-to-date dataset for a development SIEM instance usually means duplicating logs, resulting in additional costs and management overhead.
Not having a test environment means your team is posting experimental rules in production, which can easily cause hundreds of untuned alerts to be generated, throwing off KPI reporting, and causing disorientation across team members. In a worst-case scenario, not having an adequate environment to test detection modifications could create additional false-negative detection risk for the SOC.
Luckily, Microsoft supports the ability to extend Azure Sentinel workspaces with cross workspace queries. This ability allows us to have a separated Sentinel workspace for development that can be used to query data that resides within the production workspace.
In Azure Sentinel, the KQL expression “workspace()” gives us the ability to query data in different workspaces even if the workspaces reside in other resource groups, subscriptions, or even tenants. In this example, I am performing a query from my development workspace “Caleb-Dev-Workspace” to my production workspace “production-ws,” and the table I’m querying is “SigninLogs.”
To make things even easier, we can utilize functions to act as an alias for cross workspace queries. In this example, we saved “workspace(“production-ws”). SigninLogs” as a function called “SigninLogs_Prod”
And, then, we can use the same “workspace()” expression and our functions to create alert rules in our development workspace.
When alerts and incidents are generated, data is only written to our development workspace, minimizing risk in production.
Further Notes
- When moving analytic rules between environments, the “workspace()” expression will need to be replaced with the production table name. For this, a simple find and replace would be adequate. If the goal is to keep the queries exactly the same when moving between dev and prod, we could utilize a similar function on the prod side so that “SigninLogs_Prod” works in both environments.
| Environment | Function Code | Function Name |
|---|---|---|
| Production | SigninLogs | SigninLogs_Prod |
| Development | workspace(“production-ws”).SigninLogs | SigninLogs_Prod |
- In this example, querying across workspaces is minimal risk as the development workspace is not writing to the prod workspace. But, when dealing with automation and playbooks, there should be extra considerations as we wouldn’t want development playbooks performing actions on prod data or resources.
- Since the cost of Microsoft Azure Sentinel is based on data ingestion/storage, our development workspace is extremely cost effective as the only data we are storing is for incidents and alerts.
Caleb Freitas is a Managed Sentinel security architect.