Research

Infrastructure as a Service (IaaS) is often thought of as merely as a more efficient (outsourced) version of our traditional infrastructure. On the surface you still manage things that look like simple virtualized networks, computers, and storage. You ‘boot’ computers (launch instances), assign IP addresses, and connect (virtual) hard drives. But while the presentation of IaaS resembles traditional infrastructure, the reality underneath is anything but business as usual. For both public and private clouds, the architecture of the physical infrastructure that comprises the cloud, as well as the connectivity and abstraction components used to provide it, dramatically alter how we need to manage our security. It isn’t that the cloud is more or less secure than traditional infrastructure, but it is very different. Protecting data in the cloud is a top priorities of most organizations as they adopt cloud computing. In some cases this is due to moving onto a public cloud, with the standard concerns any time you allow someone else to access or hold your data. But private clouds also comes with the same risk changes, even if they don’t trigger the same gut reaction as outsourcing. This series will dig into protecting data stored in and used with Infrastructure as a Service. There are a few options, but we will show why in the end the answer almost always comes down to encryption … with some twists. What Is IaaS Storage? Infrastructure as a Service includes two primary storage models: Object storage is a file repository. This is higher-latency storage with lower performance requirements, which stores individual files (‘objects’). Examples include Amazon S3 and RackSpace Cloud Files for public clouds, and OpenStack Swift for private clouds. Object storage is accessed using an API, rather than a network file share, which opens up a wealth of new uses – but you can layer a file browsing interface on top of the API. Volume storage is effectively a virtual hard drive. These higher-performing volumes attach to virtual machines and are used just like a physical hard drive or array. Examples include VMWare VMFS, Amazon EBS, RackSpace RAID, and OpenStack Cinder. To (over)simplify, object storage replaces file servers and volume storage is a substitute for hard drives. In both cases you take a storage pool – which could be anything from a SAN to hard drives on individual servers – and add abstraction and management layers. There are other kinds of cloud storage such as cloud databases, but they fall under either Platform as a Service (PaaS) or Software as a Service (SaaS). For this IaaS series, we will stick to object and volume storage. Due to the design of Infrastructure as a Service, data storage is very different than keeping it in ‘regular’ file repositories and databases. There are substantial advantages such as resilience, elasticity, and flexibility; as well as new risks in areas such as management, transparency, segregation, and isolation. How IaaS Is Different We will cover details in the next post, but at a high level: In private cloud infrastructure our data is co-mingled extensively, and the physical locations of data are rarely as transparent as before. You can’t point to a single server and say, “there are my credit card numbers” any more. Often you can set things up that way, at the cost of all the normal benefits of cloud computing. Any given piece of data may be located in multiple physical systems or even storage types. Part of the file might be on a server, some of it in a SAN, and the rest in a NAS, but it all looks like it’s in a single place. Your sensitive customer data might be on the same hard drive that, through layers of abstraction, also supports an unsecured development system. Plan incorrectly and your entire infrastructure can land in your PCI assessment scope – all mixed together at a physical level. To top it off, your infrastructure is now managed by a web-based API that, if not properly secured could allow someone on the other side of the planet unfettered access to your (virtual) data center. We are huge proponents of cloud computing, but we are also security guys. It is our job to help you identify and mitigate risks, and we’ll let infrastructure experts tell you why you should use IaaS in the first place. Public cloud infrastructure brings the same risks with additional complications because you no longer control ‘your’ infrastructure, your data might be mingled with anyone else on the Internet, and you lose most or all visibility into who (at your provider) can access your data. Whether private or public, you need to adjust security controls to manage the full abstraction of resources. You cannot rely on knowing where network cables plug into boxes anymore. Here are a few examples of how life changes: In private clouds, any virtual system that connects to any physical system holding credit card account numbers is within the scope of a PCI assessment. So if you run an application that collects credit cards in the same cloud as one that holds unsecured internal business systems, both are within assessment scope. Unless you take precautions we will talk about later. In public clouds an administrator at your cloud provider could access your virtual hard drives. This would violate all sorts of policies and contracts, but it is still technically quite possible. In most IaaS clouds a single command or API call can make an instant copy (snapshot) of an entire virtual hard drive, and then move it around your environment or make it public on the Internet. If your data is on the same hard drive as a criminal organization using the same cloud provider, and ‘their’ hardware is seized as part of an investigation, your data may be exposed. Yes, this has happened. It comes down to less visibility below the abstraction layer, and data from multiple tenants mixed on the same physical infrastructure. This is all manageable – it’s just different. Most of what we want to do, from a security standpoint, is use encryption and other techniques to either restore

MailChimp is offering a 10% discount to customers who enable 2-factor authentication. Impressive. Time to finish migrating our lists over to MailChimp (we only use them for the Friday Summary right now). We need to reward efforts like this. Share:

A lot of folks ask me how I work from home. My answer is simple: I don’t. I have a home office, but I do the bulk of my work from a variety of coffee shops in my local area. So I give a few minutes’ thought at night to where I want to work the following day. Sometimes I have a craving for a Willy’s Burrito Bowl, which means I drive 20 minutes to one of their coffee shops in Sandy Springs. Other times I just have to have the salad bar’s chocolate mousse at Jason’s Deli, which means there are three different places that I could work that day. Lunch drives office location. For me, anyway. Sometimes I don’t have the foggiest idea what I want to eat for lunch, so I get into the car and drive. Sooner or later I end up where I’m supposed to be and then I get to work. Assuming I can get a seat in the coffee shop, that is. Evidently I’m not the only guy who works like a nomad. Sometimes it’s a packed house and I need to move on to Plan B. There is always another coffee shop to carpet bag. I try not to go to the same coffee shops on the same days or to have any kind of predictable pattern. I usually shrug that off with the excuse that my randomized office location strategy is for operational security. You know, when they come to get me I want to make them work for it. But really it’s because I don’t want to overstay my welcome. I pay $2.50 a day for office space and all the coffee I can drink, because the places I hang out provide free refills. By showing up at a place no more than once a week, I can rationalize that I’m not taking advantage of their hospitality. And yes, analysts have the most highly-functioning rationalization engines of all known species. I also like to see other people. Notice I said see – not talk to. Big difference. I guess I have a little “I am Legend” fear of being the only person left on Earth, so seeing other folks in the coffee shop allays that fear. Sometimes I see someone I know, and they miss the social cues of me having my earbuds in and not making eye contact. I engage in a short chat because I’m not a total douche. Not always, anyway. As long as it’s not a long chat it’s okay, because I have to get back to my Twitter timeline and whatever drivel I need to write that day. The other reality of my office space is that I’m far more productive when I’m out of the house. And evidently I’m not alone. It seems that the ambient noise of a coffee shop can boost productivity, unlike the silence of sitting in my home office. There is even a new web site that can provide a soundtrack that sounds like a coffee shop to stir your creativity. Maybe that works for some night owls, who like to work on the graveyard shift when coffee shops are closed. For me, I’ll head out and find a real coffee shop. With real people for me not to talk to. Speaking of which, must be time for that refill… –Mike Photo credits: Busy Coffeeshop originally uploaded by Kevin Harbor Upcoming Cloud Security Training Interested in Cloud Security? Are you in EMEA (or have a ton of frequent flyer miles)? Mike will be teaching the CCSK Training class in Reading UK April 8-10. Sign up now. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Understanding Identity Management for Cloud Services Buyers Guide Architecture and Design Integration Newly Published Papers Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Understanding and Selecting a Key Management Solution Building an Early Warning System Implementing and Managing Patch and Configuration Management Defending Against Denial of Service Attacks Incite 4 U Follow the money to DDoS mitigation: Marcus Carey brings up a couple good questions regarding the screwed-up process to defend against volume-based DDoS. You basically contract with a service provider to take the massive traffic hit. But he correctly observes that’s somewhat stupid, because everyone else upstream needs to accept and transmit the bogus traffic aimed at you. Wouldn’t it be smarter for the closest service provider (the first mile) to block clear DDoS attacks? It would be. But it won’t happen, mostly because there is no way to compensate the first-mile provider for blocking the attack. It would also require advanced signaling to identify attack nodes and tell the upstream provider to block the traffic. To be clear, some consumer ISPs do block devices streaming traffic, but that’s because it’s screwing up their network. Not because they care about the target. As always, follow the money to see whether something will happen or not. In this case, the answer is ‘not’. – MR Smash ‘em up old school: Our FNG (Gal Shpantzer) and I were talking about the recent malware attacks in South Korea the other day. Unlike most attacks we see these days, these didn’t target data (at least, on the surface), but instead left a trail of destruction. If you think about it, most of our security defenses over the past 10 years were oriented toward preventing data breaches. Before that it was all about stopping massive proliferation of malware and worms. So we have covered destructive attacks and then targeted attacks, but not necessarily both. I don’t expect this to be a big trend – the financial and political economics, meaning the risk of mutually assured destruction, self-limit the number of possible targeted destruction attacks, but I expect to hear more about this in the next couple years. It is a very tough

I recently participated in a roundtable for NetworkWorld, tackling the question of Who is responsible for cloud security?. First of all the picture is hilarious, especially because it shows my head photoshopped onto some dude with a tie. Like I’d wear a tie. But some of the discussion was interesting. As with any roundtable, you get a great deal of puffery and folks trying to make themselves sound smart by talking nonsense. Here are a couple good quotes from yours truly, who has never been known to talk nonsense. NW: Let’s start with a basic question. When companies are building hybrid clouds, who is responsible for what when it comes to security? What are the pain points as companies strive to address this? ROTHMAN: A lot of folks think having stuff in the cloud is the same as having it on-premises except you don’t see the data center. They think, “I’ve got remote data centers and that’s fine. I’m able to manage my stuff and get the data I need.” But at some point these folks are in for a rude awakening in terms of what the true impact of not having control over layer four and down is going to mean in terms of lack of visibility. NW: As Sutherland mentioned earlier, a lot of this has to be baked into the contract terms. Are there best practices that addresses how? ROTHMAN: A lot has to do with how much leverage you have with the provider. With the top two or three public cloud providers, there’s not going to be a lot of negotiation. Unless you have a whole mess of agencies coming along with you, as in [Kingsberry’s] case, you’re just a number to these guys. When you deal with smaller, more hungry cloud providers, and this applies to SaaS as well, then you’ll have the ability to negotiate some of these contract variables. NW: How about the maturity of the cloud security tools themselves? Are they where they need to be? ROTHMAN: You’ll walk around the RSA Conference and everybody will say their tools don’t need to change, everything works great and life is wonderful. And then after you’re done smoking the RSA hookah you get back to reality and see a lot of fundamental differences of how you manage when you don’t have visibility. Yes, I actually said RSA hookah and they printed it. Win! Check out the entire roundtable – they have some decent stuff in there. Photo credit: “THE BLAME GAME” originally uploaded by Lou Gold Share: