Over the last year, I have been asked questions like "Is iSeries SOX-compliant?" or the same question with "SOX" replaced by any of your favorite government security regulations or industry standards. This question is normally asked with the expectation that computer system vendors can somehow build computer systems that are inherently "compliant" with arbitrary regulations or standards. These questions indicate a basic lack of understanding of the process of securing a computer system hosting business assets.

Absent a basic understanding of the security process, compliance with any regulation or standard will be hopelessly confusing and seemingly complex. So let's take a brief look at the security process. The process of securing anything can be broken down into three phases: 1) defining who can access what and for which purposes, 2) configuring security mechanisms to implement the access defined in the first phase, and 3) measuring how accurately the defined access has been implemented.

Phase 1 defines your security policy. Security policies are inherently specific to each organization. For any given security policy, there are numerous possible implementations.

Phase 2 involves implementing your organization's security policy. Policies are implemented using tools and mechanisms provided with the computer system, purchased from a third-party, or both. Phase 2 is relatively straightforward, assuming you have defined a security policy. Unfortunately, most organizations start the security process at phase 2. Starting the security process at phase 2 is like packing the car and driving off for a vacation without first deciding where you're going or how long you'll be there. So it's no wonder that security configuration and compliance seems so complex.

Phase 3 is the process of determining if you have accurately and adequately implemented (in phase 2) the security policies defined in phase 1. This part of the process is referred to as an "audit." A formal security audit should start with an analysis of your security policy and only then proceed to measuring whether you have properly implemented that policy.

How Regulations and Standards Affect Security Configuration

This brings us back to complying with government and industry regulations. Because most organizations are unaware of the necessity of defining a formal security policy, they assume that standards and regulations apply directly to their security implementation. This is an invalid assumption. SOX, HIPAA, and the myriad of other government and industry regulations and standards first and foremost affect your security policy. In fact, they are elements that are required in your organization's IT security policy; they do not directly specify how those elements are implemented on specific systems.

How you implement the required policy elements, as well as the rest of your policy, is up to you. The rest of your security policy will likely significantly affect the way you choose to implement the elements of policy required by regulations and standards.

Since regulations and standards define policies but not policy implementation, no computer or software manufacturer can possibly provide products that are inherently compliant. It's your usage of these products that must be compliant, not the products themselves.

Compliance, therefore, presents you with three problems: incorporating regulations and standards into your security policy, implementing the new policy requirements, and proving you have implemented the required policy elements.

Unfortunately, I am not a policy expert. I wouldn't even begin to assume that I could help you define policies that are compliant with anything. Fortunately, however, I do know a bit about implementing policies in the easiest, most cost-effective way. Therefore, I'll provide some advice on implementing policy and measuring whether or not you have adequately and accurately implemented your policies.

How i5/OS Helps with Compliance Issues

The good news for implementing a security policy on systems running i5/OS is that many of the functions you need to enforce any policy are integrated in—and automatically or easily enforced by—the system itself. These functions don't secure your system. Nor do they make you compliant. They do, however, make it easier and cheaper for you to implement the enforcement of your policy, which makes you compliant.

What are these functions? The same ones that most people assume somehow make the system inherently secure; they don't and it isn't, but that's what people assume. For example, the object-based architecture of i5/OS, the hardware-based pointer attributes, and the trusted translator make it fairly cheap for you to ensure that a native i5/OS virus doesn't infect your system (as opposed to the cost of ensuring a PC virus doesn't infect your PC platforms). The deeply integrated nature of many of the security functions gives the system a very high level of integrity, so you can spend much less money on additional processes and products to monitor and protect the enforcement of your security policies.

These are just a couple of the numerous functions and attributes that make implementing an arbitrary security policy on your system easy and inexpensive. But these functions don't implement your security policy. They cannot and do not determine who can access what on your system. They merely make it easier for you to implement your enforcement of these policies.

Implementing Compliance

The system provides numerous tools and functions that you configure to meet your policy. The first and most important is object-level access control. In today's environments, the only way to adequately implement any policy is through an exclusionary access control model. This model assumes that everyone is denied access to any object unless specifically granted some level of access.

There is no shortcut or alternative to implementing an exclusionary access control policy—not even exit point programs. Exit programs are an excellent way to provide access to individuals who are not otherwise authorized; they cannot prevent access from individuals who are authorized.

Implementing object-level access control can be a daunting task, especially on a system that has no defined policy and hasn't exploited object-level access control in the past. In a two-part article last May and June, I described a rigorous process that gets you to an exclusionary access control model while minimizing the risks to your production environment.

The system also provides any number of mechanisms that provide flexibility and ease-of-use for implementing your policies. System values, profiles, group profiles, authorization lists, adopted authority, various user- and group-swapping mechanisms, support for multiple authentication protocols, data encryption algorithms, operating system exit points, etc. are provided so that no matter the policy, the elements of that policy can be adequately and accurately implemented while minimizing the cost to implement and manage those policies.

With respect to security and compliance, if your security policy includes the elements required by regulations and standards, and you have accurately and adequately implemented those policies, then you have secured your business assets and are compliant.

Proving Compliance

That brings us to the third problem associated with compliance: proving you have implemented your policies. If everyone understood their roles and responsibilities, this would be a much easier problem to address. Corporate executives, legal departments, and IT management would drive the definition of security policy. System administrators and programmers would implement those policies. And auditors would spend at least as much time examining your security policies as they do your implementation.

But that's not the way it usually works. Because most management chains think security is a "technical" problem, they abdicate their role in defining policy. System administrators are typically expected to assume the responsibility of both defining and implementing policies. This is an unworkable situation. It results in a security implementation that enforces, at best, a policy that, for the most part, exists only in the system administrator's brain. The implementation very likely addresses only obvious issues (e.g., password composition) and not many of the important business requirements (e.g., whether the accounts receivable role should be able to see a customer's credit card number). Finally, because these policies are neither clearly articulated nor comprehensive, their effectiveness with respect to security or compliance cannot be accurately measured by anyone.

Many auditors don't understand the security process or their role in it either. These auditors show up at your office and start looking at your security implementation without ever asking about your policies. They arrive with preconceived notions of what configurations on your system indicate compliance. If your configurations don't match their expectations, then, in their minds, you are non-compliant and you fail the audit. However, as I discussed above, there are any number of ways to accurately and adequately implement your policy. With no knowledge of your policy, it is difficult, if not impossible, to assess whether or not you have complied with anything. Most auditors will pass judgment anyway.

Auditors who provide real value will first ask for and analyze your security policies. If the policies appropriately incorporate government and industry regulations and standards, then your organization is in compliance. Technically, your policy is what needs to be compliant; your implementation must simply match your policy. However, a pattern of poor implementation across multiple systems or major policy elements that remain unimplemented indicates that your organizational policy is other than what is described by your written policies.

Only after determining whether your policies are compliant should an auditor consider the implementation of those policies on a system. This part of the process does not determine your compliance; it measures how closely you have implemented your policies on a specific system. This process is much more straightforward and valuable to you if you have a defined policy.

Whether or not you have an explicit policy, or an auditor assumes the appropriate role, you'll have to show the auditor what policies you have implemented. A number of tools shipped with the system can help you show what you have implemented on your system. The security toolkit (GO SECTOOLS or GO SECBATCH) contains over 40 commands, many of which produce information helpful for auditors. Here are just a few of them:

• The Print Public/Private Authority (PRTPUBAUT/PRTPRVAUT) commands can show the access control model you have implemented.
• The Print System Security Attributes (PRTSYSSECA) command shows the current setting of security-related system values. The security configuration wizard in iSeries Navigator provides similar information in a written report format that can be easily massaged into a formal report for the auditor.
• The Print User Profile (PRTUSRPRF) command prints a report showing sensitive attributes such as enabled/disabled, special authorities, and last-used date, which, for example, helps an auditor determine if you have too many profiles with special authorities (an indication that you cannot adequately prevent access to data).
• The Analyze Default Passwords (ANZDFTPWD) command shows which profiles, if any, have default passwords.

If you have a company policy that encompasses the regulations and standards applicable for your systems, then these tools provide most of the information an auditor needs.

If you have no explicit security policy or simply don't have the time or expertise necessary to run these tools, many third-party products can help you. It is important to understand that these products typically report against an arbitrary security policy containing only the elements of a single regulation or standard (or perhaps a subset of those that affect your organization). While a regulation or standard can be implemented in many ways, if you don't happen to use the specific implementation encoded in the product you use, you will be considered non-compliant.

Regardless of how you or the auditor generates the necessary information about your configuration, this information is used to show whether you have implemented security controls consistent with the policies specified by government regulations and industry standards.

For any audit, it is best to manage your auditors' expectations. Don't assume the auditors know everything they need to about your policies or your system. Meet with them first and provide as much information about your configuration as possible. Show them—or at least explain to them—the policies you believe you have implemented. Run your reporting tools before the meeting and go over them with the auditor. This will show the auditor that you know your policies and understand their implementation.

Getting Compliant

Complying with any regulation or standard is a three-step process that must be repeated periodically. First, your business owners define your organization's security policy at a high level, indicating who (in terms of employee roles) can access which assets for which purposes. Second, your technical folks implement the policy by configuring the security mechanisms on your system. Third, auditors analyze your policy to determine whether your organization complies, and then they measure the implementation of your policy to ensure that the written policies truly are the policies of the organization.

Without an explicitly defined IT security policy, there is no way to accurately measure which policies you have implemented—and certainly no way to determine whether you have secured those assets.

Even if your organization has never had an explicit IT security policy, something is better than nothing. Begin one today. You can find many useful policy templates using your favorite Internet search engine. A security policy is a living document that will be changed and updated no matter how complete. So having one, even if it is incomplete, is much better than not having anything at all. For example, an explicit policy that indicates no employee should be able to access any assets that are not required for them to meet their job responsibilities is an excellent start.

Once you have an explicit security policy, configuring the security mechanisms on your system will be much less confusing. It may still require a large amount of work depending on your current configuration, but it will be much clearer what has to be changed and you'll know when you're done.

Compliance audits will also become much less stressful. From a technical perspective, you're not directly responsible for the policy itself, only its implementation. As long as you have adequately and accurately implemented your organization's documented policy, you're pretty much in the clear. Business owners are responsible for defining policy, and if the policy itself is not compliant, it is their responsibility.

The best way to approach an audit is by managing your auditors' expectations. Be proactive and provide them as much information as you can before they start to physically audit your system. If you've followed the process, the worst they'll find are incidental mismatches that can be easily corrected or documented.

Finally, don't fall into the trap of believing you have secured your business assets because you have passed an audit, especially if your organization has no explicitly defined security policy. At best, passing an audit indicates that you have implemented certain required elements of security policy. At worst, it may mean your auditor didn't know enough about the security process in general or about the specific tools and techniques available on your particular system.

Pat Botz is the eServer Security Architecture and Consulting practice leader for the Rochester Client Technology Center (CTC). You can email him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Patrick Botz, an internationally known information security expert, is the President and CTO of Botz & Associates, a firm specializing in information security services for IBM i, AIX, UNIX, and Linux environments. 

With decades of experience in key system security positions, Patrick's expertise includes security strategy; security policy enforcement; password management and single sign-on; industry and government compliance; and biometrics.

As Lead Security Architect at IBM and founder of the IBM Lab Services security consulting practice, Patrick worked with IBM customers worldwide and achieved intimate knowledge of system security capabilities and pitfalls on a broad spectrum of platforms, with special emphasis on IBM i (formerly AS/400), AIX, Linux and Unix operating systems. He architected the SSO solution for OS/400 and i5/OS, and he holds several security-oriented patents. 

Early in his tenure at IBM, Patrick lead the AIX workstation tools team for CAD/CAM systems in Rochester, MN. Previous to IBM, he worked for Control Data Corporation with responsibility for CDC's Basic compiler, and for ETA Systems, Inc., a wholly owned supercomputer manufacturing subsidiary of CDC, where he was the team leader for the distributed, Unix-based Electronic Computer-Aided Design (ECAD) tools.

Patrick is the author of numerous trade press articles and a co-author of the book Expert's Guide to OS/400 and i5/OS Security.  In addition, he is a worldwide speaker on various platform-specific and general security topics.

Also Read

Data Privacy Rules Around the World

Data Security: 8 Privacy Principles Every IT Pro Should Know

Why the IBM i Community Needs to Pay Attention to GDPR