Section 10 of PCI DSS requirements v2.0 states the need to track user activities, to be able to detect, prevent or minimize the impact of a data compromise. Because of the mere fact that most every application under the sun produces a log entry for when something goes amiss, you can also use that same log file as a security tool. It can provide a means of tracking and analysis when a possible data breach may be occurring as well as add crucial detail for investigative purposes. Now a smart criminal knows to cover their tracks at the scene of a crime, and they can do this simply by wiping out any log data that may exist. However if you’re capturing these logs in real time and sending them to a third party server, even the most savvy of crooks will be caught red handed.
Our Alliance LogAgent solution helps accomplish that, as well as satisfying parts of section 10 of PCI DSS by being able to capture logs from your IBM i’s audit journal, formatting them and sending them off to a waiting log collection server. We monitor for log entries out of numerous places on the iSeries allowing the user the a level of granularity to choose what log messages to capture and kick over the wall to the waiting log server. It's always a good idea to work hand-in-hand with your PCI auditor to make sure you're collecting all the appropriate events on your system to meet their requirements.
For instance, you'll want to make sure you're collecting AF (Authority Failure Events) events which come from the System Value QAUDLVL. This particular event is triggered by all access failures, such as sign-ons authorization, and job submissions. It also includes incorrect password and user ID attempts from a device. These details can play a crucial role in tracking down details around a possible breach into your system.
As I mentioned, Alliance LogAgent sends these events to a listening collection server or SIEM solution. We work with any SIEM product that is actively listening and waiting for logs to arrive and can accept messages in the RFC 3164 or Common Event format. There are a number of SIEM products available on the market and they help parse the influx of log messages as they arrive, as well as send out notification and alert emails when something suspicious is detected.
Currently, the PCI guidelines don't include transmitting logs over a secure SSL/TLS session (it’s a very, very good idea). However, looking ahead to when this becomes a requirement, you can rest assure that you’re already running software that can meet those needs. LogAgent is already setup to handle secure SSL/TLS transmissions and is one of the reasons it stands apart from the competition. The only change you'll have to make in the configuration of the product when switching over from UDP/TCP to SSL will be to provide an SSL application ID. This is an ID that is associated with a digital certificate that you can create with IBM's Digital Certificate Manager (DCM). Having this secure session in place will ensure that your log message data won't be intercepted on its journey to the collection server.
Download a free 30-day evaluation of Alliance LogAgent Suite and meet Section 10 of PCI DSS. In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.
The Alliance LogAgent Solution for system logging on the IBM iSeries is able to grab log messages out of a variety of places such as your system's audit journal, (QAUDJRN), your history log (QHST), and system operator messages (QSYSOPR) and format them to either a standardized Syslog format, in this case RFC3164 or Common Event Format (CEF). Once formatted, we pass the messages over to the communications module that handles the transmission of the messages to your waiting log collection server using either the UDP, TCP or SSL/TLS protocol. 
