The enStratus Blog

Cloud Management and Identity

I would like to focus on one of the big challenges in cloud information security—identity and access management. Or in other words, authentication and authorization.

How do you cleanly control who has access to what within your enterprise?

The authentication piece has been getting easier (though there are still a lot of hurdles) as more operating systems and applications support technologies such as ActiveDirectory (AD), LDAP and Single Sign On. Authorization is a much bigger problem as most applications still aren’t leveraging directory services as well as they could, but rather have their own built-in authorization systems. If you are lucky, however, they can map roles to AD or LDAP groups.

This problem is magnified when you start moving to the cloud and especially so when you move to public cloud. And while some cloud providers, most notably AWS, have started adding some authorization functionality most have little to nothing to offer on this front. As an example, on most (all?) providers anyone who has access to terminate instances can terminate any instance in that account!

One company I’m familiar with had a developer with legitimate access to their cloud provider accidentally terminate several key development databases when trying to terminate some test instances they had launched. Fortunately, those databases were backed up so recovery was relatively simple, though it did stop work for several hours while the recovery happened. Other companies I’ve talked with have dealt with this issue by creating a separate cloud account for each project. This isn’t too painful when you have a few accounts, but this quickly scales beyond the point of manageability with some companies having as many as 60, 80 or even 150 (or more!) different cloud accounts. This quickly becomes a nightmare to track and manage. Some developers or IT folks end up with dozens of different keys and other credentials to manage. This just increases the chances of errors happening. And what do you do when those folks leave? Talk about a mess to clean up!

This is where we come into play. enStratus has built a much more granular access control system. Users are assigned to groups and roles which are then granted permissions to the appropriate servers or deployments, even across multiple clouds. This access can be further restricted to particular actions such as, starting, stopping, pausing or terminating servers. This can, of course, all be managed via our API. As an added bonus, for on-site deployments we also support synchronization with Active Directory or LDAP, but that’s really the subject of another post.

To read on, you can read the new white paper on Identity and Access Management for the Cloud (PDF). I would love to continue the conversation or get your feedback.

 

David Mortman is the enStratus 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 Igie. He holds a B.S. in Chemistry from the University of Chicago and bakes, cooks and juggles in his spare time.

 

 

How Can Automation Make Your Cloud More Secure?

Hi! David Mortman here. I’m enStratus’s Chief Security Architect and I’ll be periodically blogging here to cover issues related to security and the cloud. One of the themes I’ll be hitting a lot over the coming months is the power of automation and how that makes your organization not only more efficient but also more secure.

Case in point, multiple studies have shown that one of the biggest contributors to downtime at companies is human error (Visual Ops, Visual Ops Security by Gene Kim et al.).  Automation can remove much of the human element from this equation and especially in the case of repeatable actions, ensures that those tasks are done the same way every time. This is hugely helpful during the audit process for compliance regimes. 

Similarly, as we’ve learned from the Verizon DBIR, one of the biggest contributors to security breaches over the years is the failure by organizations to change or revoke access to resources after individuals change or leave jobs. This is yet another place where automatic processes can be very helpful.

Once you have automation in place, you can start doing some really interesting things very efficiently. For example, deployment of patches becomes even simpler, as does the provisioning (and de-provisioning) of users across machines. You can also start automating the handling of encryption keys or other sensitive data. This means that you can now reduce the number of employees who need access to that sort of data even more. And, as an added bonus, all of these actions are logged by default which also helps with audit and compliance concerns be it from customers, partners or regulators.

More on the power of automation in a later post.

 

David Mortman is the enStratus 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 Igie. He holds a B.S. in Chemistry from the University of Chicago and bakes, cooks and juggles in his spare time.

 

 

Extend LDAP/AD Into Your Cloud Management

Whether you have a public, private, or hybrid cloud, a best-practice includes extending your LDAP or Active Directory (AD) into your cloud management security. This allows you to build on your existing security policies and improve the efficiencies of your cloud infrastructure user management.

1. Delegated Authority: This enables you to set up users in enStratus without the need to set up users and passwords. Here are a couple common tasks that would benefit from directory services integration.

• Add a user to LDAP - enStratus will discover the user and add that user an all group memberships for that user to enStratus.

• Terminate user from LDAP - enStratus will deactivate the user in the enStratus directory as well as remove any Windows and Unix accounts for that user on VMs in the cloud.

2. Automated Management: Remotely manage users and group membership

3. Access Controls: Granular, role-based permissioning managed within enStratus across one or more clouds

Leverage Directory Services to extend security and access controls into private and public clouds

These capabilities will save you time and keep your security policies consistent across clouds.

If you would like to learn more, you can request a copy of our User Management for Private and Public Clouds document.

Automated EBS RAID and Encryption with enStratus

We spend so much time talking about the governance features of enStratus that we often fail to talk about some of the simple operational advantages that enStratus provides. Perhaps the most overlooked operational feature in enStratus is the ability to automatically attach, format, and mount RAID volumes through the enStratus console with the option to have those volumes automatically encrypted.

When you launch an instance in enStratus in the Amazon cloud or any other cloud with an EBS-like concept, enStratus includes a tab that lets you define volumes to be created and attached upon launch. In defining those volumes, you can indicate that you would like to arrange multiple volumes into a RAID and optionally encrypt the file system built on the mounted volume. enStratus takes care of provisioning the block volumes, attaching them to the launched instances, constructing the RAID (if desired), encrypting the file system (if desired), formatting the file system, and mounting the volume(s).

You can customize the software RAID and file system encryption by extending the enStratus scripts on your machine image. By default, we use mdadm to handle software RAID and luks for file system encryption on Unix. We don’t currently provide default options on Windows, but you can extend the scripts to use whatever software RAID and encryption you’d like.

Configuring the RAID and encryption is just part of the story. enStratus manages your encryption keys and takes care of making consistent volume snapshots across your RAID.

On the encryption front, enStratus will generate a unique encryption key to use for encrypting your file system based on the number of bits required by the encryption system you are using. The key is then stored securely outside of the cloud in our credential management system. It only makes brief, well-orchestrated appearances in the cloud when your volumes need to be mounted.

enStratus tracks which volumes/RAID arrays were encrypted with which keys. It can therefore make snapshots of the encrypted volumes, create new volumes, and attach the new volumes automatically to other instances without you having to remember which volumes were encrypted with which keys. All you need are the proper access rights to the instance and volumes in question.

Finally, when it comes time to make backups of a RAID, enStratus enables you to snapshot all volumes attached to a given virtual machine together. In the Servers screen, you can elect to snapshot the server. enStratus will tell then agent on that server to lock all services running on it, lock its file systems, and then enStratus will execute a snapshot of all volumes. The resulting snapshots enable you to reconstruct the RAID in a consistent fashion at a later date.

Best Practice: The only reason to use RAID in the cloud is to get a performance boost in your disk I/O. You should thus only ever use RAID0. Other RAID levels are useless in the cloud. They provide greater resiliency over a RAID0, but erase all speed benefits.

Rolling Out CloudAudit

enStratus has been openly supportive of the efforts of CloudAudit for some time now.  Our initial involvement was based on our value proposition as a vendor—leveraging a standard to further governance in the cloud. With the release of the draft specification to the IETF, however, we have become the first customer for CloudAudit.

What is CloudAudit?

CloudAudit provides a common interface and namespace to enable automated auditing of cloud infrastructures with respect to any number of compliance frameworks. A cloud provider exposes their compliance information—either openly or password protected—under a namespace and structure prescribed by CloudAudit. Cloud customers may then automatically query the cloud provider for assertions and supporting documentation for specific controls or entire frameworks.

enStratus as a Tool Vendor

As I mentioned above, our initial interest in CloudAudit was as a tool vendor. enStratus will support CloudAudit by querying the clouds you are using for support of the compliance frameworks you care about. CloudAudit currently defines compliance namespaces for ISO 27002, PCI DSS, COBIT, HIPAA, and NIST 800-53. Furthermore, CloudAudit leverages the work done by the Cloud Security Alliance in cross-mapping between compliance framework controls.

An enStratus customer will be able to view the assertions for any supported namespace (as well as any supporting documentation) from your cloud providers directly from within the enStratus console. We’ll even enable you to establish trust levels of the different assertions and then enable enStratus to make automated decisions about moving workloads among clouds based on compliance requirements.

enStratus as a Cloud Provider 

But I'm not talking about the future right now. I'm talking about the present.

As we were going through the process of defining the CloudAudit specification, one of our customers approached us with a security audit. Because of our focus on security and governance, we are constantly working with our customers on security audits. This time, however, we decided to leverage this situation to test out the CloudAudit specification and ultimately make life easier on our customers and ourselves. 

As we were finalizing the IETF draft, I therefore went about the task of assembling enStratus responses with respect to the CSA control matrix and building a tool to construct the enStratus CloudAudit namespace for CSA. My objective was to make the process of supporting CloudAudit as simple as:

1. Provide responses in a controls spreadsheet for your target compliance framework.
2. Assemble all supporting documents in a directory with the spreadsheet.
3. Export the spreadsheet as a CSV file.
4. Run a tool on the CSV file.
5. Zip up the auto-generated directory.
6. Unzip it wherever you intend to publish it.

I thus started in the place we always start when a customer wants us to do a self-assessment or audits us: the evil controls spreadsheet. I crafted a controls spreadsheet with the CSA controls and added two columns:

• An assertion column (yes, no, or N/A)
• A support column (file names for supporting documents)

I copied over all supporting documents into the same directory as the spreadsheet. Basically, there’s nothing here any different from the way any security audit starts. The only interesting item is that I’m not actually doing an audit for anyone in particular. I am simply “pre-packing” a response against the CSA controls. 

If all you are doing is a self-assessment, you are generally done at this point. If this response is part of an audit, the information generally forms the baseline from which a human auditor executes a formal audit. The CloudAudit objective, however, is automated audit, assertion, assessment, and assurance.

CloudAudit supports automation by defining a namespace into which assertions and supporting documentation live and providing a mechanism for tools to query those assertions and discover the supporting documentation. To be compliant with CloudAudit, the self-assessment data must be distributed into a CloudAudit namespace for my target compliance framework (the CSA controls in this case).

I built a Python tool to read my self-assessment and assemble the response into the CloudAudit namespace. You can download it under the Apache 2.0 License from http://www.cloudaudit.org under the Development section of the web site. This tool reads a CSV export of my response spreadsheet and builds out a complete CloudAudit namespace for my target control and copies all supporting documentation into the appropriate places.

For example, CSA control CO-01 represents compliance audit planning. enStratus asserts that we are compliant with this control and our information systems policies and procedures document supports this assertion. CloudAudit requires information on this control to be housed in the directory .well-known/cloudaudit/org/csa/guidance/CO-01. CloudAudit further requires an index.html for human consumption and a manifest.xml file in Atom format for tool consumption. The Python script created this directory structure, built the index.html and manifest.xml files from templates, and copied the enStratus policies document into the directory.

Once we roll out our next update, any enStratus customer will be able to review enStratus from a self-assessment perspective with respect to the CSA controls directly from inside the enStratus portal. Our next objective is to roll out the ISO 27002 self-assessment.

Managing Access in the Cloud

A manager recently asked me about managing user access to his cloud infrastructure. User access in the cloud presents an interesting challenge because of the nature of cloud accounts and cloud management platforms.

I generally divide the access problem into two separate parts. The first is access to the cloud account itself, which typically requires providing the cloud account credentials to each user requiring access. The second is access to individually running servers, which requires a system administrator to create accounts for each user. A third layer is added by the enStratus cloud management platform which I will discuss in a moment.

Each of these access levels carries with it security implications. In the first case, it is unwise to spread credentials of any kind among users even if they are trusted because of the tendency for shared  credentials to be shared even further than the trusted circle.

enStratus removes the requirement for sharing cloud credentials by introducing a third layer of user management. As the cloud management platform credentials are held outside of the cloud in an encrypted database.  Using enStratus, administrators can focus on access rights and permissions without having to worry about losing control of account credentials.

User managment in enStratus is role-based and familiar to managers and system administrators. Securely adding remote access to individual servers to developers or administrators can be done quickly and reliably using the enStratus console. I grant remote access to a single user on a single server in this manner on a routine basis.

Integration into existing LDAP and Active Directory offerings enables seamless integration of user management in cloud infrastructure into traditional datacenters. When a user account is removed in Active Directory, for example, any corresponding cloud user accounts are removed.

To fully appreciate and leverage the power of user managment in enStratus I typically further divide users into groups and then grant them access permissions to specific cloud resources using the access rights enStratus assigns to cloud resources.

For example, the manager who asked me about managing users wanted to split his infrastructure into two parts, one for development and one for production, just like his company used in their own datacenter. I created two groups and permissioned the roles to allow personnel in the development group access only to servers in their group, while production remained accessible only to a select subset of developers.

This concept can be expanded to create entire virtual departments analogous to traditional datacenter components. In another account I set up a database group, an applications group, and a security group. In this particular scenario, the security group was responsible for vetting servers and then making them available to the applications and database teams.

Access and user management in the cloud can be secure and role-based using enStratus. By keeping credentials securely outside of the cloud and using groups and roles, managing access can be a successful endeavor.

enStratus and GoGrid

 enStratus already manages more public providers and private cloud technologies than any other cloud infrastructure management platform. Today, enStratus announced support for one of the pioneer cloud providers in the Infrastructure as a Service (IaaS) cloud space, GoGrid. This match teams the first provider to support Microsoft Windows in the cloud with the first infrastructure management provider to support Windows in the cloud.

As you would expect, enStratus enables you to provision and de-provision resources inside a GoGrid account. That's just the start. You also get all of the governance features you need for managing any cloud environment in accordance with typical enterprise IT requirements. These capabilities include the ability to establish different billing budgets for resources within the same GoGrid account, custom user role mappings with fine-grained permissions, LDAP and ActiveDirectory integration, management of shell and RDP accounts on your virtual machines in the cloud, and many other enStratus features.

Over the next month, we will also grow our support of GoGrid to support pre-bundled machine images with the enStratus agent pre-installed and infrastructure automation, including auto-scaling, auto-recovery, backup automation, and more. This new support will include the ability to leveraging cloud bursting from a private cloud into a GoGrid public cloud.

It's Official: enStratus Rolls Out vCloud Express Support

 A few months ago, we quietly mentioned in this blog how enStratus uses Dasein Cloudas a cloud abstraction layer and, thanks to Dasein Cloud + jclouds, that enStratus would support Terremark's vCloud Express through Dasein Cloud + jclouds + vCloud. Today, we formally announced vCloud Express support with Terremark as our launch partner for this support.  

enStratus supports all of the core features of Terremark vCloud Express, including the provisioning and de-provisioning of virtual machines and allocation IP addresses with the ability to setup IP forwarding rules. 

With enStratus, however, you expect more than simply being able to access the core Terremark functionality. enStratus provides all of the governance elements for the Terremark cloud that you expect, including:

• Cross-account user management
• Role-based access controls for managing your Terremark infrastructure
• Financial controls to enable you to track spending
• The ability to manage Unix shell and Windows RDP users from the enStratus console
• The ability to setup modjk, haproxy, and Zeus load balancers.

In our Efreet release scheduled for early June, we will add even more capabilities to our Terremark support:

• Cross-cloud clustering with auto-scaling and auto-recovery (burst from a private cloud into Terremark or balance load equally across two clouds)
• Automated disaster recovery execution into a backup cloud
• Auto-scaling and auto-recovery with automatic load balancer configuration in Terremark
• Mix Terremark compute resources with cloud storage from another cloud to create a single logic cloud
• Support for Terremark volume configuration

Finally, we'd like to take a moment to thank everyone at VMware, Terremark, and jclouds who have all been very suppportive of bringing this effort to market.

Key Management Is Key to Cloud Security

The economics of cloud computing is definitely appealing.  However, security is of course of paramount importance when deploying mission-critical applications in the cloud. There can be no trade-offs between improved accessibility, performance, and the integrity of an organization’s most valued data.

Cloud security, with specific focus on key management, is sure to be one of the main questions asked by any enterprise as it considers moving applications and storing data in the cloud. The concept of cloud computing is full of complex considerations as organizations first begin their journey. How will their all-important keys be managed and will the data be encrypted to a high standard?

Cloud providers take the role of key management very seriously. There are multiple solutions that store credentials inside and outside the cloud within a secure infrastructure depending upon the purchasing organizations cloud security needs. Many providers are concerned about data security, not only from the point of view of malicious intent, but also from a legal perspective.

Is the data encrypted to a level sufficient to avoid access by potential hackers? Is it possible for an independent attorney to provide a legal instrument such as a subpoena to gain access to data through the cloud system? Organizational system separation is maintained by some cloud security providers. This ensures that a third party would find it impossible to access a single, integrated system, potentially resulting in critical data compromise.

Sustainability is very important, as it pertains to the day-to-day operations of a cloud security company. A meaningful and logically solution is required when it comes to key management. Appropriate questions must be asked of a cloud service provider and the selection of appropriate partner should only be made on the basis of a clear understanding of the integrity of the entire solution. The process of hosting, administering, and allowing access to the relevant keys should be clear-cut and watertight.

Some key management and cloud security items to consider:

• Advanced Encryption Standards should be used for keys to protect from acts of malicious intent. All customer encryption and authentication credentials in should be stored in an AES256-encrypted database with no encryption keys stored in the credentials management zone.
• Unique keys should be used or each customer to ensure that no 2 customers will have access to each other’s applications or data
• Keys should be stored outside the cloud infrastructure provider and only used when necessary.  The public cloud infrastructure should be viewed as hostile territory.
• The cloud provider or management solution provider should have no staff access to keys or sensitive data.
• File system and backup encryption should also be considered for sensitive data.

The benefits of public cloud infrastructures have been well documented; scale, flexibility, and reduced capital expenses & operational costs. Cloud security will continue to evolve and improve and be high priority to an enterprise that have tight IT policies and procedures. As security becomes more widely understood, acceptance of the model will increase and more and more benefits will be realized.

Update Dryad

We will soon be rolling out Update Dryad which is a major system update with significant new functionality for enStratus. Major enStratus updates all center around a specific theme. The theme for Dryad was "user management".

One of the strengths of enStratus has been the ease of user management in the platform. It's one of the oldest elements of the system, and we used Update Dryad to significantly move our user management forward. Dryad introduces:

• User groups (users can be in one or more groups)
• Roles, with each group assigned a specific role on an account-by-account basis
• Comprehensive access rights management for roles

Once the upgrade is complete, you will have four user groups attached to four roles of the same name in each account. These groups and roles match up to the old Admin/Server Manager/Configurator/Reports permissions.

 

You can immediately begin customizing the system to suit your needs.

First, you define roles to encapsulate a set of access permissions. An access permission defines an action on a resource type with an optional qualifier. Qualifiers limit the scope of an action on a resource. For example, you can define a permission like:

SERVER/Terminate/MINE

That permission means that anyone tied to that role can terminate only servers they launched. You can also qualify an action based on group membership or billing code.

Why the separation between roles and groups? Within the next couple of months, we will introduce ActiveDirectory and LDAP integration. User membership in groups will be governed by your AD or LDAP management policies. Access to enStratus resources for customers leveraging AD or LDAP integration will thus be governed by tying an AD/LDAP group to an enStratus role. Users and groups will be "read-only" in enStratus for such customers.

A few weeks ago, we introduced our plans for the finance view into the system. Our next major update, Update Efreet, is focused entirely on the finance view of the system. We set the foundation for the finance view, however, in this release:

• You can define a set of billing codes and associate resources with those codes for tracking cloud usage/billing
• You can view your enStratus invoices from inside the console

To help with compliance, we've exposed more of our underlying audit capabilities in the form of Firewall change log reporting. From the reports console, you can view all firewall rule changes that have been made to the firewalls in your account, including changes made outside of enStratus. It also provides for a CSV download of your firewall change log. We also now send an alert any time a firewall rule changes.

Other changes in this release include:

• Support for AWS load balancers
• Greater ability to control AWS auto-scaling rules from the UI
• Beta support for SAML 2.0 authentication
• Configurable named networks and services to make firewall management easier
• Support for Terremark vCloud Express
• Greater ability to control alert preferences