Data Privacy Blog

Key Management Kit

Contact us




Facebook Google+ Twitter LinkedIn

Our Blog to Your Inbox

Your email:

Posts by category

Townsend Security Data Privacy Blog

Current Articles | RSS Feed RSS Feed

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



PCI compliance matrix

Download our Encryption Key Management and PCI DSS 2.0 Compliance Matrix white paper and learn more about ensuring the data you are protecting meets PCI compliance.

Click Here to Download Now

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.


Call to Action!

Related Posts Plugin for WordPress, Blogger...


But if you eliminate profiles with *secadm and *allobj you can enforce a separation of duties model. If elevated profiles, such as OSECOFR, have a controlled access with a controlled / audited check out process with limited life does this not satisfy audit concerns? You can construct a model that requires approved controls to access the elevated authority profiles, tracks what they do, and has those logs reviewed to ensure that they only do what was approved, and expires those passwords when the approved change windows end. Granted most small to midsized organization do not have these in place, but that does not mean they can not be created.
Posted @ Thursday, April 19, 2012 7:22 AM by Dutch
I agree that there are many things that an IBM i customer can do to increase the security around highly authorized user profiles like QSECOFR and anyone with All Object (*allobj) authority, and these steps are very good examples of what can be done. But we should not lose sight of the fact that these are mitigating controls and not actually an implementation of Separation of Duties. Even if you achieve Separation of Duties, you would want to take these steps to improve the security your system. Here is the definition of Separation of Duties from the PCI Data Security Standard glossary of terms: 
"Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able to subvert the process." 
I am finding that auditors are less inclined to accept mitigating controls around a sensitive security function like encryption key management. There is probably some allowance for IBM i customers who maintain little sensitive data on their systems. But in general, if you store credit card information, patient information, or financial information on your system, I think you can expect to have extra scrutiny around encryption key management separation of duties.
Posted @ Thursday, April 19, 2012 9:57 AM by Patrick Townsend
Post Comment
Website (optional)

Allowed tags: <a> link, <b> bold, <i> italics