Zero Trust is hard but worth it

Late last year, I heard of a longtime corporate contact who had a major security issue. The company had installed three layers of security and had just completed an audit. It showed that since they had completed their installation, they had had five security incidents, and all of them had started inside their security perimeter, bypassing most of their protection.

Their question was what they had done wrong and how they could fix it.

What this company has experienced is far from uncommon, and the source of their problems and the paths to correction are far from easy.

We tend to think of security as something we can achieve with just a toolkit. Not so. Security is the state you reach by facing all likely threats, and each threat must be dealt with in its own way. Problems can arise from hackers accessing an application or database from the outside, such as stealing credentials or exploiting weak authentication.

They can also come from exploits, where flaws in a program (application, middleware, or operating system) can be used to trigger malicious behavior. Finally, they can come from malware introduced in some way. Combinations of the three are increasingly common. Companies have tended to focus, as my contact did, on perimeter security as a defense against the first of these security issues. They overlooked, or maybe I should say underestimated, the latter two.

Fixing these other two issues doesn’t mean abandoning perimeter security, it means tackling all possible sources of trouble, and the issues reported by my contact offer some insight into the rules for fine-tuning security.

The first rule is that building a wall is useless if you keep the door open. Most companies are far too lax in securing employee devices, and in the majority of my contact’s security incidents, the problem was created by an infected laptop. In their case, working from home meant extending corporate VPN access to devices that were not only unsecured, but not even inspected. As far as possible, work devices should not be used for private purposes, and vice versa.

The second rule is to learn Latin, or at least the critical Latin phrase “Quis custodiet ipsos custodes”. Loosely translated, it means “Who will watch the guards themselves?” Monitoring, management, and even security tools often have privileged access to resources and applications, and in the past six months alone we’ve had two major security issues associated with contamination of one of these tools. : the SolarWinds flaw and Log4j. These problems prove that the things we need to run our networks, applications, and data centers can eat away at us, so we need to pay close attention to them, keep them up to date, and watch for unethical behavior.

Keeping software up-to-date is key to enforcing both of these rules, and unfortunately this is often a problem for businesses. Office software, especially with WFH, is always difficult to update, but a combination of centralized software management and scheduled review of software versions on home systems can help. For mining tools, don’t be tempted to ignore open source tool releases just because they seem to be happening often. It’s a good idea to include a review of critical operating software releases as part of your overall software management program and to closely examine new releases at least every six months.

Even with all of this, it’s unrealistic to assume that a company can anticipate every possible threat posed by every possible bad actor. It is best to prevent the disease, but treating it once symptoms appear is also essential. The least used security principle is that preventing bad behavior means understanding good behavior. Whatever the source of a security issue, it almost always means that something is doing something it shouldn’t. How can we know this? By monitoring different behavioral patterns. That’s what Zero Trust, another widely misused security term, should mean. Sometimes it is; often this is not the case.

What Zero Trust Really Means

There is nothing easier than putting a label on a product or service. If you look at exactly what a zero-trust solution is, you’ll see that we don’t even really have a consensus on what the concept means. How can you trust a term that has no meaning or multiple meanings? What we expect from Zero Trust is behavior monitoring and control.

I asked my contact how many apps an average worker could access, and the company was unable to get the answer. How, then, could the company know if the worker, or someone working on their laptop, was stealing data or contaminating operations? They didn’t know what was allowed, so they couldn’t spot what wasn’t allowed, and that’s where Zero Trust comes in.

A zero-trust system should assume that there is no implicit right to login to anything. Login rights are explicit, non-permissive, and this is the property that is both critical to Zero Trust security and critical to monitoring and controlling behavior.

No one questions the challenge associated with defining not only the allowed connectivity for each worker, but also the connection requirements for management and operations software, middleware, etc. These difficulties explain why companies often do not accept true Zero Trust security and why vendors may claim not to provide the necessary functionality. Yes, Zero Trust is more work, but no, you can’t avoid it and be truly safe.

Even taking on the challenge of defining allowed connectivity does not end the evil. A Zero Trust system must recognize and log attempts to establish unauthorized connections. In fact, it’s this feature that makes Zero Trust so important. Almost all attacks inside the perimeter will explore connectivity and resources looking for something interesting, and in a good Zero Trust system these explorations will be detected and logged, alerting the business to the fact that something is wrong. Quick action can then save the day.

The best way to validate a Zero Trust system proposed by a supplier is to see how to apply it. It’s good to support a hierarchical framework for assigning login rights to items, because all employees in accounting, for example, and all accounting software are likely to have common login permissions.

It’s good that logged exceptions are stored in a way that traditional analytics and even AI tools can examine them and look for patterns.

Finally, it’s fine if it seems like a bit of work, because products that don’t require a lot from you are likely to provide little in return. Creating login permissions and exception logs is critical to security, so don’t compromise these features just to relax. Security is hard, but recovering from security issues is harder.

Join the Network World communities on Facebook and LinkedIn to comment on the topics that matter to you.

Copyright © 2022 IDG Communications, Inc.

Comments are closed.