With so much fake news floating around, I thought I’d take the time to debunk the fake news I hear about IBM i security.

When I visit new clients, I often find that they have been misguided somewhere along the way and/or are making assumptions about features of IBM i security that were once true but aren’t any longer. This article goes through some of the more common misconceptions I hear.

User Class Forces the System to Check Authority

I can’t tell you the number of people who misunderstand how the system uses the User class attribute of a user profile. It is used to default the special authorities when the profile is created. It is not used when the system checks whether the user has sufficient authority to perform an operation, such as updating a file. Therefore, when you have to debug a problem to determine why a user is or isn’t gaining access, for example, you shouldn’t look at the setting of the User class. The user may be in the Security Officer (*SECOFR) user class yet have no special authorities or be in the User (*USER) user class and have all special authorities. Looking at the User class settings can easily misguide your analysis.

Enabling Security Causes Performance Issues

Given all the performance enhancements in the operating system itself as well as with the authority-checking algorithm and other security features, it’s very difficult to have security be a performance issue. That said, some security features have caused performance issues in the past but have been resolved.

Let’s take a look at those:

• Object auditing: When object auditing was first added to the operating system back in Version 2, simply enabling object auditing—that is, adding *OBJAUD to the QAUDCTL system value—caused a noticeable system overhead. However, that issue has long since been resolved. Enabling object auditing no longer has a noticeable impact. Configuring object auditing on an intensely used object has the potential to cause an impact, but in my experience, even that has not caused a performance issue. (The issue you’re more likely to see is disk space filling up with journal receivers.)
• Authorization lists: Admittedly, when authorization lists were used back in the early releases of AS/400, they did cause a noticeable performance hit. That has been eliminated with some code modifications as well as the advent of the authority cache that’s associated with each user (added in Version 4). The cache holds up to 32 private authorities and 32 private authorities to authorization lists. If users are accessing objects secured by one of the authorization lists in the cache, it’s a very fast check.
• Adopted authority: Once upon a time, adopted authority added overhead to authority checking as well. But, again, efficiencies have been added, and if the owner of the program that adopts owns the object that’s being accessed, the adopted authority check is one of the first things performed in the authority checking algorithm. Whoever thinks that using adopted authority adds overhead is sadly mistaken.

All of these performance gains came in at least by Version 5, so the idea that using any of these security features causes a performance issue today is believing fake news.

Default Passwords Can be OK

An auditor asked for clarification on this myth, and I was happy to clarify for her that there is absolutely no acceptable reason to have a profile with a default password (that is, a password the same as the profile name.) A default password is the first thing a hacker will attempt. The second issue I clarified is that it’s not a compensating control to create the profile with the password set to expired, meaning that it must be changed at first use. Regardless of whether it must be changed at first use, profiles should not be created with a default password!

QSECURITY 50 Enables All Password Rules

In one of my last “Coffee with Carol” webinars, I was asked whether security level (QSECURITY) 50 still enabled all of the password rules. I don’t know where this idea came from, but QSECURITY 50 has never affected the password system values. You must configure the password system values at every security level. No security level enables them automatically.

Adopted Authority Is Evil

While adopted authority can be enabled in such a way that it provides opportunity for exploitation, it is not dangerous if it’s implemented carefully, and it provides a method for temporarily allowing access or the ability to do something without having to perpetually provide access or assign special authorities. Thinking you shouldn’t use adopted authority takes away a very viable tool that will assist you in securing your IBM i system.

The System Can be Secured at QSECURITY Level 30

Some organizations have argued that they can be secure at security level 30. That is simply not the case. Why is this? First of all, operating system integrity is guaranteed only at security level 40 and above. This means that at levels 40 and 50, you can be assured that only operating system programs can call other operating system programs and access internal control blocks. User-written programs cannot directly call operating system programs to bypass authority checking and auditing, nor can operating system programs be replaced by a user-written program. Access is successful only through IBM-architected programs (Application Programming Interfaces, aka APIs) or commands. The second reason is that, at levels 20 and 30, you only have to have authority to a job description, not the user profile if one is specified in the job description. This means that, if you have authority to a job description that names a profile with all special authorities, you can use that job description to submit a job and run it as that privileged user. I used this example at a client to create a new job description that named the IDM profile (the profile that runs their identity management software) and then used the new profile to submit a job to create a new profile. The profile looked like it was created through their normal process but had all special authorities and a password that I knew and could use to access the system with elevated privileges.

Message: Get your systems to security level 40 or higher!

Use Only Parts of QSECURITY Level 40

When I was explaining the fact that the system can’t be secured at level 30 to one client, they asked if they could move parts of their system to security level 40. The answer is no. QSECURITY is a system value. That means it’s systemwide, and it’s all or nothing.

Laws, Regulations, and Best Practices Don’t Apply to IBM i

I know. You’ve read the heading and you’re saying to yourselves, Huh? I agree. But I’ve been questioned by IBM i administrators and especially programmers who claim that somehow they don’t have to comply with laws and regulations or follow best practices. I don’t understand how or why they have come to believe this fake news. Perhaps it’s a case of wishful thinking? Our community holds no exemptions from complying with any law or regulation or implementing best practices. But I often see organizations failing in this area. For example, organizations fail to scan their web applications for well-known vulnerabilities because they’re running on IBM i. It’s a web application. Just because it’s running on IBM i doesn’t exempt it from being coded poorly and leaving it open to vulnerabilities such as SQL injection errors or cross-site scripting issues. We would do our customers—those users whose data your IBM i holds—a favor by complying with laws and regulations and implementing security best practices.

IBM i Has Never Been Hacked

Fake news! IBM i has been hacked. As documented in Verizon’s Data Breach Digest, misconfiguration by the system’s administrator allowed a hacker to infiltrate the system and manipulate the application settings. I know this is not the first time that configuration mistakes have allowed either external hackers or internal users access to data they should not be able to reach. So yes, it has been hacked, but more than that, configuration mistakes and failure to patch known vulnerabilities—especially in open-source products—allows opportunity for inappropriate access to data.

Menu Security Is Sufficient

It still amazes me that I have to explain this, but here we go. Let me be direct (or perhaps I should just tweet this?): If you configure your users to use a menu when they sign on and do nothing to protect the data in your databases and believe your organization’s data is secure, you are believing the most fake of all fake news. What do I need to say to have you understand that users can figure out how to access data on your system, regardless of whether you promote the use of the data? Examples are all over the Internet of how to access data on IBM i. Whether you think you are providing access or not, you are! You must get serious about securing the data residing on your IBM i system!.

Summary

I hope that this discussion has helped you separate the truth from fiction. We have the most securable system available. And that’s not fake news!