In this third blog post in a series about Azure Security Logging, we will focus on collecting security logs from Windows and Linux virtual machines. In part 1 we discussed how to define a security logging strategy in Azure. Part 2 went into detail about logging in some of the key Azure services. In this post we go into detail how logs can be collected from within the virtual machines, what storage options are available and how they can be configured.
Collecting virtual machines security logs
Even when your virtual machines are running in the cloud, it is still important to centrally store security logs for digital forensics or active threat hunting. The configuration of security logging in Windows or Linux operating systems is similar to on-premise and implementing a performant log collection platform such as an ELK stack is difficult to get right.
By using cloud-native services, you gain the advantage of build-in scalability and high-availability. In Azure, security logs can be stored in a Storage Account or in a Log Analytics workspace.
In a previous blog post we discussed determining your security log strategy, but at a minimum you should store OS security logs in a Storage Account for forensics purposes. If you require your security logs to be available for complex queries, or you want to use Azure Sentinal as a cloud-native SIEM, you should store them in an Log Analytics workspace.
Azure Storage Account
Collecting logs from Azure virtual machines to a Storage Account is done by the Diagnostics VM extension.
To enable this extension when creating the virtual machine, OS guest diagnostics should be enabled, and the Storage Account selected in the management tab.
To enable the VM diagnostic setting after the virtual machines has been created, you can use the Azure PowerShell cmdlets or Azure CLI.[1]
The status of the Diagnostic extension installation can be viewed in the extensions blade of the virtual machine.
The logs are stored in the Azure Storage Table service which is a scalable NoSQL database that can be view in Azure Storage Explorer and basic queries can be made by using the Table Service REST API.[2]
Log Analytic Workspace
Ingesting security logs into a Log Analytics workspace is done by an agent, the OMSAgent for Linux or the Microsoft Monitoring agent for Windows. This is the agent used in the Azure Operations Manager Suite which can also be installed on on-premise systems. It is also the same agent that is installed when auto-provisioning is enabled in Azure Security Center and connected to a default Log Analytics workspace.
The advantage of this agent to the Diagnostic extension is that you are able to define additional log sources such as IIS logs or custom log files to ingest.
Installation of the agent can be done in multiple ways, but for virtual machines in Azure it is easiest to do this in the Workspace Datasource section Virtual machines blade of the Log Analytics workspace.
To push the agent to the virtual machine, click connect.
When the deployment of the agent is successful, the status of the Log Analytics Connection has changed.
In the extension blade of the virtual machine, you can see that the agent provisioning was successful.
To verify that the agent is working correctly, you can query the Heartbeat table in the workspace.
Configuring virtual machine security logs
Now that we have started ingesting our logs into a Storage Account or Log Analytics workspace, we will go into detail how to configure which logs are collected. By default, only a subset of security logs required for effective digital forensics or threat hunting is collected by the Diagnostic Extension and no logs are ingested into a Log Analytics after agent installation.
The configuration of audit settings in Windows and Linux or what logs should be collected is not in scope of this blogpost. A good resource for configuring Windows logging is malwarearchaeology.com. Scripts for configuring Windows audit logs and a sample configuration file for WinLogBeat can be downloaded here which are a good starting point for knowing what event logs to collect and how they should be configured.[3]
Diagnostic Extension
Log collection by the Diagnostic Extension is configured in the Diagnostic settings of each virtual machine individually.
For Windows machines, you can configure the log level of the Application, Security and System Eventlog. If you want to collect additional event logs such as Microsoft-Windows-PowerShell/Operational, you should use the custom configuration.
In Linux virtual machines, you have the option to choose the minimum log level of syslog facilities in the virtual machine diagnostic settings.
Microsoft Monitoring Agent/OMSAgent
Log collection by the Microsoft Monitoring Agent or the OMS Agent is managed centrally in the advanced settings of the Log Analytics workspace.
Windows event log collection is configured by entering the name of the event log in the textbox, clicking the plus button and selecting the log levels.
Collecting Windows Security event logs is surprisingly not an option here. This is only possible when you have enabled Security Center Standard which costs €15/month per virtual machines. It can be configured in Data Collection of the Pricing and Settings blade in Security Center.
What event log ids are collected is documented in the Azure documentation.[4]
To configure Linux syslog collection, check the “Apply below configuration to my machine” box to push the configuration to the OMSagent on the Linux virtual machines. Enter the name of the syslog facility in the textbox, clicking the plus button and selecting the log level to collect.
Wrapping up
In this blog post we have covered the security-logging capabilities Azure virtual machines. In upcoming blog posts in this series, we will go into detail in other key Azure services. Stay tuned!
[1] https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/diagnostics-linux
[2] https://docs.microsoft.com/en-us/rest/api/storageservices/table-service-rest-api
[3] https://www.malwarearchaeology.com/logging
[4] https://docs.microsoft.com/en-us/azure/security-center/security-center-enable-data-collection#data-collection-tier
