Unifying security monitoring with Elastic Security and Microsoft Sentinel

Many modern organizations have a diverse IT estate, often including a mixture of on-prem, Azure, and accounts in other cloud providers. It is important for security teams to have visibility into their entire estate. To achieve this with Microsoft Sentinel, you would need to not only build all of the customized log parsing, but also ship all of the log data to Azure and write matching rules.

Because Elastic can be run anywhere, Elastic Cloud is available in AWS, GCP, and Azure, including through the Marketplaces of all three providers. Elastic can also be run on-premises either directly on hosts or on Kubernetes using our ECK operator. Elastic comes out of the box with integrations to collect data from Windows, Linux, macOS, AWS sources such as AWS CloudTrail, and GCP sources such as GCP Audit Logs. These integrations allow for collecting, parsing, and visualizing the data, as well as Elastic Security’s powerful detection rulesets. Elastic also provides extensive endpoint protection for Windows, Linux, and macOS (as well as Windows), which can either act as the primary endpoint or a complement to a tool like Defender where required. 

Once all of this data is collected from your infrastructure, you can choose to either stream it to a central cluster or use multiple clusters and harness the power of cross-cluster search to query the data where it lives and when you need it.

These capabilities provide insight into your entire estate using out of the box tools independent of where that infrastructure exists — whether on AWS, Azure, GCP, or on-premises, you can have the same visibility and protection across any infrastructure.

Elastic is built for versatility, it seamlessly integrates with not just Microsoft data sources but also a vast array of third-party and custom applications. Whether your environment includes cloud-native apps, legacy enterprise systems, or on-premise services, Elastic has the integrations to collect and analyse that data.

Out-of-the-box integrations exist for everything from Apache logs to Oracle, allowing security teams to gain visibility into areas that Microsoft Sentinel might not natively cover. With Elastic Security, your security operations aren’t limited to a Microsoft-centric view, you get complete coverage across all your systems and applications.

Which IT data sources in your organization aren’t useful for security? … I can’t think of any either. Cyber threats don’t just hide in security logs; they lurk in application performance data, infrastructure metrics, and network telemetry. With Elastic’s observability tools, you can bring these observability data signals into your security analysis, creating a more holistic defence strategy while also providing valuable insights for your developers and SREs.

For example, a sudden spike in database query latency could be an indicator of a ransomware attack encrypting data. Unusual CPU load patterns might suggest cryptomining malware running on a cloud instance. By feeding observability data into Elastic Security, you can enrich Microsoft Sentinel’s alerts with deeper context, enabling faster and more accurate investigations.

Modern security teams need to process massive amounts of data, often in real time. While Microsoft Sentinel is great at handling Azure-centric sources, Elastic is designed to ingest and process high-volume data regardless of and across hybrid environments.

Elastic’s architecture allows for horizontal scaling, meaning that whether you’re dealing with millions or billions of logs per day, performance won’t be a bottleneck. Additionally, Elastic provides powerful filtering and aggregation features that help security teams focus on what truly matters, reducing alert fatigue and making threat detection more efficient.

Elastic’s built-in machine learning (ML) and AI capabilities are purpose-built for security use cases. Unlike generic ML platforms, Elastic’s security-focused ML jobs come prebuilt for anomaly detection in security datasets, helping teams detect threats like:

• Unusual network traffic patterns

• Domain generation algorithm (DGA) activity

• Unusual hour for user activity

These models work out of the box and against Elastic Common Schema (ECS), which means that they apply independently of the source of that data. For example, all supported firewall logs are normalised to ECS which means the ML models will work independently of the firewall used.

Elastic Security also provides access to their powerful AI Assistant for Security, which can leverage multiple large language models (LLMs) including Azure OpenAI to help guide and empower security analysts directly inside of Elastic’s SIEM.  AI Assistant can:

• Group related alerts into coherent attack chains

• Help analysts build advanced queries quickly

• Assist with the triage of alerts

• Automatically create rich case summaries 

• Automatically search your team’s knowledge base as part of the chat

One of the challenges of security data management is balancing retention needs with cost. Microsoft Sentinel provides powerful SIEM capabilities, but long-term data retention can become expensive without losing capability, particularly when dealing with high-ingestion workloads.

Elastic offers multiple features to optimise cost efficiency without sacrificing visibility:

• Index lifecycle management (ILM): Automatically move data through different storage tiers based on age and relevance, reducing storage costs per data source.

• Cold and frozen tiers using searchable snapshots: Keep historical security data in lower-cost object storage while still being able to query it on demand in the same way and with the same capability as new data.

By offloading long-term security log retention to Elastic, Microsoft Sentinel users can maintain compliance and historical analysis without breaking the budget.

Let’s put ourselves in the shoes of a SOC analyst working in Microsoft Sentinel to see what the workflow might look like. Your organization has invested in Azure and Sentinel, but you still have a significant estate on-prem and an AWS estate. To provide your analysts with a single pane of glass, you have local Elastic clusters that use cross-cluster search and all alerts go to your Microsoft Sentinel instance.

You log in to Sentinel and review your open alerts. You have been seeing multiple native Sentinel alerts over the last few weeks around failed logins, mostly related to the engineering organization. Your InfoSec team never found any compromise, and the organization has been reminded about multifactor authentication (MFA) and other security best practices. Suddenly, you see two alerts that have been generated by Elastic Security. The first alert states there has been a spike in outbound traffic from an application running in AWS triggered from anomaly detection on VPC Flow Logs. The next alert flags a new dependency discovered in the APM data from the same application.

You pivot into Elastic using a link from the Microsoft Sentinel alert and see that the alerts are linked to a key in-house application that you provide as a service to your external users. Looking through the APM data for the application, you find that there was a recent release of the application and the dependency seems to have been introduced by that release. You ask Elastic AI Assistant for Security about this alert, and it reveals  encrypted information in the subdomain. This looks incredibly suspicious. 

Through Elastic Observability’s continuous integration/continuous deployment (CI/CD) monitoring, you can see who triggered the release, so you reach out to them. They don’t know anything about a release. It looks like their credentials have been used to inject malicious code into the application, which sends user data to this new dependency. You immediately open an incident in Microsoft Sentinel and start remediation steps. You reset the credentials of the connected account, work with the AWS team to block the network traffic, and work with the developers to roll back the software to the previous version. 

In modern security, all data is security data. By combining Elastic’s breadth and advanced analytics with Microsoft Sentinel, you can span your organization's complex IT landscape and correlate data from any source while providing a single pane of glass in either Sentinel or Elastic Security.

Enough of the theory — let’s get straight into the details of how you can get Elastic Security and Microsoft Sentinel working together in your environment. 

The workflow possibilities are unlimited, so for now we’ll run through a few simple examples that show information flowing in both directions, from Elastic Security to Microsoft Sentinel and vice versa. In a future post, we’ll build on this foundation with more advanced workflows.  

For now, we will use Azure Logic Apps to help build our examples. There are many alternative approaches, but we chose Logic Apps as we expect organizations using Microsoft Sentinel to either be actively using Logic Apps already or have access through Azure without the need to install or manage another tool.

There are many ways of standing up your Elastic cluster, from completely self-built on VMs or using Elastic Cloud for Kubernetes, but the easiest option is to run on Elastic Cloud. Given we are talking about Microsoft Sentinel, let’s go over the easiest way to get set up in Azure, which is using Elastic Cloud through the Azure Marketplace. 

Within a few clicks, you can deploy your own Elastic cluster and be up and running.  Your dedicated cluster will be created in Elastic Cloud and linked to your Azure accounts for integrated billing, authentication, and native log routing.

For more information on creating an Elastic cluster through the Azure Marketplace, check out  How to deploy and manage Elastic on Microsoft Azure..

In this first scenario, we’re expecting an initial review of alerts to be completed in Elastic Security. Once the need for a  case has been identified, a matching incident will be created in Microsoft Sentinel. This workflow works well if there are local analysts that are required to make sense of alerts, such as administrators of an on-premises estate or an AWS environment. For example AWS Cloudtrail alerts being triaged by the AWS admins. 

While Elastic has comprehensive case management features as part of its SIEM solution, it’s not unusual for our customers to have a different system already in place. We offer a selection of native connectors for common incident management tools such as ServiceNow (ITSM, SecOps, and ITOM), Jira, and IBM Resilient, as well as SOAR and security automation platforms like Swimlane, Torq, and (our personal favorite) Tines. 

There is no direct connector for Microsoft Sentinel; instead, we will use a general-purpose Webhook connector, which can send requests to any service exposing a RESTful API. This actually can have some advantages as it can be easily customized to add workflow steps depending on your team’s requirements.

The connector configuration requires us to provide endpoints for the four actions that the connector can take. In Microsoft Sentinel, we’ll use Logic Apps to handle and take these actions: 

1. Case creation

2. Receiving information

3. Updating the status

4. Adding comments

Microsoft Sentinel has its own REST API, but by using Logic Apps, we’re able to remove a lot of complexity around authentication and we can smooth out certain differences in terminology. For example, Elastic Security cases and Microsoft Sentinel incidents use different names for their severity levels and status indicators. Our Logic App will help to translate these between the systems. 

A logical workflow is outlined in the diagram below:

In the second scenario, we require a workflow where triage is done directly in Microsoft Sentinel. To achieve this, we can use the Elastic Webhook Alert Connector to send alerts directly to a Logic Apps workflow in a similar fashion to the cases method described above.

Elastic Security integrates alerts from external tools by ingesting these alerts as an additional log stream and then using a dedicated external alerts rule to surface these alerts to analysts. To achieve something similar in Microsoft Sentinel, we can use a similar strategy. We can ingest Elastic Security alerts into a Log Analytics stream and then use a Microsoft Sentinel rule to surface these alerts to analysts in Microsoft Sentinel. The logical diagram of the architecture is shown below.

By combining the power of Elastic Security with Microsoft Sentinel, organizations can achieve a more comprehensive and cost-effective security posture. Elastic’s broad data collection, powerful analytics, and built-in machine learning complement Microsoft Sentinel’s strengths, providing a unified view across complex IT environments. This integration enables security teams to detect, investigate, and respond to threats more efficiently, ensuring that no attack goes unnoticed.

Ready to experience the combined power of Elastic Security and Microsoft Sentinel? Visit elastic.co/security to learn more about Elastic Security and how it integrates with Microsoft Sentinel. You can also sign up for a free trial of Elastic Cloud on Azure through the Azure Marketplace and see firsthand how this powerful combination can enhance your organization's security. Don't leave your security to chance — empower your team with the best tools available.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.