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.
