Research

Encrypting IaaS storage is a hot topic, but it’s time to drop the esoterica and provide some technical details. I will use a lot of terminology from last week’s post on IaaS storage options, so you should probably read that one first if you haven’t already. Within the cloud you have all the same data storage options as in traditional infrastructure – from the media layer all the way up to the application. To keep this post from turning into a white paper, we will limit ourselves to volume storage, such as Amazon Elastic Block Storage (EBS), OpenStack volumes, and Rackspace RAID volumes. We’ll cover object storage and database/application options in future posts. Before we delve into the technology we should cover the risk/use cases. Volume encryption is very interesting, because it highlights some key differences between cloud and traditional infrastructure. In your non-cloud environment the only way for someone to steal an entire drive is to walk in and yank it from the rack, or plug in a second drive, make a byte-level copy, and walk out with that. I’m simplifying a bit, but for the most part they would need some type of physical access to get the entire drive. In the cloud it’s very different. Anyone with access to your management plane (with sufficient rights) can snapshot a volume and move it around. It only takes 2-3 command lines to snapshot a drive off to object storage, make it public, and then load it up in a hostile environment. So IaaS encryption: Protects volumes from snapshot cloning/exposure. Protects volumes from being explored by the cloud provider (and private cloud admins). Protects volumes from being exposed by physical loss of drives (more for compliance than a real-world security issue). Personally I worry much more about management plane/snapshot abuse than a malicious cloud admin. Now let’s delve into the technology. The key to evaluating data at rest encryption is to look at the locations of the three main components: The data (what you are encrypting). The encryption engine (the code/hardware that encrypts). The key manager. For example, our entire Understanding and Selecting a Database Encryption or Tokenization Solution paper is about figuring out where these bits to satisfy your requirements. IaaS volume encryption is very similar to media encryption in physical infrastructure. It’s a coarse control designed to encrypt entire ‘drives’, which in our case are virtual instead of physical. Whenever you mount a cloud volume to an instance it appears as a drive, which actually makes our lives easier. This protects against admin abuse, because the only way to see the data is to go through a running instance. It protects against snapshot abuse, because cloning only gets encrypted data. Today there are three main models: Instance-managed encryption: The encryption engine runs within the instance, and the key is stored in the volume but protected by a passphrase or public/private keypair. We use this model in the CCSK cloud security training – the volume is encrypted with the standard Linux dm-crypt (managed by the cryptsetup utility), with the key protected by a SHA-256 passphrase on the volume. This is great for portability – you can detach and move the volume anywhere you need, or even snapshot it, and can only open it if you have the passphrase. The passphrase should only be in volatile memory in your instance, which isn’t recorded during a snapshot. The downside is that if you want to automatically mount volumes (say as you spin up additional instances or if you need to reboot) you must either embed the passphrase/key in the instance (bad) or rely on a manual process (which can be automated with cloud-init, but that’s another big risk). You also can’t really build in integrity checking (which we will discuss in a moment). This method isn’t perfect but is well suited to many use cases. I don’t know of any commercial options, but this is free in many operating systems. Externally managed encryption The encryption engine runs in the instance, but the keys are managed externally and issued to the instance on request. This is more suitable for enterprise deployments because it scales far better and provides better security. One great advantage is that if your key manager is cloud aware, you can run additional integrity checks via the API and get quite granular in your policies for issuing keys. For example, you can automate key issuance if the instance was launched from a certain account, has an approved instance ID, or other criteria. Or you can add a manual check into the process where the instance requests the key and a security admin has to approve it, providing excellent separation of duties. The key manager can run in any of 3 locations: as dedicated hardware/server, as an instance, or as a service. The dedicated hardware or server needs to be connected to your cloud and is used only in private/hybrid clouds – its appeal is higher security or convenient extension of an existing key management deployment. Vormetric, SafeNet, and (I believe) Voltage offer this. Running in an instance is more convenient and likely relatively secure if you don’t need FIPS-140 certified hardware, and trust the hypervisor it’s running on. No one offers this yet, but it should be on the market later this year. Lastly, you can have a service manage your keys, like Trend SecureCloud. Proxy encryption In this model you connect the volume to a special instance or appliance/software, and then connect your instance to the encryption instance. The proxy handles all crypto operations, and may keep keys either onboard or in an external manager. This model is similar to the way many backup encryption tools work. The advantage is that even the engine runs (hopefully) in a more secure environment. Porticor is an option here. This should give you a good overview of the different options. One I didn’t mention, since I don’t know of any commercial or freeware options, is hypervisor-managed encryption. Technically you could have

Ever hear of File Activity Monitoring? You know, that cool new data security tech I published a white paper on? This Wednesday at 11 PT I will be giving a webinar on FAM (sponsored by Imperva – a guy’s gotta eat). I’ll cover the basics of the technology, why it’s useful, and some deployment scenarios/use cases. I do think this is something most of you are going to be looking at over the next few years (even if you don’t buy it), so might as well get started early 🙂 If you’re interested, you can register now. Share:

First day back in the saddle after vacation is always interesting. I must have had a million ideas while lounging on the beach. I remember maybe 3, and probably won’t have time to do much of anything for a while – first I need to dig out of a week of inflow. But one thing I did want to revisit quickly is defining what security folks are, and more importantly what we need to move forward. I hit on this years ago when I published the Pragmatic CSO and sent out a little series called “5 tips to be a better CSO.” The first is this: Tip #1: You are a business person, not a security person When I first meet a CSO, one of the first things I ask is whether they consider themselves a “security professional” or a “finance/healthcare/whatever other vertical” professional. 8 out of 10 times they respond “security professional” without even thinking. I will say that it’s closer to 10 out of 10 with folks that work in larger enterprises. These folks are so specialized they figure a firewall is a firewall is a firewall and they could do it for any company. They are wrong. One of the things preached in the Pragmatic CSO is that security is not about firewalls or any technology for that matter. It’s about protecting the systems (and therefore the information assets) of the business and you can bet there is a difference between how you protect corporate assets in finance and consumer products. In fact there are lots of differences between doing security in most major industries. There are different businesses, they have different problems, they tolerate different levels of pain, and they require different funding models. Pragmatic CSO’s view themselves as business people first, security people second. To put it another way, a healthcare CSO said it best to me. When I asked him the question, his response was “I’m a healthcare IT professional that happens to do security.” That was exactly right. He spent years understanding the nuances of protecting private information and how HIPAA applies to what he does. He understood how the claims information between providers and payees is sent electronically. He got the BUSINESS and then was able to build a security strategy to protect the systems that are important to the business. This concept came back to me when I was reading Dave Shackleford’s post, “I’m not a coder” may not fly forever. His point is that a lot of our security problems are application-centric and we need to develop a bit of code fu to be effective moving forward. Can’t argue that fact, but does that mean we can take our eye off the network? The servers? The data? Probably not. Many of us identify as security folks, but in reality that is a limiting and self-destructive perception. I think we are entering an age of security specialization, at least within the large enterprise. Generalists will get lost in the complexity of enterprise problems. I believe the senior security folks still have to be focused on the business issues, and be considered a senior management peer to be effective. That’s what I describe above – the idea of being a business specialist. But not everyone needs to (or can) play at that level. The technical practitioner will have to make a choice. I don’t see a way around that. As Dave points out, someone needs to understand applications at the code level. Shrdlu has pointed out on numerous occasions that one of the best hunting grounds for security folks is the ranks of system and network adminsm because they understand how this stuff really works within the infrastructure. But those folks probably won’t be code ninjas, not unless they are savants or something like that. Regardless of which discipline you choose, you’ll need to understand how things really work for plenty of reasons. First, security isn’t something that folks do out of the goodness of their hearts. So you have to appeal to these colleagues in their native languages. That’s business for business folks, code for developers, and network and server configs for admin types. You try to talk to these constituencies in a generic language and they’ll shut down, write you off, and in the best case ignore what you are saying. More likely they’ll go around whatever you try to do and make it pretty much impossible for you to succeed. Second, you need to really understand when someone is yanking your chain. You need to be able to call folks out when they go around you. You must build credibility with the folks you are trying to influence. The only way to do that is to show them you aren’t a lightweight in the area they care about. Unless you are, in which case you have different issues. Obviously if you work for a smaller entity, specialization is not an option. You just don’t have the bench strength. So you need to fight complexity, because you ultimately need to be a mile wide, which means you’ll be an inch deep. Again – unless you are a savant. But large enterprise security folks will be specialists, methinks. Agree? Disagree? Am I two years behind the common wisdom (for a change)? Share: