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:
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.
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.