As we noted in our introductory post for this 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 – check out our Tidal Forces post for the rundown. This disruption will have significant ramifications for how we build and manage networks. Let’s work through the requirements for this network of the future, and then provide some perspective on how you can and should migrate to the 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 required these environments to be built for peak usage, but at the same time to support the lowest common denominator from a functionality standpoint. Yes, those are contradictory requirements – that’s how it worked out. Your network had to serve all masters (regardless of the disparity in functional requirements per application) and be sized to stay up under any conceivable load.

In the Cloud Age we need to think differently. Now it’s about what kind of network this specific application or use case requires not what you already have. So you build what is needed, where it’s needed. We’ll get into specific use cases later in this series, but a network to support a distributed workforce doesn’t need, and probably shouldn’t have, the same characteristics of the network that interconnects your primary sites. And an externally-facing web application needs a different network than one for access to sensitive data still locked within your enterprise data center.

And everything in the Cloud Age is software defined. You basically program your network, adapting it to specific conditions laid out in a set of governing policies. 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 hand-waving above into specific requirements for a secure network of the future, we come up with the following:

• Availability: This is consistent with the networks you have been building for decades. It’s a bad day for the network/security team when the network goes down, whether in your data center or the cloud. So a cloud network needs to be built to ensure availability with diverse routes, alternative access points, and alternative access to corporate date – wherever it may reside.
• Elasticity: Instead of building a 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 you pay for more (metered billing), but you don’t need to put in a big order for new mega switches which might be fully utilized once over the next year. 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. A cloud network needs access flexibility because employees and other constituents move around. It needs architectural flexibility – you will need to adapt to changing requirements in areas such as scaling, usage, and security. Things move very quickly in cloud land, and you don’t have time to wait for network administrators to reconfigure the network, so you need an automated system to do it. This is driven by software, so orchestration and automation via other products and services is essential.
• Policy-driven: Speaking of Software Defined Networks (SDN), you need a cloud network governed by policies which specify rules for when it changes. Many attributes can drive these policies, and the role of a network security architect is evolving to encompass these policies, because once released into production policies are applied automatically and immediately, so things can go south quickly if they aren’t solid.
• Flexibly Secure: Finally, you want to make sure all your constituencies can be supported and protected by the cloud network. So if you support remote users proper authentication, access control, and inspection for threat/malware detection must be provided on the ingress side. You’d also like those users’ egress traffic (including encrypted traffic) to be protected against security issues, such as data leakage and connections to malicious servers. Additionally, you should be able to protect traffic to cloud applications. And cloud networks needs to satisfy all these use cases.
• Monitoring & Reporting: Compliance oversight and governance don’t go away when you move to the cloud. So you need 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

A good thing about moving to secure networks in the cloud age is that you don’t need to get there in one fell swoop. It’s not like an overnight cutover to a new switching environment because the old and new vendors cannot play nicely together. This is where 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 still served out of your own data centers. If your web app and manufacturing systems run on your own hardware, 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 network.

You may be able to take better advantage of your WAN by leveraging a service provider. Supporting access for a global user base, and maintaining connections between sites, may not be the best use of your constrained networking and security resources.

The other area to focus on is the back-end interconnection points between your existing enterprise networks and cloud services. This is where you are most exposed, because any issues in your data center could affect the cloud and vice-versa. Of course if you have architected your cloud networks correctly any damage should be isolated. But make no assumptions. You will want extensive monitoring, and to really lock down traffic between your data center and the cloud.

Service Providers

Understanding your requirements for a cloud network, the next question is to figure out to what you can and 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 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 while continuing to run your existing network to support existing applications.

In terms of the buy vs. build decision, the fundamental choice is whether to build a network which offers the scale and services you (might) need, across all the geographies where you need connectivity. We’ll dig into specific use cases in our next post. There are variations for each company’s environment, but the choice between buy vs. build is generally reasonably clear.

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

• Coverage and Scale: Obviously your provider should have presence in the places you need access. Another area to consider is their network’s scalability architecture. Yes, scale is their problem, but don’t just take their word that they can scale. So diligence is warranted to ensure the provider can handle your scale, especially for any use cases which could be hit by Denial of Service attacks.
• Security: Well, duh. But we have seen a number of service providers who weren’t as secure as they should have been, so understand the control sets they use and how they secure their own environment. Most vendors understand that a high-profile attack on their infrastructure could be an existential threat, so they take security seriously. But you still need to do your homework, and understand how the provider protects themselves and traffic on their networks.
• Innovation: Another thing about cloud architecture is how fast it’s changing. What is new and shiny today seems to be obsolete in a quarter or two, so ensure 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, your provider doesn’t need to be either. But if you are, you will get very frustrated if you try to route traffic or deploy capabilities your provider doesn’t support.
• Modular Services: You can move to a cloud network at your own pace, so you want your provider to offer the services you need, when you need them. That means not paying for stuff you don’t use, with a very flexible provisioning process to add new services quickly. For example a portion of your network might just need connectivity. Another use case might require deep packet inspection of all traffic. Another scenario might specify an application front-ended with DDoS protection and a WAF. You don’t need the same provider for everything, but make sure your providers 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. You may not be able to access raw packets, but you need sufficient information to substantiate controls, and satisfy compliance and governance requirements.
• API Access: Finally, in a policy-driven environment, you need the ability to automate changes to your network environment, through an API. Given the newness of cloud networking, we don’t yet have standard APIs for network access into the cloud, so you’ll be doing the integration yourself (at least until someone delivers a cloud orchestration tool). So an API needs to suffice for now.

As we continue this series, we will dig into a few use cases to show the advantages of secure networking in the cloud, and how to support the most common scenarios you will face as you migrate.