Guru: IBM i Privileged Account Management, And What’s So Special About Special Authorities
August 1, 2022 Bruce Bading
Privileged Account Management (PAM) is a keystone of cybersecurity. Everywhere we look PAM is a hot topic. How and why should we worry about it? IBM, Ponemon, Verizon, etc., tell you that it is vitally important to protect your endpoints from cyberattacks and insider threats. While the Verizon DBIR states that external threats account for 80 percent of security incidents, it points out their findings that show otherwise for incidents resulting in data compromise where the insider threat exceeded that of an outsider by more than 10 to one. Simply put by Verizon, “This supports the principle that privileged parties are able to do more damage to the organization than outsiders.”
Further, IBM Security estimates the average cost of an insider-related incident to be $17.92 million dollars. So why is this a big deal for the IBM i? Let’s just start with Introduction to IBM i security – IBM Documentation. Dig a little further and you’ll find Preventing and detecting security exposures – IBM Documentation. And while you’ll find exit programs are part of your overall strategy as we discussed in last month’s article. The smart people in Rochester, where I was the Senior Security Architect for years before retiring and forming BFB Security, an IBM Business Partner in 2017, reviewed and agree with everything we put into the CIS IBM i Benchmarks, it goes far beyond exit points and SIEMs and involves people, processes, and tools.
So that circles back to PAM and what this has to do with Special Authorities. If you read though the IBM i Security Reference and/or Knowledge Center information on Special Authority, you’ll see that we all list Special Authorities as one of your top risk items. First, when you create a *USER class user and give it *SPLCTL or *JOBCTL, you already have a mismatch between the user class and Special Authorities. Second, there is NO reason that application *USER class users need either of these two authorities. Wait, what? But my system will not function without these authorities you may say. But that is simply not correct.
Change your queue settings and authorities and you will remediate 99 percent of the SPLCTL/*JOBCTL issues. An example is as follows. Many applications spool output as a common user. Let’s just assume that user is SPLUSER for now. Your users run your applications and spool output is owned by SPLUSER. Now you find that your users can’t view the spooled files owned by SPLUSER unless you give them *SPLCTL or *JOBCTL – STOP!
The IBM i Security Reference and/or knowledge center information on queue commands has more on how to do it. I’ll save you reading the tables. You can change the queue AUTCHK parameter from the default value of *OWNER to *DTAAUT and give your users *CHANGE authority to the queue and now, your users can read, delete and perform all actions on spooled files they don’t own or that are owned by an application user.
Example: CHGOUTQ OUTQ(QGPL/TEST) AUTCHK(*DTAAUT)
Now you can probably remove *JOBCTL and/or *SPLCTL special authorities while also controlling access to confidential queues through the *PUBLIC and private authorities to the queues. With *JOBCTL and *SPLCTL, you have no control over your queue authorities.
Further, the Principle of Least Privilege (PoLP) is required by every compliance framework. Simply read NIST publication 800-53 and search for “Least Privilege.” You’ll find it referenced throughout. Section AC-6 states the following:
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
Discussion: Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions.
Take *JOBCTL Special Authority for example. The IBM i Security Reference lists the risk associated with *JOBCTL as follows:
RISK: A user who abuses *JOBCTL special authority can cause negative effect on individual jobs and on overall system performance.
That’s because *JOBCTL Special Authority gives access to end, change, control, etc. any job including system jobs and every other user’s job on the system.
SPLCTL has the following risk: The user with *SPLCTL special authority can perform any operation on any spooled file in the system. Confidential spooled files cannot be protected from a user with *SPLCTL special authority.
The other six Special Authorities grant administrators powerful privileges that can affect other aspects of the system’s Confidentiality, Integrity, and Availability and almost all can be remediated through proper access controls and changes to queue authorities. Proper use of adopted and swapped authorities can remediate the rest.
So before you give users the Principle of Much More than Least Privilege (PoMMtLP), consider the NIST requirements of the PoLP and read the IBM i Knowledge Center section on Special Authorities.
Agile creates technical debt that translates into security debt that must be repaid with interest. Remember that the lead signatory on the Agile Manifesto, Robert C. Martin, states that “Agile is a set of principles, practices, and disciplines that help small teams build small software projects. Agile is a small idea about the small problem of small programming teams doing small things. Agile is not a big idea about the big problem of big programming teams doing big things.”
Today’s breach rich landscape demands a change on our large systems. Fail fast, not twice which means you need cybersecurity experts working alongside your developers with DevSecOps.
You can’t defend what you don’t know and it’s difficult to know what is going on inside those big IBM i systems with too many special authorities and privileges that can be obtained in many ways through users, groups, *PUBLIC and privately authorized profiles, adopted and swapped authorities and much more. PAM is taking over on all systems and zero trust is the new normal.
For those at risk, the time to remediate is now. For those that have been breached, the time to remediate was yesterday.
Bruce Bading is a senior security consultant with more than forty years of information security experience and 25 years of corporate c-suite experience. He is an expert on IBM i security and has helped some of IBM’s largest clients meet their security and compliance requirements in today’s complex technology and business environments. Bruce has exceptional communications skills, has worked with diverse audiences at all business levels to provide training and education and has led dozens of large enterprise risk management projects for the world’s largest organizations. He is a member of the Information Systems Audit and Control Association, a CIS benchmark author, and professional threat hunter.
Editor’s Note: Bruce is one of a number of new Guru experts that we are working with to keep the Guru column going within The Four Hundred. We look forward to the coming in-depth security coverage that Bruce can give as you work to secure your IBM i platforms in these interesting times.
RELATED STORIES
Guru: The Finer Points of Exit Points
Guru: SIEM Is Only Part Of IBM i Cybersecurity
Guru: Would You Rather See a Fire Marshal or a Fire Fighter?
