Notes on Productivity Home Page

Information that is encrypted with a private or shared encryption key and stored in a field in a Notes Document is not accessible even with an unencrypted version of the NSF, unless the accesser also has that key. So if your server were hosted at our data center, but you created a key on your local client, put it in your ID file, and then encrypted contents in your database on our server, we would not be able to access those contents.

Well, at least without traveling to the 24th century, grabbing a few computers, bringing them back to 2009 and tasking with performing cryptanalysis on your data for a couple of weeks.

Now if you want to make sure the hosting provider can't access unencrypted contents within the NSF, that's a different matter. That is a much harder problem, as is far as I know, there is no way to truly prevent it yet (though there may be an option in this not-distant-future... possibly) but you can make it a royal pain in the ass.

Hi Nathan, Thanks for your comment.

I used Mail as an example to keep my description easy, but I now realize that's a weak example because a user can encrypt their mail file on the server as well as locally, which will solve the problem. The mail file can be encrypted with the local user's ID file and the contents will be protected from all but the user(s) that posses the same key. That works great for Mail files and I have done this. It presents a problem with users that want to share a database, for example an admin assistant sharing the exec's mail file or in my customer's example, a document library that contains very sensitive documents that need to be shared between a small group of people. Nathan, do you know if there a mechanism for distributing an encryption key between a handful of Notes users only so that a server database can be encrypted with it while allowing the users in possession of the key to access the encrypted database on the server? This would be ideal, as the users would never know the difference yet the customer could rest secure that the data is encrypted end-to-end and on the server as well.

While cloud computing is an attractive option when it comes to saving money on infrastructure and system maintenance, I think that it has a lot of bit falls.

For instance, as you pointed out, there are concerns around security. Not only that but what happens if a company goes through some sort of financial crisis and cannot afford to pay the hosting fees? Are they switched off? Can they afford to migrate to an on-site solution?

Yes, Vaughan, this doe raise many points of concern, however, I think these can be mitigated - especially in a Domino environment. Personally, I would feel more secure about hosting my own information in the cloud if it were encrypted end-to-end and only those I designate have the key. This way, if access to the data files is breached, all they have are bits.

to your other point, I would be more concerned if the hosting provider went through a financial crisis and what they would do with the server and the data. For those hosting providers that make backups, there is obviously a concern about security and access to the backups. I recall reading about a courier that left the provider's backups in a truck only to have them stolen.

It just goes to show that you are letting your data be managed by people with systems which you have no idea about.

I can see both sides of the argument. But, for me personally, I would want to host and manage my own systems.

Eric, the simple answer is: yes. The full answer on how to do it is outside the scope of a blog comment for me at the moment. I'm sure any number of people in this community could tell you how to make it work, but if they don't, just give me a call at 404 578 1968 weekdays after 10am.

Thanks.

Vaughan, I believe there are compelling arguments for hosting a Domino server in the cloud. The purpose of my post was to share a customer's concern and start a discussion about how to address the concerns. But yes, in the end, if you are super concerned about the integrity of your data, then having the server under your control may give you peace of mind. Of course if under your control means the server is in a bedroom closet or an office back-room, that brings up other issues. I am aware of attorney firms that have been broken into and the robbers simply picked up the server and as many laptops as they could carry and walked out. Ultimately, I believe the better solution will involve managed encryption - something that Domino does well.

Thanks, Nathan. Knowing that there's a solution (and I suspected that there would be) I can certainly dig through the manuals myself. if I get stuck, I'll call. Domino Rocks.

Eric,

you can encrypt the database with the server key, that will make "accidential access" from a backup tape much harder. Encrypted with a locked down ACL you are one step closer.

As Nathan pointed out: you can encrypt documents (careful: it actually encrypts the fields and if the property isn't checked it won't get encrypted, typically only the body field is encrypted) with a shared key. In ID management there is the option how to share a shared key (using an encypted email :-)). You also need to be clear: every field you encrypt can't be used in a view.

Stephan, it seems like encrypting with the server key is the way to go, as long as the server's ID is password protected. At least a few customers have removed the server password to allow for auto-start of Domino so that presents a problem. (That's not Domino's fault, but hopefully there's a solution for that). I tend to avoid encrypting documents for the reasons that you mention, but I know it is a very secure way to go. (We do some of that in the eProductivity Reference DB so that users can have truly private documents.) So if a customer wants to move Domino into the cloud and is paranoid about the databases getting into the wrong hands, he can encrypt all server replicas with the server id. That leaves only the server.ID file itself to protect. Any suggestions?

Other than the small performance hit, are there any down sides to encrypting all server Databases with the server's ID - any impact to names.nsf in a situation like this? I would think not, but it never hurts to ask.

ExtraComm has a product named SecurTrac for this kind of scenario and you can use this for your critical databases.

You also need to agree on security requirements with the hosting provider and possibly have an arrangement where only individuals affiliated with a professional security organisation (ISACA,ISC2 etc.) 'touch' the environment as these people will lose their credentials when there is a proof that they have abused their priviledges, which might be difficult to prove though.

Thanks, Mpoed. I've used and recommended Extracomm ExtraFax products for years. Seems like Securetrac is more for compliance auditing than securing the data but I'll have to look again. Ideally, most customers will want to secure the data. Larger customers will want the compliance capability. Thanks for the tip.

Eric Mack,

Yes, you are right its more about compliance. Perhaps what I should have said is that you can use SecurTrac in conjunction with the Domino encryption capability. What will you will then get is notification for any breaches so its a DETERRENT control measure as opposed to a preventive control measure and at times that works well enough and in some situations its the only option you have.

Thx

I have a similar situation where I am in need of encrypting a fax 'mail-in' db in Notes R8.02

for PCI compliance. It is an in-house db, and will be accessed by a few people, however am not comfortable by simply protecting it via ACL

Is the short answer encrypting it via the server ID? If so, can you give me the necessary steps or alternative solutions?

Thanks in advance,

Leo Ghazarian