The securing of business information has, in the past, been placed way down the list of priorities when it comes to day-to-day running of the business. The actions of auditing systems have normally been reliant upon Windows event logs or the OS X / Linux audit logs, rarely were these looked at unless there were issues cropping up.
Now as more and more businesses are suffering cyber attacks, or attacks from malicious users, the need for easy visibility of events is increasing. But what do you do with all these events, ignore them? leave them until you need them? Alert on them? There are many options available to you.
Logs play a critical part of any system, they allow the system administrators an insight into what systems are doing, as well as what happened after an event. As soon as you have more than a handful of systems to manage, viewing and searching event logs becomes unbearable, this is where centralised logging comes into play.
What is an audit log?
An event log can be classified as a type of database that contains all the events which have been carried out on the device in question, whether this is a desktop computer, laptop, networking device or some IoT device.
The audit logs allow you to see what has been going on with your device, has there been any software installed, any users or files created etc. the list goes on, depending upon the device and version of software that has been used.
In MS Windows, you can find your logs under the Windows Event Viewer console which can be seen below. The Windows Event Viewer is made up of the following categories, and is configured by default to capture the more popular events that happens on the system:
You can however, through Group Policy configure additional events to be captured, including how long they are kept and whether an action should be executed, this is useful when working within a large business. More information can be found here: https://technet.microsoft.com/en-us/library/cc778402(v=ws.10).aspx
In Linux, there is a dedicated audit log which can be found at: ‘/var/log/audit/audit.log’, however to view this file you will need to be root.
In OS X, the audit logs are in ‘/var/audit’, again you will need to be root to view the contents of this directory.
What’s centralised logging?
Centralised logging is a system which allows you to direct all your logs from multiple devices all into one system, via the use of log collectors. Log collectors are located on all the machines or devices that are being monitored.
Some of the more popular log collectors are:
These collectors monitor all the events which are being written and then automatically send the data over in the format of choice (normally syslog of json) and is then written to the central storage.
The central storage is usually a huge storage area that contains all the logs of the business for a predefined time, or in some cases indefinitely.
Having all this information isn’t very helpful if there’s no way to query the data, this is where the graphic interfaces come into play. For the ELK stack, the most popular centralised logging solution there’s Kibana, which allows you to graph and display your data in an easy to view layout.
Examples of central logging solutions
There are several centralised logging solutions available to you, all vary in features and cost. Some of the more popular ones are:
- Elastic Stack (Elasticsearch, Logstash, Elk) – https://www.elastic.co/
- Sumologic – https://sumologic.com
- ElasticSearch – https://aws.amazon.com
- Loggly – https://loggly.com
- io – https://logz.io
Putting it all together
One you have your event logs configured correctly and you have set up your centralised logging system, its time to put everything together. You need to define a solution where your audit logs are automatically sent to your centralised logging solution (through log collectors).
This can be via syslog as well as using a third-party agent which have been mentioned above and are provided by the central logging provider.
Then once you start collecting your data, you need to start looking at your events and start working out a baseline, to find what the anomalies are. Its good practice to setup dashboards and alerts to view your data in real time. Kibana and the ELK stack can provide some interesting information.
I hope this article is of use to you and that it helps you protect your business through the monitoring of alerts. Ensuring that you manage and monitor alerts will ensure that you have a quicker response time, should you notice any potential incidents, such as brute force attacks or unauthorised logins.