August 1, 2022
Privileged Account Management (PAM) is a keystone of cybersecurity. Everywhere we look PAM is a hot topic. How and why to worry about it? IBM, Ponemon, Verizon, etc. tell you that protecting your endpoints against cyberattacks and insider threats is extremely important. While Verizon’s DBIR reports that external threats account for 80% of security incidents, it points out that their findings show the opposite for incidents resulting in a data compromise where the internal threat exceeded that of an outsider by more than 10 percent. a. Simply put by Verizon, “It supports the principle that privileged parties are capable of doing more damage to the organization than outsiders.”
Additionally, IBM Security estimates the average cost of an insider incident at $17.92 million. So why is this such a big deal for IBM i? Let’s just start with Introduction to IBM i Security – IBM Documentation. Dig a little deeper and you’ll find Security Exposure Prevention and Detection – IBM Documentation. And even so, you will find that exit programs are part of your overall strategy, as we discussed in last month’s article. The smart folks in Rochester, where I was the lead security architect for years before retiring and forming BFB Security, an IBM Business Partner in 2017, have reviewed and approved everything we put in the IBM i CIS benchmarks go far beyond exit points and SIEM and involve people, processes and tools.
So that comes down to APM and what it has to do with special authorities. If you read the IBM i Security Benchmark and/or the Special Authority Knowledge Center information, you will see that we all list Special Authorities as one of your top risk items. First, when you create a user of class *USER and assign it *SPLCTL or *JOBCTL, you already have a mismatch between the user class and special authorities. Second, there is NO reason why users of the *USER class of the application need either of these two authorities. Wait what? But my system will not work without these authorities you will tell me. But that’s just not right.
Change your queue parameters and authorities and you’ll fix 99% of SPLCTL/*JOBCTL issues. An example is the following. Many applications spool output as a common user. Let’s just assume the user is SPLUSER for now. Your users run your applications and the spool output belongs to SPLUSER. Now you find that your users cannot view spool 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 explains how to do this. I will spare you the reading of the tables. You can change the AUTCHK queue parameter from the default of *OWNER to *DTAAUT and give your users *CHANGE authority on the queue and now your users can read, delete and perform all actions on spooled files that they do not own or that belong to an application user.
Example: CHGOUTQ OUTQ(QGPL/TEST) AUTCHK(*DTAAUT)
Now you can probably remove *JOBCTL and/or *SPLCTL special rights while controlling access to private queues via *PUBLIC and private rights to queues. With *JOBCTL and *SPLCTL, you have no control over your queue rights.
Additionally, the Principle of Least Privilege (PoLP) is required by every compliance framework. Just read NIST Publication 800-53 and search for “Least Privilege”. You will find it referenced throughout. Section AC-6 states the following:
Use the principle of least privilege, allowing only authorized access for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
Discussion: Organizations employ least privilege for specific tasks and systems. The principle of least privilege is also applied to system processes, ensuring that 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 risks associated with *JOBCTL as follows:
RISK: A user abusing the *JOBCTL special authority can have a negative effect on individual jobs and overall system performance.
This is because *JOBCTL Special Authority provides access to terminate, modify, control, etc. from all work, including system work and the work of all other users on the system.
SPLCTL poses the following risk: the user with *SPLCTL special rights can perform any operation on any spool file in the system. Confidential spool files cannot be protected against a user with *SPLCTL special authority.
The other six special authorities grant administrators powerful privileges that can affect other aspects of system confidentiality, integrity, and availability, and almost all of them can be remedied by appropriate access controls and authority changes. queue. Appropriate use of adopted and swapped authorities can remedy the rest.
So, before giving users the Principle of More Than Least Privilege (PoMMtLP), consider the NIST PoLP requirements and read the IBM i Knowledge Center section on special authorities.
Agile creates technical debt which results in security debt which must be repaid with interest. Remember that lead signer of 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 of the small problem of small programming teams doing small things. Agile isn’t a big idea big deal about big programming teams doing big things.
Today’s breach-rich landscape demands a change in our major 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 hard to know what’s going on inside these large IBM i systems with too many authorities and special privileges that can be obtained in many ways through users, groups, *PUBLIC and private permissions profiles, authorities adopted and exchanged and much more. PAM is taking over all systems and zero trust is the new normal.
For those at risk, the time to remedy is now. For those who were violated, the time to remedy was yesterday.
Bruce Bading is a senior security consultant with over forty years of information security experience and 25 years of corporate experience. He is an IBM i security expert 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 communication skills, has worked with diverse audiences at all levels of the business to deliver training and education, and has led dozens of major enterprise risk management projects for the world’s largest organizations. . He is a member of the Information Systems Audit and Control Association, CIS reference author, and professional threat hunter.
Editor’s note: Bruce is one of many new Guru Experts we work with to maintain the Guru column within the four hundred. We look forward to the next in-depth security coverage Bruce can offer you as you work to secure your IBM i platforms in these interesting times.
Guru: the intricacies of exit points
Guru: IBM i Security *USRPRF
Guru: SIEM is just part of IBM i cybersecurity
Guru: Would you rather see a fire marshal or a fireman?
Guru: IBM i Unauthenticated Access