Any Compliance Auditor is going to ask to see evidence that a full audit trail of user and device activity is retained, requiring all audit log events to be securely backed up to a central log server.

As with much of what an Auditor asks for, this request may well be met with a roll of your eyes and a shake of the head '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 firewall logs need to be covered.

So why do it in the first place? There are two priorities for logging as a security best practice:

  • Firstly, as a pro-active security measure, by continuously analyzing audit trails on a daily basis the Security Team becomes more intimate with the daily 'business as usual' workings of the network. As a consequence, when a genuine security threat arises, it will be more easily detected by being seen as an unusual, irregular and unexpected pattern of activity. The aim of contemporary SIEM technology is to automate this task
  • The second driver for log retention is to create a 'cyber-flight recorder/black box' audit trail so that if a cyber attack is successful, a forensic analysis of the activity surrounding the security incident can be conducted.

At best, the perpetrator and the extent of their wrongdoing can be identified and remediated. At worst – lessons can be learned from the attack so that procedures and technological security defenses can be improved, for example, a new patch developed for the exploited software. For this reason, audit log trails must typically be held for a minimum of 12 months – it can take weeks or months for a breach to be uncovered.

Naturally enough, one of the most critical types of device to be monitored are the firewalls, being a key layer of protection from internet-borne attacks. Beware, though - firewalls are notorious as one of the noisiest log sources to monitor, often being responsible for 90% of log volumes despite being just 10% of the devices sending logs.

Storage may well be cheaper than it has ever been before, but we still don't want to unnecessarily burn-up disk space. And, since for most of us, our centralized logs are going to be analyzed by some kind of SIEM system, we definitely don't want to be wasting our precious 'events per second' SIEM capacity.

So how do we meet the compliance mandate and keep our auditor happy but avoid wasting precious IT investment in storage and SIEM performance? Before we can start we are going to need some logs from our firewall.

 

How do we get Event Logs from Firewalls and Network Devices?

 

Clearly, the exact command set varies between manufacturers and firewall versions but you will need to enable 'logging' via either the Firewall Web interface or the Command Line. The same approach will work for most other networking devices too, such as routers and switches.

For this example, we will use a Cisco ASA and the Cisco ASDM Management Tool, as well as the alternative CLI approach.

Choose Configuration > Device Management > Logging > Logging Setup and check mark the Enable logging option.

Next, select Syslog Servers and add the IP Address of your Syslog/SIEM server. Make sure you have connectivity for Port 514 UDP through the network.

Alternatively, the CLI command sequence is as follows

logging on

no logging console

no logging monitor

logging a.b.c.d (the address of your syslog server)

logging trap informational

 

This will ensure all 'Informational' level and above messages are forwarded to the syslog server and guarantee all logons/logoffs are captured, one of the key audit trails required for security and compliance.

Which is generally where the problems with out of control log storage consumption begin. The 'Informational' severity on a Cisco ASA is actually just one level above Debugging, in other words, this setting in isolation will generate event overload.

So please don't just stop here - it is vital to refine your audit policy further if runaway/excessive storage usage is to be avoided.

 

Collect ALL the logs? The fear and loathing of log savers…

 

There is much uncertainty relating to this area, concern that vital events will be excluded or missed, and therefore there is often a temptation to just 'play it safe' and just go ahead and collect all the events. After all, many of us will be doing this primarily to keep an Auditor happy, so we don't want to pull any punches and come up short when we get asked to show a specific audit trail?

But this is definitely a case of 'log in haste, regret at leisure'. Whilst the earlier recommendation was to use 'Informational and Above' – and this is a quick and an effective solution to covering all auditor requirements - for a firewall this will always result in huge spurious log volumes being forwarded, loading the network, overwhelming the Log Server and burning up more and more storage.

 

So which logs are essential to capture? Then I can dump the rest…

 

In terms of the PCI DSS, they are fairly explicit about the audit trails required, although the language used still leaves many confused as to the specific events needed, again, leading to the 'just store everything' approach. However, a more pragmatic review of Requirement 10 in the context of a Firewall could provide an interpretation as below (Note: OK, so QSAs are nothing if not independent, so don't be surprised if you get asked for additional logs, but the below is drawn from our experience of working with QSAs around the world over the last ten years)

Req.

Title

Description

Firewall Context?

10.2.1

Verify all individual access to cardholder data is logged

Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account in order to access cardholder data. A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused

 

Almost never applicable to a Firewall

10.2.2

Verify all actions taken by any individual with root or administrative privileges are logged

 

Accounts with increased privileges, such as the "administrator" or "root" account, have the potential to greatly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is unable to trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and individual.

 

Capture logons and use of Privilege mode

e.g. %ASA-7-111009 User executed cmd:string

(see later note regarding severity override)

10.2.3

Verify access to all audit trails is logged.

 

Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace steps made by unauthorized personnel.

 

Capture any 'logging' events

 

e.g. %ASA-3-414xxx

10.2.4

Verify invalid logical access attempts are logged.

 

Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user's attempts to "brute force" or guess a password.

 

Capture Failed Logons

%ASA-4-1090xx

%ASA-6-611102

10.2.5

10.2.5.a Verify use of identification and authentication mechanisms is logged.

10.2.5.b Verify all elevation of privileges is logged.

10.2.5.c Verify all changes, additions, or deletions to any account with root or administrative privileges are logged

 

Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts that may have been used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account.

Capture user authentication events

 

%ASA-n-109xxx

%ASA-n-113xxx

 

%ASA-6-611101

 

And any AAA events

 

%ASA-5-5021xx

 

 

10.2.6

Verify the following are logged:

§   Initialization of audit logs

§   Stopping or pausing of audit logs

 

Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions.

 

See 10.2.3 - Capture any 'logging' events

 

%ASA-3-414xxx

10.2.7

Verify creation and deletion of system level objects are logged.

 

Malicious software, such as malware, often creates or replaces system level objects on the target system in order to control a particular function or operation on that system. By logging when system-level objects, such as database tables or stored procedures, are created or deleted, it will be easier to determine whether such modifications were authorized.

 

Events 111xxx, 112xxx, 208xxx, 308xxx

(Note: Use FIM to capture show version, show running & show startup to track software version and size changes)

 

 

As an alternative to the specific PCI Requirement 10 view of what constitutes the important, the SANS Institute have produced a simpler summary and more generic chart of events to be retained.

What to look for on Network Devices:

Traffic allowed on firewall

Traffic blocked on firewall

Bytes transferred (large files?)

Bandwidth and protocol usage

Detected attack activity

User account changes

Administrator access

The idea of looking at blocked and allowed traffic and taking an interest in any large data transfer is based on sound, security best practice of making sure you know what is going on in your network. Bear in mind that this chart was formulated over ten years ago and, while the security purist will still tell you this level of analysis to 'second guess' breach activity is needed, in today's contemporary context, where firewalls are more intelligent than ever, the basic tasks of identifying suspicious looking activity is now largely automated for you.

This has now reached a point where Intrusion Protection capabilities have been engineered into the firewall's standard operation and a wide number of intelligent threat identification techniques have also been built-in, making the need for manual vigilance over all activity less necessary than it was when firewall technology was more primitive.

 

Taking all this into account, what do I need to log, and what can I exclude?

 

It could be argued that, if a risk-oriented approach to firewall event analysis is adopted, the finite resource in any organization is best employed focusing on the 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, actually more a file integrity monitoring task than a logging one)
  • high severity alerts (if an alert has Alert, Critical or Error severity then it is worth investigating)

It is important to clarify that you can never 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. In spite of this, while there will always be a finite limit to the amount of resource that can be spent on the log review tasks, it is necessary to prioritize and what we are advocating here is an approach that reduces the level of 'audit trail noise' while concentrating focus on the most important events being generated.

 

Summary Guidance – The Cisco Recommendation

We like the Cisco recommendation because it takes a good compromise position between the very precisely targeted/ultra-lean audit policy approach and the 'let it go, store everything' position.

Cisco's guidance starts with a very broad audit policy, with logging set at the informational and above level, then selectively prunes out the noisiest event IDs. It's the most effective way of getting the maximum reduction in spurious events while making just a few config changes.

Step 1 – Disable Events 305010, 305011, 305012

%ASA-6-305010: Teardown translation from interface_name to interface_name

%ASA-6-305011: Built translation from interface_name to interface_name

%ASA-6-305012: Teardown translation from interface_name to interface_name

These messages are essentially reporting the regular, successful operation of the firewall as it does its job of allowing permitted traffic to pass. There is a need to review firewall rules regularly to maintain security, but this is better done by analyzing the rules/config itself, rather than generating then reviewing copious events.

Similarly, you may also consider disabling the following messages:

%ASA-6-302014: Teardown TCP connection id for interface to interface

%ASA-6-302016: Teardown UDP connection number for interface to interface

If dynamic Network Address Translation (NAT) is not configured on the appliance, you can also remove the following messages:

%ASA-6-302013: Built TCP connection_id for interface to interface

To disable these messages, use the following configuration commands:

no logging message 305010

no logging message 305011

no logging message 305012

no logging message 302014

no logging message 302016

no logging message 302013

Finally, for compliance purposes, there is at least one event that will need its severity level changing in order to receive these messages while the base audit policy is set to Informational and Above.

Fortunately, the Cisco ASA 5500 Series appliances allow you to change the severity level at which a message is logged.

Event ID %ASA-7-111009, records the execution of exec commands on the appliance, and by default is logged at level 7 – Debug. The following configuration command would cause this event to be logged at Informational level instead:

logging message 111009 level 6

Final Tuning – Mute that Firewall!

 

Depending on the deployment of the ASA, it may also be appropriate to tune some of the advanced settings of the IPS features to further reduce spurious event noise.

The steps are relatively simple but need careful consideration before doing so. For example, increasing the Event Count for the IPS Sensor will ensure alerts are only sent for persistent threats detected while quenching out routinely occurring false positives. Alternatively, you may even consider disabling sensors entirely according to what is appropriate for your environment and deployment e.g. the ping sweep detector may be falsely triggered on an internal network by other management tools/security scanners.

 

Conclusion

 

Whatever your approach to logging for your firewalls, don't be too passive. Take time to familiarize 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 overwhelming majority of log noise that you don't need for compliance. If you don't need to process and store events, make sure they are suppressed by the firewall or at least 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.

NNT has a range of training and managed service offerings to help you get the most of your solution.
Call 1-888-898-0674 or click here to request more information.

NNT Products
USA Offices
New Net Technologies Ltd
Naples
Suite #10115, 9128 Strada Place
Naples, Florida, 34108
Atlanta
201 17th Street, Suite 300
Atlanta, Georgia, 30363.

Tel: 1-888-898-0674
email[email protected]
UK Office
New Net Technologies Ltd
Spectrum House, Dunstable Road
Redbourn,
St Albans

Herts
AL3 7PR

Tel: 08456 585 005
Fax: 08456 122 031
email[email protected]
NNT Newsletter
Sign up to receive our monthly newsletter covering breaking security news, how-to-tips, trends and commentary directly to your inbox.


Google+ Linkedin Twitter - Change Tracker Facebook rss feed YouTube
CIS benchmarking SEWP Cybersecurity 500 Sans Institute
Copyright 2017, New Net Technologies Ltd. All rights reserved. 
NNT and Change Tracker are registered trademarks of New Net Technologies Ltd.
All other product, company names and trademarks are the property of their respective owners.