As we wrap up our series on secure networking in the cloud era, we have covered the requirements and migration considerations for this new network architecture – highlighting increased flexibility for configuration, scaling, and security services. In a technology environment which can change as quickly as a developer hitting ‘commit’ for a new feature, infrastructure needs to keep pace, and that is not something most enterprises can or should build themselves.

One of the cornerstones of this approach to building networks is considering the specific requirements of the site, users, and applications, when deciding whether to buy or build the underlying network. This post will work through a few use cases to highlight the power of this approach, including:

• Compromised Remote Device: The underlying network supporting cloud computing needs to respond, pretty much instantaneously when under attack. This use case will show how you can protect it network from users who appear to be compromised, without needing someone at a keyboard reconfiguring pipes.
• Optimized Interconnectivity: You might have 85 stores which need to be interconnected, or possibly 2,000 employees in the field. Or maybe 10 times that. Either way, provisioning a secure network for your entire organization can be highly challenging – not least because mobile employees and smaller sites need robust access and strong security, but fixed routes can negatively impact network latency and performance.
• Protecting SaaS: Cloud applications have become a visibility black hole for enterprises, so we’ll discuss how to protect users and sites which access critical corporate data, even if they never traverse a traditional corporate network. This is especially important because the lack of clear inspection points on the network breaks traditional security models, so you need to bring the secure network to the site and/or users.
• Security by Constituency: One of our key requirements is the ability to flexibly support users, locations, and applications; so our final use case will show how a policy-driven software-defined secure network can provide the secure connectivity required by a variety of different users.

Of course there is considerable overlap between these use cases. For instance a mobile employee may predominately use SaaS applications, thus benefit from both those use cases. But these scenarios help illuminate the future of secure networking.

Compromised Remote Device

It happens on your network all the time. A device is compromised and starts acting strangely. One of your security monitors fires an alert, which shows suspicious activity from that device. In the old days you needed to figure out whether the issue was real; then go into the network console, isolate the device, and begin investigation. It all sounds simple enough, right?

But what happens when the device is remote, and not on your corporate network? You might not know the device has been compromised, and you may have no way to take it off the network. Hopefully it won’t slip buy long enough to escalate privileges and find a way into your internal network.

To address this, you basically extend your network out to your users. So the device connects to the closest point of presence (regardless of where it is) and virtually joins your corporate network. Sure, that sounds a lot like just running each user on a VPN and bringing them back behind your perimeter, but this model offers real advantages.

First, traffic is not backhauled to your corporate network, which avoids overburdening the security controls and adding a huge amount of latency. The burden of enforcing security polices happens within the network, not on the devices running on your premises. Second, compromised devices are isolated from the rest of your network. It becomes much harder for attackers to move laterally through your network, because they need to bypass additional inspection points to reach the internal network.

Once a device has been determined to be compromised, a policy can automatically quarantine it to prevent access to key SaaS apps and the internal network.

Optimized Interconnectivity

One of the larger hassles in networking is supporting large numbers of remote sites. Setting up many security devices, especially remotely, both costs and requires onsite IT chops to troubleshoot. And of course traveling employees are all over the place, demanding fully access to critical data (both on the internal network and in the cloud), as if they were in the office.

These are two separate issues, but there is one solution. It involves extending the secure network to the user and/or site. This enables you to use a last-mile service, typically a basic dumb Internet pipe, for access to the closest point of presence with access to your network. Once on your network, the user or site gets all the same intelligent routing and security services as on your corporate network. Without having to backhaul traffic to your corporate network.

Of course you need to figure out whether to build out PoPs and network infrastructure to extend the network where your organization needs it. In reality, you are likely to engage a network service provider to build a virtual network between your sites, and provide connectivity to your users. This gets you out of the Wide Area Networking business. In many scenarios it provides enhanced network performance, increased security, and greater flexibility. We won’t weigh in on cost because many factors affect the cost of provisioning this kind of network, but the additional capabilities make this a pretty easy decision if the costs are in the ballpark.

Protecting SaaS

As we mentioned previously, the advent of SaaS has removed much of your visibility into what employees are doing in critical applications. Let’s consider a sales automation service and a disgruntled salesperson who wants to grab his client list before quitting. If they are sitting in a coffee shop somewhere, you probably have no idea what they are doing within the application, because they don’t traverse your network to access the SaaS service.

But if you have the rep on a performance plan, you know they are a flight risk. So you can proactively set a policy to watch for any downloads of the customer list from the group of employees on performance plans. You should have already locked down your SaaS environment, so this data can only be accessed via the secure network, and your virtual network can monitor the flow and quantity of data to and from that user. You can also inspect the content as it traverses the network, and see they are taking client list or other sensitive data.

At that point you can block the transmission via security policy, and shut down the employee’s access until Human Resources can take care of the situation. All without having to watch for specific alerts or wait for an administrator make changes in real time.

Security by Constituency

One interesting extension of the policies above would be to define slightly different policies for certain groups of employees, and automatically enforce the appropriate policies for every employee. Let’s consider a concern about the CFO’s device. You can put her and all the folks with access to sensitive financial data in a special secure network policy group.

The security for this group is turned up to 11 (in Spinal Tap parlance), since you want to ensure these folks don’t accept or make connections to sites known to participate in botnets. Your secure network has access to threat intelligence feeds including lists of known active bot networks, so you can automatically block traffic for those users to and from all suspicious sites. You can also stop file transfers to any unauthorized site, and alert on anomalous behavior for anyone in that group, to further lock them down.

You can relax security policies for other groups of employees that may not have access to such sensitive data. So you restrict their access to only the general Internet from inside the corporate network, and you don’t allow them to connect to anything internal from outside the network. By policy they can only access corporate data from work. Of course you could implement another policy for those employees, so they can request a temporary exception if they know they’ll need to work from home for a day, and simultaneously increase their monitoring level. Without minimal human intervention.

For all these use cases policies can be pre-defined, so enforcement occurs automatically once they connect to the secure network. This happens regardless of where the employee happens to be, or what application they are accessing. You can change policies as needed, and make them as simple or complicated as your business requires. Your secure network can adapt to your business, as it should.