Security

What Federal Technology Will Need to Be Replaced to Create a Zero-Trust Environment? 

The answer depends on existing IT capabilities and identity authentication goals.

Joel Snyder, Ph.D., is a senior IT consultant with 30 years of practice. An internationally recognized expert in the areas of security, messaging and networks, Dr. Snyder is a popular speaker and author and is known for his unbiased and comprehensive tests of security and networking products. His clients include major organizations on six continents.

The White House’s January announcement that zero trust is now an official federal cybersecurity strategy put a stake in the heart of the “crunchy shell around a soft, chewy center” security architecture that dominated network design for decades.

For agencies moving toward zero trust, the hard work is in changing assumptions about how to handle security and authentication for applications. But for federal network managers, zero trust also implies fundamental changes in architecture: more secure sockets layer (SSL), more network segments, and more identity and access management. Here’s how to get started.

Make Sure Your Network Can Handle More SSL

There’s no single recipe for how to handle zero trust, but most architectures depend heavily on SSL to provide both encryption and authentication of the data stream between a user and the application. That’s going to mean lots more SSL passing through your network.

Federal network managers can prepare for this onslaught by beefing up their SSL acceleration capabilities, not just at the network edge but also deep inside the data center network. SSL is also used inside the data center to ensure that no one is listening in on server-to-server traffic.
Existing standard tools, such as load balancers (sometimes known as application delivery controllers or ADCs), should be evaluated to make sure they are up to the task of handling all that crypto traffic.

Network managers should also investigate firewalls with built-in SSL offloading. While they may not have the crypto acceleration power of a dedicated appliance, they can be used as an adjunct or when network topology makes it hard to bring a large load balancer/ADC farm in front of an application.

Because firewalls sit — or should sit — between almost any two communicating devices, having the ability to use them for SSL offloading delivers flexibility and helps maintain a cleaner architecture.

The downside of having SSL everywhere is that controlling, debugging and monitoring traffic becomes hard or impossible, especially with modern crypto suites. This creates a challenge for network and security managers, and there’s no easy solution to the tension between security and visibility.

However, network managers should be investigating beefing up their ability to tap into the network at any point using software technologies such as Remote Switch Port Analyzer (RSPAN) and Encapsulated RSPAN (ERSPAN) and hardware such as dedicated network tap and network capture appliances. Having lots of places where you can grab and look at network traffic, especially when it’s encrypted, is a significant timesaver when debugging in a mostly SSL world.

LEARN MORE: We've got the answers to five common questions about zero-trust cybersecurity.

Zero trust isn’t just about the user; it’s about not trusting the network or other servers either.

Joel Snyder Senior IT Consultant and Security Expert

Add More Segments to Your Network

Zero trust isn’t just about the user; it’s about not trusting the network or other servers either. A zero-trust architecture means more network firewalls, each controlling access between different network segments. While some network managers have elected to supersize their firewalls and turn them into enormous routers between microsegments within the data center, this instead creates a huge potential single failure point.

More important, existing firewalls and their management systems are not designed to have hundreds of segments, each with a slightly different security policy, pushed to a single device. Add to this the federal Cloud Smart strategy, which discourages centralization within an agency private data center.

Network managers should look into more distributed architectures, adding multiple smaller firewalls to provide segmentation within private and public data centers. This is especially true when functions are different. For example, user-to-application traffic needs different unified threat management firewalling than server-to-server, which requires much simpler access controls and a less sophisticated firewall.

The most important component, no matter how many devices are in the network, is a good management system that supports global objects (such as application definitions and network addresses) when it is used to create and push policy to each device. This critical capability reduces the likelihood of human error and miscommunications creating security problems.

Network managers also need to be on the lookout for requirements from DevOps teams, as application developers are increasingly including automation and orchestration in their toolkits and development stacks. These are popping up not just in data center networks but also in cloud Infrastructure as a Service environments where tight integration between the IaaS and the (virtual) firewall is critical to managing controls across microsegments.

DIVE DEEPER: Get CDW•G's help in guiding your agency to a zero-trust environment.

Boost Identity and Access Management Tools

At first glance, zero trust doesn’t necessarily require significant changes in infrastructure. However, many agencies are considering identity and access management (IAM) systems as a required component for implementing zero trust, and that creates additional stress on some network infrastructure components.

One obvious place is authentication and authorization services. This is because users aren’t being simply authenticated using a central directory — they are also being authorized, and these authorization checks can occur with almost every mouse click.

Network managers have long worked with desktop and server managers to deploy common authentication systems. Now, these authentication and authorization servers may be under much heavier stress than originally anticipated. Authentication and authorization services should have the ability to run nonstop and to scale up to handle additional load when required. This is equally true for the databases, logging subsystems and back-end directories that these services depend on.

Network managers should also be an active part of the team for any IAM initiatives going on with their agency. Because network and security devices have long depended on enterprise directories such as Windows Active Directory and protocols such as RADIUS and LDAP for both authentication and authorization, any changes coming as part of a more comprehensive IAM system must be compatible with existing network and security appliances.

If the entire agency starts to head down an OAuth path with multifactor authentication for IAM, that’s great — as long as the network and security teams have enough notice to upgrade appliances or find workarounds to support these newer protocols.

hernan4429/Getty Images