It can be difficult to identify IBM i users who have administrative privileges. This is because of the unique nature of IBM i user profiles. An IBM i user has an explicit level of privilege that is easy to determine, but that user can adopt additional privileges through a Group Profile and through any number of profiles defined in a Supplemental Group.
I recently sat down with Patrick Townsend, Founder and CEO, and discussed how to determine the true level of authority of a user profile, control and monitor administrative level users, and set email alerts to include critical job and security information.
Cyber criminals attempt to escalate their level of privilege by stealing and using administrative credentials. Because IBM i servers are accessed from user PCs across internal and external networks, credential stealing from these exposed PCs and networks is the preferred mechanism for compromising an IBM i server.
That’s right. An attacker will typically compromise a user’s PC and use that as a platform to attack an IBM i server. While it is possible to attack an IBM i directly, I think that is a pretty unusual case. Normally an attacker will try to determine who in your organization is likely to have elevated privileges and then, using standard attack vectors like phishing emails or poisoned web links, get access to that user’s PC. From that point, it is not difficult to piggyback on that user’s credentials into the IBM i platform – and that gives them access to data from the IBM i, especially if they have elevated privileges. On the IBM i server, we have a particularly difficult challenge in identifying exactly who has a lot of privilege. It is quite surprising how many regular users end up with a high level of privilege – and that is because of the hierarchy (Group Profile and Supplemental Groups) that can be related to a user profile on the IBM i platform. If any of those groups that the user is a member of has elevated privileges, so does that user.
To determine a user’s actual level of authority, an IBM i security administrator may have to research dozens of additional accounts. That sounds like a daunting task.
It is. IBM gives us some security commands to help print information about users, but unfortunately they don’t drill down and give you all the information that you need in one place. You need to use multiple commands and look specifically at a particular user – which becomes an administrative headache. Imaging multiplying that by hundreds or thousands of users on an IBM i server and you have got a major challenge in front of you. At Townsend Security, we are giving the IBM i administrator some new tools in Alliance LogAgent that make this job a whole lot easier. We will actually chase down those highly privileged users, resolving all of the adopted authorities that they have through group profiles and supplemental groups, and then alert system administrators when a highly authorized privileged user signs on to the IBM i server. Alerts are sent via email notifications or by special events to your SIEM. We think we have done a pretty good job of helping the IBM i administrator see and resolve problems with adopted authorities.
That is really cool. How does it work?
We look at a user profile or a selected subset of user profiles, and for each one we look at what authorities each one has. Do they have All Object authority? Do they have control over jobs or audit capabilities? What authorities do they have? Then, we drill down into the group profile and ask the same questions. What authorities are additive to the ones that you natively have? With this information, we start to build a matrix. If a user picks up authority with a group profile, we’ll tell you. We take the mystery out of where the level of privilege comes from. This makes it easier for an IBM i security administrator to say “Oh my goodness, I have a user profile here who has All Object authority. That shouldn’t be there!” and make it easier to reign in the number of highly authorized users.
Aside from reporting to a SIEM, there is an email-alerting component as well, right?
Yes. We send an email in real-time when a highly authorized user signs on to the IBM i server or starts a job (either interactive or batch). The notification contains information on the name of the user and job – enough information so that a security administrator can easily identify the system where the job is starting. This gives security administrators a real fast alerting process so that they can identify when a highly authorized user signs on to the system. That means that they can detect a brute force attack, somebody who has stolen credentials, or even when someone is signing on at an odd time. If you find yourself saying “Bill in the shipping department has a high level of authority and signed on at 2:00am, there might be a problem here” – you now have a way to see and react very quickly.
What else would you like to tell us about Alliance LogAgent, your log and event monitoring solution?
Alliance LogAgent is a very rich and mature system logging and notification solution and is designed to integrate with any SIEM (IBM Security QRadar, Splunk, LogRhythm, etc.). Additionally, we do File Integrity Monitoring (FIM) and can pick up changes to a database, even on a field by field basis. FIM is a part of PCI DSS, for example, and other compliance regulations. It really allows you to put a very detailed focus on the sensitive data sitting on the IBM i.
Additionally, the security audit journal is not the only place on the IBM i that collects important security information. We monitor many exit points on the IBM i (FTP, ODBC, etc.) and capture activity and send it to your SIEM. The communications are all built into Alliance LogAgent – syslog, UDP, TCP, and TLS encrypted sessions to move data in real-time off of the IBM i platform to your SIEM. The solution allows you to bring your IBM i fully into a continuous monitoring SIEM view of security events on the IBM i.
To hear this interview in it’s entirety, download our podcast “Identify Escalated Privilege Attacks on IBM i” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss determining the true level of authority of a user profile, controlling and monitoring administrative level users, and setting email alerts to include critical job and security information.
