Top 11 Ways to Protect Your IBM i from Insider Threats

February 22, 2017 Alex Woodie

Hackers get a lot of attention when it comes to cyber security, and for good reason: external cyber threats are growing in volume and sophistication. But one shouldn’t overlook the harm that insiders can—and do—wreak on companies on a daily basis. Security expert Carol Woodbury recently shared 11 ways IBM i pros can protect the server from the very real threat posed by insiders.

Woodbury, who is the vice president of global security services at HelpSystems and formerly was IBM‘s chief security architect for the AS/400, says IBM i shops unknowingly leave themselves open to internal attacks through a combination of carelessness, recklessness, hurriedness, and a general lack of understanding of how the platform’s security apparatus works.

“There are a lot of things that administrators do just in the course of their business that they just might not think about the fact that it’s leaving the systems vulnerable,” Woodbury said in a February 7 HelpSystems webinar titled “Mitigating the Insider Threat in the IBM i World.”

But it doesn’t have to be this way. In the webinar, Woodbury offered 11 ways IBM i administrators can shrink the attack surface and otherwise protect the IBM i server from insider threats:

Trim Special Authorities

If there’s one thing that will drive IBM i security pros up the wall, it’s overuse of special authorities, such as SPLCTL, JOBCTL, and the big one, ALLOBJ. And when common user profiles are given these special authorities, the system can quickly sustain major damage by blundering newbies and ruthless villains alike.

“QSYSOPR, QUSER, QPGMR are often granted more authority than what they’re shipped with, and when that happens, that can often present users with more authorities than what you really intended to,” Woodbury says. “It [QPGMR] is also the owner of a lot of vendor software, so that means that vendor software may be running with more capability than it’s supposed to. We really try to help our clients understand the dangers of this, and remove that when at all possible.”

Use Open Source Cautiously

Everybody just knows the IBM i has bullet-proof security, thanks to its object-oriented architecture, and is practically impermeable to all the malware afflicting X86 machines, right? Unfortunately, the IBM i server is more vulnerable to “common” security threats than you may have thought.

“We all love the fact that our beloved system, the IBM i, is modern and supports all the newest and latest technologies, including Web applications, PHP, all the languages for accessing it, Python and so forth,” Woodbury explains. “But the thing is, in supporting those technologies, the vulnerabilities associated with them also come along. So, Web apps that run on IBM i are subject to cross-site scripting, SQL injection errors, and the list goes on.”

Woodbury applauds the fact that many companies are upping their security game and using Web application vulnerability scanners to identify poorly coded apps that could leave their X86 servers open to attack from internal and external threats.

“The problem is a lot of people skip the applications running on the IBM i,” she says. “And they should not be skipped, because you can code and insert a SQL injection error, if the webpage is coded incorrectly, just as easily on IBM i as you can on Linux.”

Ransomware and Malware

Thanks to mapped network drives and the proclivity of IBM i shops to share root access, it’s actually very easy for a piece of PC-based ransomware or malware to infect the IFS, Woodbury says.

Ransomware can land on your IFS drive.

“If somebody is mapped to root, and their laptop or PC is infected with ransomware, at that point, any mapped drive just looks like any other drive on the PC,” Woodbury says. “And ransomware doesn’t know any different that it’s an IBM i, so it can go right across and start encrypting those directories.”

Adopted Authority

You’d be hard pressed to find a bigger fan of adopted authority than Carol Woodbury. The security pro applies it liberally in her client engagements because, when used correctly, it can actually reduce the security exposure of an IBM i system.

“I am a huge fan of adopted authority,” Woodbury says. “There are just a few things you have to be aware of so you don’t propagate adopted authority to places you’re not intending.”

If used incorrectly, adopted authority could inadvertently allow a sophisticated insider access to a command line, where he could do things he’s not supposed to be able to do, such as directly access the database. “We need to make sure that we are not propagating that adopted authority up to the command line,” she says.

There’s a second caveat about adopted authority that sometimes leads the security-minded far astray, and that has to do with ALLOBJ authority. According to Woodbury, there’s a widespread misperception that a program configured to use adopted authority must run under a user profile that has ALLOBJ authority.

“The profile that is owning the programs that adopt does not have to have any special authorities,” Woodbury says. “So be careful not to over-authorize the profile that is owning the programs that adopt.”

Unattended Workstations

Getting IBM i security right can be tough. There are so many knobs and switches to get right that, all too often, admins misconfigure something, or just throw up their hands in frustration and go along with the (unsecure) status quo. So here’s an easy one, and it has to do with physical security.

Don’t forget to lock your workstation when you leave.

“If you walk away, anybody has a playground to do anything they want to, and it’s going to be logged as you,” she says. It would be your word against the QAUDJRN’s word, and the QAUDJRN will win.

The solution: lock your keyboard when you’re gone. Get a device timeout that automatically disables the workstation after a few minutes, and forces you to log back in. “Discipline yourself when you walk away,” Woodbury says.

Review Service Accounts

Many IBM i shops run with an array of service accounts that were installed way back when, and are often rarely used anymore. The problem is, many of these service accounts have ALLOBJ.

“If you can discipline yourself to have a regular review of the programs with ALLOJB, you’ll catch that rather than waiting for an annual risk assessment or somebody to come through to see that profile that has ALLOJB that probably didn’t need it,” Woodbury says.

IBM i shops that have upgraded to IBM i 7.3 can avail themselves of a powerful tool that will help with service accounts. The collection function will automatically show the security officer a variety of pertinent information about service accounts, including which authorities are being used, which objects are being touched, and so on.

Apply Those PTFs!

IBM is really good about issuing patches to fix security vulnerabilities in its software. Unfortunately, customers aren’t nearly as good about keeping up with PTFs, and that can leave systems open to nefarious insiders as well as cybercriminals from afar. File this one under the “low-hanging fruit” category in the IBM i security remediation handbook (or maybe the “duh!” category).

“My encouragement is that you stay current on your PTFs, whether operating system PTFs, Java PTFs, or any PTF that has to do with open source technology, and certainly the use of SSL/TLS,” Woodbury says. “Leaving the system open when there is a patch for the vulnerability definitely leaves yourself open for that insider threat.”

Avoid Default Passwords

It’s painful to read PowerTech‘s annual “State of Security” report and see how many IBM i systems are running user profiles with default passwords. Any hacker worth his IBM i salt knows that the default password is the user ID. The default password issue is especially critical when dealing with potentially sleazy insiders who already know the naming convention for the user ID.

“When they know the naming convention of the user name, they know half the equation,” Woodbury says. “And if there are profiles with default passwords, they also have the second half of that equation. And it’s very easy to try.”

Lock Down Test Partitions

Developers often create copies of production data and use that data to test new applications or changes to existing applications in a separate dev or test LPAR. This is a necessary part of the development process, but all too often the data is left vulnerable.

“I can safely say the vast majority of time, that data is not as secured as it is in production,” Woodbury says. “One of the thigs we like to do is make sure data is secured. That includes removing ALLOBJ for the developers on a test system.”

Woodbury also avails herself of new features that make it easier to encrypt and mask data, such as the field proc, which debuted in IBM i 7.1, or row and column access control (RCAC), which debuted in IBM 7.2.

The bottom line is, data must be protected, wherever it resides. “Either secure it the same [as the production database] or take extra steps to ensure it’s not available in the same format as it is in production,” she says.

Beware of Shadow IT

You’ve seen them lurking with their spreadsheets in the shadows, or hiding under their desks with Tableau dashboards. They’re the Shadow IT people, and they’re coming for your data.

You name it, they’re crunching the data in some way,” Woodbury says. “But they’re storing that data in a way that’s not secured. They forget to lock down the folder on SharePoint. Or the information that is encrypted on IBM i is typically not encrypted because they’re not following any of the rules.”

The solution: Bring shadow IT out into the light, where rules can be enforced.

Beware of Forgotten IT

While some scofflaws in sales and marketing create vulnerabilities by purposely avoiding the long arm of the CISO, the sleazy insider can also avail himself of long-forgetten bits of data and application logic.

“This one comes under guise of ‘You’re busy and didn’t mean to leave it like this, but you totally forgot to come back and clean up,'” Woodbury says. “One of the things that happens is that the process fails, so it’s given ALLOBJ. It’s rerun, and you’re onto the next thing, and ALLOBJ isn’t removed or public authority isn’t locked back down, or the group file isn’t removed from the authority.”

It’s critical to make security a first-order architectural principal of the systems you’re building, not an after-thought, or a never-though. “As much as you can, raise the awareness of security at the bringing of a process, not the end,” Woodbury advises, “and point out the fact that this is leaving your system vulnerable and your data open to insider loss or theft.”

RELATED STORIES

IBM i Priorities For 2017: Pivot To Defense

Did IBM i Just Get Hacked at DEF CON?

State of IBM i Security? Still Horrible, After All These Years