Latest posts

Planning for and implementing security logging



Most data security breaches have something in common; they are not overly technical, and in most cases they could have been easily detected – far sooner than they are currently. The available evidence from forensic investigations has shown that over 40% of data breaches remain undetected for months at a time. Our collective goal must be to work to detect data security breaches in order to reduce exposure and harm to cardholders and card issuers. A successful log management solution is no longer a recommendation but a must have element of any security strategy.

Any hacking activity, by its very nature, generates messages that are logged by a wide variety of systems. Ideally these logged events should act as a trigger for a response to limit the likelihood of a successful attack and subsequent breach of sensitive data, or at least to quickly detect a successful attack to reduce the damage caused by the attack. Unfortunately, through investigation of many data breaches it has become clear that in many cases the organisation was operating completely unaware of a compromise because:

  • Logging had been either disabled due to perceived performance issues;
  • The logs were overwritten so frequently that trigger events were lost;
  • Logging had been enabled but it wasn’t been monitored
  • The compromised entity was unaware of what events were being logged.

Despite the general availability of information logged across an organisation, a robust logging solution
catering for all relevant system components can require a significant investment in time and resources, not to mention financial commitment. The issue facing many small retailers is understanding what they should log, or knowing what questions to ask when they are developing a logging strategy.


Logs are generated throughout an IT environment (by both hardware and software) by recording any events taking place within these systems. However, in many cases these events are frequently not analysed, not acted upon or are deleted/ overwritten after a short period of time.

With so much information available one of the major issues identifying what log events your business may be interested in. For example, a single failed login on a particular system
is not necessarily unusual or cause for concern, but multiple failed logins on a single system, or on multiple systems across the network, within a few seconds of each other should be cause for concern and could indicate a potential attack.

Before considering the many available solutions, be they in- house or as part of logging solution provided by a third party, it is important to spend time considering the data that you may need to log. This is especially true considering the wide range and cost of potential solutions available to you. For example, it may make little financial sense to invest funds in a solution that can generate hundreds of alerts per day and weekly reports if you do not have the staff to review and act upon these alerts and reports.

Considering this, simply committing large financial sums into purchasing very expensive tools is not the most effective route to follow. Spending time up front to consider the overall objective, such as helping to reduce organisational risk, it becomes clear that it is important to understand your requirements.

In highlighting the availability of this information and the benefits of a logging solution, both from a security and business operations point of view, we can work cooperatively to limit data security breaches.

The goal of this post is to assist businesses in developing a logging strategy and understanding how that information can be put to good use. In highlighting the availability of this information and the benefits of a logging solution, both from a security and business operations point of view, we can work cooperatively to limit data security breaches. If the worst does happen we can reduce the window of exposure to both cardholders and the business affected by self-detecting a potential data breaches at an early stage.

Logging and PCI DSS

PCI DSS requires not only the creation and retention of log information, but also that the logs are reviewed on a daily basis. Depending on the nature of your environment, the daily reviews can be via log management tools or manually. By performing these daily reviews, it will provide you with an important element of your security strategy by alerting you to any potential security issues within your infrastructure.

The logging requirements for PCI DSS are well defined and any logging solution developed should at a minimum include:

  • establishing a logging policy for all system components
  • logging events and relevant supporting information
  • syncronising times across critical systems providing log information
  • securing log data to prevent misuse
  • reviewing logs daily
  • maintaining log information for at least one year.


Implementing an event log analysis system is a complex process, but by considering the points in this paper your organisation can ensure that your solution is fit for purpose and adding value to the organisation through careful consideration and planning.

It is important to highlight once more that there will always be an administrative workload associated with performing effective log analysis, and it is for this reason that the tools/ solutions selected should be carefully screened and tested before committing to any investment.

Lastly, understanding your organisation’s event logs
will, without a doubt, open a new dimension of business intelligence that can lead to enhanced security, increased service uptime, and overall operational improvements.

An efficient logging and event management program could actually be considered a business enabler, linking Marketing Information, Business Continuity, Incident Response and Disaster Recovery with network and system health.



No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *