Designing a Device Posture Assessment System

Hello! Welcome back to our course on architecting security products.

In our last lesson, we designed the ZTNA data plane, the high-speed pathway for user traffic. We focused on the secure tunnels connecting the user's device to the ZTNA edge and onward to the internal connector, evaluating the trade-offs between protocols like WireGuard and MASQUE/QUIC. However, our access decisions so far have been based primarily on a user's identity.

True Zero Trust requires verifying not just the user but also the device they are using. Is it a trusted, company-managed laptop, or a personal device of unknown security hygiene? This is the principle of "never trust, always verify" in action.

This lesson directly addresses the learning outcome: Design a device posture assessment system, including agent health checks, a signal collection pipeline, and compliance scoring. We will design the components that collect, transport, and evaluate critical device health signals, turning them into a key input for our ZTNA policy engine.

1. The Core Idea: What is Device Posture?

Device posture (or device health) is a measure of a device's trustworthiness at a specific point in time. It's not a static property but a dynamic state determined by a collection of security-relevant attributes.

The goal of a posture assessment system is to answer questions like:

• Is the operating system up-to-date and patched?
• Is the disk encrypted?
• Is security software (like an EDR or antivirus) running and healthy?
• Is this a corporate-managed device or a personal one?

The video below introduces how a Zero Trust system consumes these signals to make smarter access decisions.

As you can see, the endpoint agent is our sensor on the device. Let's design the system that processes the data from this sensor.

2. System Architecture: A Three-Part Design

We can break down the design of a device posture system into three main parts, which we will explore in detail:

1. Signal Collection (The Agent's Role): What data does the agent on the client device need to collect?
2. The Signal Pipeline (Data Transport): How do we efficiently and reliably transport this data from thousands of devices to a central service?
3. Compliance Scoring (Making a Decision): How do we transform raw data into a meaningful score that our policy engine can use?

This high-level architecture is a common pattern in Zero Trust implementations. Google's BeyondCorp, a foundational ZTNA model, uses a similar structure.

3. Part 1: Signal Collection (Agent Health Checks)

The ZTNA agent on the device is responsible for gathering posture signals. The specific signals to collect depend on the organization's risk tolerance and policies. Here are some fundamental categories:

• Operating System: OS type (e.g., macOS, Windows), version, and patch level.
• Hardware: Device serial number (often used to identify corporate assets), disk encryption status (e.g., BitLocker on Windows, FileVault on macOS).
• Security Software:
  • Is an Endpoint Detection and Response (EDR) or antivirus solution installed, running, and up-to-date?
  • Is the local firewall enabled?
• Management & Identity:
  • Does the device have a valid client certificate issued by a corporate Certificate Authority?
  • Is the device present in a Mobile Device Management (MDM) system?
• Agent Health: Is the ZTNA agent itself running correctly and hasn't been tampered with?

The following video demonstrates how a real-world ZTNA product, Cloudflare Zero Trust, uses some of these exact checks to enforce policy.

The agent gathers these signals by querying OS-level APIs (e.g., WMI on Windows, system_profiler on macOS) and checking the status of specific processes and files.

4. Part 2: The Signal Collection Pipeline

Once the agent collects the signals, they must be sent to a central service for storage and analysis. This is a classic data pipeline problem, a domain you're familiar with from your software engineering background. We'll design this pipeline in stages, drawing parallels to standard security telemetry systems.

Based on this framework, let's design our pipeline:

1. Collection Agent (ZTNA Client):

   • Periodically (e.g., every 5 minutes, or on significant network/system events), the agent gathers the raw posture signals.
   • It batches these signals into a structured format like JSON.
   • It sends this batch via an HTTPS POST request to a dedicated Signal Collection Endpoint. The request is authenticated using the device's unique identity (e.g., a client certificate or token).

2. Ingestion & Processing Layer:

   • The Signal Collection Endpoint is a highly available API gateway. Upon receiving data, it places the raw payload into a Message Queue (e.g., Kafka, Azure Event Hubs). This decouples ingestion from processing and absorbs traffic spikes.
   • A pool of Processing Workers consumes messages from the queue. Their job is to:
     • Parse and Normalize: Transform the OS-specific data into a standardized schema. For example, Encrypted: "true" from one agent and EncryptionStatus: 1 from another both get normalized to a common format.
     • Store: Update the device's record in a Device Inventory Database. This database holds the most recent posture state for every enrolled device, indexed by a unique device ID.

This architecture ensures scalability and resilience. If the processing workers are down for maintenance, signals queue up safely without being lost.

5. Part 3: Compliance Scoring

Raw data in a database isn't enough; we need to turn it into a decision. This is where compliance scoring comes in. We need a system that can look at a device's current state and produce a verdict. There are two primary models for this.

Model A: Binary Checklist

This is the simplest model. A policy defines a set of non-negotiable requirements.

• Disk Encryption: MUST be enabled.
• OS Version: MUST be >= 13.5.0.
• EDR Agent: MUST be running.

A device is either compliant or non-compliant. If even one check fails, the device is non-compliant. This is easy to implement but lacks nuance. An OS that is one minor patch behind is treated the same as a device with no disk encryption.

Model B: Weighted Trust Score

A more sophisticated approach is to calculate a numerical "trust score." Each posture signal is assigned a positive or negative weight, and the final score is the sum.

Example scoring logic:

• Base Score: 100
• Disk Encryption disabled: -50
• Firewall disabled: -30
• OS is 1-2 minor versions behind: -10
• OS is a major version behind: -40
• Corporate certificate present: +10

This allows for granular policies:

• Score > 90: Full access.
• Score 70-89: Access allowed, but require re-authentication with MFA.
• Score < 70: Block access and redirect user to a remediation page.

This model is more flexible and better reflects real-world risk.

6. Integration with the Policy Engine

Now, let's design the API that exposes this score to the rest of our ZTNA system. We don't want the central Policy Engine querying our Device Inventory Database directly. Instead, we'll create a dedicated Posture Service that exposes a clean API.

Fortunately, there are industry standards for this. Cloudflare's documentation for custom integrations gives us a perfect blueprint.

Based on this resource, we can define our Posture Service API:

• Endpoint: POST /v1/posture/query
• Authentication: The caller (our Policy Engine) authenticates with a service token.
• Request Body: A JSON object containing a list of device IDs:

  {
    "devices": [
      { "device_id": "a1b2c3d4-..." },
      { "device_id": "e5f6g7h8-..." }
    ]
  }
  

• Response Body: A JSON object with scores for each device:

  {
    "results": [
      { "device_id": "a1b2c3d4-...", "score": 95 },
      { "device_id": "e5f6g7h8-...", "score": 65 }
    ]
  }
  

When a user tries to access an application, the Policy Engine calls this endpoint with the user's device ID, gets the score, and uses it as a critical input to make the final allow/deny decision.

Conclusion

In this lesson, we have designed a complete device posture assessment system from first principles. We have moved beyond simple identity checks to a more robust verification model that is essential for Zero Trust.

Key Takeaways:

• Posture is a collection of signals: We designed the agent's role to collect critical data about the OS, hardware, and security software.
• Signal collection is a data pipeline problem: We architected a scalable and resilient pipeline using message queues to transport signals from thousands of agents to a central device inventory database.
• Scoring translates data into decisions: We contrasted a simple binary compliance model with a more flexible weighted trust score, which allows for granular, risk-based access policies.
• APIs provide clean integration: We designed a Posture Service with a clear API contract, allowing the central Policy Engine to query for a device's trust score on-demand.

Preview of the Next Lesson:

Our system is now capable of making a very sophisticated access decision at the start of a session. But what if a device's posture changes during a session? For example, what if a user disables their firewall after they've already connected?

In the next lesson, we will design a continuous authentication mechanism involving session risk scoring and real-time policy re-evaluation on signal changes. We will explore how to react to changes in posture and other risk signals in real-time, enabling us to terminate a session instantly if it becomes non-compliant.