Everyone has firewalls and many of the more regulated industries require collecting and reviewing their logs to meet regulations like PCI and HIPAA. But many organizations aren’t sure how to efficiently accomplish this, particularly with traditional (first generation) firewalls that, even though they contain a large amount of valuable data, frequently lack context. For example, a traditional firewall can answer “Who is trying to communicate with who, and is it successful?”, but can’t answer key details about the type of traffic or why it is happening.

Monitoring your firewall logs - knowing where to start
Few organizations have the means to quickly or efficiently analyze data at scale to get real value out of their firewall logs. And because there is so much data that has been largely ignored over the years, analysts no longer know where to even get started.

The challenge becomes how to deliver actionable monitoring alerts from network devices that generate large volumes of data that is often missing context.

  • What activities can be detected from firewall logs?
  • What are the challenges that must be considered when developing and deploying these monitoring use cases?

Firewall Detections
The list of detections below describe some ways to you might begin monitoring your firewall data:

DETECTION DESCRIPTION
Traffic to/from malicious address Looks for communications to or from restricted or malicious IP space
Sensitive Port Activity Looks for communications to or from key network ports
Possible Port Scan Looks for one source address connecting to multiple ports on a single destination address.
Possible Network Sweep Looks for one source address connecting to a single network port on multiple destination addresses.
Possible Beaconing Looks for repeated network communications appearing on a routine or predictable schedule.
Src address blocked and permitted Looks for source addresses performing network discovery activity.


Here’s a deeper look at one example. Additional examples can be found in our whitepaper “Extracting Value from Legacy Firewall Logs”.

Identifying traffic to/from malicious address
This is a pretty straightforward use case. No company wants to see network communications with addresses that are KNOWN to be malicious, so immediate detection is critical. But there are a few challenges that make this a more difficult task than you would think.

  • Dynamic IPs make it easy for attackers to bypass blacklists of known malicious sites by quickly dropping blacklisted IPs and getting new ones
  • Shared IPs make it difficult to distinguish between benign and malicious domains
  • Relays/Proxies/Anonymizers let attackers hide their activity in legitimate traffic
  • The quantity of known malicious addresses (100s of thousands) and the shear volume of FW logs (potentially millions per hour) makes the number of necessary lookups unsustainable

Detection Methodology:
OPTION 1: Direct comparison of traffic to threat intel indicators

To begin, a company must first consider the accuracy of this challenge, the computational cost associated with the challenge, and then weigh the benefits of implementing the detection. If this remains a detection a company wishes to implement, one method would be to perform a straight comparison of the destination addresses. To have any hope of scaling, content developers can perform some actions including:

  • Identify subnets that receive large quantities of traffic. For example, you may analyze the most common subnets and determine that 40% of your traffic can be reduced simply by excluding comparisons to subnets operated by Google, Facebook and Youtube.
  • Aggregate the destination addresses so as to only perform one comparison. If a destination address exists in the logs, 40 times, i only need to check it against the threat intel list once.
  • Keep a GOOD threat intel list: IP indicators go bad with time quickly. The best threat intel lists are updated daily if not hourly and pruned for accuracy regularly. Doing this will keep the size of the threat intel list smaller while increasing the accuracy.

OPTION 2: Map addresses to higher level indicators and check those indicators:

  • To begin, aggregate the destination addresses so as to only perform one comparison. If a destination address exists in the logs, 40 times, Ii only need to perform the assessment activities once.
  • One easy indicator to implement that has a high fidelity is to identify traffic to/from countries listed by the Office of Foreign Assets Control (OFAC) as sanctioned countries. If content developers can perform geographic look-ups on the IP addresses using external services or functions within their SIEM, they can compare the results to the list of countries listed at https://www.ofac-guide.com/ofac-countries.htm
    In addition to geographic lookups, another way to compare large blocks is by comparing ASN ranges for the IP subnets. Content developers should begin by looking up the ASN associated with subnets and comparing to the results from sites like https://www.spamhaus.org/statistics/botnet-asn/

Triage Assistance
Investigators and SOC analysts should seek to answer the following questions:

  • Why is the destination address considered bad? Is this classification accurate?
  • Is the destination address a shared address (proxy, shared hosting, cloud address, etc.) that would reduce the confidence in the detection?
  • What data exists in other data sources from your SIEM that would provide context WHY the communication occurred?
  • What other destination addresses was the source address communicating to at the same time? (e.g. - where they going to a website that was hosting malicious ads)

The Bottom Line
Although legacy firewall logs can be expensive to collect and monitor (and better security tools exist that provide more context to attack activity), for many organizations there is still value in finding a way to do so effectively. With the right tools in place, legacy firewall logs still allow for valuable security detections and awareness for organizations that continue to use them.

If you have legacy firewalls and are looking for more information about how you can use your firewall logs more effectively, download our whitepaper here...

Blog

Related Posts

September 13, 2022 Kumar Saurabh

Why No Code Solutions Are a Double-Edged Sword

Most out-of-the-box security automation is based on a simple logic — essentially, if “this”...

Learn More

August 16, 2022 Willy Leichter

Understanding MDR, XDR, EDR and TDR

A program with proper threat detection and response (TDR) has two key pillars: understanding the...

Learn More

August 9, 2022 Willy Leichter

Intuition vs. Automation: What Man and Machine Bring to Data Security

Cybersecurity experts Colin Henderson and Ray Espinoza share their take on the automation-driven...

Learn More

August 2, 2022 Anthony Morris

Using AI/ML to Create Better Security Detections

The blue-team challenge Ask any person who has interacted with a security operations center (SOC)...

Learn More

July 26, 2022 Willy Leichter

How to Select the Right MDR Service

It can be difficult to understand the differences between the various managed detection and...

Learn More

July 21, 2022 Willy Leichter

The Evolving Role of the SOC Analyst

As the cyber threat landscape evolves, so does the role of the security operations center (SOC)...

Learn More

July 19, 2022 Kumar Saurabh

Life, Liberty, and the Pursuit of Security

As cyber threats evolve, organizations of all sizes need to ramp up their security efforts....

Learn More

July 15, 2022 Tessa Mishoe

LogicHub Security RoundUp: July 2022

Hello, and welcome to the latest edition of the LogicHub Monthly Update! Each month we’ll be...

Learn More

July 12, 2022 Willy Leichter

Security Tools Need to Get with the API Program

No cloud API is an island The evolution of cloud services has coincided with the development of...

Learn More

July 6, 2022 Willy Leichter

Why the Rush to MDR?

LogicHub recently published a survey conducted by Osterman Research, looking at changing trends and...

Learn More