Chances are, you're looking at that title and thinking it's just click bait. Of course, I'm not talking about your data. Right? Wrong.

I was at the COMMON User Group Fall Conference in Orlando earlier this month. I had debuted a session called Rapid Fire Admin, which was just a ridiculous 150 IBM i administration tips in 75 minutes. I actually did it with 15 seconds to spare!

In my session, I had a couple of tips in there about security, and based on some feedback I received, I decided to put together an article to pinpoint a few areas of concern that we all need to understand.

My apologies for interrupting the current "CAMSS in Conversation" series. However, with security being the overriding theme on each of Cloud, Analytics, Mobile, and Social aspects, it seems fitting to provide a real-life example of just how much we have a false sense of security about our systems.

First, I had a couple of slides highlighting a few items mentioned in the PowerTech 2015 State of IBM i Security study. The thing that struck me as most alarming was the percentage of user profiles with specific special authorities. This should scare the living hell out of you.

Given that the average system size in that study was about 1090 users, it should be quite a shock that special authorities are at a cavalier level. For instance, approximately 15 percent of user profiles have Spool Control (*SPLCTL) and approximately 20 percent have Job Control (*JOBCTL).

So what's wrong with *SPLCTL? Nothing of course, because no IBM i shop runs any form of payroll software or generates financial statements or employee checks, right? Users with *SPLCTL own your output. Make no mistake about it. If you've spooled the secret proprietary recipe full of secret ingredients to an output queue, then it's vulnerable. In fact, in my humble opinion, it's a breach given the fact that it could've been very easily compromised by 15 percent of your users and you'd never be the wiser.

*JOBCTL has pretty much the same capabilities but with a few added goodies. You can control jobs plus printers and spooled files. If an output queue is operator controlled *OPRCTL(YES), then someone with *JOBCTL has access to that queue, no matter how sensitive the data is. The great rub about *JOBCTL is the ability to start and stop subsystems and even the ability to power down a partition.

Think about that. Nearly 20 percent of users have the authority to power down a partition.

Now, I'm fully supportive of ensuring user profiles are secured. I'm also 110 percent behind most, if not all, the recommendations in the PowerTech study. I'm a big fan of password phrases instead of short passwords. We need to be using complex password rules and forcing changes. Every IBM i admin should download that study and have a good, hard look at their IBM i security.

Chances are, you've got user profiles with far more authority than they should have. What's the biggest reason we don't want to change those profiles? It usually goes like this: "I know Donald has essentially the same authority as QSECOFR. He's got all special authorities, but he's been here for 25 years. He'll be retiring soon, and if he wanted to cause any damage, he would have already. Changing his authority will just be a make-work project. Plus he runs all the payroll jobs and keeps an eye on the QSYSOPR queue for us. If we change his authority, we could break payroll!"

It's the don't rock the boat answer. It's also the bury our heads in the sand answer. First, the fear of breaking something should not be in our vocabularies as technology professionals. Second, would you rather Donald accidentally break payroll or even something worse when you're not looking and then tell you about it later when the crime scene is cold? No. The best thing we can do is to do a controlled experiment on profile authority reduction. This is a perfect guest partition test actually. We need to be breaking things (potentially, or course) and precisely when we're going to be watching the systems.

And about Donald? Donald will continue to work for another 10 years. He hasn't caused any damage yet…or at least none that you know about. His password is "judy," which happens to be his wife's name, and she works right next to him. How common is this? I'd argue it's far more common than we'd like to admit. Now just think about how easy it is for a layman to gain access to payroll.

You're only as secure as your weakest link.

No matter what you do to secure your system from the inside and no matter how complex you make your passwords, it won't make much difference if you're sending all your Telnet traffic unencrypted.

One of the big eye-openers for me was when I asked my session attendees to raise their hands if they encrypted their Telnet traffic. Out of a room of approximately 30 people, I saw two hands come up. And one of those doesn't count because he's Larry Bolhuis. You know Larry does admin right. So I'm only counting one out of 30. That means 97 percent of that room is sending data, including their user IDs and passwords, via plain text.

This is a major red flag.

Why are we not encrypting Telnet traffic? Maybe it's because you couldn't really sniff a twinaxial line 20 years ago. When we all converted to TCP/IP, we just didn't secure it from the start.

How bad is it? All we need is one curious person on our network with a copy of Wireshark, and anything on the network sent to and from an IBM i partition is fair game to sniff.

How easy is it to sniff data in plain text? Have a trusted security-minded person on your team download a copy of Wireshark and find out. You may be very surprised at what you pick up.

How easy is it to remedy? Incredibly. So much so that there isn't any reason not to do it.

This type of solution doesn't break things. It's very similar to securing any other service with SSL that's running on IBM i or any operating system. Would you create an online payment system over HTTP rather than use HTTPS? Or transmit B2B data in plain text via FTP instead of SSH? Of course not. If the data is confidential, then it's irresponsible to send it in a clear-text manner over the public Internet. We live in an age of data security and data integrity. Breaches cost money and a loss of trust. Considering most breaches come from within the organizational walls, then that's where we need to be starting.

IBM i is designed with security in mind. It's got the capabilities to be one of the most secure operating systems in existence. The problem is that many of us haven't changed and assume we're protected based on the way our technology used to behave. Our auditors come to the doors and ask generic security questions because many of them have no idea how IBM i security works. Then the auditor gets sent info about how secure the AS/400 was designed and is satisfied...based on 1988 information. I've seen that happen a few times in a few shops by reputable auditors. Again, they're not IBM i auditors. I've hired groups like SkyView Partners and PowerTech in the past, and the difference between them and financial auditing companies is that they understand IBM i from a modern perspective. I'd argue IBM i audits should happen in addition to standard financial and IT audits, or at least every few years to ensure things haven't run off the rails.

IBM i has changed with the times to ensure our risk is reduced, but it doesn't matter if we don't take advantage of those changes.

SSL-enable your Telnet. Please.