I have some, you have some — we all have some holes in our knows. As security professionals, we are often reluctant to admit it. The Dunning-Kruger effect states that the less you know about a subject, the more you are unaware of your lack of knowledge. But by the time we gain expert security knowledge, we are more aware of the unknowns.
Filling the Holes in Your Knows
In 2015, security expert Bart Kulach decided it was high time to show the world that nothing, not even the IBM i operating system, is totally secured. His presentation at a major security conference showed that the system has security flaws just like any other. Let me be clear: I am not suggesting and inferring that there are any reasons that IBM i is not a highly rated system or am I unjustly attacking one of my company’s divisions. I am only stating the research.
To mainstream client server teams, IBM i is not dead. Based on implementation, it poses security threats just like any other system in your network. Security is there, but it’s up to you to use it. Not only is the mainframe not dead, it uses some of the same attack vectors and all the same attack mythologies: weakest link, privileged escalation, enumeration, exploiting known and weak ciphers in third-party applications, etc. If you don’t believe me, come to DEF CON.
When security is implemented per best practices, the attack surfaces are reduced. To Kulach’s point, security best practices were not followed on the system test he performed.
Digging Out of Trouble
What does the above anecdote have to do with security intelligence? Quite a bit. What does it have to do with the holes in our knows? Even more.
For starters, don’t create privileged user accounts without monitoring. Use those accounts only as they are needed, not all the time. If you’re not watching when those accounts are being used, you have holes in your knows. IT managers must know what operating systems, patch levels, communication strings and applications are being used on the network. They also need to monitor xFLOWS, traffic statistics, user logins and linear connection streams.
It’s important to be wary of undiscovered threats or issues stemming from another compromised system that already has trusted access. This, too, represents holes in your knows. Designers, in efforts to impress with flashy features, often produce half-baked programming parameters that fail to meet the needs of IT professionals in the field. I have more than enough data across multiple platforms to prove my point.
Carve Out Your Niche Systems
IT managers often find an issue and then use it to prove a point. This is backward. If you discover a vulnerability, you must collect evidence to support your findings, which is what Kulach did. That’s why it’s important to have tools in place to help with this burden.
Niche systems are great for finding needles in haystacks, but not to eliminate false positives. You can create more holes in your knows by bypassing intelligence systems for niche tools and failing to program them to alert you of anomalous activity. Instead, build it right and make the machine work for your particular needs.
When it comes to the IBM i or any other mainframe, be sure to monitor privileged accounts and tie that activity to auditable executions. In short, if you can’t see it on your network or identify the what, why, when and how of an incident, you have holes in your knows.
Read the white paper: Managing Security Risks and Vulnerabilities