Scaling Network Security: The Scaled Network Security Architecture

Posted under: Research and Analysis

After going into the challenges with existing network security architectures (RIP Moat), we laid out a number of requirements for the new network security. This includes the need for scale, intelligence and flexibility. This sounds all good and well, but how do you get there? We’ll wrap up the series by discussing a couple of key architectural constructs that will guide how you build your future network security architecture.

Although before we go into the specifics, let’s wrap a few caveats around the architecture. Not everything will work for every organization. There may be cultural impediments to a some of the ideas we recommend. We point this out because any new way of doing things can face resistance from the folks that will be impacted. Within that context, you’ll have to decide which ideas make sense to solve your current problems, and which battles are not worth fighting.

There may also be some technical challenges, especially when dealing with very large networks. Not conceptually as faster networks and increased flexibility are a thing regardless of the size of your network. The challenge is more in terms of phasing migration. Although nothing we are going to recommend requires a flash cutover, nor are any of these ideas incompatible with the existing network security constructs. Philosophically we’ve always advocated a customer-controlled migration, that entails you deciding when you are going to embrace new capabilities — not some arbitrary requirement from a vendor or any other influencer.

Access Control Everywhere

The first construct we’ll hit is access control everywhere. This is a pretty fundamental aspect of your environment since network security is about controlling access to key resources. Duh. We’ve also been making the point that segmentation is your friend for years. Yet in traditional networks it became very hard to do true access control in a scalable fashion since data flows weren’t predictable, workloads and data are moving around, and users need to connect from wherever they are.

The advent of software defined everything (including networks) has given you an opportunity to more effectively manage who gets access to what and when. The key to this is setting the policy. Yes, you start with critical data and who can/should access it from where to set your baseline. But the larger the network and more disbursed your employee base and resources (including mobility and cloud) are the tougher it is. So you do the best you can with the initial set of policies and then you hit it from the other side. Your new network security should be able to monitor the traffic flows and suggest a workable access control policy. Obviously, you’ll need to scrutinize and tune the policy while cross-referencing it to the initial cut that you took, but this will accelerate your effort.

Returning to the need for flexibility, you want to be able to adapt the policies as needed. Sometimes even on the fly, within the acceptable parameters defined by the policy. That doesn’t mean you need to embrace the machines making policy changes with no human oversight or intervention, at least at first. In a customer-controlled migration, you decide the pace of automation allowing you to get comfortable with the policies and ensure maximum uptime and security.

Applying Security Controls

With segmentation reducing the attack surface by making sure unauthorized access to critical resources is not allowed, you still have to ensure that authorized connections/sessions are not doing anything malicious. Since devices have been known to get compromised from time to time, this means we can’t forget about the prevention and detection tactics we’ve been using on our networks for decades. Those are still very much a requirement, but as we described in the requirements, we need to be more intelligent about when the security controls are used. After all you’ve probably spent a couple of million ($currency) on the network security controls, so you may as well make the best use of that investment.

Once again, we’ll return to the importance of policy-based network security. Depending on the source, destination, application, time of day, geography and about a zillion other attributes (OK, we may be exaggerating a bit there), we want to leverage a set of controls to protect the data. Not every control is applicable to every session, and the network security platform needs to selectively apply the controls.

Decryption

Before you start worrying about which controls to apply to which traffic, you need to make sure you can actually inspect the session. With more and more network traffic being encrypted nowadays, before you apply security controls you’ll need to decrypt the traffic. We wrote about this at length in Security and Privacy on the Encrypted Network, but things have changed a bit over the past few years.

The standard approach to network decryption involves intercepting the connection to the destination (ergo the person in the middle) and then decrypting the session using a master key. The decryption device then routes the connection to the appropriate security control (based on the policy), and then sets up a separate encrypted connection to the destination server. And yes our political correctness may be getting the best of us, but we’re pretty sure that network security equipment is not gender specific, so we like the person in the middle description.

Any network security platform will need to provide decryption capabilities where needed. Yet, that’s getting more complicated, as we described in the TLS 1.3 Controversy, clearly a person in the middle approach weakens the overall security of the connection, since any organization (some good – like your internal security team, and some bad – like adversaries) could conceptually get in the middle and sniff the traffic in the session. The TLS 1.3 specification addresses that weakness by implementing Perfect Forward Security, which uses a different key for each session and therefore eliminating a single master key that could monitor everything.

Obviously not being able to get in the middle of the network session eliminates your ability to inspect the traffic and enforce security policies on the network. To be clear, it’s going to take a long time for TLS 1.3 to become pervasive and in the meantime, your connections can down-negotiate to TLS 1.2, which would still allow the person in the middle approach. Yet, you’ll need to start thinking about different, likely endpoint-centric approaches to inspecting traffic before it hits the encrypted network.

Contextual Protection

Assuming we can inspect the traffic on the network, we want to implement a policy-centric approach to security. That means identifying the traffic and determining which security control(s) are appropriate based on the specifics of that connection. This uses context to ensure you are using the appropriate security controls, which both improves security posture and helps to optimize control capacity (as we’ll discuss below).

The best way to understand this concept is to use a few simple examples:

• Ingress: In the case of an inbound connection, you want to protect against malware coming into the network, as well as application attacks. So you can set a policy that routes email traffic through an email security gateway and then a network-based malware scanner. Or maybe you take email from an email security service and then run it through the malware scanner or IPS to ensure any links in the message aren’t malicious. To protect application traffic, first the connection goes through a WAF, but you can also have the connection run through an IPS to detect more traditional attacks. Similarly you’d like to be able to leverage different controls if the session originates in a hostile country which would demand more scrutiny.
• Egress: Looking at it from the other perspective, if you are dealing with outbound traffic you’ll first want to decrypt an encrypted session and then send the connection through a web filter since that will determine if the session is being misused, connecting to a malicious site or showing patterns that may indicate command and control traffic. Yet, depending on what kind of data is in the payload, you may also want that connection to be run through a DLP device to ensure data is not misused. You’ll want to apply context to DLP inspection, since that’s very resource intensive.

These are oversimplified examples, but contextual protection allows you to use the controls you need to protect that specific connection.

Optimizing Capacity

As we mentioned in the requirements post, you don’t always have the luxury of upgrading network security controls at the same time as the bandwidth on the network increases. Moreover, heavy duty deep packet inspection as we described above in both examples of contextual protection may not be needed for all traffic, given the significant resources that kind of inspection requires. So not when determining which controls are used on which connections, it’s important to make sure that capacity is factored into the mix.

Yet, we’ll also make the point that you don’t want to compromise on security due to capacity issues. But, having a network security platform that can give you a sense of when specific security controls are at capacity, as well as potentially buffer the connection to the packets aren’t dropped, will provide a graceful way to manage network capacity.

To once again show an example, if you’ve recently upgraded your data center network to 100GB, but don’t have the security budget to increase the speed of the internal firewalls used for segmentation, you can have the network security platform buffer the traffic while the firewall enforces the policy. To be clear, this is not a great answer because this will impact application traffic, but the alternative is to either violate segmentation rules (which probably won’t sit well with the auditors) or dropping packets.

Similarly, another example is intelligently routing connections to your authorized SaaS applications just through your security web gateway service and not through the internal DLP engine because you already have a CASB looking at activity happening in those SaaS applications. That will allow your DLP device to scale more effectively. Again, pretty simple examples but provide the perspective that intelligently determining the security controls in use for each connection is an interesting concept.

Getting There

The key here is to not get wrapped up in trying to boil the ocean. You can start small, maybe implementing a SDN technology in front of your egress security controls to apply the policies we’ve discussed. Or possibly introducing a packet broker in front of a key application to make sure that appropriate security controls are not overwhelmed if a flood of traffic happens. You could start thinking about starting with micro-segmentation in your virtualized data center and map those capabilities to any new applications being deployed in IaaS (infrastructure as a service). Or you could be interested in a new fangled Zero Trust access control environment or a Secure Network as a Service offering for employee access and roll out intelligent networks internally to provide access to some resources (that remote employees need), while segmenting everything else.

The possibilities are endless in terms of how to migrate to this kind of network security platform, and there is no right or wrong answer. There is only the reality that your security controls cannot scale at the same rate as your networks and that means you’ll need to apply intelligence to how security controls are deployed within your environment.

– 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: http://securosis.com/blog/scaling-network-security-the-scaled-network-security-architecture