Practical Sentinel: Creating Incidents From Networking Data

Find the Right Data to Use for Alerts

After identifying what networking data you should ingest into Sentinel and choosing the most efficient ingestion method, the next step is to start creating alerts and incidents using the data.

The exact alerts and incidents are usually targeted to a specific environment and depend on the identified use cases. Two main categories exist for alerts created from networking data:

• Threat detection or security intelligence from the product vendor (the vendor of the firewall, proxy, network switch…)
• Custom detection logic based on raw logs.

I typically recommend starting with the built-in threat detection of the firewalls. It is the easiest alert to configure as the product vendor does the heavy lifting to identify security threats. After using the built-in threat detection feature and learning the data it generates, you can expand to custom use cases using previous experience.

Leveraging Built-in Threat Detection

Most firewalls include threat detection systems. For example, Palo Alto firewalls have Threat Prevention while Fortinet has security profiles. While the name differs between vendors, the functionality remains much the same. These capabilities consist of malware scanning and other features such as TLS inspection. Each packet that transverses the firewall is inspected and checked against known signatures of malware. If a packet matches, the firewall drops the packet and generates an alert.

The first step is to verify what capabilities exist on the firewall. Not all capabilities are enabled by default and it’s probable that you need to review the configuration. If threat detection systems are not properly configured, the data transmitted to Sentinel will lack meaningful insights. Doublechecking the configuration of the firewall is important.

After reviewing the configuration, you can consider drafting rules. Let’s start thinking about what threat alerts should be created in Sentinel. It might sound interesting to create an event for every threat detection in the firewall’s system, but this is not always the case. Some examples are:

• Guest Networks
  • Most companies have a guest network for which access is not controlled or controlled in a lower level. On guest networks, it is expected that people use personal devices. The security team doesn’t control the devices using the guest network, which is a good reason to exclude alerts generated by the guest network because they are not actionable. The only thing to watch out for is ensuring there is a strict segregation between the guest network and the corporate network to avoid any lateral movement.
• Traffic Originating from the Internet
  • It is no secret that hacking attempts happen every second of every day. While monitoring firewall logs, you will see connection attempts originating from all over the world.There is limited value to alert on blocked requests originating from the internet. We expect this type of behavior and if the threat is blocked, there is no reason to alert on this.
  • What is important is to alert when multiple failed attempts are followed by a successful one because this can happen due to an attacker breaching the firewall.
• Detection Type
  • Not all threat detection types are as valuable as others. Threat detections that don’t require an action such as unwanted software (greyware applications such as CCleaner might not be worth alerting on).
  • It is important that all created alerts are actionable. An investigation needs concrete steps to proceed and can’t be limited to viewing the alert and closing it. There is no added value to gain from reviewing unactionable events.

Raw Logs

Creating alerts based on raw logs takes more effort as a deep understanding of the logs is required before a KQL query to generate alerts can be drafted. There are some common use cases I favor towards:

• Incoming Public Connections
  • Identify potential exploitation of public-facing services by monitoring connections from the internet to the local network.
• Lateral Movement
  • By using raw firewall logs, Sentinel can detect potential lateral movement between subnets and physical locations.
• Threat Intelligence
  • We can identify malicious activity by mapping Sentinel’s Threat Intelligence to the raw network logs. This enables Sentinel to generate alerts based on malicious IP addresses seen in the firewall logs.

Drafting Rules

To draft the initial set of rules, I recommend using the templates provided by Microsoft on GitHub (the Solutions folder holds many different templates). Each template has its own subfolder, so it takes time to identify the correct one. Even if the product you are researching isn’t listed here, it is still useful to go through the list and examine the rules for similar products to learn what might be useful.

Threat Detections

An example of a rule to alert on threat detections by a network device is listed below. This is a sample rule for a Cisco ASA firewall:

CommonSecurityLog

  | where isempty(CommunicationDirection)

  | where DeviceEventClassID in ("733101","733102","733103","733104","733105")

This is a simple query . It uses the built-in device events from Cisco and creates alerts based on threat detection’s from Cicso. It is an example on how easy it is to convert network alerts into Sentinel alerts.

Microsoft or vendor documentation can be used to find interesting events to query.

Raw Logs

As mentioned earlier, drafting rules to work against raw data requires knowledge of the data. Here’s an example: detecting a potential port scan.

Note: This is a simplified version of the rule listed on GitHub here. I removed some of the KQL operators to make it easier to understand the thinking process.

1. CommonSecurityLog
2. | where DeviceAction !in (“reset-both”, “deny”)
3. | where DestinationPort !in (“443”, “53”, “80”)
4. | summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated), count() by DeviceName, SourceUserID, SourceIP, DestinationPort, Protocol, DeviceAction, DestinationIP
5. | where count_ >= 10

1. Start off by retrieving the correct table. Knowing what table to query is covered in the previous article about setting up a data connector.
2. Filter out events that are denied by the firewall. As mentioned before, we are not interested in denied events as the firewalls have already taken care of these and blocked the events.
3. Ignore a set of commonly used ports in order to avoid false positives.
4. By using the summarize operator, we can identify how many requests were sent by a specific actor.
5. A threshold is set to only create an alert of each actor that has 10 attempts.

The query is specific to data from Palo Alto firewalls and will differ between products. By using the template queries, you can learn the data structure and columns and can map the use case against the structure. To start with such a query, I typically run the code line by line to fully understand what action is performed by each line.

Moving Forward

Creating alert rules is a continuous process and it should be treated as such. Rules don’t have to be perfect from the start, but it is important to monitor their performance and update the rules if they generate too many false positives. Don’t strive to create custom rules based on raw data first. Make it easy for yourself and start off with some of the template rules. They can get you going really quickly and ensure that you don’t reinvent the wheel.