Below is an article comparing two different approaches for sending logs from a third-party platform to Microsoft Sentinel's Log Analytics Workspace via Syslog or CEF Log Forwarder.
SPOILER ALERT: The "Azure Monitoring Agent" method is far better than the "Microsoft Monitoring Agent" method π
The "Microsoft Monitoring Agent" method is getting deprecated on 31st August 2024
Pre-requisites
β Microsoft Sentinel vs Log Analytics Workspace | LinkedIn
β Basic Knowledge around Syslog or CEF Log Forwarder
β HTTP Data Collector API vs Log Ingestion API | LinkedIn
β Azure: Identities Comparison
β Before and After - Data Collection Rules
Terminologies and Context
Forwarders
β Syslog forwarder - A machine that sits in between two different platforms that cannot talk with each other natively. Thus, the machine acts as an intermediary to collect logs from the source platform and send it to the destination platform.
β CEF log forwarder - Same as syslog forwarder, but the "format" of the log it collects is common to different devices (standardized and recognizable by any platform). Thus the name "Common Event Format" (CEF).
β So can a CEF log forwarder be called as syslog forwarder?
Yes it can π, although it is advised to refer as CEF log forwarder, just to differentiate the type/format of the log it is collecting.
Agents
β MMA - Microsoft Monitoring Agent (MMA) is an agent you put on a machine to send logs to the Azure Log Analytics Workspace. It is also called by other words as "Log Analytics Agent" or "OMS Agent".
β AMA - Azure Monitoring Agent (AMA) is an agent you put on a machine to send logs to the Azure Log Analytics Workspace, just like MMA - but better.
β How is AMA better than MMA?
AMA has a better authentication mechanism than MMA. It also has log filtering capability via Data Collection Rule (which is not supported in MMA).
CEF Log Forwarder
CEF Log Forwarder is a machine that acts as an intermediary between two platforms that cannot talk with each other natively. Below is a high level representation of how CEF Log Forwarders work:
In the above diagram, we have three key components:
β Source Platform - the platform "FROM" which we aim to collect logs from. As an example, we will use Palo Alto Networks Panorama Firewall as the source platform.
β Destination Platform - the platform "TO" which we aim to send the collected logs to. As an example, we will use Microsoft Sentinel as the destination platform.
β Log Forwarder - since Palo Alto Networks Panorama Firewall CANNOT send logs directly to Microsoft Sentinel, we send the logs to a machine/virtual machine. The machine then sends the collected logs to Microsoft Sentinel.
Log Collection: Syslog or CEF agent
Log Ingestion: "some" monitoring agent
The "some" monitoring agent could either be MMA (Microsoft Monitoring Agent) or AMA (Azure Monitoring Agent).
CEF using MMA
Below is a high level diagram of a CEF log forwarder ingesting logs into Microsoft Sentinel's Log Analytics Workspace using Microsoft Monitoring Agent.
It is to be noted that the diagram only covers the "Log Ingestion", and not the "Log Collection" part that uses syslog/CEF agent.
π© Red Flag 1: The Microsoft Monitoring Agent uses Workspace ID and Workspace key for authentication (and is to be hard-coded in the log forwarder). Using a workspace ID and workspace key is like using username and password. The threat vector is too high, and a compromise of the credentials can cause a huge impact with operations.
π© Red Flag 2: Based on the above diagram, there is no way to filter logs before being ingested into Microsoft Sentinel's Log Analytics Workspace. Platforms like (any) Firewall would usually send high volume of traffic logs - some of which aren't important for Security monitoring. This might end up accumulating the cost of storing unwanted logs in Log Analytics Workspace. MMA does not have a capability to filter/drop logs based on specific conditions before being ingested into Microsoft Sentinel's Log Analytics Workspace.
β The machine/virtual machine that acts as the log forwarder can either be in on-prem or in Azure (or in any cloud platform). Although most of these log ingestion scenarios would require the log forwarder to be on-prem.
π How-to Documentation: Microsoft Sentinel | CEF Log Forwarder (legacy)
CEF using AMA
Below is a high level diagram of a CEF log forwarder ingesting logs into Microsoft Sentinel's Log Analytics Workspace using Azure Monitoring Agent.
It is to be noted that the diagram only covers the "Log Ingestion", and not the "Log Collection" part that uses syslog/CEF agent.
β The Azure Monitoring Agent uses "Managed Identity" for authentication - which is very much secure and better for access management.
β It is also to be noted that the logs are sent to a "Data Collection Rule" before being ingested into the table of Log Analytics Workspace. The Data Collection Rule has the capability to filter/drop logs based on specific conditions before ingesting them into Log Analytics Workspace.
βIt is to be noted that the machine/virtual machine that acts as the log forwarder "MUST" be in Azure.
βDoes that mean - the Azure Monitoring Agent cannot be used if the machine is on-prem or in a different cloud?
β There's always a way π. For machines that are not on Azure, we would require adding another agent (Azure Arc) to the machine to make it compatible with Azure Monitoring Agent.
Azure Arc is a service to have machines in your own network (or in a different cloud) - but onboard it to Azure to treat and control it like an Azure Virtual machine. It's like using an Azure Virtual Machine without having the machine on Azure π€―
Conclusion
It is an obvious choice to go with Azure Monitoring Agent for the below three reasons:
β Better authentication mechanism
β Supports log filtering capability using Data Collection Rule
β MMA is getting deprecated in less than 6 months anyway π€·βοΈ