In our last post we bid adieu to The Moat, given the encapsulation of almost everything into standard web protocols and the movement of critical data to an expanding set of cloud services. Additionally, the insatiable demand for bandwidth further complicates how network security scales. So it’s time to reframe the requirements of the new network security. Basically, as we rethink network security, what do we need it to do?
Scale
Networks have grown exponentially over the past decade. With 100gbps networks commonplace and the need to inspect traffic at wire speed, let’s just say scale is towards the top of the list of network security requirements. Of course as more and more corporate systems move from data centers to cloud services, traffic dynamics change fundamentally. But pretty much every enterprise we run into still has high speed networks, which need to be protected. So you can’t punt on scaling up your network security capabilities.
How has network security scaled so far? Basically using two techniques.
- Bigger Boxes: The old standby is to throw more iron at the problem. Yet at some point the security controls just aren’t going to get there – whether in performance or cost feasibility, or both. There is certainly a time and a place for bigger and faster equipment, we aren’t disputing that. But your network security strategy cannot depend on the unending availability of bigger boxes to scale.
- Limit Inspection: The other option is to selectively decide where and what kind of security inspection takes place. In this model, some (hopefully) lower risk traffic is not inspected. Of course that ultimately forces you to hope that you’ve selected what to inspect correctly. We’re not big fans of hope as a security strategy.
The need for speed isn’t just pegged to increasing network speeds – it’s also dependent on the types of attacks you’ll see and the amount of traffic preprocessing required. For example with today’s complicated attacks you may need to perform multiple kinds of analyses to detect an attack, which requires more compute power. Additionally, with the increasing amount of encrypted traffic on networks, you need to decrypt packets prior to inspection, which is also tremendously resource intensive.
Even if you are looking at a network security appliance rated for 80gbps throughput for threat detection, you need to really understand the kind of inspection being performed, and whether it would detect the attacks you are worried about.
We don’t like to compromise on either spending a crapton of money to buy the biggest security box you can find (which still might not be big enough) or deciding to just not inspect some portion of traffic. The scaling requirements for the new network security are:
- No Security Compromises: You need the ability to inspect traffic which may be part of an attack. Period. To be clear that doesn’t mean all traffic on the the network, but you need to be able to enforce security controls where necessary.
- Capacity Awareness: I think I saw a bumper sticker once which said “TRAFFIC HAPPENS.” And it does. So you need to support a peak usage scenario without having to pre-provision for 100% usage. That’s what’s so attractive about the cloud. You can scale up and contract your environment as needed. It’s not easy on your networks, but that’s the mentality we want to use. Understand that security controls are capacity constrained, and make sure those devices are not overwhelmed with traffic and don’t start dropping packets.
So what happens when network speeds are upgraded, which does happen from time to time? You want to upgrade your security controls on your timetable. Which coincidentally brings both scaling requirements into alignment. You can’t compromise on security just because network speeds increased. And a network upgrade actually represents a legitimate burst. So if you can satisfy those two requirements, you’ll be able to gracefully handle network upgrades without impacting your security posture.
Intelligent and Flexible
The key to not compromising on security is to intelligently apply the controls required. For example not all traffic needs to be run through the network-based sandbox or the DLP system. Some network sessions between two trusted tiers in your application architecture just require access control. In fact you might not need security inspection at all on some sessions. In all cases you should to be making the decisions about where security makes sense, not being forced by the capabilities of your equipment.
This requires the ability to enforce a security policy and implement security controls where they are needed.
- Classification: Figuring out which controls should be applied to the network session depends first on understanding the nature of the session. Is it associated with a certain application? Is the destination a segment or server you know holds sensitive data?
- Policy-based: Once you know the nature of the traffic, you need the ability to apply an appropriate security policy. That means some controls are in play and others aren’t. For example if it’s an encrypted traffic stream you’ll need to decrypt it first, so off to the SSL decryption gear. Or as we described above, if it’s traffic between trusted segments, you can likely skip running it through a network sandbox.
- Multiple Use Cases: Security controls are used both in the DMZ/perimeter and within the data center, so your new network security environment should reflect those differences. There is likely more inspection required for inbound traffic from the Internet than for traffic from a direct connection to your public cloud. Both are external networks, but they generally require different security policies.
- Cloud Awareness: You can’t forget about the cloud, even though network security can differ significantly from your corporate networks. So whatever kinds of policies you implement on-premise, you’ll want an analogy in the cloud. Again, the controls may be different and deployment will be different, but the level of protection must be consistent regardless of where you data resides.
The new network security architecture is about intelligently applying security controls at scale, with a clear understanding that your applications, attackers, and technology infrastructure constantly evolve. Your networks will look significantly different in 3 years, but you don’t want your level of protection to differ, nor do you want your security environment to need forklift upgrades every 18 months.
So the challenge of meeting these requirements is accepted, and in our next post we’ll wrap up this series with an architecture to do it. As with all of our research, there is no one right answer, but we’ll present the decision points so you can figure out what will work for you.
Comments