Security changes often, but old excuses don’t.

By Steve Pitcher

I had a great conversation with one of our salespeople a few weeks ago about the challenges of selling the value of IBM i security services.

Me: “Do you have ADT home security at your house?”

Salesperson: “No.”

Me: “Why not?”

Salesperson: “I’ve never had someone break into my house.”

Me: “That’s why it’s a challenge to sell computer security solutions.”

You can tell people about poor object authority, excess special authorities, and a lack of encryption until the cows come home. Some won’t think they have a problem because it’s difficult to prove they’ve never had a security breach. You can certainly prove if you’ve had one, especially if controls are in place to capture evidence. You can’t really prove a breach never happened unless you’re watching for a specific one. It’s like the philosophical argument of using the evidence of absence for proving a negative. How can you prove there’s no car in your living room? Well, you’re watching the living room. You can take a picture of the living room. You can walk around the living room and touch everywhere a car isn’t. You can have an impartial third party take inventory of the contents of the living room. You can prove without a shadow of a doubt that there’s no car in the living room.

Security is no different. If you’re auditing your systems, reviewing audit logs (ideally via an impartial third party), locking down exit points and special authorities, fortifying your object security, and the like, you can prove that some things did not occur based on the evidence of absence. If you’re ensuring Telnet clients are hitting your system by turning off port 23 and forcing encrypted connections via port 992, you can prove there’s nobody passing unencrypted data (including user IDs and passwords) via port 23.

Let’s consider a breach in context. Would a user with bare-bones authority downloading poorly secured data they shouldn’t have access to in the first place be considered a breach? Certainly. But they haven’t broken any rules other than ethical ones.

With that foray into philosophy, I want to share with you some of the fallacies we commonly hear about IBM i security. These fallacies have been around a long time.

IBM i Is the Most Secure Platform in the World

No. It is not. Not out of the box at least. And definitely not if you’ve run IBM i since 1988 and haven’t modernized your security thinking with the times. So much has changed since the advent of the AS/400. Simply changing from twinaxial networking to TCP/IP offered a drastic change in how all data is transmitted to and from your IBM i partitions. I would argue that most IBM i customers do not allow for encrypting their TCP/IP communications from client to server. Of those who do, only a fraction force encryption rather than make it optional. Check every HelpSystems security survey since forever. They don’t even ask about encryption, probably because they’re still drilling home the basics for shops that have 25 percent of users running *ALLOBJ authority. It’s scary.

Hackers Don’t Know IBM i

I used this John Lennon quote in another article on DB2 modernization a few months ago. “I'm an artist, and if you give me a tuba, I'll bring you something out of it.” I don’t know COBOL, but if you give me a compiler, I’ll bring you something out of it. Don’t assume that because IBM i is a niche operating system (mostly manufacturing and financial industries) people can’t learn quickly that there are default user accounts that can be figured out pretty quickly. And some of those might just have default passwords. Don’t forget that someone isn’t banging on the door with user profile root. Someone’s using QSECOFR, QSYSOPR or any of the 70+ potential IBM i profiles on your system. More than 70? You bet. See the list below.

Now add your user profiles on top of that. If I know Jim Miller works in your company’s finance department and lives in Anytown, Anystate, USA, then I can find a whole lot of information by way of social engineering. I can find his wife’s name, kids’ names, dogs’ names, birthdate, what books and movies he likes…all from social media. So, yeah, hackers don’t know IBM i. And they don’t need to.

We’re Too Small, Nobody Would Attack Us

Fifty-five percent of small businesses had a security breach in 2016. Sixty-one percent had a breach in 2017. SMBs are the target du jour, and it’s only going to get worse because customers are banking on this fallacy being true. It’s not.

Small shops also have an issue because they have limited budget dollars to spend on security. They likely have a very small staff to implement and monitor security properly as well. Burying heads in the sand won’t save us.

Nobody Wants Our Data

Well, you want your data. All data has value. If your data is important to you, it has tremendous value to someone who wants to hold your data hostage and make you pay for it. The value to someone else isn’t in the data. The real value is that the data is valued by you.

If We Add Security, We’ll “Break Stuff”

Truth be told, this is not really a fallacy. It’s just a pathetic argument. If you implement security properly and test it accordingly, the chances of breaking things will be minimal. It’s all in the time, effort, and planning that goes into any project. The corollary argument would be that if you don’t add security, someone else is going to break stuff worse when you’re not prepared for the fallout.

We Trust Our Employees

I worked for a guy back in my early career who was adamant that we not implement proper security because malicious behavior was an ethical issue and therefore a Human Resources problem. He said what now? Yep. He was able to sell that fact to senior management along with a handful of magic beans and the Brooklyn Bridge. His point was that if the company didn’t trust the employees, then they couldn’t be an open and honest business. That’s valid, but the degree of trust is highly subjective. When do we stop trusting people? When we get burned by that trust. So regardless of whether you trust your employees, implementing proper controls ensures that they don’t have the opportunity to burn you, either maliciously or by mistake.

Myths Debunked

Clearly, all of these excuses are a lot of nonsense. Do the right thing: Keep your company’s IBM i secure.

Steve Pitcher works with iTech Solutions, an IBM Premier Business Partner. He is a specialist in IBM i and IBM Power Systems solutions since 2001. Feel free to contact him directly This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility