According to the IBM X-Force, misconfiguration is one of the top issues that leave organizations vulnerable. IBM i is not immune to misconfiguration. While there are many ways to misconfigure a system, Carol describes her top five.

I read articles about security breaches all the time. Except for cases when an organization is targeted by a nation-state or a competitor, the cause of the breach is usually attributed to “misconfiguration.” Misconfiguration can take numerous forms. Several situations come to mind that cause IBM i misconfigurations.

Many organizations set system values, object authorities, and user profiles to specific values that match security best practices, but they never bother to monitor to see if those values are changed. System values may be changed during vendor product installations, object authorities can be modified to accommodate a user request (which shouldn’t have been granted), or programmers may be assigned *ALLOBJ special authority for a short-term project never removed. Other organizations have totally ignored security, doing whatever they feel is necessary to make administration as easy as possible. Typically, this means making configuration decisions without regard to the security implications. In both cases, misconfiguration occurs. While I could list many configurations that make your system vulnerable, let’s take a look at my top five.

Vulnerability #1: Sharing root (/)

Sharing root shares the entire system, not just the directories. So even a read-only share exposes all aspects of the system to being viewed by users who don’t have a job responsibility to do so. Make that a read-write share and the system becomes highly vulnerable to malware. On top of this misconfiguration, when the *PUBLIC authority of root is left at the default setting, the system becomes vulnerable to malware. This is not theory: we have seen numerous clients become affected by ransomware. Fortunately, most of them have had a backup that allowed them to recover the portions of their system that were encrypted. Other types of malware also exist. For example, one organization was infected when the PC mapped to the root share became infected because someone clicked on a link that downloaded malware that renamed all directories—first on the PC and then on IBM i.

Vulnerability #2: Running at the Wrong Security Level

IBM i has shipped at QSECURITY level 40 for many releases now (since the 1990s!), but we still encounter systems that are running at security level 30 and some at 20. These organizations are leaving themselves open to having users elevate their privileges, bypassing some auditing, and potentially de-stabilizing the operating system depending on whether developers are directly accessing data (rather than using APIs or commands (*CMDs)) or modifying internal control blocks. None of these things are an issue at security level 40 or 50. There’s no excuse for not running at 40 or 50 these days. All vendor code runs at security level 40. The issue today is that organizations may have to clean up a bit of their own code, but rarely is it a huge issue. The good news is that you can audit to determine what issues you may encounter prior to moving from level 30 to level 40. Moving from 20 to 40 takes a bit more planning but is also quite doable.

Vulnerability #3: Default and Other Weak Passwords

Allowing default passwords is an open door for anyone to try to access your system. All hackers know that a default password on IBM i is the same as the profile name. So that’s the password they’ll try. Default passwords are easy to discover (Analyze Default Password—ANZDFTPWD) and, as of V7R2, can be prevented. By specifying *LMTPRFNAME and *ALLCRTCHG in the QPWDRULES system value, no one can specify a default password—even when creating or changing a profile. We’re recommending that our clients move to using the QPWDRULES system value rather than the individual password composition rule system values because of the additional options available. Allowing other weak passwords also leaves the system vulnerable. I’ve heard a lot of excuses for not requiring strong passwords, but, to be honest, I’m losing patience with those. Online banking and most online retail sites now require strong passwords. How it is that users can put up with strong passwords in their personal life but not their work life? Yes, they will complain, but they will be able to handle them!

Vulnerability #4: Unencrypted Communications

If someone infiltrates your network or an insider “turns” and has a desire to harm your organization, leaving communications in clear text rather than implementing encrypted sessions (using TLS) allows the communications to be read, including user ids and passwords. All that’s needed is to find one user ID/password combination of an administrator, and the intruder or insider makes even more inroads into your organization. Encrypted sessions are not difficult: everything you need to configure them comes with IBM i.

Vulnerability #5: Continuing to Think That “Menu Security” Is Sufficient to Protect Data

Sad but true, I still have organizations claiming that they don’t need to do anything more to protect their data because their users can only access data through menus. Sigh. I’m not sure if they actually believe this or if they’re trying to make excuses for why they haven’t taken action to secure their data. If you’ve read other articles or heard me speak, you’ve heard me mention “multiple layers of defense” or “defense in depth.” The data residing on our IBM i systems is a valuable corporate asset. How many layers of defense you’ll choose to implement will depend on the value of the data to your organization and/or will be dictated by laws or regulations.

Here are the layers of defense to consider. The outermost layer of defense are exit points; think of this as a logical firewall that will prevent users from accessing data via FTP, ODBC, DDM, etc. The next layer that will protect data is object-level security. Setting data to “deny by default” means that database files will be set to *PUBLIC *EXCLUDE, and only users with a business need will have access to the data. Or perhaps your business simply requires data integrity. That means that the *PUBLIC authority will be set to *USE so that the organization can be assured the data is modified only via application interfaces but anyone can read the data. We’re now seeing an increased number of organizations using a final layer of defense and encrypting fields containing sensitive data. Finally, securing data assumes that you have your role-based access in place, meaning that only administrators have been granted *ALLOBJ special authority.

Summary

All of these vulnerabilities work together. All should be addressed if you want to have a secure system. The good news is that, with the possible exception of Vulnerability #5, all of these are easily corrected. Determining which data to protect and how many layers of defense you’re going to implement takes a bit more planning.

My hope with this article is that you understand that IBM i is not immune to misconfiguration and that you’ll start looking to see if corrections need to be made.