Guru: SIEM Is Only Part Of IBM i Cybersecurity
March 28, 2022 Bruce Bading
Many times, we hear from IBM i business owners that their SIEM – that’s short for Security Information and Event Management – is their cybersecurity solution for the IBM i. But that can’t be true, and I want to explain why it is part of the security shield but certainly not all of it.
Let’s start with SIEMs and how they fit into cybersecurity frameworks. SIEM is mentioned in the PCI appendix, but not once in the core of the 250+ PCI DSS requirements, likewise, the NIST Cybersecurity Framework lists event monitoring as one of the 100s (1/100s) of NIST core requirements as do virtually all frameworks. Thus, SIEMs are only a fraction of any cybersecurity framework (PCI, SOX, HIPAA, NIST, etc).
IBM monitors 150 billion events per day for clients worldwide to develop its Threat Intelligence Index. That’s 150,000,000,000 per day, everyone. To put that into context, that’s roughly the number of stars in our local Milky Way galaxy. All of this aggregate log data is leading to what we cybersecurity experts term: “Alert Fatigue.”
Speaking of context, we all agree that to identify threats, we must correlate vulnerability data with real risks to make all that log data mean something tangible. And one way to lessen the noise is to lessen the number of vulnerabilities and threats. Threats exploit vulnerabilities and lead to financial and reputational risks. Putting it another way, without proper threat context, event attribution is difficult or impossible at best.
Simply ask a SIEM analyst what normal behavior is so that they can identify IBM i threats and they will most likely tell you they have no context of what constitutes a threat in the IBM i logs. And further, you may not even be logging all the right data. To make the point, I would offer that if you knew what constituted the proper use of many elevated privileges and vulnerabilities on the IBM i, we would already be remediating these privileges and vulnerabilities. Yes, that is right, there can be vulnerabilities and threats on your IBM i platform. The IBM i is one of the most securable systems, but if your developers are not trained and practicing secure coding, your systems may not be as secure as you think.
One of the many vulnerabilities we often detect is DDM/DRDA set to *USRID where it should be remediated to a secure value of *ENCUSRWD, but we always find that no one can tell us why it was changed from the shipped value *USRIDPWD. Same for *PUBLIC and privately authorized profiles, special authorities, default passwords, access control classifications, adopted authority, systems values, and so forth. No one would know how to put all that into context without expert analysis from an SME like us at BFB Security and thus, we are just creating the aforementioned cybersecurity landfill to alert fatigued SIEM and staff.
Now back to cybersecurity frameworks. The IBM i is no more exempted from these frameworks than a Ferrari is exempted from traffic laws. Just as these supercars need to comply with laws, the IBM i needs to comply with cybersecurity frameworks. SIEMS and/or monitoring solutions are of course a fraction of the requirements of all frameworks as we mentioned above and an integral cog in your cybersecurity, but these frameworks contain hundreds of aforementioned standards each, not just event monitoring.
We also know the meaning of the phrase “why monitor a problem if you don’t fix it.” Lastly, why does Splunk, one of the world’s top event monitoring systems, tell us that zero trust and risk management is needed to stop data breaches. You would think that Splunk would just advertise their tool as a complete solution to cybersecurity and quit telling us about all the vulnerabilities, threats, risk, zero trust, and so much more. Maybe Splunk knows something. You think?
I will leave you with this, a real-world penetration test after an IBM i vulnerability assessment brought us to pen-testing the creation of a security officer (*SECOFR) class profile on a development system through DDM/DRDA without a password (*USRID). It worked and a *SECOFR profile was created. When asked if the SIEM analysts had detected the test, they just shrugged and asked what we were looking for. A week later, the business called up and stated that the SIEM analysts never alerted them, so that began another large IBM i enterprise risk management project.
I will repeat: Don’t create a cybersecurity landfill. Cybersecurity is people, process, and technology and a SIEM without proper context is just one pillar of cybersecurity that will topple without the other two pillars. And lastly, as we all know, cybersecurity is never one and done.
Bruce Bading is a senior security consultant with more than forty years of information security experience and twenty-five years of corporate c-suite experience. He is an expert on IBM i security and has helped some of IBM’s largest clients meet their security and compliance requirements in today’s complex technology and business environments. Bruce has exceptional communications skills, has worked with diverse audiences at all business levels to provide training and education and has led dozens of large enterprise risk management projects for the world’s largest organizations. He is a member of the Information Systems Audit and Control Association, a CIS benchmark author, and professional threat hunter.
Editor’s Note: Bruce is one of a number of new Guru experts that we are working with to keep the Guru column going within The Four Hundred. We look forward to the coming in-depth security coverage that Bruce can give as you work to secure your IBM i platforms in these interesting times.
RELATED STORY
Guru: Would You Rather See a Fire Marshal or a Fire Fighter?
