A Comprehensive Guide To IBM i Security

This report was originally intended to outline IBM i security best practices, covering areas like security related system values; password controls; user special authorities; object authorities; data masking, etc.

However, if you look on the Internet it’s full of information on IBM i security ranging from the basics right though to advanced security controls; and so I would run the risk of repeating a lot of what has gone before.

IBM i is one of the most secure computer platforms available and yet it can be, and often is, very insecure. How’s that for a contradiction? It’s not through any lack of controls on the system or the inability to find the right information. We continually find that the IBM i is not as secure as it should be. Perhaps we need to take a step back when looking at IBM i security best practices and think about the following information before just reading another review of what IBM i can do technically.

The IBM i has security built in from the ground up, right from the hardware through the Operating system; into the applications and interaction with other platforms; hence ‘i’ means integration. And everyone has been told about how secure the IBM i is. It’s true, to a point. The tools available for administering security are powerful, flexible and easy to use. Why then might such a secure platform have a security problem? The simple answer is that those tools are not being used. Security doesn’t just switch itself on, out of the box. It has to be configured. Maybe, incorporating security slows down application development; costs money to incorporate (someone has to do it and they have to be paid) and adds nothing to the functionality of an application. It adds nothing to the bottom-line. What good is that bottom-line when the system has been hacked; valuable (maybe priceless) information has been stolen or damaged. Perhaps your company is being held to ransom to get that information back.

Let’s start our security best practices review with the following – We have to rememeber that IBM i security has to be configured by someone; it doesn’t just happen. You should base your IBM i security on your company security policy. The business security policy, in essence, covers ‘how should your employees, customers and complete strangers be able to use your company’s information?’ Therefore, align your IBM i security policy to your business security policy. This gives you a base from which to start.

Get used to the idea that administering security is not a one-time function. It’s ongoing, never stops and you should have someone looking after it all the time. It will need configuring, testing, auditing and changing to meet the changing environment of your business. Employees will come and go; responsibilities will change; information will change and so will it’s value. If your security configuration doesn’t adapt it will become out of date and your information will be vulnerable.

Don’t assume all your threats are external, you need much more than good network security. Be aware that your own system administrators, programmers and users often have more access to sensitive information than they need. They should only have enough capability to do their job and nothing more; yet we often find that administrators and programmers are able to view the contents of sensitive database files.

Think about what 3rd party security tools give you, and what they don’t. There is some fantastic 3rd party security software available but use it correctly. They work well when first set up and your focus is on them, but as we have said, environments change; personnel change; information changes. Have you checked that your security tools are still doing what they were configured to do – security is not a one-time job. You must continually review and if necessary make changes. 3rd party security tools still require you to have a solid grounding in IBM i security; either yourself or access to people with IBM i security knowledge, whether they be in-house or external. For example, a security tool may continually review user profiles and tell you that you have too many users with *ALLOBJ special authority (the ability to work with every single object on the system).

You still have to know what this means; how much of a threat it poses and, more importantly, what to do about it. I believe that there is no substitute for having people (or access to people) that understand IBM i security. Good 3rd party tools are great for helping you take the drudgery out of security control; whatever they’re configured for they will constantly monitor your system for violations, etc (even when you’re not working) and may even correct those violations. But they are not a replacement for having the fundamental skills.

Earlier we talked about how internal technical personnel often (usually) have more access to the system than they need to do their jobs. This often comes about because it is far easier to give a user profile *ALLOBJ special authority than to give them only what authorities are necessary. The next recommendation is – Don’t take shortcuts. There’s no doubt that security administration takes time and effort but consider this – what would a company’s owners or shareholders rather have; the latest and greatest application and compromised back-end security or a functional application with excellent back-end security. Ideally it would be the best application with the best security but with finite resources you have to decide carefully. That great application won’t do much for your business if the information is stolen or damaged.

The next thing to consider as a best practice is to restrict access to system objects, such as database files, by default. For example, when new objects are created or amended any user that needs access to them should be specifically given access to them; not the other way round which relies on users having to be specifically excluded from using them if they don’t need to use them. The latter situation is observed quite regularly and is far harder to control.

Always think of security at the object level as well as the application level. Many people assume that their information is secure because their applications can only operate in certain well-known ways. However there are many ways that information can be accessed outside of applications using tools like ODBC, JDBC, FTP, etc. If you secure a database file object correctly it will be better  protected for different access methods.

Set up and use the security auditing capabilities on the IBM i. Initially this will give you a real understanding of who is accessing your information and when. As you continue to implement more security controls and plug gaps auditing can be used to trap security violations.

Think about security every day; make it part of your daily workload and not when the next audit comes around or it becomes project of the month. The amount of work necessary to control security can be large but if your company has taken the decision that certain information is critical or must be protected by law (who does that leave out?) then why not build it in to your daily routines; get the message out that it’s important. As a start it may deter the curious from looking at things they shouldn’t.

Don’t try and secure everything to the same degree all at once. Your applications may consist of thousands of objects such as database files and programs. Protecting every single last one of them may be unnecessary. Only a handful of objects may require complete security (i.e. it would seriously damage your business were they to be damaged or stolen); focus on them and work out how to protect them. The other parts of your system can be protected with a good backup and High Availability strategy.

At the beginning I said that there was plenty of technical information available on securing the IBM i. My aim here was to cover the less well obvious aspects of security. I hope you take away the following – ‘The IBM i is one of the most secure computer platforms available if you configure it to be secure; continually review that configuration and adapt it; don’t make assumptions about where your threats may come from and keep security in mind every day.’