Information on Dell Cloud Manager tools and general perspectives on cloud computing.

Cloud Security

04/23/2014

So it turns out there’s a lot of fear among the security community around using methodologies/concepts like DevOps. This fear is largely due to a number of myths about how organizations that are using a DevOps model are doing business, and what the implications are for the security of that organization. I’ll address one of those myths in today’s post, and some other myths in later posts.

Today’s myth is that by taking on the DevOps model of allowing developers to deploy code into production, you are violating separation of duties, which not only violates a variety of corporate policies but also has impact upon regulatory compliance requirements. And that would be true, if allowing developers to deploy to production actually violated separation of duties – but it doesn’t.

10/10/2013

For the most part, when it comes to security, there are not a lot of fundamental differences between running in your own data center versus on a public cloud provider. The differences that do exist however are important to understand both in terms of their implications and for dealing with them appropriately for your organization. These four differences are even more important if you have to deal with regulatory or legislative compliance regimes. The differences are:

Authentication/Identity Management: Identity management is a huge problem in the cloud space especially for Infrastructure as a Service (IaaS) providers. Very few provide the ability to leverage an enterprise directory such as LDAP or Active Directory (either natively or via SSO protocols such as SAML or WS-Security). This is less of an issue with Software as a Service (SaaS) providers who have a much higher tendency to support SSO of some sort. What this translates to though, is that each cloud you add becomes another IDM end point to manage; each one of which increases the chances of not properly de-provisioning a user when they change roles or leave the organization. An ideal response to this is to deploy a cloud management product that provides this sort of integration for you. Not only do you minimize the number of IDM end points to manage, but users can be automatically provisioned and de-provisioned on the basis of their directory groups. This also has the benefit that users no longer have any native accounts on the cloud provider so that they can’t make changes outside of your control systems. This becomes even more important when tied directly with the next concern.

Access control/Authorization: Cloud providers, as a rule do not offer fine grained access control to resources within their cloud. In many cases, the degree of coarseness is inconsistent across the various products that they offer which adds to the confusion of how to properly restrict access across a cloud account. A key example of the course grained access control problem is that with most clouds, once you have the ability to terminate a resource like a VM instance, you have the ability to do that to any VM within that account. This makes it very easy for someone to accidentally or maliciously terminate something they weren’t supposed to. To make matters more confusing, every cloud provider has a different scheme for authorizing users which makes running across multiple clouds more complex. A well designed cloud management tool addresses all of these issues by overlaying a consistent level of fine grained role and attribute based access controls that are cloud independent. For organizations using these sorts of tools, rules that restrict instance termination or firewall changes etc. are usually limited to the user or group that created the instance/rule for instance.

Both authentication and authorization/access control are key considerations when dealing with compliance related data because you need to be able to definitively be able to demonstrate to the auditors that you know who can make a set of changes.

Logging/alerting/auditing: This one is huge for compliance. Every compliance regime ever requires that you be able to demonstrate that you have an end to end log trail of who did what when. A dirty secret of the cloud industry is that most (none?) cloud providers from IaaS as to PaaS (Platform as a Service) to SaaS have the functionality to provide logging auditing or alerting on what users have done. Out of the box, this means that unless you are willing to go to manual logging process, you cannot use cloud providers for any compliance related application whether it falls under PCI, HIPAA, FISMA or anything else. Fortunately, since you’ve been worried about issues #1 and #2 above and you’ve deployed a cloud management product, you also get the logs you need. A high quality product will not only provide logs of what users did and when they did it, but will also provide automatic alerts when users do certain things. This is fantastic for tracking security related changes but also can be extremely helpful when doing incident response.

Key management: When it comes to key management, it’s not that it is different compared to running on premises, but rather that it is much more important to have a strong key management process in place because encryption becomes a lot more important especially when dealing with public cloud. Compliance drives this somewhat because many regimes mandate encryption, also breach disclosure laws usually give organizations a pass on announcing if their data was encrypted. Similarly a lot of organizations who are still uncomfortable with the security of the cloud providers like to encrypt everything so they feel more protected. Perhaps the biggest incentive to encrypting data however is that in the U.S., services providers don’t need to notify their customers if the customers’ data has been subpoena’s. With traditional outsourcing, you can get notification added as a contractual requirement, however with cloud service providers there’s generally only a boilerplate contract that doesn’t include this. As a result many organizations are encrypting all of their data so that should their provider get subpoena’s all the authorities get is encrypted data. To be truly effective though, they encryption keys can’t be stored on the cloud provider or this becomes an exercise in futility. This way, if an agency wants your data, they have to come to you with a subpoena requesting the keys. A good cloud management product will be able to manage encryption keys and author credentials outside of the clouds being managed as well as provide for automatic encryption and decryption of relevant resources as appropriate for an application.

The above four differentiators authentication, authorization, logging/alerting/auditing and key management form the basis of how cloud is different from traditional IT services. While these differences are key to understand, they can easily be addressed with a high quality cloud management solution that not only makes the cloud more usable but also more secure in the process.

David Mortman, Chief Security Architect at Enstratius (now a part of Dell Software), and has been doing Information Security for well over 15 years. Most recently, he was the Director of Security and Operations at C3. Previously, David was the CISO at Siebel Systems and the Manager of Global Security at Network Associates. David speaks regularly at Blackhat, Defcon and RSA amongst other conferences. Additionally, he blogs at emergentchaos.com, newschoolsecurity.com and securosis.com. David sits on a variety of advisory boards such as Qualys and Virtuosi. He holds a B.S. in Chemistry from the University of Chicago and bakes, cooks and juggles in his spare time.

04/11/2013

Ever since the advent of Infrastructure-as-a-Service (IaaS)
providers, a common complaint has been the difficulty of migrating machine
images between providers. This is particularly difficult given the wide range
of virtualization formats, hypervisor options and supported custom kernels. For
some providers, this even causes issues between their own regions or clouds. As a result, there is often concern about
vendor lock-in and also the propagation of the idea that building a
multi-region/multi-cloud application deployment is impossible.

The reality, however, is that image portability isn’t the
answer. It’s not even the question.

What you really need
to be asking is: “How portable are my applications and data?” Or, to
rephrase in a more actionable way: “Are the operating systems I need to use
available from my cloud provider(s) in the appropriate region(s)/cloud(s) that
I need to use?”

Idealists will say that if all of your providers are using
the same cloud platform, such as OpenStack, then image portability will “just
work”. Not so.

Even if all of your CSPs are based on the same platform
there are other compatibility issues:

Is the provider using the same hypervisor?

Are they supporting comparable kernels?

Have they made customizations in either that
break functionality?

One approach to dealing with these issues is to abstract
away as much of the operating system dependencies you have as possible, much
like IaaS clouds abstract away the hardware.

Start by using a configuration
management & automation tool like Opscode Chef or Puppet to template
out what your systems look like. When you switch or add another provider, the installations
and configurations of all of the standard pieces you use such as Apache, Tomcat,
MySQL, Riak, Cassandra and all of their dependencies, such as Java, are
automatically handled. This can even include things like installing SSL certs
and creating any necessary users on the VMs.

This approach significantly reduces the amount of data you
need to move between cloud providers, as well as easing the transitions with
regards to dependencies created by variations in operating systems or CSPs. You
can now focus on just moving your applications and their associated
configurations and data.

If you want to go more hardcore, you can abstract things
even further and use Chef/Puppet to install a Platform-as-a-Service (PaaS)
environment to make the application migration even more seamless. Regardless of how far you go down this
path,each bit you do to make yourself
more independent from your cloud provider will ultimately make it easier to
manage multiple cloud providers. Not only will it help you avoid lock-in,
but it also protects you from lock-out from other vendors you might want to use
today or in future.

David Mortman is the Enstratius Chief Security Architect and has been doing Information Security for well over 15 years. Most recently, he was the Director of Security and Operations at C3. Previously, David was the CISO at Siebel Systems and the Manager of Global Security at Network Associates. David speaks regularly at Blackhat, Defcon, and RSA amongst other conferences. Additionally, he blogs at emergentchaos.com, newschoolsecurity.com and securosis.com. David sits on a variety of advisory boards such as Qualys and Virtuosi. He holds a B.S. in Chemistry from the University of Chicago and bakes, cooks and juggles in his spare time.