As we discussed in the blog Understanding System Logging on the IBM i – Part 1, 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! Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE). After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.
Here is a recap of that Q&A session:
Q: Can you pick which group of users to audit?
Patrick: In our current version of Alliance LogAgent, our IBM i system logging solution, you can define a list of “excluded users.” So you can actually tailor events on the IBM i platform and exclude particular user profiles. We also provide some basic filtering capability allowing you to filter based on IBM event type and on User event type. So yes, there is a fair amount of filtering capability in the product. From a security posture, it would be a mistake to filter out significant security events, however the solution allows you to easily choose and select the events you want. We have an option that maps straight to the security system values so you can easily set LogAgent to process those or you can establish and select any and all of the event types in the product that you want to monitor.
Q: With all the different IBM system events, is it possible to set up filtering of just the IBM security event types?
Patrick: Yes, In our solution, collection of the system security events is set as the default “out of the box” setting. You have total control over the events you collect, and with just a few keystrokes, you can re-map your collection and filter in additional events, or leave it set to what IBM identifies as the security type events being collected in QAUDJRN.
Q: Can File Integrity Monitoring (FIM) also monitor read access to a database file? What about a user that comes in from another server doing just a select in SQL?
Patrick: The File Integrity Monitoring component in LogAgent is based on a database journal. A record-level read event is not collected in a database journal; but a file open and closed event is collected. So if a user does access a file through read and there’s no update, insert, or add type of event, it may not appear in the journal. We capture all the information that the system makes available to us in the file integrity monitoring component on significant changes or access to any protected file.
Q: You mentioned File Integrity Monitoring. Can you further explain how an organization would use it?
Patrick: File Integrity Monitoring is designed to monitor configuration changes and highlight them for early detection. Generally, when an attack happens on an application it often involves changes to configuration files in an attempt to escalate privileges and give the attacker more authority or access than they should have. For example if a new user is suddenly granted authority in the HR application to print checks, that is an important indicator of a potential problem! Another common use for File Integrity Monitoring is to monitor the use of stored sensitive information (credit card information or social security numbers) on your IBM i platform, you would want to use FIM on those databases or applications in order to strengthen your security stance and identify those potential attacks early on.
Q: How do you keep QAUDJRN entries from flooding the network?
Patrick: With the large volume of events that can be collected by QAUDJRN, you can really help minimize network impacts by filtering out events that are not security related. You can still collect those events, but exclude them from being transmitted to your SEIM console. Because LogAgent works in real time it helps reduce the impact on your network because you are not transmitting millions of events all at once. We also provide metering capabilities so you can reduce the number of events per second that are being transmitted.
Q: How do these logs get stored?
Patrick: When it comes to log storage, you want them off of your IBM i platform as quickly as possible to avoid potential tampering or corruption. With LogAgent, we do not make a copy of the events, we take the filtered events out of QAUDJRN in real time, format and transfer them to your log collection server or SEIM. Since some compliance regulations require the events are stored for a defined period of time, SEIM consoles compress, store, and protect those log events so you have the ability to do forensics, queries, and reporting on them.
To learn more, view our webinar "Understanding Log Management on the IBM i" which examines the security principles, compliance requirements, and technical challenges for log collection and forwarding on the IBM i platform with the following learning objectives:
- Security principles of log collection and monitoring
- Compliance requirements of PCI DSS, HIPAA/HITECH, SOX, GLBA/FFIEC
- Communicating with log collection and SIEM servers
- File Integrity Monitoring and log collection
- IBM i log collection challenges
