Let’s face it, logging is not the first thing on an application developer’s mind at the start of their working day. It’s my experience that the excitement of writing code and seeing it in action is still the overwhelming motivational driver for all software engineers these days. Having understood the business requirements for their application, the developer’s challenge is to produce an effective computer program that will deliver the expected business benefits in line with those requirements – usually as quickly as possible as the “time-to-market” needs to be minimised.
Writing code in such a way that it contains suitable hooks and triggers for the effective recording of key events in an appropriate audit log takes extra time and effort and can easily be seen as an unwanted additional development cost. Often and at best, audit logs are regarded as a “nice to have”, at worst they are totally ignored or forgotten.
Should a security incident occur however, it is to the audit logs that the forensic investigators will turn first. In the firestorm of a data breach involving the use of an application, a well-managed and ordered logging regime will help efforts to “put the fire out”.
A comprehensive and secure audit trail will help forensic investigators to track-down what happened and to identify possible sources of the data breach.
The creators of the Payment Card Industry (PCI) Data Security Standard (DSS) have understood this well and that’s why there’s a whole section of the PCI DSS (Requirement 10) that is focused on “tracking and monitoring all access to network resources and cardholder data”.
The PCI DSS provides a very helpful set of detailed and mandatory requirements for the implementation of an effective audit logging system around access to payment card data. But these requirements are good for wider use too.
It is not only payment card data that should be the subject of logging activities, all company systems and data that are deemed to be of critical value should be subject to carefully designed and engineered audit logging mechanisms.
By its very nature an audit log is classed as a “detective security measure” in that, on its own, it does not provide any active, preventative security defences. However, when an audit log is coupled with an active monitoring and alerting solution, real-time alarms can be raised should any suspicious or down-right malicious activity be spotted from the audit logs.
It is a good practice for all application developers to be trained in how to implement audit logging and event monitoring in their applications. Ideally such training will leverage a strategic IT approach, whereby a business-wide central logging system receives and securely-holds all event records sent to it by all applications and systems in use throughout the business. Such a strategic approach to event logging yields many advantages for a business, not only in spotting data breach “fires” and helping to put them out, but also in providing valuable insights into how its systems and applications are being used.