Agent Volatility

Some fields in the agent are made available specifically to mitigate against active attacks, and are therefore expected to change rapidly relative to the infrequent changes that IT organizations normally expect. Trust scores are an example of this type of dynamic data. Trust score systems can evaluate each request in the network, using that activity feed to update the trust scores of users, applications, and devices. Therefore, in order for a trust score to mitigate a novel attack, it needs to be updated as close to real time as possible. Chapter 4 goes into greater detail about trust scores.

In addition to rapidly changing data, agents will frequently have sparse data. A device undergoing bootstrapping is an example scenario where the agent will have less data when compared to a mature device. During the bootstrapping process, little is known about the device, yet it must still interact with corporate infrastructure to perform tasks like device enrollment and software installation. In this case, the bootstrapping device is not yet assigned to a user and can run into problems if policy expects an assigned user to be present in the agent. This scenario should be expected and reflected in the authorization policy.

Sparse data isn’t just found in bootstrapping scenarios. Autonomous systems in a zero trust network will frequently have sparse data when compared to human-operated systems. These systems, for example, will likely not authenticate the user account the application runs under, relying instead on the security of the configuration management system that created that user.

What’s in an Agent?

The granularity of data contained within an agent can vary based on needs and maturity. It can be as high level as a user’s name or a device’s manufacturer, or as low level as serial numbers and place of residence or issue. It should be noted that the more detailed data is more likely to have data cleanliness issues, which must be dealt with.

Another point of consideration is if the data contained in the agent is trusted or not. For instance, device data populated during the procurement process is more trusted than device data which is reported back from an agent running on it. This difference in trust arises from difficulties in ensuring the accuracy and integrity of the reported information in the event that the device is compromised.

Agents are Not for Authentication

It is important to understand the difference between authentication and authorization in the context of an agent. Agents serve solely as authorization components and do not play any part in authentication. In fact, authentication is a precursor to agent formation and is generally performed separately for user and device. For example, devices could be authenticated with X.509 certificates, while users might be authenticated through a traditional multifactor approach.

Following successful authentication, the canonical identifiers for users and devices can be used to form an agent and its details. A device-specific certificate might be used as the canonical identifier for the device and therefore be used to populate information like device type or device owner. Similarly, a username might serve as the lookup key to populate user information like their role in the company.

Typically authentication is session oriented, but in the case of authorization, it is best to be request oriented. As a result, caching the outcome of an authentication request is permissible, but caching an agent or the result of an authorization request is ill advised. This is because details in the agent, which are used to make authorization decisions, can change rapidly based on a number of factors, and it is desirable to make authorization decisions using the latest data. This is in contrast to authentication materials, which change much less often and don’t directly affect authorization itself.

Finally, the act of generating an agent should be as lightweight as possible. If agent generation is expensive, it will discourage frequent authorization requests due to performance reasons. We will talk more about how performance affects authorization in the next chapter.

Rigidity and Fluidity, at the Same Time

Knowing the format of an agent, and where to find particular pieces of data within it, is very important when considering how and by what it will be consumed. The “coordinates” of certain pieces of data must be fixed and well known in order to ensure consistency across control plane systems. A good analogy here is the schema of a relational database, which applications accessing the data must have knowledge of in order to extract the right pieces of information.

This data compatibility is extremely important when it comes to implementing and maintaining zero trust control plane systems. Zero trust networks, particularly more mature ones, are likely to construct an agent from multiple systems and data sources. Without a schema of sorts, not only will it be difficult to surface the data in a consistent manner, but it will also contribute negatively to the amount of effort required to introduce new control plane systems or agent data, something which is considered critical for a maturing zero trust network.

One thing to keep in mind, however, is that agent data is likely to be fairly sparse, thanks to the practically unavoidable data cleanliness issues encountered in source systems like device inventories. The result is a “best-effort” agent, where many fields may be unpopulated for one reason or another. Rather than seeking data cleanliness (a problem that only gets harder with scale), it is best to accept reality and craft policy that understands that not all data may be present. So while one may still require a particular piece of data to be present in the agent, it is a useful thought exercise to consider alternative pieces of data in its absence.

Standardization Desirable

One might wonder how it would be possible to standardize a data format that is so seemingly inextricably tied to the organization consuming it. After all, an agent is likely to contain information types that relate to business logic or other proprietary/local information. Is standardization even feasible in such a case?

Luckily, there are already some standards out there defining data formats that behave in such a way. One of the best examples is the Simple Network Management Protocol (SNMP), and its associated management information base (MIB).

SNMP is a protocol frequently used for network device management, allowing devices to expose data to operators and management systems in a standard yet flexible way. The MIB component describes the format of the data itself, which is a collection of OIDs, or object identifiers. Each OID describes (and is reserved for) a particular piece of data and is registered with ISO, a global standardization body. This lends itself well to widely accepted “coordinates” for certain pieces of data. Let’s look at an example, shown in Figure 3-1, of a simplified set of nodes in an OID tree.

Figure 3-1. A simplified diagram showing the organization of nodes in an object identifier (OID) tree

In this example, the “ip” node and associated data would be addressed as 1.3.6.1.1.1.4. A MIB arranges and gives color to a set of OIDs. For example, a Cisco MIB might provide definitions for all OIDs under the 1.3.6.1.4.1.9 portion of the tree, including human-readable descriptions.

Of course, this registered list can be extended, and oftentimes chunks of OID space are carved out for organizations or manufacturers. In this way, an OID can be compared to an IP address, where an IP address globally identifies a computer system and an OID globally identifies a piece of data.

Unfortunately, there is no good OID equivalent of private IP address space, which would be useful for ad hoc or site-specific data. The best available compromise is to register (http://pen.iana.org/pen/PenApplication.page) for a Private Enterprise Number with IANA, which will give you a dedicated OID prefix for private use. Luckily, such registration is free and with few questions asked. There have been some efforts to create a private range similar to that found in IP. However, such efforts have been unsuccessful. Despite the lack of a truly free/private OID space for experimental or internal use, SNMP remains a useful analogy to make when considering the standardization of an agent. It describes the format and packaging of a set of data—data that is easily found and identified using their unique OIDs—and how that data can be transmitted and understood from one system to another.

In the Meantime?

While there have been several developments in zero trust networks in recent years, and standard bodies such as National Institute of Standards and Technology (NIST) and others have issued architecture guidance, agent standardization remains primarily an implementation task. In the meantime, agents take the form of least resistance, given the needs of the implementor. Whether it be a JSON blob, signed and encrypted JSON Web Token (JWT), Protocol Buffers,FlatBuffers, or a any other custom binary format, it is recommended to ensure that the data contained within it be flexible and easily extensible. Loose typing or no typing should be preferred over strong typing, as the latter will make introducing new data and systems more difficult. Pluggable design patterns may help in moving to a standardized agent in the future. However, this is far from required, and should not be pursued if they impede the adoption of agent authorization in your network.

The following is an illustration of a possible JSON that carries an agent information.

{
  "iss": "Wayne Corporation ",
  "iat": 1676938201,
  "exp": 1708474201,
  "aud": "APP01091",
  "sub": "[email protected]",
  "given_name": "Bob",
  "email": "[email protected]",
  "assigned_roles": [
    "Manager",
    "Project Administrator"
  ],
  "device_id": "D98VCVQ3JMBH",
  "device_patched": "yes",
  "device_os_version": "13.2 (22D49)",
  "device_os_type": "MacOS",
  "user_id": "UID1233",
  "user_location": "Dallas,TX",
  "user_ip_address": "1.2.3.4",
  "user_auth_method": "X.509",
  "trust_score": "7"
}

Once signed and encoded, the JSON from above yields a JWT token that looks like the one below. Any common JWT decoder will work to decode it. For instance, by pasting the encoded token into website like https://jwt.io , you can decode its content online. Note that you can also encrypt the token, though the example omits this step for clarity.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJXYXluZSBDb3Jwb3JhdGlvbiAiLCJpYXQiOjE2NzY5MzgyMDEsImV4cCI6MTcwODQ3NDIwMSwiYXVkIjoiQVBQMDEwOTEiLCJzdWIiOiJib2JAd2F5bmVjb3JwLmNvbSIsImdpdmVuX25hbWUiOiJCb2IiLCJlbWFpbCI6ImJvYkB3YXluZWNvcnAuY29tIiwicm9sZSI6WyJNYW5hZ2VyIiwiUHJvamVjdCBBZG1pbmlzdHJhdG9yIl0sImRldmljZV9pZCI6IkQ5OFZDVlEzSk1CSCIsImRldmljZV9wYXRjaGVkIjoieWVzIiwiZGV2aWNlX29zX3ZlcnNpb24iOiIxMy4yICgyMkQ0OSkiLCJkZXZpY2Vfb3NfdHlwZSI6Ik1hY09TIiwidXNlcl9pZCI6IlVJRDEyMzMiLCJ1c2VyX2xvY2F0aW9uIjoiRGFsbGFzLFRYIiwidXNlcl9pcF9hZGRyZXNzIjoiMS4yLjMuNCIsInVzZXJfYXV0aF9tZXRob2QiOiJYLjUwOSIsInRydXN0X3Njb3JlIjoiNyJ9.eSE9Onzyb3s_WGGi5kE2eaH5h8KVCSlOcCoNeWMWwOE

Protocol buffers, as shown below, are another popular cross-platform mechanism for serializing structural data that can be used to represent agent information. Look at the protocol buffers message definition of an agent below stored in the “agent.proto” file. The protocol buffers message definition needs to be stored with .proto file extension.

syntax = "proto3";
package waynecorp.agent;
import "google/protobuf/timestamp.proto";
message Agent {
    string device_id=1;
    bool device_patched=2;
    string device_os_version=3;
    string device_os_type=4;
    string user_id=5;
    string given_name = 6;
    string email=7;
    string user_location=8;
    string user_ip_address=9;
    string user_auth_method=10;
    int32 trust_score=11;
    string iss=12;
    string aud=13;
    google.protobuf.Timestamp iat=14;
    google.protobuf.Timestamp exp=15;
    repeated Role assigned_roles=16;
    message Role{
        string role_name=1;
    }
}

After the message definition is created, the required code artifacts are created using the targeted platform of choice, in this case Python (but all major platforms are supported). For example, the following command generates the code artifacts required to both persist data (serialization) and read/prase data (deserialization) for the agent defined above.

protoc -I=. --python_out=. ./agent.proto 

The command above generates the “agent pb2.py” Python file, which you can use to create an agent object, and use methods to persist it to the file, and read it back as shown in the sample code below. For more information about the methods please review the the Python reference for protocol buffers.

import agent_pb2 as agent_v1
agent = agent_v1.Agent()
# Not all fields are set for brevity
agent.iss = "Wayne Corporation"
agent.aud="APP01091"
agent.user_id="UID1233"
# Seralize the agent as string
agent_obj = agent.SerializeToString()
print(agent_obj)
# Write the agent back to disk.
with open("agent.bin","wb") as f:
   f.write(agent.SerializeToString())
# Read the agent back from disk
with open("agent.bin", "rb") as f:
   agent_from_file = agent_v1.Agent()
   agent_from_file.ParseFromString(f.read())