for improved visibility and compliance with the NIS2 framework
Nowadays cybersecurity and compliance with various intergovernmental frameworks are a hot topic, especially as the NIS2 is on our doorstep, with various checkboxes to fill. One of these checkboxes (one of the more important ones at least) is to have a working SIEM system in the organization, which collects and normalizes logs and capable of presenting them on a single user interface to make incident response easier and early incident detection enabled.
Besides using a SIEM, there is another useful type of IT Security application, called EDR (Endpoint detection and response), what is capable of behaviour-based threat detection (the old school antivirus apps worked by signatures, like hashes, IP addresses and stuff) could help tremendously by blocking modern threats, like ransomware. Cloud applications, like Microsoft’s M365 is also in the room with us, with the company’s recently renamed Entra ID (formerly Azure AD), so a lot is happening in the IT/Security space nowadays.
When entire sectors are shitfting, it’s usually quite hard to follow the tides, but this blog post is trying to make easier to at least mount a little wave, by using the Crowdstrike EDR application as a SIEM (Security Incident and Event Management) system, by feeding Microsoft Entra’s logs into it.
By doing this, one can get a lot more context into their basic EDR logs, to make incident investigation easier and to enable threat hunting, alerting and search scheduling not only for events what are happening on the endpoints, but also for events in the cloud.
In the last something years, Crowdstrike was a simple EDR (Endpoint Detection and Response) tool, until the biggest overhaul in its history, where they bought Humio and got into a new era, by replacing their backend from Splunk to Logscale.
With this upgrade, not just the query language changed, but they started to support third-party log sources for ingestion and parsing. They also created a free plan for using CS as a SIEM system. The plan contains 10 GiB of daily log ingestion and parsing and a week’s worth of log retention, so it’s not a full-fledged SIEM in terms of retention, but it’s quite a good Incident Response tool for investigation. There is also a possibility to buy more retention time, but this is not the main topic of this article.
To use the SIEM capabilities in the application, first one needs to integrate some log sources. To do this, I suggest to either read the documentation or just check the Data Connectors page within the application. This shows the supported appliances and applications when there is a connector and parser for the logs. There is also an option to create and modify parsing scripts, however it’s out of scope for this article.
If you have a valid subscription, you can see the connectors on this page: Data onboarding | Next-Gen SIEM | Falcon.
Regarding the connectors, I will show how to set up one for MS Graph API, to ingest MS Entra and defender logs. I usually suggest using the Graph API for M365 ingestion, as it’s a lot more simple than using event hubs and MS is not charging for using it.
You can find the official documentation about the graph connector here: Data Connector built for Microsoft Graph API | Next-Gen SIEM Third-Party Integrations | Third-Party Integration and Data Connectors | Falcon Next-Gen SIEM | Documentation | Support and resources | Falcon
First search for the proper connector under data sources:
Click on it and hit “Manage Configurations”:
Click on Accept and then Add Configuration:
In the next popup, fill out the information from the application created in Entra/AAD. About the creation of the application, you could find more information in the vendor documentation linked earlier.
If everything is done, there is a some waiting involved and you could see if the connector is working well under My connectors | Data connectors | Falcon.
It’s worth to check if the logs are arriving and parsing well, via the advanced search (Advanced event search | Next-Gen SIEM | Falcon). The simplest search for checking is the following: “#repo=microsoft_graphapi”. If the logs are visible, then everything is working (until MS is changing something in the API and breaking it).
CS is creating different repositories for every third-party log source it is ingesting, so this is the usual way of checking if everything is okay with the new log source.
And this is all, so it’s not really a complex process, but could be a tremendous help when one is investigating or just wants to create some alerts/scheduled searches or workflows regarding AAD/Entra related events.