Greetings all...
My company is currently tasked with evaluating various hardware key stores for field-level encryption that my company intends to use with multiple databases, both MSSQL (2008) and Progress/Openedge (10.1B). (We are moving toward 2008 R2 and 10.1C respectively). Although this is in part motivated by PCI guidelines, we're also serious about restricting access, which is why we're going down this road rather than a simpler software-based key store.
Among the various vendors under consideration are RSA, SafeNet, and Thales. Not surprisingly there are generally APIs available for MS, but Progress/Openedge does not garner much attention.
We've already spoken directly with SafeNet, and it sounds like interfacing via Progress ABL appears to be a do-it-yourself affair in SSL socket programming. Although we've not spoken with the other vendors yet, we're obviously not expecting a plug-and-play implementation.
So we're interested to know if there is anyone with experience in this area who could provide some suggestions (from the above list or not, positive or negative) with regards to any particular appliance vendor, specifically with respect to Progress implementations. I've noticed in the documentation that Sonic ships with RSA's BSAFE-J SSL (and Sonic is a possible option) so I'm also curious if that would potentially simplify an RSA solution in relative terms. We'd find out for ourselves when we get an actual box to play with, but some advice would be appreciated. We are hoping for minimal reinvention of wheels, though I certainly expect some work will be required.
I should add that, apart from a miraculous "Blessed by Progress" solution(s) I'm as yet unaware of, the specifics of the actual hardware box are perhaps less important than the general flexibility and helpfulness of the vendors... Clearly we don't expect too much detail. [In other words, please don't post, "I'm from ACME and we use RSA box number IMAID10T, our key length is..."]
* * *
Off-topic: Is PEG dead? I was going to post there, but it doesn't appear to have been updated since March 2009.
I know you are looking for a hardware based solution, but have you considered going to 10.2B and using the in-build Transparent Database Encryption (TDE)?
Re PEG: Very much alive, but Greg is busy and the website is not being updated at the moment. There is still plenty of traffic on the email lists..
...have you considered going to 10.2B and using the in-build Transparent Database Encryption (TDE)?
Various options have been discussed and considered at this point.
The primary issue is key-handling. In an environment with just a few administrators and programmers, the hardware solution may be overkill. But in the case where the company has an IT staff in the hundreds, the question of who has access to keys becomes much more acute. Programmer access to keys is one of the things we're trying to get away from; if we can also reduce the number of admins who have access, so much the better. In other words we're trying to dissociate DB access and root access from key access -- at least as much as practically possible.
[Here I'll note that we understand programmers/admins can always play "man-in-the middle" by interposing code. In focus is the common threat of large-scale data dumps, so we're aiming toward throttling atomic access on a user level external to the DB. Source control is a different horse and (for this question at least) is out of scope with respect to keys since it applies to any solution -- one thing at a time.]
One of the secondary issues is reliability. In our case, any solution is going to be homegrown, at least in part, because we own the source. Like a hardened padlock on a weak latch, one of the biggest problems with encryption is not with the algorithms themselves but with how they're implemented and how the data flowing in and out is handled. A sealed-box hardware solution that has been FIPS 140-2 certified is far more likely to be secure than an internally-built key store, even if "our guy" doing the programming has a fair amount of experience.
Also in play is the MS SQL Server question... building a specific Progress solution almost certainly means complicating the MS side of things (at least in comparison to boxes with pre-built APIs).
None of these issues rule out a Progress-based solution completely, but they do tend to point us in the other direction.
My apologies; for whatever reason I can't get rid of the Javascript snippet that ended up in the quote.
Grrr. Arrgh.
I would, at least, consider taking a look at 10.2B. I know it won't help with your MS SQL issue, but all appearances are that it is a very thorough solution to the problem, including preserving the encyption in backups and dumps. Moreover, it is highly performant and it looks like it has all the flexibility one would want for control.