Comprehensive Coverage with the ION Detection Stack

The ION Detection Stack covers all corners of your estate, from endpoints such as clients and servers to identities, network devices, and your cloud applications and workloads.

Most of our customers primarily use Microsoft products in their on-premises or cloud environments, which is why they chose Microsoft’s security solutions in the first place. But is the detection coverage provided by those products good enough out of the box? And what about attack surface areas outside of Microsoft’s scope? This blog post outlines what you can expect from Ontinue’s ION Detection Stack and why you can’t rely on out-of-the-box detection content alone.

Holistic coverage

Our detection stack uses a multi-layered approach for each category of assets, extending Microsoft’s first-party detection capabilities with third-party solutions you might already be using in your estate, and, of course, our own custom detection content.

Microsoft’s security products layered with Ontinue’s custom content and your third party log sources

Consider the following scenario: On your Windows laptops and servers, Defender for Endpoint (MDE) provides ample protection and detection against today’s threat landscape. But even if you are deeply invested in Microsoft’s products and solutions, you may still have a small number of Linux servers running somewhere, serving some niche purpose. While MDE on Linux is an option for these scenarios, many of our customers can’t or won’t install another agent on these endpoints—whether due to a lack of official support for their Linux distribution or concerns about diminished performance. To avoid this blind spot, our detection stack provides alternative coverage using native OS telemetry collected from the Linux audit daemon (Auditd) and shipped to Sentinel through Syslog. Along with these custom analytics rules, we also provide guidance for our customers’ audit configuration to ensure all relevant events are logged.

We take the same multi-layered approach to your identities. While Defender for Identity and Entra ID Protection cover your on-premises and cloud identity directories, there might be other areas within your environment where sensitive identity information is held. To provide thorough coverage for your identities, our detection stack extends to various IAM and PAM solutions.

Optimized Out-of-the-box analytics rules

Microsoft Sentinel provides excellent detection coverage for a wide range of log sources, which you can browse in the Sentinel Content Hub. The corresponding templates for analytics rules are open source, and you can view all details, including the KQL queries, in Sentinel’s GitHub repository. However, as with out-of-the-box content from any SIEM vendor, careful evaluation and customization of these templates are necessary before deploying them at scale. Distinguishing signal from noise is key in detection engineering, and many out-of-the-box rules generate too many alerts based on common, non-malicious activities occurring in your environment. We identify these scenarios and update Microsoft’s detection logic with our own custom code to increase the precision of malicious behavior detection.

As an illustration, let’s take a look at the template aiming to detect suspicious Azure role assignments. The original template can be found here. It uses a threshold to identify suspicious activity and builds a 14-day baseline to surface previously unseen IP addresses.

Original KQL query on the left side, Ontinue optimized query on the right.

In our testing, we have found that the maximum allowed lookback for Sentinel analytics rules, which is 14 days, is not suitable for building reliable baselines across all our customers’ workspaces. Given that IP addresses are ephemeral and therefore unsuitable for this kind of anomaly detection, we had to abandon the original detection approach. Instead, we opted to correlate this type of Azure Activity with suspicious sign-in activity, triggering alerts for users who had an elevated risk during sign-in before they made role assignments. This improvement not only allowed us to meet our internal quality standards for detection accuracy, but it also enabled us to optimize the rule’s scheduling. Instead of running only once a day as set in the template, our optimized rule now runs every hour, improving mean time to detect (MTTD). On top of that, we were able to reduce the amount of data the query needs to process from 14 days to two days.

Apart from query optimizations like those mentioned above, there are several other improvements we make before incorporating an out-of-the-box rule into our ION detection stack:

• No two customers are alike, but our analytics rules have to perform well on all of them. We add customizable variables into our templates, which are evaluated dynamically as we deploy them through our CI/CD pipeline into our customers’ workspaces. That way, we tune thresholds or benign behavior specifically for each customer, creating tailor-made detections.
• We adjust the alert severity to align it with our own severity methodology. Having a framework that considers impact, accuracy, and asset criticality establishes consistency across detections. Rules with higher severity are evaluated as frequently as possible to detect breaches early.
• Entities such as hosts, accounts, IP addresses, and others are mapped using strong identifiers. For example, we try to identify an identity not only by its sAMAccountName but also by the corresponding domain name, so Microsoft’s alert correlation engine can uniquely identify the entity and correctly correlate related alerts into incidents. This, in turn, helps our analysts get the big picture during investigations.
• We fix incorrect mappings to tactics and techniques of the MITRE ATT&CK framework to ensure we are always aware of our detection capabilities and potential blind spots.

Gap analysis and custom detection

Microsoft’s first-party detection capabilities through Defender XDR are excellent. However, your adversaries’ tactics evolve constantly and rapidly as they find new ways to breach your defenses. We continuously analyze emerging threats and evaluate if and how they are detected. For any blind spot we discover, we develop our own custom analytics rule.

Over time, we have systematically built a large library of custom detection rules covering a wide spectrum of the MITRE ATT&CK framework, providing coverage for blind spots we have discovered in Microsoft’s detection capabilities. Our latest additions include custom detections for token theft scenarios and device code phishing, for example, as adversaries shift from compromising your endpoints to directly grabbing your data from SaaS applications.

Sometimes Microsoft successfully detects a threat but, due to their internal correlation logic, does not alert on the detected activity. After a successful token theft, for example, adversaries replay the stolen token to compromise the victim’s account. While the attacker’s location or other sign-in properties can trigger alerts in Entra ID Protection, these alerts are often remediated and auto-closed by Entra ID Protection itself because the user is seen successfully passing multi-factor authentication (MFA). These kinds of blind spots drive us to identify detection opportunities within Microsoft’s native telemetry and then develop custom detections to leverage that telemetry.

Beyond supporting and supplementing Microsoft’s security products, we also provide detection coverage outside of their reach. Think about your organization’s crown jewels, for example. Whether you are relying on SAP to drive your manufacturing and logistics, or host sensitive intellectual property on a code repository like GitHub, we provide coverage for your critical assets. For new types of log sources, we actively work with you to build new custom detection capabilities.

Data normalization

Security products usually each come with their own, tailored log format with different field names for the same content. Web proxy products, for example, might log a URL in fields named url_s, requestUri_s, or RequestURL. This poses a challenge when queries need to be run across multiple types of logs. Transforming vendor-specific logs to a common data schema ensures that all of the data you collect and ingest is easily accessible to the SOC. Data normalization simplifies the creation of queries for detection rules, incident investigations, threat hunts, and automation workflows.

Microsoft’s take on data normalization in Sentinel is their Advanced Security Information Model (ASIM), which supports ingestion-time and query-time transformation of your log sources. Sentinel comes with numerous parsers for popular log sources out of the box, and Ontinue’s team will write custom parsers where necessary.

CommonSecurityLog 
| where DeviceVendor == "Vectra Networks" and FlexNumber1Label == "threat"
| extend EventCount = toint(1)
| extend EventStartTime = TimeGenerated
| extend EventEndTime = TimeGenerated
| extend EventType = "IDS"
| extend EventProduct = tostring(DeviceProduct) 
| extend EventVendor = tostring(DeviceVendor)
| extend EventSchema = "NetworkSession"
| extend EventSchemaVersion = "0.2.6"
| extend EventResult = "Success"
| extend EventMessage = tostring(Activity)
| extend ThreatName = tostring(Activity)
| extend EventResultDetails = "NA"
| extend Dvc = DeviceAddress
| extend DvcOsVersion = tostring(DeviceVersion)
| extend DstIpAddr = tostring(DestinationIP)
| extend DstPortNumber = toint(DestinationPort)
| extend DstHostname = tostring(column_ifexists("DestinationHostName", ""))
| extend Dst = DstIpAddr
| extend SrcIpAddr = tostring(SourceIP)
| extend SrcHostname = tostring(column_ifexists("SourceHostName", ""))
| extend Src = SrcIpAddr
| extend EventSeverity = case(
                            FlexNumber1 >= 90 and FlexNumber2 >= 90, "High",
                            FlexNumber1 >= 70 and FlexNumber2 >= 70, "Medium",
                            FlexNumber1 >= 50 and FlexNumber1 < 70 and FlexNumber2 >= 50 and FlexNumber2 < 70, "Low",
                            "Informational"
                        )
| project-keep TimeGenerated,EventCount,EventStartTime,EventEndTime,EventType,EventProduct,EventVendor,EventSchema,EventSchemaVersion,EventResult,EventResultDetails,EventMessage,Dvc,DvcOsVersion,DstIpAddr,DstPortNumber,DstHostname,Dst,SrcIpAddr,SrcHostname,Src,EventSeverity,ThreatName

Our custom ASIM alert normalization parser for Vectra AI.

The above example shows how data normalization helps unify various log sources into a common data schema. The CommonSecurityLog table holds events collected in the Common Event Format (CEF) from several types of log sources, such as firewalls, proxies, or IDS/IPS appliances.

At Ontinue, we leverage ASIM to surface alerts from various IDS/IPS solutions as incidents using a single analytics rule. Since Sentinel supports only 512 scheduled analytics rules per workspace, this approach helps us keep our use case library lean and prevents the bloat that vendor-specific rules would cause.

ION ticketing tool showing incidents from Darktrace AI, Vectra AI, Palo Alto and Azure Firewall generated by a single analytics rule.

Conclusion

While Microsoft’s security solutions offer a strong foundation, relying solely on out-of-the-box capabilities leaves significant gaps, both in coverage and in detection quality. Ontinue’s ION Detection Stack addresses these blind spots by augmenting first-party detection capabilities and extending them with custom analytics for a wide range of log sources. We don’t just deploy detection content—we engineer it, test it, and continuously tune it to provide reliable, holistic coverage of your estate.