In a previous article, I discussed prioritizing the correct data connectors within Sentinel. Data from networking appliances, such as firewalls, proxies, or switches, is not typically the first data connector I enable, but many use cases exist for importing this data into Sentinel. In this article, I focus on the use cases to ingest networking data into Sentinel.

Firewalls, Proxies, Switches, or Access Points

Many different types of networking equipment exist, each with their own functionalities and use cases to add into Sentinel.

• Firewalls: A firewall is placed between networks. The most common example is between the company network and the internet. A firewall provides insights into inbound as well as outbound traffic. If an organization has multiple internal networks (subnets), a firewall is responsible for routing traffic between those networks.
• Proxies: A proxy adds layer 7 information, which is information that Microsoft’s EDR tool, Microsoft Defender for Endpoint (MDE), lacks. If you use an always-on (cloud) proxy such as zScaler, Netskope, or Microsoft Entra ID’s Internet access, you are certain that information is always available, independent if the endpoint is behind the corporate firewall or not. This means that there is a different type of data compared to the firewall, a firewall only logs when the user is behind it, e.g. on the corporate network. A cloud-based proxy functions all of the time, even if the user is working remotely.
• Switches: The data generated by a switch is typically without many details or intelligence (no packet inspection or Intrusion Prevention Systems). The logs contain an overview of all connections being made (insights into both IP addresses and packet size…).
• Access Points: The data generated from an Access Point is comparable to that of a switch and contains data about its connected hosts and various network connections.

When I work with a customer, I typically prioritize all types as displayed above.

A firewall can capture traffic from devices that are not onboarded in Microsoft Defender for Endpoint and allows you to cover blind spots. Additionally, a firewall typically has security features of its own, like TLS inspection and Intrusion Prevention Systems (IPS). Their security features are interesting as they generate ‘alerts,’ just like Defender. If you want some diversification from Microsoft, this is a good thing. It allows you to depend on threat detections from technology created by other network vendors, ensuring you don’t solely depend on Microsoft.

Proxies are useful as they provide details of networking data that Defender for Endpoint lacks, like packet size, full URL, and HTTP methods. I typically see a proxy installed on top of Defender for Endpoint supported devices (legacy devices don’t support most proxy solutions), meaning they won’t add insights into devices that are not unboarded. Proxies expand the scope and go where Defender for Endpoint stops.

Switches and Access Points are data sources that I haven’t brought into Sentinel often. Their log sources contain low-level detail information, and they don’t contain a lot of security features. The most interesting use case to ingest is administrator activity such as console logins or configuration changes. Other logs can be useful for threat hunting purposes, but typically not for alerting as they are too noisy.

Identifying Use Cases

Before you start ingesting data, you need to define your use cases. This ensures you only ingest data that you are actively using. As discussed in in an article about prioritizing data connectors, multiple potential use cases exist: reporting, retention, alerting, and enrichment.

Choosing what data is useful for alerting heavily depends on your alerting use case. Before you create any rules, you should understand the data and know for what actions you want to generate alerts.

What data is important to you? Every situation is unique and no two networks are the same. That is why it is important to execute the following exercise to understand your environment.

To identify use cases, I use two main functions:

• Crown jewels – a company’s most critical asset. As a security team, you must know what the critical assets are. This includes both domain controllers and other IT systems, but also the applications/systems that keep the business running. By identifying the crown jewels, you know what is important and can prioritize enabling protective and detection controls for these systems first.
• Current gaps. There are always detection gaps in a SOC. Attackers will try to fly under the radar and it is our job as defenders to fight that and ensure we can see what they are doing. Filling detection gaps with new data sources is an important exercise. Knowing where your gaps are can be done using a couple of techniques: MITRE ATT&CK assessments, red and purple team exercises, or breach and attack simulations (BAS).

Avoid Data Overlap

When ingesting any type of data, you should avoid data overlap wherever possible. This ensures you don’t pay double for storage.

To identify overlaps, you need to investigate what data is present in each data source. There are a couple of known overlaps:

• Firewall and Switches
  • Before you start ingesting switching data into your SIEM, you need to know where the routing between subnets happens. If it all happens on your firewalls, it means that all cross-subnet traffic is logged by the firewall. This decreases the need to ingest switching logs as you would have a lot of duplicate data.
• Proxy vs Defender for Endpoint
  • It is a common misconception that Defender for Endpoint logs all required events. Layer 7 traffic is something that is currently not logged in detail. This is where a proxy solution comes in.
  • When ingesting both Defender and proxy data, some data overlap is created because some basic networking data is available within MDE.
• Firewall vs Defender for Endpoint
  • If all your devices are onboarded in MDE, the need to ingest your firewall decreases as all network traffic is logged both on the client and firewall. In order to minimize the ingestion cost, it might be interesting to scope the data that is being sent into the SIEM.

Scoping Ingestion

Scoping is an important part of ingesting networking data. A network appliance can generate a lot of log files and significantly increase the cost of your Sentinel instance. During a recent engagement, a customer’s firewall generated about 10,000 euros worth of logs each month. By scoping (filtering) the ingestion, you only ingest interesting events and fields.

How you want to scope depends on your use cases. By defining the use cases, you know what type of data you need in your alert rules. In theory, you could decide to only ingest that data and remove everything else.

Before you do that, you need to think about what data is required for investigations. A SOC analyst needs context to execute an investigation and that context typically comes from logs. For such types of logs, consider ingesting them as basic logs. This ensures you have the data ability to query, but at a reduced rate.

Starting Ingestion

The planning step is the most important step when considering the ingestion of networking data into Sentinel. You need to know what data you are ingesting, what the use case is, and how you can filter it to avoid costs. After doing this, you can look into starting the ingestion. In a follow-up article, I will dive into the different architectures and how you can decide what suits your organization best.