Mainframe Encryption

[gjo1967-pci@yahoo.com]

Hello all,

This is a great forum, I'm glad I came across it today.

We are working towards PCI compliance on card data stored on a mainframe. My initial question is, would a symmetric in-line encryption device which encrypted the storage but not the column or fields specifically be an acceptable encryption solution?

That is, if we have a DB2 database storing PAN data (which can not be removed or re-engineered for various reasons beyond my control) and we do not implement encryption at the column level but rather encrypt the physical store on the SHARK storage which holds the database, would that be acceptable?

I understand there are other issues around key management and such, those we would have well in hand.

Thanks very much!

[lyalc]

The short answer is that encrypting the storage volume containing the database is acceptable in PCI.

The challenging part (having just worked through this with a client) is finding compatible devices at the data path level - escon, ficon, don't seem to be well supported by encryption vendors, while fibre channel is better supported. If your mainframe supports fibre channel - great.

Software based solutions that use MIPS also work but can be expensive, since they use up the limited MIPS capacity - and extending the available MIPS costs twice - once for the MIPS and again for those software packages that are licensed by the MIPS.

Depending on your hardware (I asume IBM) the integrated crypto-processor hardware may be very useful - but see IBM or your vendor to confirm implementation feasaibility and specifics.

Lyal

[jbhall56]

I am assuming that when you say that the store is encrypted that, as long as the store is opened by the mainframe, all of the data is available to all authorized users unencrypted since the encryption is only in place when the store is closed.

If my assumption is correct, then your backups also likely contain an unencrypted copy of the data store unless the Shark/Tivoli are in control of backups and only allow the copy to be created to be the encrypted version.

It is my understanding from my 'friends' at IBM that column level encryption is the only way to protect data in a database.

[lyalc]

This is a good point - not all storage encryption solutions provide ideal protection e.g. against system admins etc. This is also true of some database solutions - DBAs etc often get access to the unencrypted data.

SAN/NAS storage encryption tools that I've seen tend to offer some level of user authenticaiton on top of the OS-based authentication.

The questions for a site to resolve become a mix of environmental fit, PCI compliance, cost and on-going overheads - issues that are particularly true for mainframes.

Mind you, I saw one set of IBM 'friends' recommend, for 8.5.4, an automated link between HR and all OSes to ensure user accounts are terminated the instant HR says so. This particular proposal (and budget) went well beyond 8.5.4.

Lyal

[jbhall56]

Lyal makes a good point about some SAN/NAS providing user authentication capability through the mainframe's authentication process, LDAP or similar authentication mechanisms. However, I believe if you use Top Secret or ACF/2 for access control, they may not provide the same user level authentication as RACF does for the Shark SAN.

In addition, just because a SAN provides this capability does not mean that it was necessarily implemented. So a QSA would need to determine that the authentication capability was turned on and that the authentication capability meets the PCI DSS standards.