PTSS First to Achieve NIST Compliance for DB2/400 Encryption

May 4, 2010 Alex Woodie

Patrick Townsend Security Solutions demonstrated why it calls itself “the encryption company” last week when it because the first and only vendor to receive certification from the National Institute of Standards and Technology for a DB2/400 encryption solution. The NIST certification, combined with its support and deep technical understanding of the new automated encryption facilities that IBM introduced with i/OS 7.1 gives the company a solid leadership position in the i/OS security business.

John Earl, who became CEO of PTSS last year after leaving PowerTech, says achieving NIST compliance for Alliance AES Encryption for System i on i5/OS V5R4, i/OS 6.1, and i/OS 7.1 is important for two main reasons.

First, it confirms PTSS’ standards-based approach to developing encryption and proves that its work has been thoroughly vetted by an independent third party. The second reason is that the standards groups, including the Payment Cardholder Industry (PCI) standards body, are leaning toward certification of encryption products as part of their compliance mandates.

“We will go to COMMON with the certificates in hand, so we’ll be the only company with NIST certified encryption on all supported versions of IBM i,” Earl said in an interview with IT Jungle last week. “That’s pretty significant because even the encryption algorithms provided by IBM are not NIST certified.”

And neither are any of the i/OS encryption algorithms provided by other third-party vendors, Earl says. “We’ve seen encryption algorithms out there that are, frankly, baffling, and don’t make a lot of sense. They certainly haven’t been peer reviewed, and they aren’t certified, although sometimes you see the claims for that,” he says.

“Getting encryption right is not a simple thing, and it’s not something you do over the weekend. We’re going to really stress that and we’re really proud of the fact that we’re the only company that has NIST certification for database encryption on IBM i,” he says.

Earl says it’s likely a matter of time before the PCI standards body requires that companies use an encryption tool that holds a certification from NIST. “While the PCI Security Standards Council does not yet require strict adherence to the NIST standard, it is clear they are driving in this direction,” Earl writes on the PTSS Blog.

PTSS is one of only two i/OS security software vendors that have committed to supporting the new DB2/400 field procedure that IBM introduced in i/OS 7.1 to make it easier for System i shops to implement automated encryption without modifying application source code. The other vendor is Linoma Software.

As PTSS founder and renowned encryption expert Patrick Townsend explains it, the problem didn’t have to do with enabling automated encryption in i/OS–it was the automated decryption that was the problem.

In previous releases of the operating system, most vendors like PTSS used SQL views and triggers to automated encryption and decryption. In fact, it was possible to almost completely automate the encryption of field values using this method. However, when a user went to read a record that had been encrypted, a built-in limitation in DB2/400–one that doesn’t exist on most other platforms–prevented DB2/400 from showing decrypted values.

“When you insert or update a record [SQL views and triggers are] nice, because you can grab that data before it’s written, encrypt it, and write it into the file. Now you have protection. That works really well.

“But on a read operation, the trigger fires, you get the data, and you can decrypt it. But guess what? The buffer is not updatable,” Townsend explains. “Your trigger gets fired, your program gets called, the data gets decrypted–it just never gets passed upstream. In IBM terms, it’s not updateable.”

This limitation has been eliminated with the addition of the new field procedure in i/OS 7.1, and PTSS is champing on the bit to start using it to help its customers clamp down on their data.

While the new “field proc” exit point will (mostly) eliminate the need to make source code changes to implement automated encryption and decryption, the new technology also introduces a whole new set of security challenges.

“With great power comes great responsibility/risk. A field exit point is another potential point for security failure,” Townsend says. “A proper implementation has to enforce policy around who can encrypt data, and which applications can encrypt data.”

If a System i shop failed to implement the proper security controls around the field procedure exit point, they could risk exposing all of their encrypted data, Townsend and Earl say. A savvy user with a power tool such as ProData‘s extremely popular Database Utility (DBU) could essentially lay in wait for a user with the proper security credentials to access a file. And then every file is all of a sudden decrypted and viewable to the rouge user.

“There are substantial risks around deploying field proc exit points in the wrong way,” Townsend says. “I think customers need to be aware of those risks and be fully cognizant of the issues around it. I believe an exit point solution has to enforce a rule. If you’re not explicitly authorized to see data, it should be denied to you. If an application is not explicitly authorized, it should be denied access to data.”