OK, I know what Zero Trust means. Now what?

In the previous article, I spent some time unpacking NIST’s seven tenets of zero trust. However, those ideas only describe what zero trust intends to accomplish, and that leaves many questions unanswered. What does zero trust actually look like to implement? What are the technologies involved to meet the needs described in the tenets? How does one figure out what it all will cost?

I will never say that you can buy security, but you can buy a relationship with someone who may be more capable of building your security than you are today. One answer to all of these questions is to seek out a service partner who can help you in your journey. If you have an organization with an immature security posture or with limited IT support, designing a low (capital) cost zero trust architecture may be possible. It will also almost certainly be very costly in terms of the time your staff will have to dedicate to learning what measures might be appropriate for your needs, let alone the time designing, implementing, testing, and managing your new environment.

Those providers already have many answers for these questions. For those of you intent on building your own solutions, or simply want to learn more on the subject, the rest of the article is a survey of some of the technologies that implement zero trust principles in a modern environment. For each technology that I discuss, I will include a reference to some zero trust tenets to which they might apply.

Disclaimer: I illustrate some of these technologies with examples; I do not recommend any particular vendor or product.

IT asset management (Tenets 1, 7)

The first task for implementing zero trust is to understand that there isn’t a button you can press or an appliance you can buy that will “do the zero-trust job.” You will have to construct it, bespoke, for each environment. That process can only start with a deep and conscious knowledge of the specific environment you will transform. For any environment more complex than your home office, working familiarity likely will not be enough. To see what I mean by working familiarity, ask yourself two questions:

How many unique devices are in my environment? Am I sure?

If you had to approximate, you are not ready to make a plan. If you had a definite answer, you might be ready—but you might also be wrong about your working knowledge! However, if you had to look it up, congratulations! An authoritative source that can provide that information is the tool you need to start a zero trust design.

IT asset management is a tool that can record information about your assets’ configuration, location, and current state (and potentially many other kinds of information as well). That kind of reference will be invaluable in making sure you can document each kind of required information flow—which is necessary for designing the required security for each process.

Examples: Snipe-IT, Cherwell ITSM.

Micro-segmentation/SDN (Tenets 1, 2)

This one will require some unpacking. First, you may or may not be familiar with cardinal direction terminology in networking. North-South connections are network connections between clients and servers. Virtually every network exists to make these connections possible. East-West connections are those between devices with similar roles or contexts, e.g., server-to-server, client-to-client, peer-to-peer. East-west connections may be required for certain workflows, but they often exist as unintended consequences of common network technologies. For example, each device plugged into the same Ethernet switch, by default, will share east-west connections with each other—even though they only need that switch to give them access to a server upstream.

Micro-segmentation is the concept of segmenting each device to only those connections that are required. In the proceeding Ethernet switch example, that would be like giving each device its own dedicated connection to the server to eliminate the east-west connections altogether. That would be ridiculous to implement physically, of course, so software-defined networking [SDN] handles defining and regulating the connections necessary for micro-segmentation. Windows Server has some SDN capabilities, and Quagga is a Linux project that can provide those capabilities as well.

Certificate-based authentication/802.1X (Tenets 2, 4)

If there is one authentication method that everyone knows, it is usernames and passwords. In security terms, this is the “something you know” authentication mechanism, and for all its faults, it has done a reasonable job of authenticating users over decades. For device authentication, “something you have” works much better. Digital certificates act as this “something” for devices. An authority issues a cryptographic certificate to each authorized actor in an environment; certificate authentication can then mediate access to various resources like wireless networks.

Certificate authentication operates easily in most environments; Microsoft Active Directory Certificate Services is a popular example. It also works well with RADIUS services for 802.1X device authentication (commonly seen in enterprise wireless contexts, but useful in many more scenarios).

Multi-factor authentication (Tenets 2, 3, 4, 6)

While usernames and passwords have done a reasonable job of authenticating users for decades, their time as the sole authentication mechanism is in its twilight—if it hasn’t ended already. Tools for breaking password security are advancing much faster than humans are getting better at handling passwords safely. Adding app-based challenges, physical tokens, or even location data to a password challenge increases the assurance of authentication to a great degree.

A caution: avoid text messaging for your multi-factor authentication method. Text messaging is inherently insecure, and attacks against those methods are only going to increase in the wild. If smart cards or other physical tokens are not a good choice for your use-case, then consider using a smartphone app service like Authy or Duo Mobile.

Endpoint security and endpoint management (Tenets 1, 4, 5, 7)

Two separate technologies, though they are often implemented in the same product. By endpoint security, I refer to the anti-malware packages you are all familiar with by names like Symantec, McAfee, or Windows Defender. Without some level of assurance that endpoints are intact as configured, you should consider them active threats. Endpoint management is a set of tools to monitor the configuration of endpoints so that their state is always visible. Those tools should also include patch management, so that updates can be deployed in a controlled and efficient way, and device management for enrollment, configuration, and package deployment capabilities.

Examples: Apple MDM, NinjaOne

Attribute-based access control (Tenets 3, 4, 6)

Also known as policy-based access control, this new access control model significantly extends the capabilities of older role-based controls. Instead of basing all access decisions on role/group membership, requests are fulfilled to the degree that their assessed attributes meet some pre-defined policy. This capability greatly depends on the ability to generate attribute data, and on the existence of access control policies, so consider all of the earlier controls to be prior requirements. Once those are in place, attribute-based access control gives the power and flexibility necessary to manage increasingly complex environments.

Examples: Open Policy Agent, Windows Server Dynamic Access Control

IDS/IPS (Tenet 5)

Intrusion detection and intrusion protection systems monitor the state and activity of your networks. You will often find their sensors placed behind firewalls (so that you can measure the efficacy of your firewall configuration), but in zero trust those sensors should be placed everywhere you can afford. IDS/IPS will be one of the main tools you use to identify the existence of the compromise we assume is already in progress.

Example: Snort

SIEM (Tenets 5, 7)

Security Incident and Event Management software provides a number of useful capabilities for the perspective that zero trust administrators require. Log management, event correlation, alerts, and compliance are all potentially critical components for your zero trust architecture.

A specific product recommendation for SIEM is a bad idea. A SIEM requires a whole team to run effectively, and you should not plan to build or run one yourself. Instead, a managed service provider is probably the optimal solution. Splunk, QRadar, and Exabeam are leaders in that field.

For the next article, we will look at a particular real-world scenario, and walk through one architect’s approach to moving an environment towards zero trust.