Azure Sentinel News
  • Home
    • Home – Layout 1
    • Home – Layout 2
    • Home – Layout 3
  • Security and Compliance
  • SOC
  • Threat Intelligence
  • Security Ochestration & Automated Response
  • SOAR
  • Security Operations
  • Artificial Intelligence
No Result
View All Result
  • Home
    • Home – Layout 1
    • Home – Layout 2
    • Home – Layout 3
  • Security and Compliance
  • SOC
  • Threat Intelligence
  • Security Ochestration & Automated Response
  • SOAR
  • Security Operations
  • Artificial Intelligence
No Result
View All Result
Azure Sentinel News
No Result
View All Result
Home SOC

Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

Azure Sentinel News Editor by Azure Sentinel News Editor
December 16, 2020
in SOC
0
With new release, CrowdStrike targets Google Cloud, Azure and container adopters
4.5kViews
651 Shares Share on Facebook Share on Twitter

Executive Summary

When you register the Microsoft.Security Resource Provider (RP) for a subscription and want to start using Azure Security Center or when you want to use Azure Sentinel, you are confronted with workspace design choices which will affect your experience going forward.

The top 8 best practices for an optimal Log Analytics workspace design:

  1. Use as few Log Analytics workspaces as possible, consolidate as much as you can into a “central” workspace
  2. Avoid bandwidth costs by creating “regional” workspaces so that the sending Azure resource is in the same Azure region as your workspace
  3. Explore Log Analytics RBAC options like “resource centric” and “table level” RBAC before creating a workspace based on your RBAC requirements
  4. Consider “Table Level” retention when you need different retention settings for different types of data
  5. Use ARM templates to deploy your Virtual Machines, including the deployment and configuration of the Log Analytics VM extension. Ensure alignment with Azure Policy assignments to avoid conflicts
  6. Use Azure Policy to enforce compliance for installing and configuring Log Analytics VM extension. Ensure alignment with your DevOps team if using ARM templates
  7. Avoid multi-homing, it can have undesired outcomes. Strive to resolve by applying proper RBAC
  8. Be selective in installing Azure monitoring solutions to control ingestion costs

Choosing the right technical design versus the right licensing model

In the on-premises world, a technical design would dominantly be CapEx driven. In a pay-as-you-go model – the Azure model – it is primarily OpEx driven. OpEx will more likely drive a Log Analytics workspace design based on the projection of costs; related to data sent and ingested. This is a valid concern but if wrongly addressed, it can have a negative OpEx outcome based on operational complexities when using the data in Azure Security Center or Azure Sentinel. The additional OpEx costs, caused by operational complexities, are often hidden and are less clear as your monthly bill. This document aims to address those complexities to help you make the right design choice.

Please refer to Designing your Azure Monitor Logs deployment for additional recommended reading.

1. Use as few Log Analytics workspaces as possible

Recommendation: Use 1 or more central (regional) workspace(s)

Having a single workspace is technically the best choice to make, it provides you the following benefits:

All data resides in one place

  • Efficient, fast and easy correlation of your data
  • Full support of creating analytics rules for Azure Sentinel
  • 1 RBAC and delegation model to design
  • Simplified dashboard authoring, using Azure Workbooks, avoiding cross-workspace queries
  • Easier manageability and deployment of the Azure Monitor VM extension, you know which resource is sending data to what workspace
  • Prevents autonomous workspace sprawl
  • 1 Clear licensing model, versus a mix of free and paid workspaces
    • Getting insights in costs and consumption is easier with one workspace

Having one single workspace also has the following (current) disadvantages:

  • 1 Licensing model – this can be a disadvantage if you do not care about long term storing your data for specific data types*
  • All data share the same retention settings*
  • Configuring fine grained RBAC requires more effort
  • If data is sent from Virtual Machines outside the Azure data center region where your workspace resides, it will incur costs
  • Charge back is harder, versus every business unit having their own workspace

*) Table retention support is on the roadmap

2. Avoid bandwidth costs by creating “Regional” workspaces

Recommendation:  Locate your workspace in the same region as your Azure resources

If your Azure resources are deployed outside your Azure workspace region, additional bandwidth costs will negatively affect your monthly Azure bill.

Azure RegionsA region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network.

All inbound (ingress) data transfers to Azure data centers from, for example, on-premises resources or other clouds, are free. However, Azure outbound (egress) data transfers from one Azure region to another Azure region, incur charges.

At the writing of this blog, there are currently 54 regions in 140 countries available. Please check this link for the latest updates.

All outbound traffic between regions is being charged, pricing information can be found here. All inbound traffic is free of charge. For example sending data from Europe West and Europe North will be charged.

The following illustration shows a Log Analytics design based on regional workspaces:

thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

3. Explore Log Analytics RBAC options

Designing the appropriate RBAC model for a Log Analytics workspace before the actual deployment is key. Test driving RBAC requirements, mapped to roles and permissions in a Proof of Concept (PoC) environment provides a good operational insight.

Multi-homing your agents (discussed later in this document), in order to separate data, is one of the use cases affecting your workspace design. When using a central workspace, there are two options which will support the requirement that specific data types are not accessible by unauthorized personas:

  1. Table Level RBAC – allows you to delegate permission based on a specific data type, like Security Events
  2. Resource Centric RBAC – only provides access to the data if the user has access to the resource, as shown in the screenshot below where the viewer has VM reader access:
thumbnail image 2 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

Fig. 2 – Log Analytics Resource Centric RBAC – projected by accessing a VM

4. Consider “Table Level” retention

“Table Level” retention will allow you to apply a different retention setting for specific Log Analytics tables. This eliminates the need to create a separate workspace when you need different retention settings for specific data types. For example, if you need to comply with a regulation which dictates that you need to save security alerts for 2 years, but there is no need to save performance counters longer than 7 days, then Table Level retention is going to solve that challenge.

Please note that Table Level retention is not yet available and is on our backlog.

5. Use ARM templates to deploy your Virtual Machines

Recommendation: Use ARM templates to deploy your Virtual Machines, including the installation and configuration of the Log Analytics VM extension

Part of your Log Analytics workspace design is how your agents are deployed and configured. The recommended agent deployment type for Azure Virtual Machines is using the Log Analytics VM extension. The main reason is that a VM extension is deployed and managed by Azure Resource Manager (ARM) and fully supports a CI/CD pipeline DevOps scenario. When using the Log Analytics Agent not installed through the VM extension, updating the agent – or configuring the Log Analytics workspace settings – requires direct interaction with the Virtual Machine. This is not necessary when using the VM extension. ARM templates – where you declare your deployment – are idempotent, meaning that you can repeatedly deploy the same ARM template without breaking anything.

The following ARM template resources section snippet shows how to include the Log Analytics VM extension part of the VM deployment and provide the workspace settings:

{
	"type": "extensions",
	"name": "OMSExtension",
	"apiVersion": "[variables('apiVersion')]",
	"location": "[resourceGroup().location]",
	"dependsOn": [
		"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
	],
	"properties": {
		"publisher": "Microsoft.EnterpriseCloud.Monitoring",
		"type": "MicrosoftMonitoringAgent",
		"typeHandlerVersion": "1.0",
		"autoUpgradeMinorVersion": true,
		"settings": {
			"workspaceId": "myWorkSpaceId"
		},
		"protectedSettings": {
			"workspaceKey": "myWorkspaceKey"
		}
	}
} 

Fig. 3 – ARM template snippet example how to deploy and configure the Log Analytics VM Extension

Please ensure alignment with Azure Policy assignments to avoid conflicts upon deployments.

6. Use Azure Policy to enforce compliance

Recommendation: Use Azure Policy to enforce compliance for installing and configuring Log Analytics VM extension

For enforcing compliance at scale across your tenant(s), Azure Policy is the recommended strategy and is powered by ARM. Capabilities to enforce compliance upon deployment, but also after a resource has been deployed, makes it a powerful solution to prevent and correct non-compliant resources. Azure Policy should be part of your design.

When authoring an Azure Policy definition, you can decide under which conditions the Log Analytics VM extension is deployed. For example, if your design consists of regional workspaces, you can configure the workspace settings based on the resource location so that a VM deployed in West US 2 will be configured to report to a workspace residing in West US 2. The following Azure Policy definition snippet demonstrates this, using a location property:

       "policyRule": {
        "if": {
          "allOf": [
            {
              "field": "type",
              "equals": "Microsoft.Compute/virtualMachines"
            },
            {
                "field": "Microsoft.Compute/imagePublisher",
                "equals": "MicrosoftWindowsServer"
            },
            {
                "field": "location",
                "equals": "[parameters('location')]"
            }
          ]
        }
      } 

Fig. 4 – Azure Policy definition snippet to support regional workspaces

Ensure alignment with your DevOps team if using ARM templates to avoid conflicts.

7. Avoid multi-homing, it can have undesired outcomes

Every best practice has exceptions. If you are not concerned about…

  • Potential double billing (data could be sent twice)
  • Adding complexity to your agent lifecycle management – ARM and Azure Policy do not support multi-homed deployments
  • Authoring complex correlation queries

…Then multi-homing might be for you, but for most of the use cases, you will add unnecessary complexity to your workspace design. The most common consideration to implement multi-homing is separation of data, e.g. security events will be sent to workspace A, performance data will be sent to workspace B, as depicted in the illustration below:

thumbnail image 3 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

Fig. 5 – Multi-homed agent

What might appear as a use case for separating data, originates often from the requirement to prevent data being accessed by an unauthorized party. For example, a Security Operations Center (SOC) might want to prevent that the first line helpdesk is able to view security events for a specific group of computers, like domain controllers.

Please note that multi-homing is not supported using the Log Analytics agent for Linux.

8. Be selective in installing Azure monitoring solutions

Recommendation: Be selective in installing Azure monitoring solutions to control ingestion costs

One of the most common questions asked related to cost & billing are “Which resources are responsible for a high monthly bill?”. Providing an answer to this question can be challenging. It is important to understand the factors driving costs. In one of the previous sections, egress traffic costs have already been mentioned. Another factor is the solutions which will send data to your workspace.

Azure monitor offers a number of monitoring solutions which provide additional insight into the operation of a particular application or service. These solutions will store their data in your workspace and will affect ingestion costs. How these solutions are configured related to data collection, differs per solution.

For example, Azure Security Center offers the option to configure the log level for Windows based agents:

thumbnail image 4 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

Settings that affect data ingestion, can also be found in the workspace advanced settings. This contains multiple options for configuring the log collection interval, but also for example, the Syslog facilities (not on the screenshot below):

thumbnail image 5 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

Analyzing workspace costs

Each Log Analytics workspace has the option to explore usage details, as shown in the screenshot below:

thumbnail image 6 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

This can be visualized with an out of the box bar chart, based on the data ingestion per solution and data retained per solution:

thumbnail image 7 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

For a more detailed analysis, it is recommended to get acquainted with the workspace query language called “Kusto”. There are a number of helpful queries which can be found here. These queries can be customized, like for example to identify which computer is sending the most Security Events over the last 7 days:

union withsource = tt *
| where TimeGenerated > startofday(ago(7d)) and TimeGenerated < startofday(now())
| where _IsBillable == true
| where tt == "SecurityEvent"
| summarize GBytes=round(sum(_BilledSize/(1024*1024*1024)),2)  by  Solution=tt, Computer
| sort by GBytes nulls last
| render barchart kind=unstacked 
thumbnail image 8 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Best practices for designing an Azure Sentinel or Azure Security Center Log Analytics workspace

This allows you to quickly identify the top computers sending data.

Reference:https://techcommunity.microsoft.com/t5/azure-sentinel/best-practices-for-designing-an-azure-sentinel-or-azure-security/ba-p/832574

Tags: Azure Security CenterAzure Sentinellog management
Azure Sentinel News Editor

Azure Sentinel News Editor

Related Posts

Microsoft’s newest sustainable datacenter region coming to Arizona in 2021
SOC

How to Evolve the SOC with Azure Sentinel: Hunting Queries

January 5, 2021
Microsoft’s newest sustainable datacenter region coming to Arizona in 2021
SOC

How to Grant Access to Specific Azure Sentinel Playbooks for Specific Analysts

December 31, 2020
Enriching Windows Security Events with Parameterized Function
SOC

New Private Preview Tag in Azure Sentinel

December 30, 2020
Next Post
Microsoft’s Azure Defender for IoT Uses CyberX Tech

Data Connector Health - Push Notification Alerts

Microsoft and Docker collaborate on new ways to deploy containers on Azure

SolarWinds Post-Compromise Hunting with Azure Sentinel

CRITICALSTART Adds Support for Microsoft Azure Sentinel to MDR Services

What's new: Improvements to the Log Analytics Agent

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Follow Us

  • 21.8M Fans
  • 81 Followers

Recommended

AttackIQ integrates Security Optimization Platform with Microsoft Azure Sentinel cloud-native SIEM platform

AttackIQ integrates Security Optimization Platform with Microsoft Azure Sentinel cloud-native SIEM platform

4 months ago
ForgeRock integrates with Microsoft, Auth0 launches marketplace to secure enterprise digital identity

Why Use Jupyter for Security Investigations?

3 months ago
CRITICALSTART Adds Support for Microsoft Azure Sentinel to MDR Services

Compliance Reporting for Azure

3 months ago
How to use Microsoft Sysmon, Azure Sentinel to log security events

How to use Microsoft Sysmon, Azure Sentinel to log security events

3 months ago

Instagram

    Please install/update and activate JNews Instagram plugin.

Categories

  • AI & ML
  • Artificial Intelligence
  • Incident Response
  • IR
  • KQL
  • Security and Compliance
  • Security Ochestration & Automated Response
  • Security Operations
  • SIEM
  • SOAR
  • SOC
  • Threat Intelligence
  • Uncategorized

Topics

anomaly automation Azure Azure DevOps Azure Security Center Azure Sentinel Azure Sentinel API Azure Sentinel Connector BlueVoyant Call cybersecurity Detection file GitHub Hunting Huntingy IAC incident response Incident Triage infrastructure as code Investigation jupyter LAQueryLogs MDR Microsoft microsoft 365 mssp Multitenancy Notebooks Pester Playbooks PowerShell python Records Security Sentinel Sharing SIEM signin Supply Chain teams Threat hunting Watchlists Workbooks XDR
No Result
View All Result

Highlights

New Search Capability for Azure Sentinel Incidents

Follow-up: Microsoft Tech Talks Practical Sentinel : A Day in the Life of a Sentinel Analyst

Changes in How Running Hunting Queries Works in Azure Sentinel

Azure Sentinel can now Analyze All Available Azure Active Directory Log Files

Replay Now Available – Microsoft Security Insights 036: Azure Sentinel with Rod Trent

Understanding the Little Blue Permissions Locks in Azure Sentinel Data Connectors

Trending

Microsoft’s newest sustainable datacenter region coming to Arizona in 2021
IR

The Holy Grail of Azure Sentinel Data Connections: The Azure Service Diagnostic Setting

by Azure Sentinel News Editor
February 22, 2021
0

The Azure Sentinel product group continues to crank out new Data Connector after new Data Connector. There...

Microsoft’s newest sustainable datacenter region coming to Arizona in 2021

New Items of Note on the Azure Sentinel GitHub Repo

February 18, 2021
Microsoft’s newest sustainable datacenter region coming to Arizona in 2021

Tuning the MCAS Analytics Rule for Azure Sentinel: System Alerts and Feature Deprecation

February 17, 2021
What’s new: Microsoft Teams connector in Public Preview

New Search Capability for Azure Sentinel Incidents

February 16, 2021
With new release, CrowdStrike targets Google Cloud, Azure and container adopters

Follow-up: Microsoft Tech Talks Practical Sentinel : A Day in the Life of a Sentinel Analyst

February 16, 2021

We bring you the best, latest and perfect Azure Sentinel News, Magazine, Personal Blogs, etc. Visit our landing page to see all features & demos.
LEARN MORE »

Recent News

  • The Holy Grail of Azure Sentinel Data Connections: The Azure Service Diagnostic Setting February 22, 2021
  • New Items of Note on the Azure Sentinel GitHub Repo February 18, 2021
  • Tuning the MCAS Analytics Rule for Azure Sentinel: System Alerts and Feature Deprecation February 17, 2021

Categories

  • AI & ML
  • Artificial Intelligence
  • Incident Response
  • IR
  • KQL
  • Security and Compliance
  • Security Ochestration & Automated Response
  • Security Operations
  • SIEM
  • SOAR
  • SOC
  • Threat Intelligence
  • Uncategorized

[mc4wp_form]

Copyright © 2020 - Azure Sentinel News

No Result
View All Result
  • Home
  • Security and Compliance
  • SOC
  • Threat Intelligence
  • Security Ochestration & Automated Response
  • SOAR
  • Security Operations
  • Artificial Intelligence

Copyright © 2020 Azure Sentinel News