Zerotrust the Streetwise Way #3. Endpoint Protection

Why a Strong Focus on Device Protection Is Needed

It turns out that for an attacker to access admin data, the easiest way is to hack an employee's laptop. Our goal is the opposite—to prevent this.

Device Protection Measures

At the initial stage, we have to comply with the bare minimum:

1. Basic OS configuration requirements

2. Agent installation and operability

We write requirements for OS configuration. They should include the need for a lock screen, disk encryption, disabling unnecessary services, and so on. The status of meeting these requirements is checked with an agent on the device. The simplest option is osquery. Osquery allows us to constantly monitor the protection status of our devices. It also integrates easily with SIEM for potential data enrichment.

In addition to osquery, we need some kind of agent to collect logs from the device, ideally an EDR agent. This allows us to detect device attacks and also respond to them quickly, including disabling admin access for a compromised device.

On top of the basic minimum, you can add any controls you like, the main thing is to ensure status delivery for these controls into a single place where we can see the overall protection status of our device fleet.

Integration into ZT

Let’s take a closer look at how device protection and data access are connected. We’ve rolled out osquery, installed an EDR, and send logs to SIEM. All that’s left is to write a service, call it the “Decision-Making System” (DMS), where the main logic will run. It will contain the requirements for admin access, which will be matched to the current device status.

The logic looks like this: each HTTP request from an endpoint comes to the proxy, the proxy asks the DMS whether to allow this device. At any moment, the device status may change—say a new browser RCE appears, but updates haven’t been installed yet. At that point, the DMS sets the device status to unprotected, and the user sees a placeholder in the admin panel instead of data, notifying them they need to update. After updating, data arrives to the DMS via osquery, and the device status turns green again. Different admin panels can have different requirements—non-critical panels might allow outdated devices, while critical ones can have extra checks.

As can be seen from the diagram, Device inventory and the database with device security data are separated. This is done because, in many cases, device inventory systems are difficult to expand or adapt slowly to dynamic functional requirements. Therefore, for development speed, it's possible to deploy your own system, where inventory data will be synchronized from the unified Device inventory, and compliance status will be fetched from osquery and other agents.

Inventory and agent tasks are complex and labor-intensive, which makes it reasonable to split them into a separate project and assign specific people to handle it. Communication is also key in this area—you need to notify users as widely as possible about the introduction of new technologies and the need to comply with requirements. Particular attention should be given to agreements with managers, securing their approval and support. These steps will significantly reduce friction during the transition to a new access scheme and greatly boost overall device fleet security.

Additional device protection measures.

Earlier, we discussed the basic task of building a secure device fleet and integrating it into Zerotrust. As an extra, I'd like to share some additional activities that will take the security of laptops—and, to some extent, users—to the next level.

Red-Purple Teaming

Dedicated people should constantly monitor new attack vectors and test them in practice. New delivery tools, persistence methods, social engineering approaches—all of these must be tried regularly, and together with the Security Operations Centre team, you need to assess which vectors were detected and which were not. For all missed vectors, controls should be implemented, and these controls must be validated.

Additional monitoring

Red Teaming often finds vectors that are poorly or not at all detected by available security tools. To deal with this, you either a) write specific monitoring rules, if possible, or b) create your own software, or use open source solutions.

Examples of tasks that are poorly detected by antivirus tools but are commonly used in attacks:

• Adding an ssh key to authorized keys

• Launching a binary from a flash drive.

• Most persistence methods on macOS

For the above situations, ready-made solutions exist, or it’s not hard to write some small custom daemons.

Obviously, device security as a topic is much broader, but as the attack vector through laptop compromise is so important for us, the need to pay attention to this topic can hardly be overestimated.

Previous articles:

1. Zerotrust, the street way

2. Zerotrust, the street way #2. How to make a device trusted