Establishing a Foundation for Enterprise Security Policy in the Public Cloud

Featured article by Rich Campagna, VP Products & Marketing, Bitglass

In many respects, Cloud Access Security Brokers are the future of what we currently know as the data center firewall. How so? A data center firewall sits in front of enterprise applications/databases (systems of record) in the data center, providing control and visibility. Increasingly, those applications and databases are moving from the corporate data center to the public cloud – with apps like Office 365, Box, and Salesforce, quickly becoming the norm in the enterprise. In this context, cloud apps become the new system of record. Since the traditional data center firewall can’t see cloud traffic, it can no longer provide the protection that we need.  Enter the Cloud Access Security Broker, a new category of security technology designed specifically for this shift. As the enterprise migrates to this new technology, our security policies must be redesigned entirely.

Enterprise firewalls have been around in one form or another for almost 30 years, starting as basic packet filters. The second generation of firewalls, the stateful firewall, represents the oldest generation of firewall technology still currently in use. A stateful firewall policy is based on Layer 3 and Layer 4 of the OSI stack. Stateful firewall policies are based on a “5-tuple.” Specifically:

• * Source IP
• * Source Port
• * Destination IP
• * Destination Port
• * Protocol

Such policies, by definition, assume knowledge of and control over the underlying networking infrastructure.

As applications have evolved, more and more of them began to operate on similar ports, most notably, port 80 (HTTP) and port 443 (HTTPS). This change lead to a major limitation of a stateful firewall operating at Layer 3/Layer 4 – it became practically impossible to block traffic operating on these ports because doing so would also block legitimate traffic operating on the same ports. This limitation led to development of the next-generation firewall.

The next-generation firewall builds on stateful firewall technology, including a broader range of security services, and application fluency, which provides the ability to differentiate between legitimate and unwanted traffic on the same port. While the set of policy options available on a next-generation firewall is large, for most organizations, the move to a next-generation firewall means an expansion of their 5-tuple policy to include:

– User – identity of the user in the transaction

– Application – actual application in-use (e.g. Salesforce vs Dropbox, both on port 443)

Once again, the next-generation firewall policy relies on knowledge and control over the network infrastructure. As our systems of record move to the cloud, that is no longer a reality. For most, the cloud is a black box – an application for which we have no knowledge of the infrastructure. The implication is that we require an entirely new “tuple,” the cloud-tuple, for policy decisions.

Unfortunately, the cloud-tuple is entirely different from what we’ve done with our traditional firewalls. Fortunately, it allows us to write policy with contextual elements that are simple for humans to interpret and understand. What are the elements of this new model, and what questions does it allow us to answer?

– User/role – Is the person an employee or contractor? What is their role in the organization?

– Device – Is the user coming from a managed or an unmanaged device? Is the device running an OS version that our organization supports?

– Application – What application is the user attempting to access? Salesforce? Office 365?

– Location – Is the employee physically located inside a corporate office? Is the person attempting to access corporate data from a country where we don’t do business?

– Transaction – What action is the user attempting to take? Download a file? Send an email?

– Data – What is the sensitivity of the data being accessed? Does it contain information to regulatory compliance? Personally identifiable information or credit card data?

The downside of the cloud-tuple is that we must learn an entirely new way to think about constructing security policies. The move from the traditional, layer 4 stateful firewall was incremental – the 5-tuple remained, but we layered on application and user as extensions of the policy. The move to the cloud is a revolution – with very little prior basis on which to build.

The upside is that cloud-tuple policies are human readable and user friendly. Gone are the days of trying to figure out what those 13,544 ACLs in the firewall were created for. It is easy to understand that the sales team should have access to Salesforce, but that access should be limited for users connecting from BYOD devices.

Cloud apps represent new applications with sensitive data that needs to be protected, and a new way of thinking about protection. A Cloud Access Security Broker fills the security gaps left as your organization moves to the cloud, and the new way of building security policies, while different, is easy to understand and operationalize.

Rich Campagna drives product management and marketing at Bitglass. Prior to becoming an integral team member at Bitglass in April 2013, he was senior director of product management at F5 Networks, responsible for access security. Rich gained valuable experience in product management and sales engineering at Juniper Networks and at Sprint before working at F5.