In conversations with many security teams, I've found a common frustration: relying on WAF access logs to secure their APIs and web apps. The unfortunate truth is that WAF logs don't work in practice. This post goes into detail about why.
Lack of Detail in WAF Access Logs
Many security teams attempt to use logging to monitor and secure their APIs. However, WAF access logs typically include basic information such as the request method, URL, status code, response time, and possible even rule triggered. This level of detail might be sufficient for simple traffic analysis but falls short for thorough threat investigation.
AWS WAF Logs lack sufficient detail for threat investigationCritical data, such as detailed attack payloads or the patterns of malicious requests, are often missing. This limitation leaves security teams unable to see the full scope of an attack, making it difficult to respond effectively.
Incomplete Logging Due to Sampling
Another significant issue with WAF logging is the sampling of data. At a previous company I worked for, many of my customers complaiend because although they could see some attack payloads in their WAF logs, they weren’t able to see all of them because the logs were sampled.
This is pretty common practice in the WAF industry, not just my previous company. For example, AWS WAF logs up to 100 requests that match or don't match a WAF filter, which represents only a small fraction of the total traffic. This 100-request limit is insufficient for a comprehensive investigation, preventing teams from fully understanding the attackers' tactics and techniques.
The High Cost of WAF Logging
Logging all access attempts at full detail is not only challenging but also extremely costly. At a previous WAF company, we tried dumping all access logs into Google BigQuery for threat investigation. This approach became so expensive that the cost of storing and analyzing the logs exceeded the cost of running the WAF itself.
This is the underlying reason for why most WAF providers try to rely on sampling - to manage these expenses. Streaming, processing, and storing HTTP requests at full line rate require significant resources, making it a financially unviable solution for many organizations.
Impart logging was designed to work for security teams
Given these challenges, it's clear that traditional WAF access logs are not enough for effective API security. Security teams need more detailed, complete, and affordable logging solutions to understand and mitigate threats fully.
That’s why at Impart, we designed our logging capabilities from the ground up to work for security teams. How did we do that? By being smarter.
Investigate Sensitive Data directly in Datadog SIEMLogging what matters
Logging settings with most WAFs are fairly straightforward - on or off. You can either turn on logging, or turn it off. (And if you turn it on, you get a sample that you can’t really control). The problem with this approach is that it’s completely orthogonal to what actually matters for a security team.
What matters to a security team isn’t logging everything (that’s way too much noise), and it isn’t logging a sample (that’s not good enough for audit, evidence collection, or investigation). What also doesn’t matter is whether the logs appear in the WAF console, since most enterprise security teams spend most of their time in their SIEM where all their logs are consolidated, rather than in a point solution like a WAF to look at WAF logs.
Impart Splunk DashboardWhat matters to a security team is being able to log 100% of the things that matter. Things like blocked attacks, or suspicious activity, or sensitive data going to the wrong place. WAFs aren’t aren’t able to log requests with these types of insights, because their logging logic is static and inflexible. You can either log everything, log nothing, or log a random sample of traffic.
Dynamic, Conditional Logging
With Impart, we designed our logging capabilities from the ground up to work for security teams, instead of against them.
This means that security teams can finally define dynamic logging policies that adjust to what is actually happening in real time. No longer to security teams have to take guesses ahead of time of what to log, but they can log based on what live traffic insights are actually observed.
Some real world logging examples that are only possible with Impart:
- Logging specific headers that contained sensitive data for 100% of requests that were attacked in order to save for evidence collection
- Logging only suspicious usernames and passwords that were used in ATO or credential stuffing attacks
- Logging 100% of attack payloads only for use in fine tuning threat detection models
- and more!