Ensuring all data is encrypted at rest with LuxSci
Email and other data is either being “transmitted” or “processed” or is “at rest.” I.e., it is moving from one computer to another, or it is stored/at rest on a computer, or it is preparing to be transmitted or stored.
While most types of compliance regulation, such as HIPAA, specifically require that data be transmitted securely, not all regulations require that data be stored in an encrypted form while at rest. I.e., HIPAA does not require at-rest encryption, though it is recommended to decrease risk and potential liability in some situations
Having your email and other data encrypted while at rest can potentially increase the security of that data, even if that level of security is not explicitly required. As a result, many LuxSci customers have asked about how to ensure that all of their email and other data is encrypted while at rest.
Full-disk encryption encrypts the hard drives or data stores themselves, and not the actual files visible in the server when it is running. Full-disk encryption protects everything on the server; these kinds of things are technically “encrypted at rest” under full-disk encryption:
- Sent email and email folders
- Web site and FTP data
- Data stored in customer MySQL databases
- All WebAides
At LuxSci, full-disk encryption is available for:
- All enterprise-class shared and dedicated server accounts
- Dedicated business-class dedicated server accounts who purchase separate disk space for encrypted storage.
Full-disk encryption is not the be-all and end-all solution, however, as it does not protect the data from access by users or programs running on the server. See the section at the end for more on full-disk encryption. In the following sections, we discuss the possibilities for encryption in addition to, or instead of, full-disk encryption. In the following sections, “at rest encryption” refers to encryption of saved data on the server, and not to full-disk encryption, which may also be in use.
At-rest encryption for email
Email encryption with LuxSci requires use of LuxSci’s SecureLine service. SecureLine includes 4 modes of email security: TLS, Escrow, PGP, and S/MIME.
- TLS: This method is always used by LuxSci when possible, even if another mode is also used. It can be the only mode used for customers who require only transport encryption and for whom the usability of TLS SMTP encryption is desirable. However, TLS by itself is for message transport only. It will not encrypt your message when at rest.
- SecureLine Escrow: Messages sent via Escrow are encrypted using PGP and stored in a secure database. They are encrypted at rest and during transmission (via use of SSL for access).
- PGP and S/MIME: Messages sent via PGP and S/MIME are also encrypted at rest and during transmission.
So, as long as you disable use of “TLS Only” as a permitted means of encryption in your SecureLine settings, then all of the messages that you send securely will be encrypted at rest.
Caveats — there are always some:
- Sent Mail: Your sent email messages are not generally individually encrypted, whether saved from Webmail or saved from an email program. There is an easy solution to this, however – Encrypting your sent email:
- Disable saving of sent email in WebMail (My Email Tools>My Preferences>WebMail Composition) and/or your email program.
- Enable your LuxSci setting “Forward a copy of all messages sent via SMTP or WebMail to a specific email address” and have the email forwarded to yourself.
- Add a PGP or S/MIME certificate for yourself in the LuxSci user interface so that email to yourself is encrypted using a certificate, and not via Escrow. S/MIME is recommended over PGP for compatibility with most email programs.
- Create a Custom Email Filter in your LuxSci account to match messages “from yourself” that arrive to your account and have them saved to your sent email folder.
- The net result will be that a copy of every message that you send will be encrypted for you and sent to you and then saved to your sent folder when it arrives, thus ensuring that the sent email is always encrypted at rest.
- SecureLine Auto-Decrypt: SecureLine has a nice feature that allows you to have inbound PGP and S/MIME encrypted email auto-decrypted when it arrives so that it is stored as regular email in your account. This is off by default and you would not want to enable it if at rest encryption is desired.
- Caching on Send: When messages are sent, their data may be cached temporarily on disk or in memory while they are processed and encrypted. These cache locations are never backed up and are ephemeral … the data may be there for only fractions of a second to a few minutes. The only way to eliminate the need for the message to be processed in an unencrypted state is to have it encrypted before it ever arrives at LuxSci. This can be done by using PGP or S/MIME in your email program … but then you cannot send messages to people not using the same PGP or S/MIME system and cannot send to recipients using Escrow. This kind of short unencrypted processing step is common to server-side encryption technologies.
While “sent email” storage is clearly storage at rest, most people consider the short duration processing and caching to send and read a single message to be not exactly an “at rest” state as it is an ephemeral process. Hence, people’s requirements about what needs to be encrypted when “at rest” vary greatly based on the regulations that they need to follow, their own security concerns and policies, the nature of the data, and the degree of trust in the services used. E.g. unless your security requirements are very strict, the message being in an unencrypted state on the server when sent or opened is usually very acceptable and expected.
The down side of at-rest encrypted email
It’s worth mentioning some of the down sides of having your email encrypted at rest. In general:
- Encryption requires more work to open and read the messages than regular email.
- The content of encrypted messages stored in your email folders cannot be searched. E.g. you can’t search your folder for all messages whose bodies contain some specific content.
- You can permanently lose access to encrypted messages if your cannot recover the password to your PGP or S/MIME certificate, or if you lose your Escrow notification message (and are not using Message Center).
- You may not be able to open the secure email messages from your email program or mobile device … you may have to login to a web site to access it.
- If multiple people are sharing an email folder which contains encrypted messages, then they need to share the decryption information and passwords.
At-rest encryption for WebAides
WebAides are LuxSci’s collaboration tools used to store contacts, calendar entries, tasks, files, blogs, passwords, and more. The general data for these WebAides (e.g. the schedule information in a calendar event) is stored unencrypted in a secured database.
However, all WebAide attachments (including all files in Documents WebAides) are stored individually encrypted at rest using 128-bit AES encryption.
- Choose to have it PGP encrypted.
- It will be digitally signed automatically.
- You can pick what users and/or groups of users will be permitted to decrypt it.
This provides double at rest encryption (encryption using PGP, and then further encryption of that PGP-encrypted data using AES) for your sensitive data, extra access control by encrypting it for specific recipients only, and validation through digital signatures. As all of the encryption and decryption is done through the LuxSci web interface and that interface can create PGP keys for your users and groups on demand, PGP encryption is very easy … nothing to install or buy or setup, beyond requesting a PGP key and giving it a password.
The WebAides that support both AES and PGP encryption are:
- Documents: For file storage and sharing
- Blogs: For internal blogs and notes
- Passwords: For password library storage and collaboration (PGP encryption for passwords is required)
SecureForm at-rest data storage
The SecureForm service at LuxSci enables your web and PDF forms to deliver posted data to you in a versatile and secure manner. SecureForm allows you to receive your form data in many ways: email, FTP, MySQL, and WebAides Documents. Some of these formats support at-rest data encryption:
- Secure Email: SecureForm can send the form posts to you encrypted using Escrow, PGP, and S/MIME …all of which result in the data being encrypted at rest. Avoid TLS-only secure delivery as that will not result in at rest encryption.
- Documents WebAides: Your form data and files will automatically be encrypted at rest, like all Documents WebAide attachments. Additionally, you can choose to have these files also double encrypted with PGP.
- MySQL: SecureForm can save your form post data to a LuxSci-hosted MySQL database. You can choose to have this data encrypted at rest using native-MySQL AES encryption. See: Can your web and PDF forms save to an Encrypted Database?
- FTP: While SecureForm supports FTP and SFTP delivery of form data to your server, those files will not be individually encrypted on your server once it is delivered there.
At-rest encryption for Widgets
LuxSci’s Widgets allow your to make custom dashboards with access to just the right arrangement of tools for your tasks. Most of these widgets simply access and render other types of data (e.g. email, WebAides, RSS feeds, etc.). A few widgets store information for you directly as part of the Widget. Of, these the “Notepad” widget can be used for saving arbitrary information.
LuxSci encrypts the contents of your Notepad widgets while it is stored at rest in the database, using native-MySQL AES encryption.
Web hosting and at-rest encryption?
Customers that host web and/or FTP sites with LuxSci can have data stored encrypted at rest on these sites; however, that encryption and decryption is the customer’s responsibility. E.g.
- Upload and download pre-encrypted files … using some software on your computers to handle the encryption or decryption for you.
- Create web site pages that automatically encrypt/decrypt files on the server or saved in your hosted databases using openssl, PGP, or some other technology.
For web hosting customers with strong web site security/privacy needs, LuxSci recommends use of dedicated servers.
What about full-disk encryption?
LuxSci does use disk-level encryption for enterprise-class servers and business-class dedicated server customers who explicitly require it. Customers often wonder why it is not pervasive and think that full disk encryption would solve the “data encrypted at rest” issue simply and easily. This is really not the case.
Full disk encryption is great for hard drives in desktops, laptops, and thumb drives — media that could easily be lost or stolen. The full disk encryption makes it difficult for someone who gains physical access to that lost or stolen media to access the raw stored data. That in turn mitigates compliance risk.
However, when translating this to an enterprise hosted environment, the situation breaks down. We’re not talking about an easily lost or stolen physical disk anymore. A live LuxSci server’s “hard drive” is some slice of space taken from a vast array of hard drives in a dedicated storage server … where the drives are arranged in complex RAID arrangements. The scenarios where disk-level encryption benefits are:
- Someone breaks into the data center, and through their security, arrives at our data storage arrays (really big and heavy devices, screwed into many racks). Takes these offline and either tries to plug into them directly there in the site, or tries to carry them away to access them privately … all while preserving their configuration exactly as it was.
- Someone at the data center with full access and clearance attempts to gain such access.
- The media that was previously used to store ePHI is not properly destroyed and falls into the hands of people who should not have access to the data on that media.
In reality, the risk of those vectors is very small due to the very strong level or security associated with our premium server environment, and due to the fact that we have a HIPAA Business Associate Agreement with our server vendor, so their staff are being trained, monitored, etc., to ensure that this kind of thing never happens.
So why not do it anyway? We do. Our Enterprise-class servers reside on a private storage area network (i.e. one dedicated of LuxSci) which is encrypted. We also offer encryption of added data storage for customers with Business-class servers (where the system drive itself can not use disk-level encryption). Full disk encryption has many downsides, including:
- Full disk encryption decreases server performance somewhat, especially in disk-intensive applications like email. This makes email somewhat slower
- Full disk encryption adds another layer of complexity or failure and another thing that could go wrong and corrupt data
- Full disk encryption requires that methods be in place for booting or restarting servers so that they can regain access to the encrypted data. This generally increases downtime associated with any maintenance or other issues or lessens the security of the encryption system in some ways.
While it does mitigate the unlikely event of the data storage array being compromised in our HIPAA business associate’s data center, this only protects against access to the raw disks and it comes with some tangible down sides.
Compared to inappropriate raw hardware access, it is very much more likely that any attack would come via customer mistake or by a live server being compromised in some way. E.g. a customer uploads inappropriate files to his/her web site, a server is compromised due to a vulnerability, etc. In each of these cases, the server is already on and any program or process on that server has full access to the unencrypted data … even where the disk is encrypted. So, “encrypted disks” providing “at-rest encryption” do not protect in any way against attacks over the network against live servers or against customer actions.
That said, at-rest encryption via encryption of individual files, messages, database entries, etc. does solve the problem … as any access to the raw drives OR the live server still yields only these encrypted data items. Hence, LuxSci focuses on strong per-item encryption rather than relying solely on hard drive encryption, which offers weak protection, by itself, in this context.