Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

PCI Section 10 requires logging for anyone who collects credit card data

Requirement 10:  
 “Track and monitor all access to network resources and cardholder data”

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!