Any Compliance Auditor is going to ask to see audit trails of user and device activity, requiring event logs to be backed up to a log server.
This may well be met with a roll of your eyes: “And now they want us to store unending terabytes of logfiles?”
Sadly, for many, that is actually the main tangible result from doing this, especially when handling firewall logs.
So why do Auditors want logs? There are two priorities for logging as a security best practice:
- Pro-active Security: By analysing audit trails, security officers become intimate with the “business as usual” workings of the network. When a genuine security threat arises, this unusual activity will be more conspicuous, so easier to spot.
- To provide a “Cyber-flight Recorder”: If a cyber-attack is successful, a forensic analysis of the activity surrounding the attack can be conducted.
At best, the perpetrator and details of their wrongdoing can be identified. At worst, lessons can be learned from the attack. This is why audit trails are typically held for 12 months – it may be months before a breach is uncovered.
Firewalls provide protection from internet-borne attacks and are a key log source. Beware though – they are often responsible for 90 percent of log volumes.
Storage may be cheaper now, but we don't want to unnecessarily burn-up disk space. Likewise we don't want to squander our precious “events per second” SIEM capacity.
So how can we meet the compliance mandate and keep our auditor happy while avoiding waste of storage and SIEM performance?
Collect ALL the logs? The fear and loathing of log savers…
There is a temptation to just “play it safe” and collect all events. Most of us are doing this primarily to keep an Auditor happy, and we don't want to come up short when asked to show a specific audit trail.
So which logs are essential to capture? As an example, the PCI DSS uses language that leaves many confused as to the specific events needed, leading to the “just store everything” approach.
Alternatively, the SANS Institute provide more generic guidance, borne out of security best practice philosophy that you need to know what's going on in your network.
Bytes transferred (large files?)
Bandwidth and protocol usage
Detected attack activity
User account changes
However, much of this guidance was formulated years ago and, while the security purist will still tell you this level of analysis to “second guess” breach activity is needed, today's contemporary Intrusion Protection capabilities automate many of the time-honoured threat-identification techniques.
Taking all this into account, what do I need to log, and what can I exclude?
It could be argued that the finite resource in any organisation is best focused on fewer key audit trails, namely
- successful and failed logons (you need to know if anyone is accessing the firewall)
- changes to rules/config (you need to know if the config or software has been tampered with, more a file integrity monitoring task than a logging one)
- high severity alerts (these should be few and far between and all should be investigated)
You never can spend enough time reviewing events from your firewall, and the fundamental security best practices of knowing what good/regular operation looks like in order to spot the suspicious/irregular activity is still essential. But in reality, prioritising investigation efforts necessitates the reduction of “audit-trail noise” to concentrate on the most important events being generated.
Summary guidance – Tthe Cisco recommendation
Cisco's guidance advocates a broad audit policy, with logging at the “informational and above” level, with the noisiest event IDs then selectively disabled. For example, just a few config changes will suppress events generated by connection and address translations being built then disbanded. These events just show the firewall doing its “business as usual” operations and also form the majority of log volumes.
Depending on the deployment of the firewall, it may also be appropriate to tune the settings of the IPS detection capabilities to further reduce spurious event noise, for example, ping-sweep alerts that may be triggered by your own regular network scans.
Whatever your approach to logging for firewalls, don't be too passive. Take time to familiarise yourself with the audit policy applied and the resultant log volumes and event IDs. It's likely you will have a minority of event IDs generating the majority of log noise and which are not needed for compliance. If you don't need to process and store events, make sure they are suppressed by the firewall or filtered and discarded by your SIEM system.
Yes, security and compliance is vital and does come with a price, but that shouldn't leave you needing to write blank checks for storage and SIEM resources.
Contributed by Mark Kedgley, CTO, New Net Technologies (NNT)
*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media or Haymarket Media.