Research

Hey everyone. It’s a new year and time for new stuff from your pals here at Securosis. We used to run a Monday-morning ‘Firestarter’ post to get people thinking for the week. We decided to revive it with a twist. We are restarting the Firestarter as a weekly short video (15 minutes or so is our target). As we work out the details we also plan to push it out as a podcast, and once every month or so we will run a longer episode to dig deeper into a topic. We pre-recorded this version, but as you’ll see we ran it on Google Hangouts. When possible, we will post our recording times up there so you can participate (sorry, via text only) as we record. This week we decided to cover the NSA/RSA controversy and the… interesting… decision by some to pull out of the RSA conference over it. Share:

As you may have noticed, I haven’t been blogging much the past month or so. 2013 has been an… interesting… year, filled with personal and professional highs and lows. Our third child was born, and we were back in the thick of things with 3 kids aged four and under. Don’t even get me stared on the near nonstop string of minor illnesses. There’s nothing like stomach flu twice in a month. Once on a travel day – thus the last month of minimal blogging. On the other hand my son took his first steps just shy of 7 months old, I had one of my best business years yet (yep, Securosis grew once again), and experienced a career highlight by presenting my first technical Black Hat session on 90 minutes notice (including a technical demo). Work-wise I am having more fun than I have in many years – largely due to spending more time hands-on with programming and the cloud. This is the kind of defensive technical security research I have always wanted to drive forward. And the bonus? My daughters love super heroes, robots, and science (plus princesses and the color pink – I’m not trying to turn them into boys or anything). All this is possible because of you reading the site. Every day thousands of you read our content (or point your bots at us), and a fair few hire us to help you with research and analysis. We aren’t a billion-dollar company with a big name – just a couple handfuls of full and part time security obsessives who get the opportunity to do what we love, and enjoy an amazing lifestyle with our families in the process. We never, not for an instant, forget who we serve and who makes this all possible. We only hope we meet our end of the bargain by providing you something useful. We have a lot of new things lined up for 2014. The nature of our work is pulling us in new and exciting directions, and we try to adapt every year to the ever-changing landscape of social media and online tools we use to engage and deliver content. Some of it works and some doesn’t – that’s life. As 2013 comes to a close, I just wanted to personally thank you all. (You know, with a heartfelt generic blog post.) And I would like to also thank our contributors… some of whom get paid, and others who keep us on our toes with their insights. Mort, Pepper, Gattaca, Myrcurial, Gunnar, and Gal. Plus Mike and Adrian – the best two partners I could ask for. Or not ask for – they actually sort of just showed up, uninvited. Share:

This should be no surprise because I just pounded through all the posts and put the paper up on GitHub for open review. As of today I am happy to launch the official exec-friendly white paper version of the Executive Guide to Pragmatic Network Security Management. There is a landing page, or you can go directly to the PDF. As a reminder, this paper focuses on managing your network security program – not a particular appliance or tool. It targets those of you with larger or more complex networks – or, really, anyone struggling to manage network security from a big picture perspective. I would like to thank RedSeal Networks for licensing the paper, which is how we get to publish these things for free. Share:

Ah, the holidays. That wonderful time of year when I struggle to attempt to explain to my children why the Christmas decorations are up before Thanksgiving. They are very adamant that Thanksgiving is first, and there really shouldn’t be Xmas decorations yet. Because I agree, and struggle to keep “Burn their houses down!” in my head rather than out loud when I drive past certain neighbors, I really can’t explain. Which is somewhat, well, odd, because I am a bit of a Jewish atheist. I mean really, of all the people on this planet, I am fairly low on the list of ones who should be obsessing about putting up colored lights and fake trees. But the thing is, we American Jews friggin’ love Christmas. Oh, not the religious pieces, those are quite confusing to us, but the general holiday spirit. And by “holiday spirit” I mean TV episodes, reruns of Christmas Vacation, the decorations and music, the endless catalogs that make Sky Mall look like one of those corporate 15-year anniversary gift brochures (you know, filled with demeaning lucite blocks and trashy fake jewelry to reward your many years of slavish dedication to the corporate overlords). But back to the decorations. My wife’s parents’ have neighbors who spent two days putting up their decorations. Actually, I need to correct myself: they spent two days watching the people they paid put up the decorations. Not two hours. Two. Full. Days. I will be the first to admit I have experienced a passing mental dalliance with the concept of paying someone with a much nicer ladder than me to spend an hour or two giving my home a colored LED bodyslam, but it just seems wrong. The whole idea of the holidays is to outdo your neighbors with your own sweat and blood, Clark Griswald style. To relish how your ability to run an extension cord to the second story makes you a better person. Paying someone? That’s the Lance Armstrong of Christmas. Actually, Lance had to cheat because everyone else was – he was just better and meaner at it. Paying someone to put up your lights before Thanksgiving makes you lower than a meth cooker with an ice cream truck. There’s no excuse for it, and I, for one, plan on complaining to my HOA. Which probably won’t help because I live in a different town, but someone needs to know. Sorry. I was going to talk about how awesome the Amazon Web Services concert conference was, but the lights got under my skin. For the record, I can’t remember a more exciting time to be in technology, and thanks to Amazon and other innovators, a truly awesome future is becoming reality. But did I mention those lights? &$%ers. On to the Summary: Favorite Securosis Posts Mike Rothman: CISO’s Guide to the Cloud: Real World Examples. Rich just killed it in this series. Really great research from top to bottom. And stuff not many others are thinking about. Yet. They will. Adrian Lane: Compliance for the Sake of Compliance. If a company can’t implement a security program, there is no security program. Rich: Mike’s You Cannot Outsource Accountability. Ever. Other Securosis Posts Digging into the Underground. Incite 11/20/2013 – Live Right Now. Black Hat Cloud Security Training (Beta) in Seattle Next Month. Defending Against Application Denial of Service: Building Protections in. The CISO’s Guide to the Cloud: Adapting Security for Cloud Computing, Part 2. The CISO’s Guide to the Cloud: Adapting Security for Cloud Computing (part 1). Favorite Outside Posts Mike Rothman: 20 Things You Need to Let Go to Be Happy. Ah, the elusive happiness. For me, happy is a place I visit a couple times a day. Then it passes. But these little tips remind me about why I get unhappy. Mostly because I’m not following this advice. Adrian Lane: 2014 to be an eventful year for SSL. Most people forget that SHA-1 is basic infrastructure, used by just about every single HTTPS/SSL/TLS connection in existence. The deprecation of SHA-1 is not just because it was an NSA contribution via NIST, but it has overstayed its welcome. Larry does a nice job of covering the issues. Mort: What’s my name? No, really, what is it? In other words: a user forgetting their username and/or password is orders of magnitude more likely than user enumeration… Mort (2): Boring Is Good. Rich: AWS vs. CSPs: Hardware Infrastructure. I was at these sessions. It is hard to express the enormity of cloud computing in general, and AWS in particular. They can’t even buy routers big enough to handle the traffic so they have to build their own networking stack and rearchitect everything. Research Reports and Presentations Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Dealing with Database Denial of Service. The 2014 Endpoint Security Buyer’s Guide. The CISO’s Guide to Advanced Attackers. Top News and Posts Senators back lawsuit against NSA: ‘no evidence’ that bulk phone spying helps national security. Feds Arrest 5 More Suspects in $45 Million Global Bank Heist. The second operating system hiding in every mobile phone. Blog Comment of the Week This week’s best comment goes to Andrew, in response to The CISO’s Guide to the Cloud: Adapting Security for Cloud Computing. ‘We cannot overstate the importance of hardening the management plane. It literally provides absolute control over your cloud deployment – often including all disaster recovery.’ Great point. Information assurance is vital. Managing all the risks related to the usage, processing, storage, and transmission of data needs to be at the core of cloud services. Share:

This is part five of a series. You can read part one, part two, part three, or part four; or track the project on GitHub. Real World Examples Cloud computing covers such a wide range of different technologies that there are no shortage of examples to draw from. Here are a few generic examples from real-world deployments. These get slightly technical because we want to highlight practical, tactical techniques to prove we aren’t just making all this up: Embedding and Validating a Security Agent Automatically In a traditional environment we embed security agents by building them into standard images or requiring server administrators to install and register them. Both options are very prone to error and omission, and hard to validate because you often need to rely on manual scanning. Both issues become much easier to manage in cloud computing. To embed the agent: The first option is to build the agent into images. Instead of using generic operating system images you build your own, then require users to only launch approved images. In a private cloud you can enforce this with absolute control of what they run. In public clouds it is a bit tougher to enforce, but you can quickly catch exceptions using our validation process. The second option, and our favorite, is to inject the agent when instances launch. Some operating systems support initialization scripts which are passed to the launching instance by the cloud controller. Depending again on your cloud platform, you can inject these scrips automatically when autoscaling, via a management portal, or manually at other times. The scripts install and configure software in the instance before it is accessible on the network. Either way you need an agent that understands how to work within cloud infrastructure and is capable of self-registering to the management server. The agent pulls system information and cloud metadata, then connects with its management server, which pushes configuration policies back to the agent so it can self-configure. This process is entirely automated the first time the agent runs. Configuration may be based on detected services running on the instance, metadata tags applied to the instance (in the cloud management plane), or other characteristics such as where it is on the network. We provide a detailed technical example of agent injection and self-configuration in our Software Defined Security paper. The process is simple. Build the agent into images or inject it into launching instances, then have it connect to a management server to configure itself. The capabilities of these agents vary widely. Some replicate standard endpoint protection but others handle system configuration, administrative user management, log collection, network security, host hardening, and more. Validating that all your instances are protected can be quite easy, especially if your tool supports API: Obtain a list of all running instances from the cloud controller. This is a simple API call. Obtain a list of all instances with the security agent. This should be an API call to your security management platform, but might require pulling a report if that isn’t supported. Compare the lists. You cannot hide in the cloud, so you know every single instance. Compare active instances against managed instances, and find the exceptions. We also show how to do this in the paper linked above. Controlling SaaS with SAML Pretty much everyone uses some form of Software as a Service, but controlling access and managing users can be a headache. Unless you link up using federated identity, you need to manage user accounts on the SaaS platform manually. Adding, configuring, and removing users on yet another system, and one that is always Internet accessible, is daunting. Federated identity solves this problem: Enable federated identity extensions on your directory server. This is an option for Active Directory and most LDAP servers. Contact your cloud provider to obtain their SAML configuration and management requirements. SAML (Security Assertion Markup Language) is a semi-standard way for a relying party to allow access and activities based on approval from an identity provider. Configure SAML yourself or use a third-party tool compatible with your cloud provider(s) which does this for you. If you use several SaaS providers a tool will save a lot of effort. With SAML users don’t have a username and password with the cloud provider. The only way to log in is to first authenticate to your directory server, which then provides (invisible to the user) a token to allow access to the cloud provider. Users need to be in the office or on a VPN. If you want to enable remote users without VPN you can set up a cloud proxy and issue them a special URL to use instead of the SaaS provider’s standard address. This address redirects to your proxy, which then handles connecting back to your directory server for authentication and authorization. This is something you typically buy rather than build. Why do this? Instead of creating users on the SaaS platform it enables you to use existing user accounts in your directory server and authorize access using standard roles and groups, just like you do for internal servers. You also now get to track logins, disable accounts from a single source (your directory server), and otherwise maintain control. It also means people can’t steal a user’s password and then access Salesforce from anywhere on the Internet Compartmentalizing Cloud Management with IAM One of the largest new risks in cloud computing is Internet-accessible management of your entire infrastructure. Most cloud administrators use cloud APIs and command line interfaces to manage the infrastructure (or PaaS, and even sometimes SaaS). This means access credentials are accessed through environment variables or even the registry. If they use a web interface that opens up browser-based attacks. Either way, without capability compartmentalization an attacker could take complete control over their infrastructure by merely hacking a laptop. With a few API calls or a script they could copy or destroy everything in minutes. All cloud platforms support internal identity and access management to varying degrees –

This is part four of a series. You can read part one, part two, or part three; or track the project on GitHub. As a reminder, this is the second half of our section on examples for adapting security to cloud computing. As before this isn’t an exhaustive list – just ideas to get you started. Intelligently Encrypt There are three reasons to encrypt data in the cloud, in order of their importance: Compliance. To protect data in backups, snapshots, and other portable copies or extracts. To protect data from cloud administrators. How you encrypt varies greatly, depending on where the data resides and which particular risks most concern you. For example many cloud providers encrypt object file storage or SaaS by default, but they manage the keys. This is often acceptable for compliance but doesn’t protect against a management plane breach. We wrote a paper on infrastructure encryption for cloud, from which we extracted some requirements which apply across encryption scenarios: If you are encrypting for security (as opposed to a compliance checkbox) you need to manage your own keys. If the vendor manages your keys your data may still be exposed in the event of a management plane compromise. Separate key management from cloud administration. Sure, we are all into DevOps and flattening management, but this is one situation where security should manage outside the cloud management plane. Use key managers that are as agile and elastic as the cloud. Like host security agents, your key manager needs to operate in an environment where servers appear and disappear automatically, and networks are virtual. Minimize SaaS encryption. The only way to encrypt data going to a SaaS provider is with a proxy, and encryption breaks the processing of data at the cloud provider. This reduces the utility of the service, so minimize which fields you need to encrypt. Or, better yet, trust your provider. Use secure cryptography agents and libraries when embedding encryption in hosts or IaaS and PaaS applications. The defaults for most crypto libraries used by developers are not secure. Either understand how to make them secure or use libraries designed from the ground up for security. Federate and Automate Identity Management Managing users and access in the cloud introduces two major headaches: Controlling access to external services without having to manage a separate set of users for each. Managing access to potentially thousands or tens of thousands of ephemeral virtual machines, some of which may only exist for a few hours. In the first case, and often the second, federated identity is the way to go: For external cloud services, especially SaaS, rely on SAML-based federated identity linked to your existing directory server. If you deal with many services this can become messy to manage and program yourself, so consider one of the identity management proxies or services designed specifically to tackle this problem. For access to your actual virtual servers, consider managing users with a dynamic privilege management agent designed for the cloud. Normally you embed SSH keys (or known Windows admin passwords) as part of instance initialization (the cloud controller handles this for you). This is highly problematic for privileged users at scale, and even straight directory server integration is often quite difficult. Specialized agents designed for cloud computing dynamically update users, privileges, and credentials at cloud speeds and scale. Adapt Network Security Networks are completely virtualized in cloud computing, although different platforms use different architectures and implementation mechanisms, complicating the situation. Despite that diversity there are consistent traits to focus on. The key issues come down to loss of visibility using normal techniques, and adapting to the dynamic nature of cloud computing. All public cloud providers disable networking sniffing, and that is an option on all private cloud platforms. A bad guy can’t hack a box and sniff the entire network, but you also can’t implement IDS and other network security like in traditional infrastructure. Even when you can place a physical box on the network hosting the cloud, you will miss traffic between instances on the same physical server, and highly dynamic network changes and instances appear and disappear too quickly to be treated like regular servers. You can sometimes use a virtual appliance instead, but unless the tool is designed to cloud specifications, even one that works in a virtual environment will crack in a cloud due to performance and functional limitations. While you can embed more host network security in the images your virtual machines are based on, the standard tools typically won’t work because they don’t know exactly where on the network they will pop up, nor what addresses they need to talk to. On a positive note, all cloud platforms include basic network security. Set your defaults properly, and every single server effectively comes with its own firewall. We recommend: Design a good baseline of Security Groups (the basic firewalls that secure the networking of each instance), and use tags or other mechanisms to automatically apply them based on server characteristics. A Security Group is essentially a firewall around every instance, offering compartmentalization that is extremely difficult to get in a traditional network. Use a host firewall, or host firewall management tool, designed for your cloud platform or provider. These connect to the cloud itself to pull metadata and configure themselves more dynamically than standard host firewalls. Also consider pushing more network security, including IDS and logging, into your instances. Prefer virtual network security appliances that support cloud APIs and are designed for the cloud platform or provider. For example, instead of forcing you to route all your virtual traffic through it as if you were on a physical network, the tool could distribute its own workload – perhaps even integrating with hypervisors. Take advantage of cloud APIs. It is very easy to pull every Security Group rule and then locate every instance. Combined with some additional basic tools you could then automate finding errors and omissions. Many cloud deployments do this today as a matter of course.

I am teaching another cloud security class for Black Hat. There are two classes, one on December 9-10, and the other December 11-12. This class covers the CCSK certificate requirements and includes a test token to sit the exam (online). But we maintain the CCSK courseware, and it is time to try out some updated material. Specifically: We are streamlining the lecture day to reduce cruft and generally clean up the slides. We have even more real-world examples of how to get things done, based on our ongoing research. The labs are being updated for changes at Amazon Web Services. We are bringing more advanced material, as we did in Black Hat Vegas. The advanced material is not part of the core course, and we only get to it after the normal training requirements. It is an extension of the material I wrote about in the Software Defined Security paper. This class also qualifies as a Train the Trainer course, with some additional online training we offer for free after the class proper. If you want to become an instructor and sign up for this class, please email me and let me know ahead of time. Thanks, and hope to see you in Seattle! Share:

This is part three of a series. You can read part one or part two, or track the project on GitHub. This part is split into two posts – here is the first half: Adapting Security for Cloud Computing If you didn’t already, you should now have a decent understanding of how cloud computing differs from traditional infrastructure. Now it’s time to switch gears to how to evolve security to address shifting risks. These examples are far from comprehensive, but offer a good start and sample of how to think differently about cloud security. General Principles As we keep emphasizing, taking advantage of the cloud poses new risks, as well as both increasing and decreasing existing risks. The goal is to leverage the security advantages, freeing up resources to cover the gaps. There are a few general principles for approaching the problem that help put you in the proper state of mind: You cannot rely on boxes and wires. Quite a bit of classical security relies on knowing the physical locations of systems, as well as the network cables connecting them. Network traffic in cloud computing is virtualized, which completely breaks this model. Network routing and security are instead defined by software rules. There are some advantages here, which are beyond the scope of this paper but which we will detail with future research. Security should be as agile and elastic as the cloud itself. Your security tools need to account for the highly dynamic nature of the cloud, where servers might pop up automatically and run for only an hour before disappearing forever. Rely more on policy-based automation. Wherever possible design your security to use the same automation as the cloud itself. For example there are techniques to automate (virtual) firewall rules based on tags associated with a server, rather than applying them manually. Understand and adjust for the characteristics of the cloud. Most virtual network adapters in cloud platforms disable network sniffing, so that risk drops off the list. Security groups are essentially virtual firewalls that on individual instance, meaning you get full internal firewalls and compartmentalization by default. Security tools can be embedded in images or installation scripts to ensure they are always installed, and cloud-aware ones can self configure. SAML can be used to provide absolute device and user authentication control to external SaaS applications. All these and more are enabled by the cloud, once you understand its characteristics. Integrate with DevOps. Not all organizations are using DevOps, but DevOps principles are pervasive in cloud computing. Security teams can integrate with this approach and leverage it themselves for security benefits, such as automating security configuration policy enforcement. Defining DevOps DevOps is an IT model that blurs the lines between development and IT operations. Developers play a stronger role in managing their own infrastructure through heavy use of programming and automation. Since cloud enables management of infrastructure using APIs, it is a major enabler of DevOps. While it is incredibly agile and powerful, lacking proper governance and policies it can also be disastrous since it condenses many of the usual application development and operations check points. These principles will get you thinking in cloud terms, but let’s look at some specifics. Control the Management Plane The management plane is the administrative interfaces, web and API, used to manage your cloud. It exists in all types of cloud computing service models: IaaS, PaaS, and SaaS. Someone who compromises a cloud administrator’s credentials has the equivalent of unmonitored physical access to your entire data center, with enough spare hard drives, fork lifts, and trucks to copy the entire thing and drive away. Or blow the entire thing up. We cannot overstate the importance of hardening the management plane. It literally provides absolute control over your cloud deployment – often including all disaster recovery.* We have five recommendations for securing the management plane: If you manage a private cloud, ensure you harden the web and API servers, keeping all components up to date and protecting them with the highest levels of web application security. This is no different than protecting any other critical web server. Leverage the Identity and Access Management features offered by the management plane. Some providers offer very fine-grained controls. Most also integrate with your existing IAM using federated identity. Give preference to your platform/provider’s controls and… Compartmentalize with IAM. No administrator should have full rights to all aspects of the cloud. Many providers and platforms support granular controls, including roles and groups, which you can leverage to restrict the damage potential of a compromised developer or workstation. For example, you can have a separate administrator for assigning IAM rights, only allow administrators to manage certain segments of your cloud, and further restrict them from terminating instances. Add auditing, logging, and alerting where possible. This is one of the more difficult problems in cloud security because few cloud providers audit administrator activity – such as who launched or stopped a server using the API. For now you will likely need a third-party tool or to work with particular providers for necessary auditing. Consider using security or cloud management proxies. These tools and services proxy the connection between a cloud administrator and the public or private cloud management plane. They can apply additional security rules and fill logging and auditing gaps. Automate Host (Instance) Security An instance is a virtual machine, which is based on a stored template called an image. When you ask the cloud for a server you specify the image to base it on, which includes an operating system and might bring a complete single-server application stack. The cloud then configures it using scripts which can embed administrator credentials, provide an IP address, attach and format storage, etc. Instances may exist for years or minutes, are configured dynamically, and can be launched nearly anywhere in your infrastructure – public or private. You cannot rely on manually assessing and adjusting their security. This is very different than building a server in a test environment, performing a

This is part two of a series. You can read part one here or track the project on GitHub. How the Cloud Is Different for Security In the early days of cloud computing, even some very well-respected security professionals claimed it was little more than a different kind of outsourcing, or equivalent to the multitenancy of a mainframe. But the differences run far deeper, and we will show how they require different cloud security controls. We know how to manage the risks of outsourcing or multi-user environments; cloud computing security builds on this foundation and adds new twists. These differences boil down to abstraction and automation, which separate cloud computing from basic virtualization and other well-understood technologies. Abstraction Abstraction is the extensive use of multiple virtualization technologies to separate compute, network, storage, information, and application resources from the underlying physical infrastructure. In cloud computing we use this to convert physical infrastructure into a resource pool that is sliced, diced, provisioned, deprovisioned, and configured on demand, using the automation we will talk about next. It really is a bit like the matrix. Individual servers run little more than a hypervisor with connectivity software to link them into the cloud, and the rest is managed by the cloud controller. Virtual networks overlay the physical network, with dynamic configuration of routing at all levels. Storage hardware is similarly pooled, virtualized, and then managed by the cloud control layers. The entire physical infrastructure, less some dedicated management components, becomes a collection of resource pools. Servers, applications, and everything else runs on top of the virtualized environment. Abstraction impacts security significantly in four ways: Resource pools are managed using standard, web-based (REST) Application Programming Interfaces (APIs). The infrastructure is managed with network-enabled software at a fundamental level. Security can lose visibility into the infrastructure. On the network we can’t rely on physical routing for traffic inspection or management. We don’t necessarily know which hard drives hold which data. Everything is virtualized and portable. Entire servers can migrate to new physical systems with a few API calls or a click on a web page. We gain greater pervasive visibility into the infrastructure configuration itself. If the cloud controller doesn’t know about a server it cannot function. We can map the complete environment with those API calls. We have focused on Infrastructure as a Service, but the same issues apply to Platform and Software as a Service, except they often offer even less visibility. Automation Virtualization has existed for a long time. The real power cloud computing adds is automation. In basic virtualization and virtual data centers we still rely on administrators to manually provision and manage our virtual machines, networks, and storage. Cloud computing turns these tasks over to the cloud controller to coordinate all these pieces (and more) using orchestration. Users ask for resources via web page or API call, such as a new server with 1tb of storage on a particular subnet, and the cloud determines how best to provision it from the resource pool; then it handles installation, configuration, and coordinating all the networking, storage, and compute resources to pull everything together into a functional and accessible server. No human administrator required. Or the cloud can monitor demand on a cluster and add and remove fully load-balanced and configured systems based on rules, such as average system utilization over a specified threshold. Need more resources? Add virtual servers. Systems underutilized? Drop them back into the resource pool. In public cloud computing this keeps costs down as you expand and contract based on what you need. In private clouds it frees resources for other projects and requirements, but you still need a shared resource pool to handle overall demand. But you are no longer stuck with under-utilized physical boxes in one corner of your data center and inadequate capacity in another. The same applies to platforms (including databases or application servers) and software; you can expand and contract database storage, software application server capacity, and storage as needed – without additional capital investment. In the real world it isn’t always so clean. Heavy use of public cloud may exceed the costs of owning your own infrastructure. Managing your own private cloud is no small task, and is ripe with pitfalls. And abstraction does reduce performance at certain levels, at least for now. But with the right planning, and as the technology continues to evolve, the business advantages are undeniable. The NIST model of cloud computing is the best framework for understanding the cloud. It consists of five Essential Characteristics, three Service Models (IaaS, PaaS, and SaaS) and four Delivery Models (public, private, hybrid and community). Our characteristic of abstraction generally maps to resource pooling and broad network access, while automation maps to on-demand self service, measured service, and rapid elasticity. We aren’t proposing a different model, just overlaying the NIST model to better describe things in terms of security. Thanks to this automation and orchestration of resource pools, clouds are incredibly elastic, dynamic, agile, and resilient. But even more transformative is the capability for applications to manage their own infrastructure because everything is now programmable. The lines between development and operations blur, offering incredible levels of agility and resilience, which is one of the concepts underpinning the DevOps movement. But of course done improperly it can be disastrous. Cloud, DevOps, and Security in Practice: Examples Here are a few examples that highlight the impact of abstraction and automation on security. We will address the security issues later in this paper. Autoscaling: As mentioned above, many IaaS providers support autoscaling. A monitoring tool watches server load and other variables. When the average load of virtual machines exceeds a configurable threshold, new instances are launched from the same base image with advanced initialization scripts. These scripts can automatically configure all aspects of the server, pulling metadata from the cloud or a configuration management server. Advanced tools can configure entire application stacks. But these servers may only exist for a short period, perhaps never during a vulnerability

This is the first post in a new series detailing the key differences between cloud computing and traditional security. I feel pretty strongly that, although many people are talking about the cloud, nobody has yet done a good job of explaining why and how security needs to adapt at a fundamental level. It is more than outsourcing, more than multitenancy, and definitely more than simple virtualization. This is my best stab at it, and I hope you like it. The entire paper, as I write it, is also posted and updated at GitHub for those of you who want to track changes, submit feedback, or even submit edits. Special thanks to CloudPassage for agreeing to license the paper (as always, we are following our Totally Transparent Research Process and they do not have any more influence than you do, and can back out of licensing the paper if, in the end, they don’t like it). And here we go… What CISOs Need to Know about Cloud Computing Introduction One of a CISO’s most difficult challenges is sorting the valuable wheat from the overhyped chaff, and then figuring out what it means in terms of risk to your organization. There is no shortage of technology and threat trends, and CISOs need not to only determine which matter, but how they impact security. The rise of cloud computing is one of the truly transformative evolutions that fundamentally change core security practices. Far more than an outsourcing model, cloud computing alters the very fabric of our infrastructure, technology consumption, and delivery models. In the long run, the cloud and mobile computing are likely to mark a larger shift than the Internet. This series details the critical differences between cloud computing and traditional infrastructure for security professionals, as well as where to focus security efforts. We will show that the cloud doesn’t necessarily increase risks – it shifts them, and provides new opportunities for significant security improvement. Different, But Not the Way You Think Cloud computing is a radically different technology model – not just the latest flavor of outsourcing. It uses a combination of abstraction and automation to achieve previously impossible levels of efficiency and elasticity. But in the end cloud computing still relies on traditional infrastructure as its foundation. It doesn’t eliminate physical servers, networks, or storage, but allows organizations to use them in different ways, with substantial benefits. Sometimes this means building your own cloud in your own datacenter; other times it means renting infrastructure, platforms, and applications from public providers over the Internet. Most organizations will use a combination of both. Public cloud services eliminate most capital expenses and shift them to on-demand operational costs. Private clouds allow more efficient use of capital, tend to reduce operational costs, and increase the responsiveness of technology to internal needs. Between the business benefits and current adoption rates, we expect cloud computing to become the dominant technology model over the next ten to fifteen years. As we make this transition it is the technology that create clouds, rather than the increased use of shared infrastructure, that really matters for security. Multitenancy is more an emergent property of cloud computing than a defining characteristic. Security Is Evolving for the Cloud As you will see, cloud computing isn’t more or less secure than traditional infrastructure – it is different. Some risks are greater, some are new, some are reduced, and some are eliminated. The primary goal of this series is to provide an overview of where these changes occur, what you need to do about them, and when. Cloud security focuses on managing the different risks associate with abstraction and automation. Mutitenancy tends to be more a compliance issue than a security problem, and we will cover both aspects. Infrastructure and applications are opened up to network-based management via Internet APIs. Everything from core network routing to creating and destroying entire application stacks is now possible using command lines and web interfaces. The early security focus has been on managing risks introduced by highly dynamic virtualized environments such as autoscaled servers, and broad network access, including a major focus on compartmentalizing cloud management. Over time the focus is gradually shifting to hardening the cloud infrastructure, platforms, and applications, and then adapting security to use the cloud to improve security. For example, the need for data encryption increases over time as you migrate more sensitive data into the cloud. But the complexities of internal network compartmentalization and server patching are dramatically reduced as you leverage cloud infrastructure. We expect to eventually see more security teams hook into the cloud fabric itself – bridging existing gaps between security tools and infrastructure and applications with Software Defined Security. The same APIs and programming techniques that power cloud computing can provide highly-integrated dynamic and responsive security controls – this is already happening. This series will lay out the key differences, with suggestions for where security professionals should focus. Hopefully, by the end, you will look at the cloud and cloud security in a new light, and agree that the cloud isn’t just the latest type of outsourcing. Share: