Anything that you can do to discourage unwanted access to your IBM i system is a good idea. So, when I heard about Port Restrictions, I immediately thought that it would be a great idea to just shut down all the unused ports on our test box.
The classic IBM i signon screen has been around since forever. I first saw it in 1988 when I took delivery of my first AS/400 system, a lowly B10. In the old days, the appearance of the signon screen made no difference since the system was a closed system. With the advent of networks, this situation changed dramatically.
With more and more people working remotely, controlling remote access to your IBM i from 5250 terminal session users is more important than ever. More IBM i shops are opening their systems up to remote access and a terminal session exposes your system to potential abuse.
Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems. For them, the interface is well known and comfortable. The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.
In the modern IBM i implementation, if your data files have public access to all users, then someone can connect to your system with FTP and download to their heart's content.
The special user profiles on your system that are set up as security officers really do have the keys to the kingdom when it comes to accessing your system.
While most users are trustworthy, there is always the opportunity for inadvertent damage to your data from someone who happens to get into your system through a door that should be closed to them.
Security exit points on the IBM i (and its predecessor OS/400) have been in existence since the mid 1990's. When the system was opened up to network access, the need for additional security over and above the standard IBM i OS security was apparent.
Programmers know how things are handled internally in your systems and know how to get around in the system. If a programmers wants to get at some secured information, they probably have the knowhow to do it.
Using the exit points, you can add protection for FTP, ODBC, File Server, Remote Command submissions and much more. This has gone a long way towards making the IBM i a truly secure platform.
One thing to keep in mind is the proliferation of user profiles with special authority of *SPLCTL. This is the equivalent of the evil *ALLOBJ authority, but as applied to spool files.
If you have sensitive or confidential information that is being stored in a print spool file, the best way to secure it is to create a special output queue (or set of output queues) that are secure to a known set of users.
Your best approach is still to limit user's ability to run commands directly from the command line. But, if you absolutely have to allow it, then make sure that an inquisitive users doesn't accidentally (or purposefully) run a bad command.
When a user on your IBM i system signs on to a terminal session, they will be presented with a command line. Given enough security permissions, a user can do just about anything from that command line, if they are inquisitive enough.
A performance issue that has security implications can happen when someone with the right special authorities on their user profile abuses those and consumes excessive system resource in their own interest.
What should you include in your checkup? Here's a list of things to start with. It is by no means comprehensive but will probably get you started and lead you into the areas where you need to be concerned.
The whole point of the FTP hack is to discover working user profiles and, hopefully, also uncover one that is using a very common password. Once a hacker has this, they are ready to come back via Telnet or some other server connection and really get into your system. You need to be prepared to stop them before that can happen
The user profile is your first line of defense in the ongoing battle of protecting your system. When a new employee shows up for work, you go to great lengths to get their profile set up just right.
Here is one way that you can review who is reading and even who is changing data on an individual object-by-object basis on your system. That is by using object auditing, a built-in feature of the IBM i OS.
On a PC using IBM i Access, the first time you log into the system for the day, there is an IBM i Access logon that establishes connection from the PC to your host system. Then, there may or may not be another logon for your terminal session.
Most IBM i installations run a scheduled save of their system to transfer files, programs and other objects to tape or other media for safe keeping. Saving the system on a scheduled basis is just good practice since the catastrophic loss of a single disk unit on your system can mean that you loose everything on your system.
Ever since the introduction of IBM i/OS V5R1, a system value for "Password Level" has been available (QPWDLVL).This value lets you have control over the kinds of passwords you use on your system and how the system treats them. Using the features provided through this value, you can implement passwords of up to 128 characters in length.
There are two things that you need to test and evaluate on your system. First, you have to make sure that users have sufficient authority to get all of their work done without a problem. Once that has been established, you then need to go back and make sure that users don't have too much authority...
The best time to test a user profile is when you initially create it. If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives. This article will assume that you have your user profiles organized into groups with group profiles active.
The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems. This is the way it comes from the factory although it is easy for the default setting to be changed. When programs are compiled with the *USER setting, then you can count on your object security setup to provide the proper control over access to objects on your system.
Users are allowed enough access to fulfill their job descriptions but not so much that they can wreak havoc for your organization either accidentally or intentionally. And, to a large extent, your trust of the person behind the profile plays a large roll in how much access you give them to your system.
Here is an easy way to implement a tracking system on an IBM i database without any significant programming on your part. This technique takes advantage of the IBM i database audit journal features.
If you just want to check up on someone, the IBM i has very good auditing capabilities that you can use down to the individual user level. And, you can do this without a major headache. You can target a specific user and leave the others out of it.
With your system attached to a network on a full time basis, and with the network interconnected to the Internet on an around the clock basis, trusting your data protection to a single piece of technology is just a bad idea.
If you want to track the history for a user profile, it is entirely possible to get all of the significant changes to the profile using the audit journal. There are two specific journal audit records that you will need to consider when reporting on these events.
When planning out the security policies for your trusted IBM i installation, security officers can often overlook the special requirements that programmers will have. This tip will try to provide some ideas of how to best deal with this situation.
Given that guessing a user profile can be pretty easy, it makes it very important that passwords not fall into the category of being easy to guess. For many years, the IBM i OS has provided tools to let you implement a variety of measures to help you with this goal. This tip will look at some of these and point you in the direction where you can find even more.
In the IBM i world, context can define how you handle security. Security in the OS is not attenuated to context, so you have to think about your requirements and implement contextual considerations as they apply.
Every IBM i shop has a few super users that you, as security officer, have to be concerned about. For one reason or another, a few user profiles just have to have full access to your system. This tip will show you one way to check up on what these users are up to, using the system security journal.
When you have to switch over to a disaster recovery site, you will need to have your security plan in place and built into the recovery process.
Is there a point where security is just too much for your installation?
Just how much security is enough security for your IBM i? This tip will explore this question and, hopefully, get you thinking about your own environment.
Typically, a "Script Kid" attack will repeatedly attempt to log on to your system using a well known profile name. Fortunately for IBM i security officers, the most common profiles used by the Kids are ADMIN and ADMINISTRATOR which are very popular profiles in the Unix world.
As an IBM i security officer, you are concerned with granting access rights to users. To do this, you need to know what the user's job responsibilities are and what they will be doing within the computing environment. Based on existing security policies for your shop, you then configure security for each user so that they can get at the computing resources they need to do their job easily, smoothly and securely.
When your IBM i is prepared in the factory, it is set so that most system commands and APIs have a public authority of *USE. This setting will let anyone use just about any command or API on your system. But, some of those commands and APIs could be used for malicious purposes.
In response to a recent tip, I heard from a reader who suggested a good technique that they use for managing a large base of user profiles on their system. They submitted this suggestion and I've been playing with it and it really does give you the basis for managing your user profile base quite nicely.
Secure access to your system often starts with your user profile and password policy. If you've been working in the IBM i world for any length of time, this is very familiar territory for you. You may even have this task assigned to an underling who maintains your user profile base without any instruction or interaction from you.
Since people are so bad about choosing passwords, having a user profile that is easy to guess makes a scripted attack very possible.
Who would ever guess that restoring user profiles would end up hosing your digital certificate files?
For years, Kisco Information Systems has kept a lone test IBM i server hanging out directly on the Internet. No firewall, no security appliances, just a direct connection with a dedicated IP address.
With each user profile on your system, there is an "Initial program to call" (INLPGM) parameter. Whenever someone signs onto your system, the operating system checks this parameter and, if there is a valid program present, calls it. You can take this feature and use it to create your log of user profile sign-on activity for selected user profiles.
When you have security auditing active on your system, all sorts of relevant security information is regularly stored in your system security audit journal that will help you to know what's going on with your system. This is a great feature for the IBM i OS, but capturing the audit information and then using it in a meaningful way are two different things.
There are also many shops where certain users claim that they need to be defined to the system as security officers to get their jobs done. Now, we all know that this is just not true, but some shops cave in and provide these authority levels as a form of appeasement. So, if you're the security officer in one of these shops, it is really incumbent on you to know two things.
Once you've got your system backed up including all of the security information, what's the best way to make sure that all of that security information is restored correctly when you have to do a full system restore?
Have you given thought to how your security policies are stored on your system and how they figure into your backup process? If not, you might be in for a rude awakening when you need to restore your system following a catastrophic system loss.
Many people, self included, take this time of year for a little introspection. We try to see where we have problems or weaknesses and then contemplate methods and strategies to make changes. If we're serious, we'll sit down and make a list of things to do in the New Year. As the security officer for your IBM i shop, this is a good opportunity to do just that for your installation and here's my list of some items you should consider.