Elkie Holland, Prospectus IT, enjoys an informative session with Bryan Shumsky, a senior Software Designer for Revelation Software about a new feature in their OpenInsight product. 
Elkie: Bryan, thanks for talking with us.
Bryan: Hi, Elkie, it’s a pleasure.
Elkie: I understand that included in the release of OpenInsight 9.3 is something called “DER”. What can you tell us about DER?
Bryan: DER stands for Data Encryption at Rest. When data is saved on the hard drive on most multivalue systems, it’s historically been stored away in plain text. This is readable not only by the multivalue database, but by anyone who might get hold of those raw files in Windows or Unix/Linux and who knows how to examine operating system files. If those files contain sensitive data, the possibility that that data could fall into unauthorized people’s hands – and could then be extracted – is a very real, and scary, concern. And there are a number of ways these files can get into the wrong hands, including the obvious ways like theft – of either hard drives or even backup files and tapes – or more innocently, when a computer’s hard drive is disposed of without wiping it clean first. To combat this problem, systems that implement Data Encryption at Rest store their data in encrypted format. The data is decrypted only when the system is actively requesting the data, and when the data _isn’t_ being used – when it’s “at rest” – it’s inaccessible or unreadable on disk. In OpenInsight 9.3 and later, we’ve included a way to designate one, or multiple, files as being protected by Data Encryption at Rest.
Elkie: Did you use a proprietary solution to encrypt the data?
Bryan: No, we decided it made much more sense to use industry standard, industry accepted tools to encrypt the data. Data encryption – and “cracking” of encryption schemes – is a high stakes cat and mouse game, and unless you’ve got teams of engineers, mathematicians, etc., you’ll never be able to outsmart the people whose job it is to develop these algorithms. So we’ve leveraged the algorithms that are included in Microsoft’s .NET framework. In addition, though not strictly required for standard Data Encryption at Rest, we provide additional data protection by using Microsoft’s Windows Communication Foundation (WCF) to encrypt the data while it’s travelling around between the various client workstations and the data server as well.
Elkie: There’s a Data Encryption at Rest standard?
Bryan: Yes, more or less. While there’s not something as nice and clear cut as a DER standards document, there are various laws, like HIPAA, that are designed to protect individual privacy and that mandate how data is protected when it’s stored. So by looking at these various laws, and coming up with some “best practices” to satisfy their requirements, you have in effect a working DER standard.
Elkie: Oh, so this can protect things like social security numbers and patient records…?
Bryan: And credit card numbers, and bank account numbers, yes. But even other kinds of personal data, like birthdates and sex, need to be encrypted in certain circumstances to protect an individual’s privacy. DER lets us do this transparently for any application that you may already have running, or might develop.
Elkie: It doesn’t require any changes to what you’ve already done?
Bryan: Exactly. That’s the whole benefit of putting the encryption into the database engine itself. If you had to modify all your programs to explicitly encrypt and decrypt different fields, that’s a LOT of work. And then your data can’t be used with normal system tools, to generate reports and forms. With our implementation of DER, the data looks exactly as it always has to the application; it’s just no longer visible outside the application, or to anyone who doesn’t have the proper permissions.
Elkie: So this is permissions based?
Bryan: Yes, again, we are “leveraging” the existing industry standards, in this case the user permissions groups that are built into Windows, to make sure that all access to the data files is appropriately controlled. Each field in an encrypted file has a set of allowed permissions, and only users who are members of the appropriate groups can see, and optionally change, that data. If you’re not a member of that group, OpenInsight will present you with either encrypted “nonsense” data or blank fields, depending on your configuration options.
Elkie: But does this mean that everyone has to go around remembering passwords every time they want to access their data? Isn’t that insecure?
Bryan: If we tried to make everyone enter their password every time they had to open up a file on their computer, all we’d end up with is a bunch of computers with passwords taped to the sides of their screens. Our implementation of DER avoids this problem, by using a specific “DER Server” and never exposing the passwords, or encryption keys, to the users. Everything is all encrypted by the DER Server, and the DER Server itself encrypts the encryption keys and passwords. The only passwords that need to be known are the ones that manage the DER Server, and we think it’s reasonable to expect the IT staff can manage those. Of course, there might be times when you want a specific password on a set of files – say, for example, that you want to copy those files between different installations. Well, you can use OpenInsight’s DER to make what we call a PASS volume, which does have its own password, and then copy that PASS volume onto a USB key, or send it via email, safe in the knowledge that the data it contains is still protected by the strong .NET encryption libraries.
Elkie: Wow, it sounds like this can solve a lot of security issues.
Bryan: Well, we think so. By putting sensitive information into a DER file in OpenInsight, users can feel confident that they’re no longer sitting on a ticking time bomb – that, even if the worst should happen and their systems are compromised in some way, at least they won’t have to worry about the legal and financial ramifications of having their client’s data exposed.
Elkie: Thank you Bryan for your time in explaining this to me.
