I’m guessing that you’ve asked someone (perhaps even yourself) one or more of these questions.

I get asked a lot of questions—via email, when I’m presenting at conferences, after my Coffee with Carol article series sponsored by my employer, as well as questions asked in response to these articles, but some questions are asked more often than others. I thought it might be fun to answer the top six most-frequently-asked questions and provide references for additional information. Here we go!

Question #1: What authority is required to do xxxx, where xxxx is a command, or a task such as copying a database file or accessing an object in a directory, etc.?

The answer to this question, if it’s a command, is to point people to Appendix D of the IBM i Security Reference manual. This manual lists all CL commands and the authority required to run each. If the question is about an API, refer to the online API guide. The documentation in the Information Center for each API specifies the authority required to run the API. Finally, if you’re running V7R3 or V7R4, you have the Authority Collection feature available in the operating system which provides—in great detail—the authority required to access objects. I’ve described three ways to use the Authority Collection in a previous article. I’ve also described the function in my book, IBM i Security and Administration, Second Edition, and the IBM documentation can be found in Chapter 10 of the Security Reference manual.

Question #2: How do I know who changed something on our system?

The answer to this question has me pointing people to the integrated auditing (logging) features of IBM i. Actions, such as who or when something was done, are captured in the audit journal called QAUDJRN. All security-relevant actions can be audited, including the creation or deletion of objects, creation or changes of user profiles, changes to system values, modification of authorities, authority failures, and more. If you’re not familiar with the auditing features of IBM i, see Chapter 9 of the IBM i Security Reference manual, or my book IBM i Security Administration and Compliance, or previous articles such as this and this.

Question #3: In what order is authority checked?

Actually, the question is usually in the form of “Which is checked first, users or group?” Or “Which takes precedence, a private authority or an authorization list?” The short answer is that users are checked first; if no authority is found at the user level, then groups are checked. If no authority is found at the group level, then *PUBLIC authority is checked.

Within the user level, presence of *ALLOBJ is looked for first, then a private authority, then authority to an authorization list. Same for the group level. The important thing to remember is not just the order, but the fact that if some authority is found—sufficient or not—the algorithm does not go on to the next level. That’s why, if a profile has been assigned *ALLOBJ special authority, granting users or one of their groups a private authority of *EXCLUDE to sensitive objects has no effect. The *ALLOBJ provides the access.

Question #4: How do I secure the IFS?

This is an increasingly popular question as more organizations realize they have sensitive data stored in a directory. Even private data stored temporarily should be placed in a directory with appropriate authority. I try to encourage people not to be intimidated by the IFS. You use the same methods for securing IFS objects as you do with objects in libraries except that you cannot use adopted authority. Also, the same authority-checking algorithm (as described above) is used—regardless of whether the object accessed is in a library or a directory. The authorities assigned are called something different than we’re used to—*R (read), *W (write), and *X (execute) —but they map into authorities that we use every day—*ALL, *CHANGE, and *USE. *EXCLUDE exists in the IFS as well. I would be remiss to not mention the Authority Collection feature again. You can collect the authority required for accessing objects in the IFS just like you can users accessing objects in libraries. This feature takes the guesswork out of what authority is required. If your system is running V7R3 or later, don’t forget to use this feature! If you have my book, read the chapter dedicated to the IFS for more details.

Question #5: Has IBM i ever been hacked?

The answer is YES! But let’s take a look at this more closely. The incidences that I’m aware of have nothing to do with a fault in the operating system. These breaches are due more to configuration issues and, in at least one case, total disregard for using of any of the security features provided in the operating system, for using any sort of common sense, and for implementing any of what would be considered to be security best practices. This breach was documented in the Verizon Data Breach Digest: Scenarios from the Field. The administrator put his organization at significant risk by putting their AS/400 (yes, it was an AS/400) directly on the Internet with no firewall in front of it, leaving an application with a known vulnerability unpatched, putting his own cleartext credentials in their web application’s config file, allowing unsecured (unencrypted) Telnet, and more. Unfortunately, I’ve seen several organizations with some of these same configurations. Articles such as this provide guidance to ensure you don’t make the same mistakes.

Question #6: How do I convince management that we need to invest in security?

Answering the other questions is easy. This question…not so much. Each organization is different, and each has different management and different reasons for their current investment in security—large or small.

To answer this question, I encourage the individual asking to start thinking about the business side of securing their systems. In other words, start thinking about the value of the data residing on their system and the cost to the organization if that data is lost, stolen, inaccurate, or unavailable. Good security practices can prevent all of these issues. For example, if management says that it’s not necessary to secure IBM i, you may want to point out all of the reports the company generates for business decisions, or data that’s being fed into your BI or AI applications, or processes that are driven or run by the system. Then ask, “What if these aren’t available?” Speak to management in business terms (as in cost to the organization) not in terms of a specific application or technology you’re trying to implement. To be blunt, don’t come off as a babbling techno-nerd! The best advice I can give you is to present your arguments as a business case, something management will understand and can use to make an appropriate decision based on the needs of the organization. If that doesn’t work, there are actions you may be able to take, even without management approval (which I discussed in this Coffee with Carol webinar and this article).

Summary

I’m guessing that you’ve asked one or more of these questions yourself. Hopefully, this will provide you with the information you need to implement IBM i security effectively.