Lately I have been working more and more in the cloud as a security architect, and my current focus has been on encryption and key management technologies. What is interesting is that there isn’t a lot of difference between the encryption technologies we use in the cloud and the encryption technologies we use in an enterprise. The biggest difference I’ve seen has to do with key management, but that is a topic I’ll save for a later blog post.
Several years ago, when IBM System Storage Tape Encryption solution was released on the TS1120 Tape Drives, I found myself in Tucson, Arizona working with the ITSO to write an IBM Redbook on the topic. I had just moved to a new position in IBM, and my new manager said that was the first thing he wanted me to do.
Since then, I’ve found myself working more and more with encryption technologies, from those first drives to the encrypting LTO drives to IBM Encryption Facility and the IBM DS8000, and even Brocade Encryption Switch. I’ve learned through implementing these technologies at many Fortune 500 companies that there are many ways to implement encryption technologies for confidentiality.
Here is a categorization of encryption technologies:
- Storage-level encryption
- Agent-based encryption
- Application-level encryption
- File system encryption
In this blog series, I will expound on each of these categories and how they fit into an enterprise encryption strategy. I’ll also talk about the differences in security between these types of encryption categories, along with how they may apply to the cloud. Key to these blogs will be key management, which is really the crux of an encryption strategy.
Here is a quick overview of the areas I’ll cover:
Storage-level encryption is any type of encryption at the storage area network (SAN) level. If you encrypt your whole SAN, it would fall into this category. I would also group tape encryption here, such as the LTO6 Drives or IBM TS1140 Tape Drives. This type of encryption typically has a negligible performance impact and requires specialty hardware.
Agent-based encryption requires a special piece of software on every system that needs to encrypt and decrypt data. In this category, performance of operations against clear text will be faster than that against ciphered data. In addition, data encryption policies and keys will need to be managed for each system. IBM Infosphere Data Encryption falls into this category.
This type of data protection is a little bit different than the previous two in that the application itself will encrypt the data. IBM FileNet P8 falls into this category. Here FileNet controls access to data objects and encrypts those objects. Each object is encrypted with a unique encryption key that is stored in database. This type of encryption is fairly common for object storage. Nirvanix would be an example of a cloud object store that can be configured with similar encryption.
File system encryption
This type of encryption is typically part of an operating system. Examples would be Windows Encrypting File System (EFS), AIX EFS and Linux using eCryptFS and/or dm-crypt. A directory or a partition is configured with an encryption key derived from a passphrase, and then data stored in that area is encrypted. This also means that each system must be configured for encryption and each system must have encryption keys managed on that system.
In the next post I’ll expand on products and architectures as well as key management of the storage-layer encryption. Please stay tuned.
Jonathan Barney is currently the lead security architect for public storage cloud(IBM GTS Offering) and SmartCloud Archive(BCRS cloud) at IBM. He has worked with SCE and SCE+ to some capacity. He also has experience with IBM CCRA. You can reach Jonathan on Twitter: @idle_j
To effectively compete in today’s changing world, it is essential that companies leverage innovative technology to differentiate from competitors. Learn how you can do that and more in the Smarter Computing Analyst Paper from Hurwitz and Associates.