Logging is a hot topic and obviously not going to drop off the business agenda any time soon. But do organisations know why and what they are logging? If we do not know why we are logging activity, and have no plan in place should something arise from the insight it drives, then we will find ourselves in the same position as US retailer Target.
While on the subject, it would be worthwhile to examine what is meant by insight. Logging generates a ton of data and, when these bits of data are understood, they become information. Yet, this is still no real use. The data only becomes useful when combined and overlaid with a purpose and becomes insight, such as when it is answering a question or solving a problem.
We all know there are certain areas of security that can be challenged by the individual’s right to expect a reasonable level of privacy. A work environment is a minefield when it comes to anything that falls within what we could term monitoring or surveillance.
However, it is undeniable things such as log management can be a vital source of warning, information and prediction when it comes to security breaches, policy violations of users and where there is room for improvement or tightening up policies which are, after all, designed to protect the business, its information and its users.
Clearly, we need to use logs for a variety of purposes, but how do we do this while maintaining the privacy of users? If we know why we are doing it and not doing it just because we can, then part of the privacy issues will start to fall away and an actual business-justified strategy can emerge which staff will buy into.
However, all too frequently we see huge amounts of data being created and stored, with those who are meant to be interrogating it becoming swamped as the logging has become an entity of its own. This means there is no insight and no information, only data for its own sake. This is why we have to be absolutely clear about what we are trying to achieve.
There are three basic types of logging we can cover here:
- Boundary logging: Logs at strategic points in our network, intrusion detection and prevention systems, early warning systems such as FireEye antimalware detection, inbound inappropriate content (email and other messaging coming in) and protecting our organisation from the "wild west" all produce logs, some of which will prove to be spurious.
- Insider monitoring: Monitoring employee and other insider activity to manage insider threat. This would include log on log off activity, file shares and the amount of network use. It would give rise to trend analysis, so out of ordinary behaviour can be pinpointed. Of course, you may get false positives such as organised overtime, for example. It will include some boundary monitoring, such as tracking and preventing threats from outside, such as phishing, with email monitoring systems. It can also be used to ensure policy and procedural compliance, for filtering and to prevent data leakage.
- Diagnostic: Primarily designed to make life easier for technical staff. This would include the gathering of information to measure peak usage, trough usage, disc space and CPU capacity, for example. Much of this will be used for diagnostic and trend analysis to forecast the need for additional components in the network.
Anonymous approach to employee monitoring
Using the IT department to collate the information anonymously could be a possible route. Employees should be aware of any monitoring or tracking their employer uses. The Information Commissioner's Office (ICO) issues guidelines on its websitefor best practice when it comes to employee monitoring and handling the resulting data.
It may well be appropriate for certain teams to collate or collect data but not to view or use it – as it would be inappropriate and therefore not a correct use of that data. So logs can be collated anonymously unless a serious incident has occurred. That way those logs can be used without the users’ privacy being affected. Obviously, there should be a commensurate speed and ability once collated anonymously to cross-refer serious incidents to specific users. Hence the suggestion that the IT department collate the logs, but not have access to the specific user information, thus maintaining an appropriate degree of privacy.
Employees have a responsibility to maintain the security of their employer and its assets, including information assets. As long as everyone is clear about the reasons and procedures, then this should cover most privacy issues.
Where problems could arise would be if the information was going to be used in disciplinary procedures. This should underline to employers how vital it is they get these monitoring procedures correct, as any deviation from employment law and guidelines in this area could result in a tribunal and costs, not to mention bad publicity and reputational damage.
Using logs to build resilience
So, it is possible the information collated by IT could be used by the security manager to build security resilience by tweaking or hardening policy or enforcement, and measuring the effectiveness of current methodologies – potentially to expand them to other areas.
It could also be used to identify training needs or influence decisions about things such as content filtering and appropriate access to internet, social media, or areas of the network that should be handled sensitively.
It can inform things such as time-outs for unattended workstations and allow for increase or decrease on time elapsed as appropriate. Of course, it could be that employees are working at their desk but are not using the PC in that time, so false positives are a potential hazard when analysing this data.
The information can also be used to analyse trends and patterns in behaviour, such as checking to see whether users are logging off at the end of their working day or just locking their screens. If employees only lock their screens, any system changes, patches or updates may not take place, encryption will be rendered useless and the machine is at risk of breach. A pattern of this behaviour or sudden change could be a security warning flag.
Logs of user policy acknowledgements can offer an organisation a level of assurance that a policy can be effectively enforced. It should be remembered that clicking on any automated "SysOps" page before logging on does not necessarily constitute reading or understanding its contents. If we bear in mind the same degree of caution mentioned in the time-out and log -ff situations when analysing this information, we can see that logs – although very useful – should not be used in isolation.
Many security incident and event management (SIEM) systems provide comprehensive logs and graphical outputs, which can be very useful. It sits above the three types of logging and harvests the data from them like a huge integration platform. The insight – which does not mean data or information – these provide, in the form of trends and weaknesses, can be used to inform the introduction of appropriate controls before the security horse has bolted.
However, if it is simply sitting there harvesting data and not being analysed to generate insight, which in turn prompts actions that would be part of a fully tested response plan, then users may not know what they are looking at, apart from a data lake.
The key is to know what you want it to do – know what your questions are and configure it accordingly. So much wasted time and pointless data, which still has to be hosted, can be avoided if this step is taken. Badly configured systems will generate work and not insight. Going back to the ICO guidelines, if you do not know why you are collecting something then you shouldn’t be. If you are just collecting data for no purpose then that is mass surveillance, which is a whole other topic.
Ultimately, what is this about? What are we doing it for? To protect out information assets and our people. We should never lose sight of that when setting up good security log management. As with all forms of security counter-measures, logging should be proportionate, pragmatic, cost-effective and deliver a business benefit. With the technology available today, it can be tempting to log everything everywhere just because we can. But just because we can do something, does not mean we should.
Read more from Computer Weekly's Security Think Tank about security and log management
Mike Gillespie is director of cyber research and security at The Security Institute.
