Following standards and regulations like NIST, the PCI-DSS, SOX, and HIPAA is of course necessary for compliance purposes – but doing so can also help limit dangerous misconfigurations in an organization’s infrastructure.
Unfortunately, the IBM i is frequently overlooked when standards are being implemented across the overall infrastructure. This leads to the presence of critical misconfigurations that leave systems susceptible to attacks and are perceived as unacceptable in the eyes of auditors.
For those responsible for managing compliance on IBM i, this blog post will outline some of the most commonly overlooked aspects of IBM i compliance, how you can configure them correctly, and how Fortra helps resolve and prevent misconfigurations so you can stay compliant and secure.
IBM i Password Management and PCI-DSS
One of the most overlooked practices in IBM i security is removing the presence of default credentials on systems. PCI-DSS requirement 2 specifically advises not using default values for passwords. Default credentials are often the preset usernames and passwords provided by software providers for initial setup and testing. On the IBM i, this refers to when the password is the same as the profile name.
While default credentials offer convenience for initial configuration, leaving them unchanged poses a significant risk. Until the release of IBM i OS Version 7.5, the user profile served as the default password for a new user profile when it was created. Best practice for new profiles is to have the password changed on first use, however, they are frequently left unchanged.
It is common for profiles that are being used for interoperability processes to be set this way and never changed. Several of these profiles are recognized throughout the IBM i community, and bad actors can readily exploit these well-known and frequently public credentials, thereby gaining unauthorized access to systems and sensitive data. Risk of data breaches, system disruptions, and reputational damage are much greater when these credentials are present.
I once worked with a customer running a common ERP system where the critical profile that was enabling the exchanges of data still had a default password configured. This simple misconfiguration was putting their data at extreme risk of being stolen and manipulated. They were able to quicky identify this using Powertech Compliance Monitor for IBM i by running a simple Profiles with Default Passwords report.
Stay Compliant by Minimizing Elevated Privileges
Elevated privileges or authorities are described as additional granted permissions to specific users, allowing them to access resources or processes beyond those available to a standard user. Configurations that lead to excessive elevated privileges are seen as a weakness during audits or compliance reviews – especially for standards and regulations like PCI-DSS, HIPPA and SOX.
On IBM i, elevated privilege can be a special authority like *ALLOBJ or private authority to specific commands or data objects. These elevated privileges are intended to assist in managing and protecting sensitive data, maintaining system integrity, and ensuring uninterrupted business operations. The granting of such privileges requires vigilant controls and monitoring to prevent unauthorized access or potential misuse.
Consistently and effectively managing and monitoring elevated privileges are fundamental requirements of regulatory compliance frameworks. Rather than maintaining a constant state of elevated authority, it should be granted temporarily, solely for the duration of the necessary process.
I have witnessed many customers use the Powertech Authority Broker for IBM i application to reduce the number of user profiles with special authorities and enable the temporary elevation for specific users at specific times. This is a game changer for organizations that have a lot of users requiring elevated authority to run specific processes, and therefore don’t require constant elevated authority. Powertech Authority Broker also provided detailed reports of the activity that was performed while the temporary elevation was in effect.
Removing Inactive Profiles for SOX Compliance and Least Privilege Access
The process of removing inactive profiles should be a standard practice. Frameworks like SOX rely on this heavily for achieving least privilege access. Profiles often remain for years after they are no longer needed on a system. It is an important aspect of system management and security to remove any unused profiles as soon as possible.
Best practice is to remove unnecessary profiles (unused or inactive) as quickly as possible. Inactive profiles are often a recurring finding in audits. These profiles may own many objects, have elevated authorities, or even elevated access within applications and therefore pose significant security risks that include unauthorized access and potential system manipulation.
A great example of how inactive or unused profiles can remain on a system came while providing a Risk Assessment to one of our Managed Security Service subscribers. A customer noticed that their method for eliminating inactive profiles was not functioning, resulting in hundreds of profiles remaining on the system that were supposed to be deleted. Using the provided Powertech Policy Minder for IBM i application, we were able to assist the customer in removing these profiles.
Why Should You Focus on IBM i Compliance?
The importance of adhering to internal standards using a NIST or COBIT framework or external standards like HIPAA, ISO 27001, PCI-DSS, or SOX cannot be overstated. These standards and frameworks are designed to safeguard sensitive data and maintain the integrity of financial and proprietary information. In this ever-changing landscape of threats, missed configurations can lead to exposing organizations to potential data breaches, legal penalties, and reputational damage along with non-compliance.
Regular audits, proactive monitoring, and prompt correction of any identified misconfigurations are essential. By focusing on these often-overlooked aspects, organizations can bolster compliance and security while minimizing the risk landscape. It is important to note, however, that being compliant does not mean that you are secure. Regardless, maintaining compliance can be a good place to start your security journey.
Ready to Start Your IBM i Compliance Journey?
See for yourself how Powertech Compliance Monitor for IBM i organizes audit and security data from all your systems, making it easy to maintain your audit record.
