Microsoft Sentinel is a cloud-native security information and event management (SIEM) solution. It collects data from various sources, including on-premises and cloud environments, so security teams can monitor activity and detect threats. Data connectors are the bridges that bring logs from different systems into Sentinel, where they get normalized and stored in tables for querying and analysis.
For Linux-based systems, you can use the Azure Monitor Agent (AMA) to send logs into Microsoft Sentinel. The AMA can run directly on the device or on a separate Linux-based log forwarder. The Syslog daemon collects local events and forwards them to the agent, which then streams the events to your Log Analytics workspace. After setup, plain Syslog messages appear in the Syslog table, while CEF-formatted messages go to the CommonSecurityLog table.
A linear flow showing Linux-based systems sending logs through the Syslog daemon to the Azure Monitor Agent, then to the Log Analytics workspace, where plain Syslog messages are stored in the Syslog table and CEF-formatted messages in the CommonSecurityLog table.
When applications on Windows or Linux generate logs that built-in connectors do not cover, you can use the Log Analytics custom log collection agent. You follow the connector's specific steps to capture the data, which then gets stored in custom tables within Microsoft Sentinel. This approach handles non-standard log formats that would otherwise be ignored.
Microsoft Sentinel includes out-of-the-box integration with major cloud providers like Azure and Amazon Web Services. You can connect these services automatically using templates found on Sentinel's data connectors page. These templates reduce manual configuration and ensure proper schema mapping for common Azure and AWS services.
Each data connector in Microsoft Sentinel falls into one of three support categories. Microsoft-supported connectors are authored and managed by Microsoft for both Microsoft and selected non-Microsoft sources. Partner-supported connectors are developed and maintained by third-party organizations such as Independent Software Vendors or Managed Service Providers. Community-supported connectors are typically created by community members without formal support structures, though issues can be raised through GitHub.
When built-in connectors do not meet your needs, Azure Functions lets you create serverless custom connectors using RESTful APIs. You can write these in various programming languages including PowerShell and Python. Deployment options include ARM templates or manual deployment using PowerShell or Python. Examples include connectors for services like VMware Carbon Black, Okta Single Sign-On, and Proofpoint TAP.
The Log Ingestion API allows you to stream data directly to Microsoft Sentinel through a RESTful endpoint. This method provides precise customization for specific data formats or unique ingestion requirements. However, it requires more programming effort compared to using built-in or template-based connectors.
After configuring a connector, you must verify that data is actually being ingested. Run targeted queries to confirm that logs appear in the appropriate tables. You can also use built-in or custom workbooks to monitor data streams and validate that the connector is performing as expected. Regular validation ensures your security monitoring has complete and accurate data to work with.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills
Prepare and test your skills
Microsoft Sentinel data connectors fall into three support categories. Microsoft-supported connectors are authored and managed by Microsoft for both Microsoft and selected non-Microsoft sources. Partner-supported connectors are developed and maintained by third-party organizations such as Independent Software Vendors or Managed Service Providers. Community-supported connectors are typically created by community members without formal support structures, though issues can be raised through GitHub.
For Linux-based systems, the Azure Monitor Agent can run directly on the device or on a separate Linux-based log forwarder. The Syslog daemon collects local events and forwards them to the agent, which then streams the events to the Log Analytics workspace. Plain Syslog messages appear in the Syslog table while CEF-formatted messages go to the CommonSecurityLog table.
When built-in connectors do not meet your needs, Azure Functions lets you create serverless custom connectors using RESTful APIs. You can write these in various programming languages including PowerShell and Python. Deployment options include ARM templates or manual deployment using PowerShell or Python.
After configuring a connector, you must verify that data is actually being ingested. You can run targeted queries to confirm that logs appear in the appropriate tables. You can also use built-in or custom workbooks to monitor data streams and validate that the connector is performing as expected.
StudyCerts
StudyCerts