Townsend Security Data Privacy Blog

Most IBM i customers struggle to provide more IT services to their organizations with an ever-shrinking set of budget and human resources. It is natural, then, that IBM i customers would look to a variety of automation and management tools to buttress their existing IT service infrastructure. IT Service Management (ITSM) tools are a great place to start.

The clear leader in ITSM is ServiceNow. ServiceNow is the Gartner Magic Quadrant leader in ITSM with more than double the market share of its closest competitor. It is easy to see why - building on its IT Service Support Management (ITSSM) tools ServiceNow has had a singular focus on the IT service management space for some time. It has a well-designed interface that makes integration with other platforms easy, and it deploys as a web-based SaaS solution. It is easy to start with Incident management and add a wide set of automation and service features. You can find a good overview here.

Here at Townsend Security we have been looking at ways of making life easier for our IBM i customers and especially IT management and Security Administrator professionals. Integrating ServiceNow with our Alliance LogAgent solution was a natural step. With a handful of customers cheering us on, we committed to ServiceNow integration and providing an open path for ServiceNow integration outside of our SIEM integration product. Our first steps focused on some critical IT and security areas.

Administrative User Access

Security professionals understand how critical it is to control and monitor administrative access to the core business systems. Administrative user access to an IBM i server should be rare and well-controlled. Cyber-criminals attempt to gain administrative privileges in order to steal sensitive data or cause havoc. Monitoring administrative user access to your IBM i is now a critical security requirement.

Alliance LogAgent can now automatically and in real time create a ServiceNow incident when a highly privileged administrator logs onto your IBM i server. This notification to ServiceNow leverages our earlier enhancements that dynamically identify a high level of privilege including those privileges inherited from Group and Supplemental profiles. Your IT security team can react quickly to unexpected administrator access. Of course, fully reporting to your SIEM solution is included.

Disabled User Profiles

IBM i users have implemented strong password controls to strengthen system security. Unfortunately this means more IT support for users who forget their password and disable their user profile. Wouldn’t it be great to get a real-time notification when a user profile is disabled? You can now do that with Alliance LogAgent. A disabled user profile will generate a ServiceNow incident record and your IT support team can pro-actively reach out to help your user. An additional security benefit is that you can detect automated attacks on your IBM i servers that result in a number of disabled user profiles.

Library and IFS Object Changes

Attackers often attempt to modify applications and configuration files as a part of an attempted breach of your system. This might include access to application configuration files and programs in a library, or it might be an attempt to modify a web configuration file in the IFS file system. Alliance LogAgent now allows you to selectively report these object and file changes to ServiceNow in real time.

ServiceNow User and Application Integration

I’m leaving the best for last! In addition to the automatic events that Alliance LogAgent raises as a ServiceNow incident, there is also a new command that lets you integrate ServiceNow into any application on your IBM i server. The new Create ServiceNow Incident (CRTSVNINC) command gives you the ability to create ServiceNow incidents from your own applications.

Is an ACH payment over the usual limit being initiated?

Log it to ServiceNow.

Is a mortgage loan being originated that violates bank policy?

Log it to ServiceNow.

Has a credit card transaction been refused due to fraud?

Log it to ServiceNow!!!

I’m sure you get the idea. Automating these types of events are now fully under your control.

If you already have a SIEM integration tool or notification system, don’t despair.Alliance LogAgent can co-exist with existing tools from third-party vendors. And you can use the new ServiceNow integration command without using the SIEM and system logging components of Alliance LogAgent. Of course, if you want to upgrade to a more advanced tool you should contact us. There’s a great competitive upgrade plan waiting for you.

The IBM i server is a great platform and we are fully committed to providing leading-edge enhancements to our IBM i solutions. You will be hearing more from us about new innovations for the IBM i in the days and weeks ahead.

Patrick

Alliance LogAgent for IBM i now instantly records critical system events and integrates line-of-business applications with ServiceNow, the leading cloud-based solution for IT systems to instantly record critical system events.

Townsend Security today announced support for integration of IBM i servers and applications with ServiceNow, the leading cloud-based solution for IT system support problem tracking and resolution. Leveraging the ServiceNow REST web interface, Townsend Security’s Alliance LogAgent solution can now instantly record critical system events as ServiceNow Incident reports. Additionally, Alliance LogAgent also exposes an API command to allow IBM i customers the ability to integrate line-of-business applications with ServiceNow. When business applications encounter critical events or errors, these can be immediately visible to the IT administrative and security teams for rapid response and resolution.

“IBM i customers want to leverage the best of the new generation cloud-based service offerings. This new release of Alliance LogAgent gives them that ability right out of the box. Existing ServiceNow customers have all they need to record critical incidents in real time. IBM i users who are not currently ServiceNow customers can rapidly subscribe to ServiceNow and start enjoying the benefits of this leading IT Systems Service Management (ITSSM) solution,” said Patrick Townsend, CEO of Townsend Security.

“The power and stability of the IBM i system can integrate with the best of the cloud-based ITSSM solutions. It’s an easy win for IBM i customers, and those with existing system logging solutions will be happy to know that Alliance LogAgent can co-exist with existing technology, or IBM i customers can take advantage of our competitive upgrade program,” continued Townsend.

New ServiceNow features in Alliance LogAgent include:

Privileged User Access
Monitoring administrative access to IBM i servers is a critical compliance and security best practice. Alliance LogAgent can identify in real-time the privilege level of a user signing on to the system and report it to ServiceNow and to any SIEM solution. Alliance LogAgent is unique in its ability to dynamically identify the true privilege level of a user by examining the native authority of the user as well as authorities inherited from Group and Supplemental profiles. Cyber criminals often use privilege escalation as a starting point in an attack. Alliance LogAgent can now identify privileged user logons and raise a ServiceNow support incident.

User Profile Disabled
A common labor-intensive task for IT administrators is managing user accounts that are disabled due to an excessive number of password failures, or which are disabled due to a brute force attack. Alliance LogAgent will now automatically identify disabled user profiles in real-time and create a ServiceNow incident report. This gives the IBM system and security administrator rapid visibility and resolution for disabled profiles. Additional system security is provided by an out-of-band notification via ServiceNow of a potential attack in progress.

File or Object Change
An attacker often modifies a program or file on the IBM i server as a part of compromising sensitive data. For example, an attacker might modify the IBM i web server configuration file to direct users to malware on infected sites. IBM i customers can now identify both library and IFS objects for monitoring by Alliance LogAgent with reporting directly to ServiceNow. Early detection of modified programs and files can help an IBM i customer avoid a data breach.

Application Integration with ServiceNow
IBM i developers can now easily integrate business applications and processes with ServiceNow through a new command named Create ServiceNow Incident (CRTSVNINC). By embedding this command into user applications the IBM i developer can provide a wide set of incident creation capabilities. This new command builds on the ServiceNow REST interface without requiring complex communications or API logic in the business application. Using the ServiceNow command does not require the SIEM integration components of Alliance LogAgent. IBM i customers can use just the ServiceNow integration component, or combine its use with Alliance LogAgent SIEM integration.

Alliance LogAgent is licensed on a Logical Partition (LPAR) basis. Both perpetual and subscription licenses are available. Volume discounts are available. Additional charges apply to the ServiceNow application. Alliance LogAgent can be downloaded from the Townsend Security website for a free 30-day trial of the fully functional solution. ServiceNow integration requires a subscription license from ServiceNow. Trial subscriptions are available from their website at http://servicenow.com.

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.

If you are an IBM i security administrator you know how hard it can be to determine a user’s true level of privilege on your system. IBM has given us a very flexible scheme to grant and restrict privileges to groups of users. And this flexibility can lead to unexpected security exposures. Let’s delve into this a bit deeper with an example (names are made up for this example):

JANICE
Janice is regional manager in the sales team. She’s exceptionally effective at her job and has taken on a number of tasks that help her support her team and the sales goals of her region. Let’s take a look at her user profile:

At first glance it would seem that Janice has a normal user level of special authorities. In fact the only special authority is spool file control (*SPLCTL) which would be reasonable for a manager who needs to run and print reports. It also seems appropriate that Janice has a Group Profile of SALES. You would imagine that this probably gives her the ability to access the company sales management application.

The first hint of concern is the long list of supplemental groups. If you’ve met effective managers like Janice it won’t surprise you that they have access to a number of applications. She probably has responsibility for approving time off for her department’s employees, and has responsibilities for reporting to management. But what privileges are hidden in that Group Profile and in those Supplemental Groups?

Let’s take a look. 

SALES (Group profile)
When we display the SALES user profile we find these special authorities: 

Janice already had authority to spool files, but notice the job control value of *JOBCTL. This means that Janice has now inherited additional authority to manage jobs. This is not a severe uplift in privileges, but it shows how privilege escalation works.

Now, what about those supplemental groups? Do we have to look at every one?

Yes we do. Let’s look at the HRUSER profile next

HRUSER (Supplemental Group)
When we display the HRUSER user profile we see these authorities: 

Wow, the HRUSER has the special authority of security administration (*SECADM). That’s a bit worrying. If we had to guess there is probably third party HR package requirement for this, or this authority was just granted out of convenience. But now Janice has much more authority. 

Let’s continue our exploration of those supplemental group profiles:

PAYROLL (Supplemental Group)
Let’s take a look at the PAYROLL user profile:

Whoops, the PAYROLL user has All Object authority (*ALLOBJ). Bingo! This is the mother load of privilege. A user with All Object authority basically has the keys to the kingdom. It is pretty much equivalent to being the QSECOFR security officer (“root” for you Linux nerds). Once you have All Object authority you can manage other user profiles, grant yourself additional authority, and basically access any data on the IBM i server. 

If I am an attacker and I can steal Janice’s credentials for the IBM i server I now have all of the authority I need to infiltrate sensitive data.

Did you notice how much work it was to track down Janice’s true privilege level? As an IBM i security administrator you probably know how to fix this problem. You need to analyze the real need for the All Object authority and revoke it. But imagine that you managed a system with hundreds or thousands of users. And imagine if you needed to check this at least monthly in order to detect any changes since the last time you inspected your users? It would truly be impossible to keep up with this task, and as the security administrator you might have other things you need to do, right?

So, is there any hope?

 Sure there is. Our Alliance LogAgent solution will do this work for you. You can run the User Authorization report and Alliance LogAgent will track down these authorities for you. It will tell you the overall inherited authority of any (or all) users, and where they are getting the authority. Here is an example of the output for Janice:

Notice that all of Janice’s cumulative authorities are listed right on the top line of the report detail. Then notice that the Group Profile and all Supplemental Group profiles are listed with their authorities. The PAYROLL user is clearly identified as having the All Object authority. Now you can go to work. 

The Alliance LogAgent report can be executed for all users, or for a group of users. And you can filter it so that you first get a list of all users who have inherited All Object authority. Then run it with additional authorities. In a few seconds you can find your privileged users, discover where they get that authority, and create a work plan to fix the problems.

However, Alliance LogAgent goes even further. As it is processing events from the security journal QAUDJRN, it can resolve in real time the true privilege of each user signing on to the IBM i server, tag job start events where the user has elevated privileges, and send them to your SIEM for monitoring. In real time.

I think that’s pretty powerful, don’t you?

Patrick

We have a lot of Enterprise customers deploying our Alliance LogAgent solution for the IBM i server to send security events to Splunk. On occasion a customer will deploy Alliance LogAgent and send data in the Log Event Extended Format (LEEF) to Splunk. The LEEF format is the preferred log data format for the IBM Security QRadar SIEM, so I’ve always found this a bit puzzling.

The light finally came on for me this week.

Security event information in syslog format (see RFC 3164) is largely unstructured data. And unstructured data is hard for SIEM solutions to understand. Here is an example from an Apache web server log:

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

An SIEM administrator would have to do a fair amount of work configuring the SIEM to properly understand the importance of this message and take the proper action. If only the data was in some type of normalized format!

It turns out that the IBM Security QRadar LEEF format normalizes the system log information. A message like the above might look something like this in LEEF format:

date=20001011 time=143252 ipAddress=127.0.0.1 violation=client denied severity=5 path=/export/home/live/ap/htdocs/test

With field definitions like “date” and “time” the Splunk SIEM can easily digest the message and the Splunk query tools work great. It is easy to create reports and dashboards with this type of normalized data. The LEEF format is really good about this and Alliance LogAgent supports the LEEF definition.

What most Splunk administrators do not realize is that our Alliance LogAgent solution normalizes all IBM i security events in this type of normalized fashion. That is, this format is the default data format for security events. This is already what Alliance LogAgent does for IBM i security events!

When we started the development of Alliance LogAgent more than 10 years ago we understood at the outset that system log data would be hard for a SIEM to parse. So from the first release of our solution we provided data in this normalized format. Whether you are using Splunk, LogRhythm, Alert Logic, or any other SIEM we make it really easy for the SIEM to digest and act on the information. And forensic, query, and dashboards are easy to create.

So, Splunk users - listen up! The default system log format in Alliance LogAgent is exactly what you need to make Splunk work really well. You can use the LEEF format if you really want to, but you have all of the benefits of normalized data with the default format.

Here at Townsend Security we are vendor neutral when it comes to SIEM solutions. Our customers deploy a wide range of solutions including Splunk, IBM QRadar, LogRhythm, Alert Logic, SolarWinds, McAfee, and lots more. And they can move from one SIEM to another without changing their Alliance LogAgent configurations. We believe that actively monitoring system logs in real time is one of the most important security steps you can take. Early detection of a problem is so much better than trying to remediate a breach after the fact.

Patrick

Active monitoring is one of the most effective security controls an enterprise can deploy. In fact, a large majority of security breaches occur on systems that have been compromised days, weeks, or even months before sensitive data is lost. A recent Verizon Data Breach Investigations Report indicates that a full 84 percent of all breaches were detected in system logs.  By actively collecting security logs in real-time, organizations can not only monitor security events, but also prevent a data breach before it starts.  I recently sat down with Patrick Townsend, to discuss log collection and active monitoring on the IBM i.

Hi Patrick, can you give our readers an overview on the importance of collecting and monitoring security logs on the IBM i?

One of the most effective things that you can do to prevent a data breach is to deploy an active monitoring solution, sometimes also known as system logging.  You’ll find active monitoring at the top of all cyber-security lists of things to do – because it is effective.  Active monitoring is key to a strong security posture, for anybody.

Today, we all know that there is no longer a true perimeter and that our systems are at risk.  Luckily, active monitoring can help.  Here are some key principles that organizations need to understand.  First, an active monitoring solution needs to involve a log collection server or SIEM solution (IBM Security QRadar, Splunk, LogRythm, etc.) to collect security events across the entire enterprise and actively detect threats.  Second, there needs to be real-time collection and monitoring of security events.  Rather than scooping up the security events once or twice a day, it is imperative to be collecting these events in real-time. When you collect logs across the entire enterprise, a SIEM can provide a lot of intelligence to identify patterns and anomalies – which will identify a potential attack.  The final critical components are good reporting, query, and forensics tools.  SIEM solutions also give you the ability to quickly run reports and analyze suspect data.  This is important for two reasons.  If you are having an attack you need to identify quickly where the attack is originating and how it is happening.  This is essential in order to know how to remediate it.  If you aren’t able to pinpoint the problem, it is very likely that you are going to be attacked by the same methods again.

Switching gears, the serious points for an IBM i customer revolve around the fact that the IBM i is a critical back-office processor for most customers and runs multiple applications.  Too often the IBM i is an island within an organization, but it is important that it is fully integrated in your enterprise’s entire infrastructure security strategy.

Also, it is generally true that a cyber-attack almost never starts on an IBM i server.  They typically start on a compromised user PC or someplace in the organization.  From there, a hacker spends a fair amount of time probing around the IBM i finding any weak points.  We shouldn’t be naïve – hackers know about IBM i servers.  They know what to look for, they know the user IDs, they know how to compromise these systems – they are very good at it.

IBM introduced some new security event sources in V7R3.  Can you talk a bit about those? And what events should an IBM i customer be collecting?

Every release of the IBM i server has had new security events and fields to collect and monitor.  At Townsend Security we work very hard to stay ahead of these releases so that our customers are well positioned to handle new information and use it for protection.  A couple examples include IPV6 address support and new fields in existing events.  Regarding the recent V7R3 release, new sources include:

• QAUDLVL (Auditing level) system value
• *NETSECURE (to audit secure network connections)
• *NETTELSVR (to audit Telnet connections)
• *NETUDP (to audit UDP connections)
  

To address the second part of your question, when you deploy an active monitoring solution on the IBM i, you are certainly going to want to collect events from QAUDJRN, QHST, QSYSOPR, as well as exit points.  Interestingly, the QAUDJRN security audit journal does not exist when you first install a new IBM i server. You must create the journal receivers and the journal to start the process of security event collection.

Aside from the new log sources that IBM introduced in V7R3, for someone who maybe deployed a logging solution a few years ago, what should they be aware of now?

First, let’s take a look at how compliance regulations have been evolving.  We now know that most attacks work on the basis of privilege escalation.  For example, an attacker gets access to our systems and then eventually gets sufficient authority to steal data. Because of this, we are seeing that it is more important to identify when an administrative level or highly privileged user logs in to our system.  This is an example of how a logging solution needs to evolve to meet current compliance requirements. Businesses are now required to log and monitor that activity.

Unfortunately, this can be particularly hard on the IBM i.  On first look, an IBM i account may appear to have normal user privileges, but may in fact inherit higher privileges through a Group Profile or Supplemental Group Profile. It is important to detect these elevated privileges in real time and provide the security administrator with an easy-to-use report to identify the source of elevated privileges. This is an excellent example of how logging solutions need to evolve with the ways security events are monitored.  We recently tackled this in the latest release of our Alliance LogAgent.

Where do you see the future of logging on the IBM i?

Let me dust off my crystal ball!  First off, File Integrity Monitoring (FIM) will become more important.  To maintain a strong posture, security administrators need to know who is accessing sensitive data and system values on the IBM i.  We’re also going to see more requirements around File Integrity Monitoring across the regulatory compliance environments.  Why?  Because, as we discussed earlier, cyber-attackers escalate privileges, access sensitive data, and change security configurations in order to get the work done that they want to do.  Again, this is why we are seeing increased requirements in regulations like the Payment Card Industry Data Security Standard (PCI DSS) and new financial services regulations.

Another interesting prediction:  It won’t be unheard of for organizations to use multiple SIEM solutions. We are starting to see businesses use one SIEM for traditional security monitoring and another to monitor operational data.  Operational data, you ask?  Sure.  Logging solutions can easily allow administrators to answer operational questions like: How full are my disks?  Do I have any critical hardware errors?  Second, they can benefit from deploying a SIEM to monitor application data.  Sales teams, for example, can track inventory status, trending products, etc.  The benefits of file monitoring don’t have to be exclusive to security.

In the near future, we will also see a pickup of integration with Artificial Intelligence (AI), also commonly referred to as cognitive computing.  IBM has the Watson platform, and there are others, which I believe will be used to enhance security.  We are already seeing initial efforts in this respect.  Harnessing that AI capability with security makes total sense.  

Finally, as we are seeing, everything not bolted down is going to the cloud.  We will definitely see an evolution of new cloud services around security and logging.  It may take a little time for vendors to start leveraging that, but I believe it is definitely in the works.

To hear this interview in it’s entirety, download our podcast “The Future of Security Logging on the IBM i” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss log collection and monitoring on the IBM i, new log sources in V7R3, and the future of security logging on the IBM i.

New features include full reporting of administrative users, including authority the user adopts through Group Profiles and Supplemental Group Profiles.

Townsend Security today announced a significant update to its existing Alliance LogAgent for IBM i (AS/400, iSeries) solution, allowing full reporting of administrative users, which includes authority the user adopts through Group Profiles and Supplemental Group Profiles. Alliance LogAgent is a Security Information and Event Management (SIEM) integration solution that collects, formats, and transmits security information in real-time to any SIEM or log collection server.

When the new configuration options are enabled, Alliance LogAgent will tag all significant security events as performed by the administrative level user. This enhancement will help security administrators easily identify which users have elevated privileges and enable SIEM solutions to quickly identify and alert on operations. In addition to the new administrative user reporting, Alliance LogAgent now provides an easy-to-use local assessment report that identifies privileged users. This will reduce the overhead of inspecting and adjusting privileges of IBM i users. 

Alliance LogAgent is compatible with all SIEM solutions that accept Syslog messages, IBM QRadar Log Event Extended Format (LEEF), or the HP ArcSight Common Event Format (CEF). The new administrative field reporting will make it easy for SIEM administrators to create dashboards, compliance reports, and alerts based on reported fields. When an administrator privileges are detected Alliance LogAgent adds the following field to the security message:

            admin_user=yes

For IBM QRadar the new field is:

            adminUser=yes

By providing a normalized field in the security events sent to the SIEM monitoring platform, the SIEM’s query and forensic tools can be used more effectively.

“Many IBM i customers have struggled with identifying who on their system has elevated privileges. It is crucial to identify and strictly control these users as cyber criminals often use privilege escalation to enable the exfiltration of sensitive data,” said Patrick Townsend, CEO of Townsend Security. “On first look an IBM i account may appear to have normal user privileges, but may in fact inherit higher privileges through a Group Profile or Supplemental Group Profile. Alliance LogAgent now detects these elevated privileges in real time, and provides the security administrator with an easy-to-use report to identify the source of elevated privileges. We think this is a crucial enhancement that will help IBM i customers better secure their platforms.”

Alliance LogAgent is in use with a wide variety of SIEM solutions including LogRhythm, SecureWorks, NTT Solutionary, IBM QRadar, Alert Logic, AlienVault, McAfee SIEM, Splunk, SolarWinds, and many others. In addition to collecting the IBM i security audit journal information Alliance LogAgent collects system history messages, operator messages, exit point information, system statistics, and a variety of open source application logs in Unix/Linux format.

The solution is licensed on a per logical partition (LPAR) basis, with perpetual and subscription licensing options available. Existing Alliance LogAgent customers on a current maintenance contract can upgrade to the new version at no charge.

Excerpt from the eBook "IBM i Security: Event Logging & Active Monitoring - A Step By Step Guide."

   PRTUSRPRF TYPE(*AUTINFO)
   SPCAUT(*ALL)

   CHGUSRAUD USRPRF(QSECOFR)
   OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD
   *PGMADP *NETCMN *PGMFAIL)

   CHGOBJAUD OBJ(PRODLIB/ORD001)
   OBJTYPE(*PGM) OBJAUD(*ALL)

   CHGAUD OBJ(‘/mydirectory’)
   OBJAUD(*ALL) SUBTREE(*ALL)
   SYMLNK(*YES)