A while after helping a client initialize our software for the purpose of event auditing and compliance checking, I returned and asked how they were getting on. It was obvious from the evasive replies that the software was running regularly, but the resulting reports were being deleted without a glance. After we resolved their commitment issues, we were able to move on toward confirming that their system was defined as they wanted.
This event inspired a colleague to suggest that we ought to create a product called ShelfIT, an empty software box showing a plethora of marketing claims. This product would be designed for clients who are being visited by their auditors: To avoid difficult questions, the clients simply point at the box and say they were just about to install it!
All of us who are security software vendors know clients who invest a lot of time and money selecting the right tool but then fail to utilize the software to the fullest extent. However, times have changed. Federal and industry regulations are getting stricter, and auditors are much more knowledgeable--even about OS/400 and i5/OS. All over our industry, people are discussing the implication of the Sarbanes-Oxley Act (SOX): You need to change if you want to keep your senior people out of jail. Of course, the buzz will eventually die down, but don't expect the security status of your organization to become less important. The next regulation may be stricter and further-reaching.
As Pat would put it, "Do something in order to be free of danger or harm." Think of this article as the security equivalent of a reminder by your hygienist to floss regularly. Yeah, yeah, of course you do--twice a day!
Checking your system's compliance to an external standard or to an internal policy has always been common sense. Unfortunately, some companies chose to ignore these important procedures until recent federal regulations mandated that they do so.
Policy compliance means many things to many people. In this article, I will cover some of the elements of policy compliance I have found to be most critical for the organizations I have worked with in the past. One thing I will not do is tell you what your policy should be. I am not interested in an intellectual argument about whether your minimum password length should be six or seven or nine. Each individual check is only a very small element of the total picture. A system with six-character passwords that expire every 100 days can be in a better state than one enforcing "stricter" rules. If you enforce a 10-character password rule but provide no guidelines on how to remember passwords, then you will have password abuse--passwords that are written down, made up of repeating strings, or shared with other users. Ignoring the user element normally leads to bypasses and shortcuts.
You have to make a decision as to what makes your system secure and then follow your own rules. If you skimp, cut corners, or cheat, you might as well change your security level back to 10. Think of it like a building you want to secure; there is no point having a security alarm if you disconnect the bell, and there is no point in having a deadbolt on the door if the windows are open. And by the way, just because you were secure the last time you checked doesn't mean that you are today or will be in an hour or even in 10 minutes.
In the good old days, when audits were less important, our senior manager warned us when a visit was forthcoming. Of course, the first thing we did was to make the system look the way the auditors would want to see it. So old profiles were removed, default passwords were changed, system values were altered, and all those "Post-it" passwords were removed from under keyboards. I often wondered why the auditors never asked to see logs of all changes made in the week before they arrived--or better yet, performed a surprise audit!
I don't have time to cover all of the critical areas of a security compliance policy in this article. What I'll do is analyze the requirements of a few areas and in doing so, set the stage for a secure enterprise. Let's start by thinking about system values. There are a number of excellent sources of best practices that cover the security-related elements of system values. For example, there are books such as Experts' Guide to OS/400 and i5/OS Security by Pat Botz and Carol Woodbury, there are standards such as GSD331 and ITSC104 used by IBM Global Services, and there are the international standards such as ISO17799. But no one can tell you what the right set of system values is for your iSeries. The values you need are unique to your environment--a mixture of what is recommended, what you can achieve, what your applications require, and what is acceptable to your user base.
Let's go through each of these in turn, using as an example password length and expiry.
- Recommendations--As mentioned, there is no shortage of advice on how many characters passwords should be, whether they should be phrase-based, and when they should expire. Do not spend hours on these decisions.
- Achievable--Maybe a phrase-based password is stronger and easier for a user to remember, but if you cannot enforce this across all your systems, you should revert back to a character string. To avoid having users find ways to bypass your security intentions, try to give them consistency.
- Application-driven--Maybe you have an application that enforces password re-entry, and it must be six characters only. For consistency, you may choose six at the system level, too.
- Tradition--If the users--particularly senior management--have been safe and secure using six-character passwords expiring every 120 days for the last 10 years, then why should they change now?
Identifying your correct system values is an iterative process based upon many factors. What's more important is that you check for compliance regularly, without fail. Checking something like password length may seem pedantic, but if you notice that it has changed from 7 to 6 or 8, find out why. If the change makes sense, then change the policy too. If it doesn't, change it back.
One lesson we can learn from policies about system values is that policies must not be regarded as static. Situations change, new methodologies and applications are introduced, new system values and new options for those values appear. So to keep current with your policy, review it every time you make a major OS upgrade or application install.
So far, I have only mentioned system values as an example of the importance of compliance. That does not mean that it is the most important category to check. In fact, I would maintain that it is only by looking at the whole picture and treating all parts as equally important that your system will be regarded as properly secured.
Yes, profile definitions are important, as are object authorities, network attributes, JOBDs, etc. But don't forget the more unusual items--exit points, for example. By now, many of you have implemented an IBM tool, written your own processing, or bought one of the many exit point processing utilities to cover FTP, ODBC, file transfer, and so forth. Well, that's great. In fact, it's more than great; it's an essential part of an overall security policy for a modern iSeries or i5 platform. But do you monitor whether anyone has removed or changed those exit points? If you rely on an exit program to provide that extra layer of security for external connections, don't let someone bypass the system (either intentionally or unintentionally) by removing the exit point program for a period of time.
In addition to exit points, think about all of the other elements that will make your systems less securable if defined incorrectly. What TCP services are running on your systems? I know of many organizations that do not use security programs over one of the exit points because they don't have that TCP service active. OK, but if you don't have someone with a security focus watching the QSYSOPR message queue every moment of every day, will you know when that service has been started?
This brings me back to the client I was talking about at the start of my article. We made three fairly simple recommendations that pointed our client in the right direction:
- Print event reports as well as compliance reports. For instance, if someone changed a system value and then changed it back just before the policy reports were generated, would you know? If you are using an event auditing tool, you will have a record of both changes and who made them. A complete picture.
- Print filtered reports rather than all the data you find. For example, if you have a list of profiles that are supposed to have a certain group of special authorities, don't report upon them every time. Only report upon deviations from your policy. Similarly, with event auditing, don't report upon the millions of object ownership change messages generated by your application software. If you can't stop these events from being generated, don't print them as they tell you nothing new.
- Assign senior personnel to check the reports daily. This way, the reports are filtered so that only the critical events and parameters are seen. The senior management will ensure that all of the excess is trimmed from the reports.
This new commitment to auditing and compliance can only benefit you during future audits. Prove that you are committed to your standards, and you may find that the auditors will start to focus on other aspects of the organization. And you can get back to your real work.
Martin Norman is Senior Systems Engineer for SafeStone Technologies, an IBM BP specializing in compliance and identity management. As one of the original developers of SafeStone's security portfolio, Martin has performed security audits and has advised on installations for clients throughout the United States and Europe. Martin can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it..
LATEST COMMENTS
MC Press Online