Townsend Security Data Privacy Blog

We’ve had an upsurge in interest recently in our Alliance LogAgent solution for the IBM i (AS/400) platform. This solution sends security events from the IBM i in real time to log collection servers and SIEM solutions. As I’ve talked to IBM i customers, I am beginning to appreciate how difficult it is to get IBM i security information into a usable format so that events can be collected and monitored. The challenges are big:

• Data format – IBM security events are in internal IBM format, not syslog format.
• Multiple sources – Security events get collected in a variety of locations, almost always in an internal and proprietary IBM format.
• Timeliness – Tools are lacking to collect security events in real-time, increasing the security exposure.
• Communications – There are no native syslog UDP, TCP or SSL TCP communications facilities.
• Data completeness – While it is possible to print security information using IBM tools, critical information is missing from reports.

Here is a really good example of this last point. I can use the Display Audit Journal Entry command (DSPAUDJRNE) to print a report of user ID and password failures. Here is a bit of what that report looks like:

Can you imagine a SIEM solution or poor network administrator trying to get useful information from this? Fields are not easily identified and extracted, and most SIEM query tools would have a really hard time extracting the meaning from this report. There are user ID and password failures here, but hard to parse them out.

And one of the most important pieces of information is missing. Can you see what it is?

Right, the IP address of the originator of the error. SIEM solutions are good at correlating events if they know where they are coming from. The IP address is critical for accomplishing this. This report could probably tell you when you are under attack, but not where it is coming from and certainly not in real-time.

Our Alliance LogAgent solution solves all of these problems. Events are extracted from all of the relevant sources, in real time, converted to standard syslog format, and communicated using your choice of UDP, TCP, or secure TLS communications to your log server. And, Yes, the IP address is in the event! Here is an example of a PW event as it is processed by Alliance LogAgent:

<118>Sep 20 15:47:11 S10125BA QAUDJRN:[PW@0 event="PW-Invalid user or password" event_type="Q-Signon failed profile disabled" user_profile="QTCP" device="*N" jrn_seq="002273092" timestamp="20120120154711021000" job_name="QTLPD00145" user_name="QTCP" job_number="630743" ip_addr="10.0.1.205" port="15427"]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             

This is caviar to your SIEM solution!  Real time alerts, event queries, and forensics become a snap when you get the right data into your SIEM solution. And real time system monitoring is one of the top recommendations by security professionals to keep your IBM i (AS/400) safe.

I’m proud of our system logging solution for the IBM platform. Our customers have deployed the solution in under an hour starting from the time they do the download from our web site.

Patrick

In our final installment on system logging on the IBM i series, Patrick Townsend, Founder & CTO, discusses what to look for when selecting and deploying a logging solution.  As we found out in part two of this series, it really isn’t a good idea to take the “do it yourself” approach.  System logs are in several different locations on the IBM i, and even if you get them all together, it is still a challenge to get them in a useable format.  Here is what Patrick has to say about selecting a logging solution:

So what do you need to look for when selecting and deploying a logging solution?

I think that there are four key points when looking at a logging solution especially on the IBM i Platform. One is, you want a real-time logging solution.  It won’t cut it to have a system collecting events once or twice a day and sending them off to a log server.  You need a real-time system that is collecting events as they happen so that your log collection server and your SIEM can actually correlate events across multiple servers and “see” what’s happening.

Secondly, on the IBM i, performance is always an issue. We have many customers running Alliance LogAgent with tens of millions of events a day.  Just this week we talked to a customer who was generating 120 million events a day.  That is a lot of events to be collecting and other solutions just can’t keep up with the sheer volume of events.  If your system can’t keep up with that, you will have a real compliance problem.  I’m really proud of the performance of our solution and that it allows us to do hundreds of millions of events every day, keeping up with the security events of the largest customers.

Third, logs should be protected while they are being transmitted to a log server.  Alliance LogAgent protects the transmission with a SSL/TCP connection.  Some of the information in your system logs can be very sensitive and it would be a bad idea to transmit this data in the clear.  When choosing a logging solution, it should have full support for a secure transfer mechanism.

Finally, industry standards are very important.  Standards are important on a very practical level.  When you buy a light bulb in the store, you want to be able to take it home and plug into a light socket.  You are able to do this because of standards.  The same is true for logging events on the IBM i.  There is a standard format for logging system events and the way you send your logs from an IBM i to a log collection server.  Query, reporting, and alerting tools depend on those standard formats.  The solution that you decide to deploy should be built on industry standards.  We support both the RFC Format and Common Event Format standards.

Those are the four most critical points for a standard logging solution and I am really proud that our product, LogAgent stands up really well on all four of those points. Overall, I think if you focus on those four items you’ll be in a good place.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.

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.

As a company that works hard to protect your data, we get a lot of questions – from people wanting to know the ins and outs of our products to IT professionals who are new to the world of meeting compliance regulations.  Luckily, our company has several experts to answer these questions.  One topic that we often get questions regarding is system logging on the IBM i (AS/400).  Logging on the IBM i is different than logging on other platforms.  I recently sat down with Patrick Townsend, Founder & CEO, to pick his brain on what system logging is, and why it is so unique on the IBM i.

System logging has become one of the most essential compliance tasks in contemporary corporate IT. Can you give a brief explanation of what logging is and why it is so important?

Sure, all computer systems, including the IBM i (AS/400, iSeries, System i) collect lots of important information about the security state or the operational state of the system as a whole.  We call these System Logs and they often include a great deal of information about what is going on in the system.  In a lot of systems, including the IBM i, these logs are created in real-time.  To give an example, if someone tries to sign into an IBM i and for whatever reason the username or password is invalid, that event is logged in the system log.  This is an important thing to log because if you were to look at this system log in real-time and notice several invalid username and password events, you would say “Hey, our system is being attacked. We need to take action on this now.”  In summary, System Logs are just a central repository on the computer system that say what is going on within the system.  This is why they are so important from a security point of view.

Where does security information live on the IBM i?

Security information lives in a number of places, which is one of the challenges that IBM i administrators have.  On the IBM i, IBM creates a central repository (QAUDJRN in the IBM i world) for a large number of security events including password and other security events. Our Alliance LogAgent customers can decide what kind of events they want to collect.  QAUDJRN is not the only place to look for this security information. There is also a system event log file called QHST that has important log-on and log-off information for users.  The operators console (QSYSOPR) collects and tracks important events and messages for security monitoring.  Finally, the IBM i sports a lot of new, web-type services that have their own log collection facilities including WebSphere, Apache, and SSH.  In order to properly look at all of the security events that are happening on an IBM i, you have to look in several places, which can be a challenge.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.