Debunking the Fake News Surrounding IBM i Security

When I visit a new client, I often find that they have been misled about IBM i security or are making assumptions about features of the platform that were once true but aren’t any longer. This article addresses some of the more common misconceptions I hear.

User Class

I can’t tell you the number of people that 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.

Performance

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 for security to be a performance issue. That said, some security features have caused performance issues in the past, but those 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 see 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 added in version 4 that’s associated with each user. 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 also owns the object that’s being accessed, the adopted authority check is one of the first things checked in the authority checking algorithm. Whoever thinks that using adopted authority adds overhead is sadly mistaken.

All 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 fake news.

Default Passwords Can be OK

An auditor asked for clarification on this 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 past 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 the provides opportunity for exploitation, implemented carefully, it is not dangerous and provides a method for 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. First of all, operating system integrity is only guaranteed 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 only successful through IBM-architected programs (APIs: Application Programming Interfaces) or commands.

The second reason is that, at levels 20 and 30, you only need authority to a job description, not the user profile if once is defined 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 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) 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!

Only Use 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 system-wide and it’s all or nothing.

Standards, 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 standards 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 in any standard or regulation or when it comes to 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 vulnerable 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 standards and regulations and implementing security best practices.

IBM i Has Never Been Hacked

Fake news! IBM i has been hacked. As documented in the 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 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. 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 fake-est 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 showing 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 this discussion has helped you separate the truth from fiction. We have the most secure-able system available … and that’s not fake news!