Network Security in the Cloud Age: Requirements and Migration

As we noted in the introductory post in the Network Security in the Cloud Age series, everything changes and technology is undergoing the most radical change and disruption since, well, ever. We’re not kidding, so check out the Tidal Forces post to get more perspective on that. This disruption will have some pretty significant ramifications on how we need to build and manage networks. So let’s go through the requirements for this network of the future, and then provide some perspectives on how you can/should migrate to this new network architecture.

At the highest level, the main distinction in building networks in the Cloud Age is moving from a one to many network(s) model. Networks have been traditionally been built and managed as a single enterprise network, which forced these environments to be built for peak usage, but at the same time needed to support the lowest common denominator from a functionality standpoint. Yes, those sound like opposing objectives, but that’s how it worked out. Your existing network had to serve all masters (regardless of the disparity in functional requirements per application) and be sized to keep the network up under any conceivable load.

In the Cloud Age, you need to think differently. It’s about what kind of network the specific application/use case requires, not what you’ve already built. So you build what is needed, where it’s needed. We’ll get into the specific use cases later in the series, but the network to support a distributed workforce doesn’t have to (and probably shouldn’t) have the same characteristics of the network the interconnects your major locations. And the network underlying the externally facing web application necessarily needs to be different than the network accessing sensitive data still locked within the enterprise data center.

And everything in the Cloud Age is software defined. You basically program your network and adapt it based on specific conditions laid out in a set of policies governing your network. No more crawling around the wiring closet to find the faulty cable that knocked out your G/L system. Though we’re sure you’ll miss those days.

Cloud Age Secure Network Requirements

When we translate the drivel above into specific requirements for the secure network of the future, this is what you come up with:

• Availability: This is pretty consistent with the networks you’ve been building for decades. It’s a bad day for the network/security team when the network goes down, whether the network is in your data center or the cloud. So the cloud network needs to be built in a way to ensure availability with diverse routes, alternative access points, and alternative ways to access corporate date – wherever it may reside.
• Elasticity: As opposed to building the network for peak usage, you don’t need to really do anything here. Ensuring sufficient bandwidth is the cloud provider’s problem, not yours. Obviously if you use more then you pay for more (it’s a metered billing thing), but you don’t have to put in a big order for new mega switches that will be fully utilized once over the next year, if that. You just need to make sure the provider can scale to what you may need, and that you can expand and extend your network as needed.
• Software defined: The Cloud demands flexibility. The cloud network needs to be flexible for access, since your employees and other constituencies tend to move around. It needs to be flexible for architecture, meaning you want to be able to adapt the network to changing requirements, which could be related to scale, usage, or security. Things move very quickly in cloud-land and you don’t have time for network admins to reconfigure the network in real time, so you need an automated machine to do that. The machine is driven by software, so being able to support orchestration and automation by other products/services is critical for the future network.
• Policy-driven: Speaking of software defined networks, you need the cloud network to be governed by a set of policies that set out the rules for when the network changes. There are many attributes that can drive the policies, and the role of the network security architect evolves to understanding and setting these policies because once released into the production network, the policies are automatically applied and that can go south quickly if the policies aren’t solid.
• Flexibly secure: Finally, you want to make sure that all of your constituencies can be supported and protected by the cloud network. So if you are supporting remote users, proper authentication, access control, and inspection for threat/malware detection must be provided on the ingress side. You’d also like those user’s egress traffic (including encrypted traffic) to be protected against security issues, like data leakage and connecting to known malicious servers. Additionally, you want to be able to protect application traffic hitting applications in the cloud. And the cloud network(s) needs to meet all of these use cases.
• Monitoring/Reporting: Compliance oversight and governance doesn’t go away when you move things to the cloud. So you’ve got to have visibility into the network traffic to detect performance and security issues, as well as the ability to generate reports to substantiate network activity and security controls.

Migration

The thing about moving to this secure network in the cloud age is that you don’t need to get there in one fell swoop. It’s not like having to do a flash cut to a new switching environment overnight because the old vendor and the new vendor don’t play nice in the proverbial sandbox. This is where the idea of moving from one monolithic network to many, application specific networks pays huge dividends.

You can keep running your existing enterprise network to support the functions that are still served out of your own data centers. If your web app and manufacturing systems run on your hardware, then moving that data to the cloud probably doesn’t make sense. But as you move or rebuild those applications within a public cloud environment or embrace Software as a Service (SaaS) to replace legacy applications, you can move that traffic to a cloud-based network.

You can also look at making your WAN more effective by leveraging a service provider, since continuing to support the access needs of a global user base and maintaining the connections between your sites may not be the best use of your (probably resource constrained) networking and security teams.

The other area to focus on is the back-end interconnection points between your existing enterprise networks and the cloud services. This is where you are most exposed because any issues in your data center could hop to the cloud and vice-versa. Of course, if you’ve architected your cloud networks correctly, any damage should be isolated. But not making any assumptions, you are going to want to do extensive monitoring and really lock down the traffic that goes between your data center and the cloud.

Service Providers

With an understanding of the requirements for the cloud network, the next question is to figure out to what you can/should do and what you should look to a service provider to do for you. As mentioned above, it’s not like the old days of outsourcing when you moved all of your assets (and people) to the outsourcer. You can look to specific service providers for specific use cases, or try to find one to meet many. All the while continuing to run your existing network to support the existing applications.

In terms of the buy vs. build decision, the fundamental choice is whether you want to build the environment you’d need in terms of both scale and services, across the geographies where you need connectivity. We’ll dig into specific use cases in the next post, and although there are variances based upon a specific company’s environment, the direction of buy vs. build is reasonably clear.

So as you consider looking at service providers, here are some selection criteria to keep in mind:

• Coverage and scale: It should be pretty obvious that if the provider isn’t in the places you need them to be and you are looking at backhauling a bunch of traffic to the closest provider POP (point of presence), then it’s probably not a good fit. One area to look into is the scalability architecture of the provider’s network. Yes, scale is the provider’s problem, but just because they say it scales doesn’t mean the architecture holds up to physics. So doing some diligence is warranted to ensure the provider can handle significant scale, especially for any use case that could be hit by a Denial of Service attack.
• Security: Well, duh. But having seen a number of service providers that weren’t as secure as they should have been, it’s certainly important to understand the control sets in use by the provider and how they secure their own environment. To be clear, most understand a high profile attack on their infrastructure could be an existential threat to their business, so they take security pretty seriously. But you still need to do your homework and understand how the provider is protecting themselves and any traffic that rides on their networks.
• Innovation: The thing about cloud architecture is that it’s changing. Fast. What is new and shiny today seems to be obsolete in a quarter or two, so ensuring that the provider can support different kinds of networking services and seems to roll out new capabilities in step with the rest of the market. If you aren’t on the cutting edge of experimenting with new cloud services, then the provider doesn’t need to be either. But if you are then you will get very frustrated if you want to route traffic or deploy capabilities that aren’t supported by the provider.
• Modular services: Given that you can move to a cloud network at your own pace, you want the provider to be able to offer the services you need, when you need them. That means not paying for stuff you don’t use and also a very flexible provisioning process to add new services quickly. For example, maybe for a portion of your network you just need connectivity. For another use case, you need deep inspection of the traffic. For yet another, you want an application front ended with DDoS protection and a WAF. You don’t need the same provider for everything, but you want to make sure the provider can meet your requirements as they evolve.
• Monitoring access: There is necessarily less visibility on cloud-based networks than a network you control in your own facilities. So you may not be able to access the packets, but you want to be able to get information to substantiate controls and other compliance/governance requirements.
• API access: Finally, in a policy-driven environment, you need to be able to automate changes to the network environment and that means being able to make changes through an API. Given the early nature of cloud networking, there aren’t really any standard APIs for network access into the cloud, so you’ll be doing the integration yourself (or until someone delivers a environment for cloud orchestration). But as long as the API exists, that’s need to suffice at this point.

As we continue the series, we’ll dig into a few use cases that really show the advantages of secure networking in the cloud and how to support the most prevalent situations you’ll face as you undertake this migration.

- Mike Rothman (0) Comments Subscribe to our daily email digest

from Network Security in the Cloud Age: Requirements and Migration