Best Practices for Managing Elevated IBM i Authorities – Part 1

This article on managing elevated IBM i authorities was originally published in Enterprise Executive. Part one of this two part post focuses on how elevated authorities can create the risk for a data breach, how IBM i users can obtain elevated authorities, the challenges of managing elevated authorities, and the role of elevated authority management solutions.

When organizations have too many powerful users, it leaves systems and data exposed to security breaches and other forms of cybercrime. That’s why security best practices and regulations such as SOX, HIPAA, the Federal and North American Information Practice Act, GDPR and others require organizations to restrict user privileges and monitor the actions of powerful users.

 On an IBM i system, special authorities grant users the ability to:

• create, change or delete user profiles
• change system configurations
• change or limit user access

Special IBM i authorities such as *ALLOBJ and *SECADM are infamous for wreaking havoc – especially if in the wrong hands – as these authorities provide full access to all data on the system.

Users with powerful authorities can access data such as customer lists, source code, financial information, valuable intellectual property, employee HR files, and other sensitive corporate information. These users could even install malware on production systems to give accomplices full access.

While most insider incidents are due to negligence caused by improper configuration of system security controls, the fact is that insider cybercrime is increasing. A recent study from Verizon found that 15% of data breaches and 20% of data security incidents were related to insider activity. “Insiders” may be employees, contractors, or business partners motivated by financial gain, revenge or achieving a career advantage.

Because insider data security incidents can be so destructive, compliance auditors require that special authority be granted to users only when needed and only for the time required. Security best practice requires separation of duties so that even administrators have someone monitoring their actions and the security measures they are putting in place.

Outsider cybercrime is just as much of a threat. If a competitor or criminal organization obtains access to sign-on credentials for one user profile, they may work to elevate its authority and maximize their access to systems and data.

Detecting abuse of authority can take years because the activity may look like an employee performing a routine task. Ultimately, managers may be held accountable for system intrusions or data theft.

Elevated authorities create data breach exposure

Controlling user authorities helps your company meet the regulatory requirements in SOX, HIPAA, the Federal and North American Information Practice Act, GDPR and others. Failure to comply and data breaches can cost thousands – or millions – in fines and remediation expenses.

On average, the cost of a data breach for U.S. businesses is $7.9 million according to research by the Ponemon Institute. Every lost or compromised record costs American companies an average of $258. After a data breach is discovered, an organization may be faced with huge expenses, including expanding helpdesk and customer service headcount, hiring outside remediation experts, legal fees, identity protection services, regulatory fines, creating a contact database, hiring outside experts, and handling an onslaught of phone calls and emails.

To help avoid the tangible and intangible costs and the risks of a data breach, users should only have the authorities required to do their jobs.

How do IBM i users obtain elevated authorities?

On an IBM i system, a user’s authorities define what they can do – the menus they can access, commands they can run and the actions they can take. How a user’s authorities are defined is a complex mix of how their profile is created, the groups they are in, and what they inherit from those groups.

Powerful special authorities can be granted to users as well. For example, users with the *ALLOBJ special authority can access every object on the system; users with *SECADM can create, add, and delete user profiles; and the *JOBCTL special authority allows users to stop subsystems or even perform an IPL.

IBM i user classes can also be assigned to control the menu options shown to a user, which defines their access to system functions. For example, profiles with the *SYSOPR user class receive the *JOBCTL special authority so they can manage jobs as well as the *SAVSYS special authority that allows them to save, restore, and free storage for all objects on the system.

This complex combination of factors contributes to the creation of powerful user profiles. Powerful users are said to be “highly privileged” or to have “elevated authority.” To keep data safe, regulations require that elevated authority be controlled and monitored.

The challenges of managing elevated authorities

Regulations such as SOX, HIPAA, GDPR and others require that elevated authority be granted only when needed – and just for the time necessary. Fines for non-compliance violations can be stiff, and resulting data breaches and other cybercrimes are increasingly common and costly.

Compliance auditors recommend that users be given only the minimum set of authorities required to do their jobs. However, users may occasionally need elevated authority for special purposes. For example, temporary elevated authority may be necessary for a third-party consultant who is implementing a new solution, or an administrator who needs to change system settings.

If users are granted elevated authority on a temporary basis, compliance auditors still want to see audit logs on the actions taken by those users while their authority was elevated. An audit trail is key to proving compliance.

The need to track the activities of users with elevated authority extends to administrative users as well. Enforcing separation of duties by granting only necessary privileges, elevating authority only as needed and for a limited amount of time, and monitoring administrators’ actions is another security practice that regulatory compliance auditors demand.

Many organizations struggle with managing the number of user profiles with elevated authority on their systems, implementing a process for granting and revoking temporary authorities to keep the number of powerful profiles at a minimum, and tracking the activities of elevated profiles.

Manually granting elevated authority is a cumbersome and time-consuming endeavor that is fraught with risk. Administrators are often inundated with requests from vendors or employees, who may or may not have permission or a valid reason for the application. Once granted, revoking elevated authority when a project or task is complete requires a manual reminder process that usually doesn’t exist.

Weaknesses in this manual process become painfully evident in a compliance audit or dry run. During audits organizations often find that employees, former employees, or vendors still have powerful access to IBM i systems long after they require it.

The process of manually granting and revoking access to IBM i systems isn’t safe or efficient. Automating the process via an elevated authority management tool can help organizations relieve the burden on administrators, track actions of elevated profiles, and meet the most stringent security requirements.

The role of elevated authority management solutions

Solutions that manage elevated authority let you take complete control of user authorities – automatically granting elevated authority as needed and on a time-limited basis.

An effective elevated authority tool must enforce segregation of duties as a security best practice of checks and balances, allow for the reduction of the number of powerful users, and produce alerts, reports and an audit trail of activities performed while in possession of elevated authority to demonstrate compliance.

The ability to integrate with help desk ticketing systems so administrators can see the requests for elevation also increases efficiencies and bolsters security.

And, as explained below, elevated authority management should support both *SWAP or *ADOPT methods to temporarily elevate authority if they are to cover authority requirements for all file systems on the IBM i.

Check out part two which explores some methods for elevating authority and shows you how Assure Elevated Authority Manager lets you take complete control of elevated user authority.

To learn more about the top IBM i security challenges, strategies, technologies and best practices of surveyed IT pros, read our eBook.