Understanding connectors
Azure Sentinel relies on Log Analytics to store large volumes of data, in order to process that data and find useful information about potential risks and security threats. The data required may be located in many different types of resources across many different platforms, which is why we need many different options for connecting to those data sources. Understanding the options available, and how to configure them, is key to developing a strong data architecture to support the Azure Sentinel solution.
A summary of the connectors is shown in the following screenshot:
Figure 3.3 – Azure Sentinel connector flow
Connectors can be categorized based on the method used to ingest data from source. Currently, there are four main types:
- Native connections
- Direct connections
- API connections
- Agent-based (Windows Server Agent and Syslog)
Let's explore each of these types in more detail.
Native connections – service to service
Azure Sentinel has been developed to integrate directly with several resources across the Microsoft security product range, including (but not limited to) the following:
- Azure Active Directory (Azure AD), including the advanced Identity Protection solution
- Office 365, including Exchange Online, Teams, and OneDrive for Business
- Cloud App Security, the cloud access security brokers (CASBs) and cloud workload protection platform (CWPP) solution
- Azure Security Center, including Microsoft Defender Advanced Threat Protection (ATP)
- Azure ATP
This is the preferred method for connecting to resources, if the option is available. Let's take a look at direct connectors.
Direct connections – service to service
Some connectors available in Azure Sentinel need to be configured from the source location. The connector will usually provide the information required and a link to the appropriate location. Examples of these connectors include the following:
- Amazon Web Services (AWS), for AWS CloudTrail
- Azure Firewall
- Azure Front Door
- Azure network security groups (NSGs); flow logs and rule activations
- Microsoft Intune; audit logs and operational logs
Now, let's look at API connections.
API connections
Several security providers have API options that allow connections to be made to their solutions in order to extract the logs and bring the data in to Azure Sentinel. This is the preferred method for connecting to third-party solutions that support it, and you have the option to create your own connectors. For further information on creating API-based connectors, see this article: https://techcommunity.microsoft.com/t5/azure-sentinel/azure-sentinel-creating-custom-connectors/ba-p/864060.
Examples of API-based data connectors include the following:
- Azure Information Protection (AIP)
- Barracuda Web Application Firewall
- Microsoft Web Application Firewall
- Symantec Integrated Cyber Defense Exchange (ICDx)
- Symantec Cloud Workload Protection
The next type of connection is required for services that do not support any of the preceding options; usually for virtual or physical servers, firewalls, proxy, and other network-based devices.
Agent-based
This connector type will allow the widest range of data connection and is an industry-standard method of shipping logs between resources and SIEM solutions. There are three types of connectors to consider; you may deploy one or more depending on your needs, and you may deploy multiple of the same type too. Let's discuss them in detail.
Windows Server Agent
Any server running Microsoft Windows can forward logs for Domain Name System (DNS), security events, Windows Firewall, and AD.
Syslog server
This is an agent deployed to a Linux host that can act as a concentrator for many resources to send logs to, which are then forwarded on to Log Analytics for central storage. For detailed guidance on implementing a Syslog server, please see this article: https://docs.microsoft.com/en-us/azure/sentinel/connect-syslog. Examples of third-party solutions that support this method include (but are certainly not limited to) the following:
- Carbon Black
- Cisco (IronPort Web Security, Meraki, and others)
- Citrix
- F5 BIG-IP
- McAfee ePolicy Orchestrator (ePO)
- NetApp
- Palo Alto Cortex
- Trend Micro
While these options provide a wide range of options for data sources to gather, there is another method that, if available from the service provider, will give a richer dataset. Let's take a look at the Common Event Format (CEF) option next.
Syslog server with CEF
This is very similar to the Syslog server deployment mentioned previously. For more detailed information, see this article: https://docs.microsoft.com/en-us/azure/sentinel/connect-common-event-format. The difference is that the source supports the CEF for logs. Examples of solutions that support this method include the following:
- Cisco (Umbrella, Cloud Security Gateway, and others)
- CyberArk
- F5 Firewall
- McAfee Web Gateway
- Palo Alto Networks Firewall
- Varonis
- Zscaler
With this range of connectors available, it is possible to connect to and gather information from multiple resources across all your operating environments, including on-premises, a hosted service, the public cloud, and even industrial operations environments or the Internet of Things (IoT).