Why Did I Fail a Security Audit on My IBM i (AS/400, iSeries)?

As security auditors get more educated on the IBM i platform, more customers are having the experience of failing a security audit around encryption key management. CIOs, IT Managers, and System Administrators want to know why this is happening to them now? They ask, why was our approach OK two years ago, and why is it not OK now?

I think I can answer that.

My job brings me into conversations with a lot of companies undergoing security audits under a broad range of regulations including PCI DSS, SOX, GLBA/FFIEC, FERPA, and many others. Security and compliance auditors look to industry standards and best practices for guidance on what their clients should be doing in the area of key management. In the US this inevitably brings them into contact with the National Institute of Standards and Technology (NIST), an agency within the US Department of Commerce. NIST provides a wide set of standards and best practices guidance in the area of encryption and key management.

As you become familiar with the broader set of data security regulations, you start to realize that the one common source they have is NIST. Even if not directly referenced in the regulations, the concepts are largely drawn from work done by NIST, and that is why there are a set of common attributes that auditors look for in a key management implementation.

So, auditors now look for key management implementations based on NIST best practices and standards. Key management best practices can be found in the NIST Special Publication 800-57 (three parts).

One of those best practices is Separation of Duties. This best practice says that the people who manage encryption keys should not be the same people who manage and have access to sensitive data such as credit card numbers, social security numbers, patient data, and so forth. It makes sense – you want as few people as possible with access to sensitive data, and you only want people who have a real need to access sensitive data to do so. The same is true with encryption keys that protect that sensitive data.

On the IBM i platform the security officer and anyone with All Object (*ALLOBJ) authority can access any database file at any time, and can access any locally stored encryption key at any time, regardless of the protections you try to put in place. This is not really a limitation or weakness of the IBM i platform, the same condition exists on other operating systems and platforms, too. No matter what you do you can’t achieve a defensible level of Separation of Duties if you store encryption keys on the IBM i platform. You can try to mitigate this situation through system logging and similar controls, but you can’t eliminate it.

Auditors have learned this about the IBM i platform.

Separation of Duties is only one problem area with the local storage of keys. You also have to contend with Dual Control, Split Knowledge, key lifecycle management, and a broader set of key management best practices most of which are difficult or impossible to achieve when encryption keys are stored locally.

And that’s the main reason IBM i customers are failing security audits around encryption key management.  Download our our Encryption Key Management Requirements for PCI white paper to learn more on how you can pass your next key management audit with flying colors.

Patrick