If you're like a lot of System i shops, your auditors have probably expressed some concern about securing your System i. But, if they are like most auditors, they probably have a very limited understanding of the security issues that System i administrators should pay attention to. Few things are more frustrating than having an auditor write an audit exception item for something when you know the audit exception item is either wrong, irrelevant, or both. Then you spend hours of your scarce time either fixing something that isn't broken or trying to convince others that it doesn't need to be fixed. So how can you head off this all-too-common nightmare?
One way is to crack open various IBM manuals and texts and bone up on security. That's not a bad idea, but it takes time and energy that many system administrators don't have an abundance of. Another option is to hire an outside consultant who can assess your environment and recommend improvements, but knowledgeable OS/400 security consultants can be hard to find. Furthermore, some less-than-expert-level security consultants can give you advice that is no better (and sometimes worse) than what the auditors recommend.
A better way is to manage your auditor and the audit process. If you can anticipate what the auditors are going to focus on, you can be prepared to address their concerns, state your shop's standards, and document exceptions before the auditor starts a game of "gotcha."
A key to managing auditors is to know what their modus operandi is. Auditors follow standards, frameworks, and policies. They love to see predictable, repeatable processes that can be documented, audited, and verified. When auditors land onsite, one of the first things they do is ask to see your security policy. If you don't have one, they'll pull out their own—usually based on a well-recognized standard such as COBIT, ITIL, or IOS17799—and then begin to compare your system to it. And you can bet you're going to have a hard time measuring up to that!
So get ahead of the auditors, and put a security policy in place before they arrive. It doesn't have to be overly complicated; it need only be a clear recitation of your standards and expectations. It should, at a minimum, address the basics like password length and difficulty, profile groups, special authority, system and network value settings, and backup and recovery procedures.
If the thought of concentrating for the next few days on a security policy distresses you, take heart. PowerTech has open-sourced an OS/400 security policy template that you can download for free and use to quickly create your own security policy. It contains expert advice and recommendations for security policy and security system settings, and you can use it as-is or modify it to suit your needs. The PowerTech open-source policy has nine major sections that cover the important foundations of an OS/400 security policy and also some suggestions on topics that will be documented in future versions. As with many open-source creations, you are encouraged to use the policy, share it with other OS/400 customers, and even make enhancements and suggestions to the document. If you enhance the document, send the results to
To download a copy of the policy, visit www.powertech.com/powertech/PowerTech_Web_Policy.asp. A registration step is required so that we can notify you of changes and enhancements to the policy so that you are sure to keep up-to-date on the latest thinking in OS/400 security. Take a moment today to get ahead of your auditors. You'll be glad you did.
John Earl is Vice President and CTO of The PowerTech Group. He can be reached at
LATEST COMMENTS
MC Press Online