Securing the Breach, Part 3 – No Rest for ‘Data at Rest’ Security

Last updated: 16 May 2016

Secure the Breach LogoIn the past posts in the series, we’ve chatted about breach acceptance, and how encryption can help protect your data. This is true, whether we’re talking about hackers, or insider threats – provided it’s managed correctly, of course.  This week we’re going to take a closer look at the types of data that need encryption, and specifically “data at rest.”

Data at rest refers to information stored on permanent media, such as tapes and disk drives. It may also be described as inactive data (i.e. not in use) which is stored in any digital form, as compared to “data in flight” which refers to information passing through a computer network.

When data enters your organization or is generated within, you can choose to encrypt in a variety of stages in its lifecycle – or at different layers in the OS stack, and there are advantages and disadvantages to whichever method you choose. Obviously the sooner you encrypt, the lower your risk of an unencrypted data breach. You can also select where you want to encrypt – in the traditional data center, a virtualized environment, or up in the cloud.  Let’s consider the various options:

  • Data at Rest Security ImageApplication level security – You could choose to protect at the application level, even in a multi-vendor infrastructure in the data center and in the cloud. This would enable you to enhance application security through fine-grained user controls with minimal impact upon the performance of application servers.
  • Transparent database security – This enables application-transparent, column-level database encryption across multi-vendor database management systems in the datacenter and in the cloud. An advantage of database encryption is that it provides support for extremely large data sets.
  • File-level encryption – This protects unstructured data in file servers and network shares. Encryption is performed transparently and affords granular access controls: authorized users and processes can continue to have read and write access to the encrypted data while unauthorized users/processes are locked out.
  • Tokenization – Tokenization replaces sensitive data (credit cards, social security numbers etc.) with a surrogate value – a token. The sensitive data is encrypted and stored in a safe repository while the token is processed throughout the organization instead.

The challenges of securing your data are compounded in virtualized environments and especially in multi-tenant public clouds. With comprehensive protection of a virtual infrastructure, you can ensure that the entire virtual machine and attached storage is secure, similar to full disk encryption solutions on your laptop, and coupled with pre-launch authentication to ensure only authorized users can access information – and that unauthorized users, even super-users, stay out.

But regardless of where/how you choose to encrypt, it’s safe to assume that this data needs to be secured. Whether you are doing it to protect your personally identifiable information (PII), intellectual property, or you’re doing this to avoid a heavy fine for non-compliance – you can rest assured if you don’t encrypt, your data is at risk of exposure.

Next time, we’ll explore encrypting data in motion as part of our “Securing the Breach – Three Step Strategy.


Secure the Breach Square ImageDownload the Secure the Breach Research Kit to learn how to use authentication, encryption, and key management to prepare for a breach effectively.

The kit includes access to the Secure the Breach manifesto, white paper, and other helpful resources.

Leave a Reply

Your email address will not be published. Required fields are marked *