Verizon’s “Data breach digest. Scenarios from the field.” document includes a description of a successful attack on a water utility running on an “AS/400” (a.k.a. IBM i.) It describes how a suspected Syrian “hacktivist” group broke into an IBM i system and attacked the Supervisory Control and Data Acquisition (SCADA) software.
Through this attack they were able manipulate the amount of chemicals used to treat the water. (You can download a copy here, but it requires your contact information.)
Surprised? I’m not.
I’ve been trying for years to get the IBM i community to understand that they can’t hide behind the claim that the “IBM i is the most secure system” available. And, frankly, not a whole lot of people are listening.
The truth is, the IBM i is NOT secure! It’s highly SECURABLE. There’s a huge difference.
Why the IBM i is NOT Secure
I’m not knocking the IBM i. As an IT security professional, it’s my favorite platform. But my hackles rise when I hear someone say “The IBM i is the most secure system” for these reasons:
- What you secure is the data on the system; not the system itself.
- Nothing is inherently secure.
The definition of “properly secured” is whether those who are specifically authorized to resources are able to access those resources and able to manipulate them only in ways consistent with your company’s security policies. There is no way a computer manufacturer can ship a system that correctly secures your data without any input from you and before you put any data on the system. So the claim that any system is the most secure system available is absurd on its face.
To further this line of reasoning, consider the idea of the world’s strongest padlock. Let’s say, for example, you use this padlock to lock the door of your shed. Does this make your shed the “best secured shed available?” Heck no! The only thing we know is that you are using the best padlock available. We don’t have enough information to know how well the contents of your shed are protected. Did you also install a window, for instance?
And notice that you aren’t trying to “protect the shed” per se; you are trying to protect the contents of the shed. The world’s strongest padlock is simply one of the tools you are using to accomplish this.
Let’s take the analogy a bit further. You don’t want to ever be in a position to not be able to get into your shed. You can’t risk not being able to find the key to the world’s strongest padlock. So, you pound a nail into the shed right next to the world’s strongest padlock and hang the key to aforementioned world’s strongest padlock on that nail.
Are the contents of the shed protected at the highest possible level that can be provided by any padlock available? No!
The moral of this analogy is that your data’s security depends entirely on how well you use the available tools to protect that data! Even if you’re using the strongest available tools, if you use them incorrectly, your data isn’t secured properly. If you have PUBLIC *CHANGE on sensitive data, it does not matter one bit whether you are using the strongest security tools possible.
So Why Do I Keep Hearing “The IBM i is the Most Secure System”
You might be asking yourself “What makes the IBM i a good choice for the security minded, then?”
I believe the answer to this question comes down to cost. Because of some of the cool built-in function and all of the optional security functions available from the system alone, it will cost you less to properly secure your information assets using an IBM i. They won’t be properly secured by default. But it will take you less time and fewer additional products to configure the security of your assets.
Even taking into account additional costs in terms of human resources assuming you don’t have internal security expertise — and, potentially, additional products — it should cost you less to implement and manage your security on IBM i than on any other commercially available platform.
Are Our Data Assets Secure?
So how do you know if you are providing the best possible security for your assets? First, you have to understand that there is no one single yardstick that everyone uses. In fact, each company has to define its own yardstick. The yardstick is your security policy. Your security policy explicitly defines what “properly secured” means for each of your information assets. If you can show that your system is configured to enforce your security policies then, by definition, your assets are properly secured.
The ”cost verses security” tradeoff decisions are supposed to made while defining security policies – not while configuring security on your system. Since organizational leadership is responsible for driving security policy definition and review, they are also responsible for making cost verses security tradeoffs. Administrators and developers should only be involved in how the system is to be configured (or applications to be architected) such that the defined security policies are accurately enforced on the system.
In the absence of explicit security policies, a security assessment can tell you the obvious flaws in your configuration. Remediating those obvious problems reduces your risk, but you have no way of understanding how much risk remains after remediation. Those assessments and the implementation of suggested remediation cannot result in your assets being properly protected because you have no way of measuring it.
Configure It and Done? No Way!
Now let’s assume you have well defined security policies and you configured your system the last time you upgraded to properly enforce those policies.
If you aren’t checking at least once a week to make sure that the system is still configured the way it was during the last upgrade, then you still have no idea whether your information assets are properly protected!
Does this sound like how your organization manages security? For the vast majority, I’m afraid it does.
How can your organization fix this?
- Start with security policies. As a CIO or director, it is your responsibility to get buy-in from the highest levels to define a security policy for your organization.
- Because it might take a while to get buy-in and to implement a security policy generation and review process, you can benefit from a security assessment up front. This doesn’t necessarily mean a formal audit, whether third-party or in-house. It could just mean finding an expert who at least understands all of the tools available to you and who can analyze your security configuration and identify alternatives that provide the same or better level of security without breaking existing processes or applications.
- Then it’s important to implement a tool that gathers the pertinent security configuration data, compares that to your intended configuration, and alerts you to anything that doesn’t match your intentions. Run this tool at least once a week and immediately address any anomalies you encounter. You might also consider using a service to do some or all of this for you.
Take Control of Your IBM i Security
No. The story of an IBM i-based water utility being successfully hacked doesn’t surprise me in the least. Too many IBM i customers have hidden behind the nonsensical notion that the IBM is the most secure platform for too long. I see it time and again.
They are the ones at risk of screwing up security on the “most secure” system in the world.
If you’re interested in understanding how to REALLY protect your assets, let us know! We can help you in a number of different ways depending on where your organization is on your security journey.
