IBM i Partitions: Six Configurations to Create a More Secure System
We’ve said it before and we’ll say it again…The IBM i is highly securable, but it doesn’t come that way.
It’s up to you to ensure that your IBM i partitions are protected from unwanted access once a new IBM Power system arrives, or when you are setting up a new LPAR. Here are six things you need to configure properly in order to ensure that any new IBM i partitions are secure and protected from threats originating both inside and outside of your organization.
#1: Check your sign-on attributes
The first step to gaining access to your IBM i is the sign on screen. Weak sign-on attributes can put your system at risk. This is why it’s important to control things like who can sign in, when they can sign in, where they can sign in, and how they can sign in. If your sign-on attributes are weak, it’s like leaving the key in the front door, while locking it from the inside. You make it easy for the wrong person to gain access to your system.
#2: Secure programs that can run under adopted authority
Adopted authorities can be very helpful since you don’t have to grant users excessive privileges in order to execute a program. They can also be risky, because the adopted authorities stay in place for as long as the program is in the call stack. If not implemented properly, a user may be able to access objects beyond the program, especially if they can gain access to a command line. Adopted authorities are like having a master key to the whole system. In order to truly protect your system, mainly your IBM i partitions, make sure you know which of your programs use adopted authorities and secure them accordingly to prevent abuse.
#3: Set more stringent password control requirements
Almost as bad a leaving the key in the front door is making the door too easy to breach. Poorly implemented password control can leave your system exposed. It’s important to have password controls which limit the amount of time a password is valid for. And make sure that your users are forced to change their passwords periodically, preferably no longer than once every 90 days. It’s also important to have adequate password level protection to help ensure that your system is more secure, including setting password parameters for things like:
- The minimum length of passwords
- Not allowing users to reuse previous passwords
- Not allowing users to use certain characters (such as vowels) in a password to make their passwords harder to guess.
- Disallowing repeating characters
- Requiring a specific digit inside each new password
Setting more stringent password requirements makes it even harder for the wrong person to gain access to your IBM i partitions.
#4: Limit exit point access
While they were designed to assist with integration and automation, exit points can also put your system at risk. Exit points allow your IBM i to interact with other platforms and applications, exposing your system to threats from the outside. It’s important to know how your exits points are being used. I’d liken exit points to leaving your windows unlocked. Violating network protection standards isn’t as bad as leaving the key in the front door, but it still leaves you exposed. It’s much better to create a process that prevents users from accessing certain exit points.
#5: Restrict user privileges to their lowest authority levels
Too many users have more authority than what they actually need to perform their day to day duties. Granting users the proper level of privilege is key to protecting your system. Users with *ALLOBJ authority have a lot more power, which can put your IBM i partitions at risk. If their user profile falls into the wrong hands due to weak password protection or sign on attributes, your data can be in real trouble. It’s important to restrict user access to the lowest level necessary in order to perform their day to day activities and to provide a mechanism for allowing higher authority only when needed.
#6: Take advantage of auditing system and user activities
Your system is also exposed if you are not auditing system level and user activities. Auditing provides a trail, so you know what has happened and who did it. Auditors want to know things such as when objects are created and deleted and by whom. Without auditing turned on, you cannot capture this information. Similar to having security cameras set up to watch what is happening, IBM i auditing will record what has happened in the event that you need to go back and look at it or provide documentation for an audit.
#7: (Optional but valuable) Get an free IBM i security assessment
Want to know if your IBM i system is at risk with any of these areas and more? SEA offers a free iSecurity Assessment which will provide you with a detailed report of the risks you currently face with your system settings and provide you with recommended solutions that can help protect your system further. SEA’s solutions can provide you with visibility about what is happening within your system and how to prevent users from taking actions that are against your security policies.
