Scaling Network Security: The New Network Security Requirements

Posted under:

In the last post, we bid adieu to The Moat, given the encapsulation of almost everything into standard web protocols and movement of critical data to an increasing number of cloud services. Additionally, the insatiable demand for bandwidth further complicates how network security scales. Thus, now 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?


Networks have grown exponentially over the past decade. With 100GB networks commonplace and the need to inspect traffic at wire speed, let’s just say scale is towards the top of the list for network security requirements. Of course, as more and more corporate systems move from your data centers to cloud services, the traffic dynamics will change – fundamentally. But pretty much every enterprise we run into still has high speed networks and those network need to be protected. So you can’t punt on scaling up your network security capabilities.

So how has network security scaled thus far? Basically using two techniques:

  1. 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, both from a performance standpoint and a cost feasibility perspective. Or likely 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 availability of bigger boxes to scale.
  2. 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 speeds on the network, it’s also dependent on the types of attacks you’ll see and the amount of pre-processing required on the traffic. For example, with todays complicated attacks, you may need to do multiple kinds of analysis to detect the attack. That requires more compute power. Additionally, with the increasing amount of traffic that is encrypted on networks, you’ll need to decrypt the packets prior to inspects, which is also tremendously resource intensive.

So even if you look at a network security appliance rated for 80 Gbps of throughput for threat detection, you’ll need to really understand the kind of inspection being done and whether that would detect the attacks you are worried about.

We don’t like to make compromises of either spending a crap ton of money to buy the biggest security box you can find (which may not big enough) or to decide just not to inspect some portion of the traffic. Thus, the scale requirements for the new network security are:

  1. No Security Compromises: You need to be able to inspect traffic that may be part of an attack. Period. to be clear, that doesn’t mean all traffic on the the network, but it means you need to be able to enforce security controls where necessary.
  2. Capacity Awareness: I think we saw a bumper sticker once that said, “traffic happens.” And it does. So you want to be able to support a peak usage scenario without having to provision for 100% peak usage. That’s what’s so attractive about the cloud. You can scale up and contract your environment as needed. It’s not as 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 start dropping packets.

So what happens when network speeds are upgraded, which does happen from time to time? Basically you want to upgrade your security controls on your timetable. Which coincidentally brings both scale requirements together. You can’t compromise on security just because the network speeds increased. And a network upgrade actually represents a potential burst. So if you can satisfy those two requirements, then 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 just require access control, since those sessions are between two trusted tiers in your application architecture. In fact, you may not need security inspection at all on some sessions. In all cases, you want to be making the decisions about where security makes sense, not based upon the capabilities of your equipment.

This requires the ability to enforce a security policy and implement the security controls where they are needed.

  1. 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 that you know hold sensitive data?
  2. Policy-based: Once you know the nature of the traffic, then you need to be able 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, then you’ll need to decrypt it first, so off to the SSL decryption gear. Or as we described above, it’s it’s traffic between trusted segments, you can likely skip running it through a network sandbox.
  3. Multiple Use Cases: Security controls are used both in the DMZ/perimeter and within the data center, and you want your new network security environment reflect the differences. Clearly there is likely more inspection required for inbound traffic from the Internet, as opposed to traffic coming from a direct connect from your public cloud environment. Both are external networks, but likely should have different security policies applied.
  4. 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-prem, you’ll want to have an analogy in the cloud. Again, the controls may be different and how they are deployed will be different, but the level 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, the attackers, and your technology infrastructure will 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 the next post we’ll wrap up the series by presenting an architecture to do so. 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.

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

*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)