Your IBM i users are human—and prone to putting sensitive information at risk.
Information will always be at risk, thanks to human failings like greed and incompetence. As guardians of our enterprise data, it's our responsibility to deploy controls and enforce policies designed to reduce the risk of a data breach, no matter what might cause it.
Note that I didn't say eliminate risk—that's an important distinction. If history has taught us anything, it's the old cliché "where there is a will there is a way." We have to accept that there is no such thing as zero risk.
As the primary researcher and author of PowerTech's annual State of IBM i Security Study, I witness an alarming lack of restrictions on servers running IBM i. We can blame the heritage of the technology and legacy applications that assume users can be controlled via a combination of menus, application-imposed security, and command-line restrictions.
Some of the blame also belongs with the misconception that the server is inherently secure, overlooking the unfortunate detail that controls are provided but are not preconfigured in a state recommended by security and compliance experts.
A Classic Case of the Inside Threat
AT&T made headlines in April when the Federal Communications Commission (FCC) imposed a hefty civil penalty—$25 million—for an insider data breach. According to watchdog publication govinfosecurity.com, call center employees in Mexico, Columbia, and the Philippines extracted information from almost 280,000 accounts over a four-month period. The information was subsequently provided to unauthorized third parties who used the information to unlock stolen cell phones and secondary market phones.
Sadly, there is nothing unique about this case, other than the fact that someone eventually found out. When we check on IBM i shops, we find terrifying statistics that would make internal breaches just like this as simple as 1-2-3!
- 35 percent operate below the IBM-recommended minimum security level
- 13 percent of profiles have passwords that match the profile name
- 80 percent of libraries are wide open to *PUBLIC (all user) access
- 51 percent have not deployed exit programs to monitor network-based connections (e.g., FTP, ODBC, DDM, etc.)
- 24 percent of servers are not audited and would likely never know they were being hacked
This security train wreck needs urgent attention. The onslaught of compliance regulations is beginning to force the issue, but we shouldn't need someone else telling us to protect our data.
We can also thank the endless parade of outsider and insider breaches that have tripped up others in recent years. If that doesn't act as a corporate wakeup call, I don't know what will. Actually, I do know. It will be the breach that hits your organization!
Give Up Your False Sense of IBM i Security
While Power Systems servers are typically behind corporate barricades, it's past time to sunset the dangerous thinking that this means we are not at risk. IBM i is not secure unless you make it so. Security by obscurity is not a legitimate answer to protecting your system!
Sadly, this is a mindset that reverberates around the "i" community. But it doesn't take a genius to figure out that a library named "payroll" likely contains payroll data or that if my profile and password are both "robin," then Donna's profile and password are probably "donna."
Numerous entities preceded AT&T and numerous more will undoubtedly follow, proving that risks lurk anywhere data resides. We need to budget time, effort, and money to the protection of this crown jewel of servers, instead of allowing it to flounder in a pool of denial and neglect.
Your Reputation Is on the Line
We'd like to think the contractors, vendors, and employees of an organization are completely committed and trustworthy. While I would never deliberately imply that everyone accessing an internal server is out to cause harm, it only takes one—and it doesn't require malicious intent—to put your employer in a very unfortunate position. I'm certainly not willing to put my career on the line to guarantee of the ethics of other people. And you shouldn't either.
There is no better time to review the privileges of administrators and end users, as well as evaluate the state of frequently misconfigured security controls. Leverage the same no-cost risk analysis process that has benefitted thousands of organizations worldwide by signing up for a security assessment of your own.