In the first part of our series on system logging on the IBM i (AS/400) we discussed why system logging is so important and where security information lives on the IBM i.  We will now continue my conversation with Patrick Townsend, Founder & CTO, and talk about log collection and meeting compliance regulations with system logging.

So now that you have identified the sources of this important system information, how do we format it for log collection and SIEM Servers?

This is probably the biggest challenge for IBM i users - getting log information from the IBM i into a usable format.  IBM i logs are not recognizable by a typical log collection sever or a SIEM console that monitor log data.  With Alliance LogAgent, we have tackled this problem by reading all of these sources of event information and translating from the IBM i format to a standard log format.  IBM does provide a few utilities for printing log information, and I have seen people try to use those to get data into a text type format, but they are unsuccessful because the printed log information is not in a standard format.  Another reason why this method doesn’t work is that it is typically not in real-time, so you’re not picking up information in a timely fashion - meaning you are missing threats that are happening in your machine.

Formatting data is a major challenge and we decided that the right way to do this was to bite the bullet and read the internal format of the logs, while they are completely unrecognizable to any standard log collection server, and format them to industry standard formats - based on existing RFC’s in terms of SYSLOG formats or Common Event Format.  Alliance LogAgent puts them in the right format and transmits them.  The technology in our logging solution is really focused on making all that log information usable, doing it in real-time, and then getting it to where it needs to go – allowing it to be monitored by your SIEM in real time.

System logging is also important for meeting compliance regulations too, right? 

Absolutely, if you take a look at PCI data security standards from the beginning, section 10 is focused on collecting logs and analyzing them in a timely fashion.  If you drill down into the recommendations for HIPAA/HITECH Act, or if you’re looking at FFIEC in the financial sector, or even privacy notification laws, they are all very consistent about requiring proper monitoring of system logs.  And this is understandable, looking at how threats evolve and what the typical threat looks like.

Sometimes bad software gets installed on a system and sits there for months at a time, undetected because nobody is monitoring the logs. That software can be phoning home through an IP connection and checking in through remote servers.  Your logs should be showing that activity.  That is why you’ll find across the board, in almost every compliance regulation, a need or requirement to collect logs in a central location, on a log collection server, or in a SIEM.  Someone needs to be paying attention to those logs and “someone” could be automated software, including products from SIEM vendors.  It is really important from a compliance point of view that you are collecting logs, doing it in a fast, real-time fashion, and have something monitoring those logs looking for threats.

View our Webcast “Understanding Log Management on the IBM i” for more information on logging and how it can help you meet compliance requirements with real-time security event logging across your Enterprise.