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.
|
QADSM |
QIPP |
QRMTCAL |
QTMTWSG |
|
QAFOWN |
QLPAUTO |
QRJE |
QTMHHTTP |
|
QAFUSR |
QLPINSTALL |
QSECOFR |
QTMHHTP1 |
|
QAFDFTUSR |
QLWISVR |
QSNADS |
QTSTRQS |
|
QAUTPROF |
QMGTC |
QSOC |
QUSER |
|
QBRMS |
QMSF |
QSPL |
QWEBADMIN |
|
QCLUMGT |
QMQM |
QSPLJOB |
QWSERVICE |
|
QCLUSTER |
QNFSANON |
QSRV |
QYCMCIMOM |
|
QCOLSRV |
QNETSPLF |
QSRVAGT |
QYPSJSVR |
|
QDBSHR |
QNTP |
QSRVBAS |
QYPUOWN |
|
QDBSHRDO |
QPGMR |
QSVCCS |
|
|
QDFTOWN |
QPEX |
QSVCM |
|
|
QDIRSRV |
QPM400 |
QSVSM |
|
|
QDLFM |
QRDARSADM |
QSVSMSS |
|
|
QDOC |
QRDAR |
QSYS |
|
|
QDSNX |
QRDARS4001 |
QSYSOPR |
|
|
QEJBSVR |
QRDARS4002 |
QTCM |
|
|
QEJB |
QRDARS4003 |
QTCP |
|
|
QFNC |
QRDARS4004 |
QTFTP |
|
|
QGATE |
QRDARS4005 |
QTMPLPD |
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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online