We have spent a lot of time discussing the disruptive impact of the cloud and mobility on… pretty much everything. If you need a reminder, check out our Inflection paper, which lays out how we (correctly, in hindsight) saw the coming tectonic shifts in the computing landscape. Rich is updating that research now, so you can check out his first post, where he discusses the trends which threaten promise to upend everything we know about security: Tidal Forces.
To summarize, cloud computing and mobility disrupt the status quo by abstracting and automating huge portions of technology infrastructure – basically replacing corporate data centers in many cases. You no longer stroll down to the wiring closet to troubleshoot network problems, because your employees are distributed across the world, using all sorts of devices to access critical data. Your data center may no longer exist, but it is certainly much less important and valuable today, because it has been replaced to some degree by a monstrous Infrastructure as a Service (IaaS) provider who offers far better economies and much faster turnaround than your IT group ever could. The physical layer is totally abstracted, and you interact with your network (and the rest of your technology stack) through a web console – or more likely, an API.
Development and Operations organizations are now collaborating, which means as soon as a developer makes a change it can be immediately deployed (after some automated testing) to the production environment. Continuous deployment may require network changes, and can introduce security issues. But there isn’t really any ability to have a human scrutinize all the changes, or ensure all the governance and security policies are in place and effective.
To further complicate things, you no longer run many applications on infrastructure you control. In case you haven’t heard, Software as a Service (SaaS) is now a thing (we call it “the new back office”), and you don’t get to tell a SaaS provider what their network should look like. You connect to their service over the Internet, and that’s that. You no longer know where your data is, nor do you have the ability to monitor traffic flows for misuse.
To be a bit clearer about the impact on networking in the cloud age, let’s highlight the impacts:
- Your data is everywhere (and nowhere): Whether it’s an application you built (now running in an IaaS environment) or an application you bought (provided by a SaaS vendor), either way you no longer have any idea where your data is, and limited means to protect it on the network.
- Lack of visibility: You cannot tap an IaaS or SaaS environment, so you don’t have visibility into what’s happening on your network. Some cloud providers are offering increasing access to network telemetry, but raw packet access is a poor fit for the cloud’s agility and elasticity.
- Bottlenecks don’t make sense: One way to get around the lack of visibility is to route all traffic through an inspection point, and enforce security policies there. Unfortunately most cloud-native architectures don’t support that approach, due to the inherent isolation between computing tiers, and the increasingly popularity of serverless systems. The last thing you want to do is make the cloud look just like your existing environment, so traditional bottlenecks won’t survive this disruption.
- App-specific infrastructure: Finally, you don’t just have one network to worry about. You can have hundreds if you implement every IaaS stack as its own network(s). Every SaaS service you buy runs on its own network. There is no longer any consistency between cloud application networks. Overall this is an improvement, because each application can have its own network – designed, tuned, and sized to its particular requirements. Applications are no longer forced into a one-size-fits all suboptimal network, but they also aren’t forced onto your network, with all your integrated security requirements and capabilities.
- Velocity of change is unprecedented: With continuous deployment changes to the network need to happen in lock-step with application and operational changes. This means your network and security ops folks’ work queues are going the way of the Dodo bird. There just isn’t time for traditional network management and security, and your existing staff cannot keep pace in this kind of environment.
The tidal forces of the cloud are rapidly upending almost everything you know about security. Those who fail to get their arms around this, clinging doggedly to old models, will fail.
Focusing on the Right Things
Before you reach for the hemlock, let’s take a step back to remember what we really need to provide as network security professionals:
- Connectivity: The network needs to provide access to resources (applications and data) wherever in the world they reside, whenever users they need access, on whatever device they happen to be using. Within policy constraints of course, but IT can no longer simply dictate access terms.
- Availability: The network needs to be reliable and survivable to satisfy application uptime requirements. It is a bad day when business stops because of a network problem, and worse when a security issue takes the network down.
- Performance: There are many potential choke-points which can slow down an application. But the network should not be one of them – even during peak usage. In the old days you needed to design and build for peak usage. But you got no credit for the other 99% of the time, when some (perhaps most) of that infrastructure was idle.
- Security: Last but not least, you had better not have any security issues originating from the network. Instead the expectation is that you will detect attacks using the network. So you need to make sure the network is secure, rather than a vector for attack.
The cloud can help us satisfy each of these critical imperatives. But: not if you think you can get away with the same old, same old, running all your traffic through a small set of ingress and egress points to inspect traffic using your old security equipment.
Don’t get distracted with outdated expectations. If you can provide connectivity, availability, performance, and security within the tolerances required by your applications, does it matter what the network architecture looks like? We know some purists say yes, but we also remember purists hanging on to the SNA protocol for years. They couldn’t make the necessary changes, and eventually went the way of the dinosaurs. Success moving forward requires making sure you can provide the services your organizations needs, while keeping pace with change in the cloud age.
Everything changes. Including network security. Let’s map out what that means to you and your network security controls, with specificity.
Network Security in the Cloud Age
We need to rethink network security in light of the critical imperatives above. The old stuff doesn’t work any more, and we cannot afford to compromise or reject the power of the cloud to keep a traditional security model. So let’s set some design goals for this new-fangled cloud network:
- Secure Network Everywhere: Traditionally to enforce security controls on remote sites and users, you would backhaul traffic behind your corporate perimeter, inspecting it using the equipment and policies used for internal traffic. But that doesn’t scale. So let’s flip our perspective: instead of moving traffic to our security controls we will extend our network controls out to the location, user, or device.
- Infinite Perimeters: You cannot dictate devices’ location or access, so you need to figure out how to build an effective perimeter around each device. Conceptually each device includes its own network, so you need to securely interconnect all your networks. In traditional networks you would set up tunnels between each location or network, but that’s a N! problem, and N is skyrocketing in the cloud age. Network architecture needs to evolve to protect every device wherever it is, doing whatever it is doing, providing a “secure mesh” between all devices.
- Elasticity: Demand for bandwidth is insatiable, so you need a secure network design which can scale with your requirements. But sizing everything for peak usage is wasteful and expensive, so you will want to contract when you don’t need as much. Ideally you will only ever pay for as much network as you currently need. Especially because now you pay based on usage.
- Policy Driven: We have different security requirements for ingress and egress focused networks. Ingress networks provide access to computing resources, and so must focus on protecting data. Egress network protect users by regulating access to resources outside the organization. These different policies must be supported whatever the network looks like, and policies must be able to keep up with continuous deployment. Which means that…
- Automation Wins: Things change instantly in the cloud. There is no time to wait for a human to make changes, so your environment must be automated. But you need to trust your automation, with the ability to roll back changes when necessary. That means you need to program your networks, just like you program everything else. Yes, this means software-defined networks. We will dig in later in this series.
Design goals are great, but what will they mean in practice? Particularly in terms of what you need and how you build it? We will explore requirements and solution architectures in our next post.
Comments