Carol discusses how the current thoughts on insider threats needs to be redefined and how insider threats can leave IBM i vulnerable.

I read an interesting article that discussed a study done by the Ponemon Institute on the “Cost of Insider Threats.” It piqued my interest because most of the people I talk to in the IBM I world don’t believe there’s any threat by people from inside their organization. The two reasons I hear most are “I trust our employees” and “Our employees would have no clue how to get access to the system through something like ODBC. They can barely sign on to their green-screen menu.” I decided to read the actual study to determine if there was applicability to the IBM i world.

The Study defined three types of insider threats:

• A careless or negligent employee or contractor, comprising 68% of the threats
• A criminal or malicious insider, 22% of the threats
• A credential thief, 10% of the threats

I found the fact that the largest threat (by far) was due to careless or negligent employees and contractors fascinating. This threat has nothing to do with the level of trust you have with your employees or their computer skills! This has everything to do with choices made by administrators and others. I quickly concluded that yes, the insider threat is alive and well in the IBM i world.

While you might not consider yourself “negligent” or “careless,” let’s face it, we all make mistakes and we all leave tasks undone because we either get busy and forget about them or get re-directed and it never again becomes a priority. Also, falling into this category are configuration choices that are made without considering the security implications of that choice. Examples of these choices as well as configuration changes that unintentionally leave the system vulnerable are the focus of this column. Let’s take a look.

Unattended Workstations

You sign on to your PC in the morning, check a few things using either your Access Client Solutions (ACS) 5250 emulation session or Navigator for i. Satisfied there are no fires that need immediate attention, you leave your desk and go to the cafeteria to grab some coffee. I know some of you are disciplined enough to lock your workstation before you leave your office, but for those of you who aren’t…think of the treasure chest you’ve just left wide open for someone to sit down and take advantage of. You’ve likely left your IBM i session signed on with your all-powerful profile, and all someone needs to do is start clearing or deleting files, changing system values, powering down the system, etc. And everyone, including the IBM i audit journal, will point to you as the culprit. Or maybe they’re more surreptitious and just copy files—a task, which if performed through iNavigator, may not even be noticed by you. It’s not like you can press F9 to recall your cursor movements in this interface like you can press F9 to recall a command entered on a command line. The innocent act of walking away from your desk can leave your system wildly vulnerable. Even if you have a group policy on your network that times out inactive workstations, discipline yourself to lock your workstation when you leave your desk!

Special Authorities Added to IBM i-Supplied Profiles

IBM-supplied profiles are shipped with only the authorities needed to perform the tasks associated with their function or role on the system. Adding more authorities, especially *ALLOBJ special authority, gives more authority than was intended to tasks you’re running or users who’ve been made a member of the profile or vendor products owned by the profiles. I often see systems where QPGMR has been given *ALLOBJ special authority. The problem with this additional authority is that QPGMR is often the developers’ group profile. Whenever they sign on to production, they have all authority to all objects on the system. This excess capability can easily lead to accidental updates or deletions or unapproved system setting changes or even circumvention of change management processes. Compounding the issue is that some vendor applications are owned by QPGMR. By giving QPGMR *ALLOBJ, users running these vendor applications may have much more power (i.e., *ALLOBJ special authority) than they should have when running the application.  

Ignoring Web Applications Running on IBM i

We often fight the idea that steps need to be taken to secure IBM i, and that laissez faire attitude extends into the web application world. Some believe that, because their web applications are running on IBM i, they don’t need to worry about vulnerabilities such as cross-sight scripting errors or SQL injection errors when writing their web applications. Nothing is further from the truth! Running a web application on IBM i doesn’t magically remove these vulnerabilities. When you’re running your web application scans for apps running on other platforms, make sure to point your scanner at your web apps running on IBM i as well.

Root Is Shared

I’ve written about this before, but sharing root is so dangerous I must repeat myself. I do understand why it’s tempting to share the root ‘/’ directory. It’s an easy way to allow users to map a drive and get to whatever directories they need to in the IFS. But as I’ve said in other columns, sharing root is literally opening up your entire IBM i to ransomware because sharing root also shares /QSYS.LIB—that is, all of your libraries. Don’t be one of the growing ranks of organizations running IBM i that’s had to recover from this type of attack.

Modified Authorities to Aid in Debug Aren’t Set Back

As our team works with clients, one of the things we encourage is to set up a process to regularly look for changes to authorities to objects and authorization lists. When we do that on our clients’ behalf and we see a change, we find that the reason for the modification was often because there was a production issue and someone thought that the security configuration was causing the issue. Changes made in this scenario are usually obvious; a developer’s group is granted *ALL authority to an authorization list, or the developer’s profile is granted authority to a secured directory, or the *PUBLIC authority of a file is changed from *EXCLUDE to *ALL…. You get the idea. The problem is (obviously) not that they were trying to solve the production issue. The problem is that when the security change didn’t solve the problem, the configuration was never put back to its original setting. This underscores the need to have a process that forces you to perform regular checks of your security configuration.

Unaware of Assignment of *ALLOBJ Special Authority

When reviewing the list of user profiles that have been granted *ALLOBJ authorities with a new client, I often hear, “That person shouldn’t have *ALLOBJ. How did that happen?” (Perhaps it was another case of trying to debug a production issue.) Or “Uh oh! I was supposed to take *ALLOBJ away as soon as that project was done. Guess I’d better do that now.” Unless you discipline yourself to review the list of profiles with *ALLOBJ (and perhaps *SECADM and other special authority assignments), users will likely have additional capabilities for much longer than is appropriate…if they should have had the power in the first place! Maybe they won’t do something malicious with all that power, but it will be quite easy for them to do something unintentional because they have too much authority.

Not Staying Current with Integrity, Open Source, and Java PTFs

Because IBM i has so few integrity PTFs (those PTFs that fix internal security issues), I fear that people assume they don’t need to keep up with those and other PTFs that address security issues. In particular, administrators need to be diligent about applying Java group PTFs and PTFs associated with technology implemented with open source. For example, IBM just announced the release of PTFs fixing recently discovered vulnerabilities in OpenSSH. To leave your system unpatched is to ask for a hacker to exploit that vulnerability. If you do any research on hackers, some specifically go looking for unpatched servers with known vulnerabilities. Last year, in one of my “Coffee with Carol” sessions, my colleague Robin Tatam and I discussed the Verizon Data Breach Digest article documenting the hack of an AS400 (their spelling, not mine!). Talk about a careless or negligent administrator! The hacker used several missteps by the administrator to walk through that system, but the hacker’s initial access was exploiting a well-known vulnerability with the web application the utility company was running.

My point is that you must stay current with your PTFs! And because you’re busy, rather than keeping track of these yourself, I encourage you to log into your IBM account and sign up to be notified when security fixes are released.

In addition to staying current with fixes, I encourage you to stay up to date with OS releases. Some organizations are having difficulty configuring their encrypted communications at V7R1 because Digital Certificate Manager (DCM) doesn’t allow multiple certificates to be assigned to servers until V7R2, and V7R1 doesn’t have all of the strong ciphers for encrypted sessions provided in V7R2/R3. While the end of life (EoL) has yet to be announced for V7R1, I highly recommend you start planning for an upgrade to V7R3.

Summary

This is a short list of issues. I could have mentioned systems running at security level 20 or 30, profiles with default passwords, etc. (the typical IBM i security checklist of issues). But I tried to describe scenarios that may trigger to you think about the non-typical issue in hopes that you’ll examine your own actions and processes that may unintentionally be leaving your system vulnerable. No one wants to see anyone in our IBM i community have an incident that’s attributed to a “careless or negligent employee or contractor”!