Have you tried implementing Zero Trust in your organisation, but the Proof of Concept (PoC) revealed that it would take too much time or financial cost to integrate all the required systems, or found that some legacy systems couldn’t be integrated due to not having the required API interfaces? If the above sounds familiar to you then read on, because in this article I aim to break down the problem and propose a solution.

Zero Trust has become a very popular buzzword in cybersecurity circles. This is because it doesn’t just promise, but truly delivers, a high level of security with a comparatively low maintenance cost. However, many companies, despite being desperately interested and repeatedly throwing money at Proof-of-Concept projects, are struggling to adopt it.

The main blockers I’ve personally witnessed (or read about) tend to be implementation project cost (both financial and time) and inability to integrate to legacy systems. But what if I told you the blockers are caused by trying to implement Zero Trust in the wrong “order”? Like putting the cart before the horse.

All implementation attempts I’ve witnessed start the project with a focus on Identity and Access Management (IdAM). While IdAM is an important component, it ignores the critical need for “Asset State Management” (a term I coined to differentiate the next stage evolution of Asset Management), which is the glue that holds Zero Trust together. Attempting to start anywhere else results in overcomplicating asset management to such a point that it sabotages the future success of the project. So let me take you through the journey of setting up the cornerstone of Zero Trust and explain how it kick-starts a chain reaction that inevitably leads into it and even more. 

Convergence of Asset Management and SIEM

Most experienced IT Practitioners would be familiar with the concept of Configuration Management Database CMDB or at least with Asset Management as a whole. The benefits of a repository to keep track of your assets are self-explanatory, but the flashbacks of failed implementation attempts are traumatic enough to give some of you panic attacks.

For multiple reasons CMDB solutions just failed to materialise the promised benefits and problems multiplied as cloud, agile and ephemeral workloads sped up the rate of environment change, causing interest in this area to dry up, as demonstrated by this Google trends graph. The drought of investment caused by the lack of interest resulted in relevant innovation emerging from other business functions, such as SIEM and log management.

SIEM tools, once being siloed like CMDBs, evolved into modular systems which leverage COTS components for cutting-edge features. An example of this is the ability to integrate directly into a centralised data lake, rather than extract security logs directly from endpoint assets and store them in a siloed SIEM-dedicated repository. In modern times, SIEM isn’t a “tool” but rather a specific configuration of COTS dashboards, querying tools and data lakes.

Over time, CMDBs adopted these innovations but, unlike SIEM, the processes built around it have not evolved at the same pace. Most significantly of all, while SIEM processes - by necessity - have adapted to leverage real-time data, CMDB functions still update too slowly or focus primarily on the more “static” attributes of assets. CMDBs are not yet leveraging logs as a means of real-time discovery, data aggregation and correlation. Zero Trust requires an evolution to asset management. This leads us back to the term “Asset State Management”.

Original Asset Management focused on static Asset attributes, CMDB evolved out of the need to monitor changes to configurable elements of assets, while Zero Trust requires monitoring of ephemeral attributes and real-time runtime context. For example: Who is currently logged on to this device? What processes are currently running on this container? What anti-virus version is currently running on this device?

This requirement pushes Asset Management to evolve to its next stage, the ability to monitor all attributes of an asset – no matter how ephemeral – something which could be described as its “Runtime State”. Hence the term Asset State Management was born, which is not to be confused with the “state” attribute, but rather is used to describe the unique configuration of all attributes combined pertaining to an asset at any given point of time.

Imagine a world where CMDBs obtained its information from ALL tools deployed in your environment, and updated the repository in real time and could provide a hyper-granular change history for every single asset. This is possible if SIEM and CMDB utilise a shared data lake.

A new application gets installed on a device: the CMDB updates in real time; a user logs onto a server: the CMDB updates in real time. This evolution means asset management is given the technical ability to monitor all ephemeral attributes of an asset, its “State”. Information about an asset can be correlated using identifiable data (i.e. IP address, hostname, fingerprint ID etc…) to aggregate information from every system and application that is feeding the data lake. This approach applies SIEM processes onto the age-old asset management function. The old risk of outdated or corrupt CMDB disappears, and the discovery of shadow IT becomes the norm. The ability to leverage value from such a system is limited only by the organisation’s creativity in querying the information.

Evolving Asset Management for Zero Trust

The benefits of this asset management evolution for Zero Trust emerge primarily from two principles: Centralisation & Granularity.

The benefits of centralisation are somewhat self-evident and benefit more than just Zero Trust. Security experts have been shouting about the need and benefit of a “single pane of glass” for many years now. It also means that all your tools only need to integrate into a single point (the data lake) rather than having to create a map of all the complex integration relationships across your whole environment. Configuring Zero Trust is so much simpler when all the information you need is a query away, instead of having to jump into various portals and systems to gather and correlate information.

Granularity, however, is why asset management is the cornerstone of Zero Trust.

The more granular the information at your fingertips, the smaller the implicit trust zone you can create. In other words: the more granularity available to you, the lower the privilege that can be granted – really evolving “least-privilege” to the next level. The only way for a Policy Decision Point (PDP) to temporarily authorise an application to run as single function from a specified virtual machine, using an ephemeral account, on a remote database is by being able to access controls that are equally as granular - and validate the effectiveness of the control through logs which are just as granular. The old asset management paradigm would struggle with this need for granularity, due to usually containing a very limited amount of information, and by having a very limited definition of “asset”.

In this new paradigm everything is an asset. Ok, maybe that’s hyperbole - but anything that has attributes is an asset, especially those with changeable attributes. In some instances, an asset can itself be an attribute of another asset.

For example: 

1. Accounts are assets, Applications are assets, IP addresses are assets, IP Subnet ranges are assets, Configuration objects are assets, Devices are assets, Documents/Files are assets etc…

2. Device asset A has IP address of 192.168.1.1. That IP address is both an attribute of Device A and an asset in its own right.

This granularity in asset management is a necessity to apply attribute-based access controls (ABAC) required for Zero Trust, and trying to implement it without this granularity will have you jumping across network controls, application controls, user controls and more just to imitate it.

By combining this granularity with centralisation, you enable the emergence of a capability the industry has called “Policy as Code”, which is exactly how a Policy Engine as defined by NIST SP 800-207 functions.

The granularity allows organisations to truly define all compliance rules as a query code without any blind spots; the centralisation means all the required information for decision making is in the same location as the policy engine, thus simplifying the automation of compliance monitoring & orchestration. The possibilities are limited only by your creativity to query the data within.

Operationalizing Zero Trust & More

So now you have defined your security policy and compliance policies as queries against the data lake. What’s next? How do you operationalise it?

Here I take another page from the SOC playbook and embed Zero Trust compliance into the Incident Response process. By translating the architecture into a set of compliance rules (software defined architecture), the rules can be translated into policy as code.

Any asset whose state or configuration is not compliant with the policy can be handled as an incident. For bonus points, you could also treat vulnerabilities as attributes of assets that are assessed for compliance.

Given the data lake is already integrated to SOC systems, this should require no additional effort. Policy as Code may even enable the automation of checking Zero Trust compliance during change management, if all proposed changes can be written as code.

This paradigm change also enables automation of certain risk management processes (Identified risks are assets, the data lake is your risk register), vulnerability management (vulnerabilities are assets in your data lake and get mapped to each affected asset), attack path/surface mapping (network controls, IAM controls and vulnerabilities in the data lake can be mapped to display viable attack paths). By applying pseudo-quantitative values to the risks and vulnerabilities, assigning criticality and sensitivity attributes to the assets one could automate the calculation of risk metrics that can assist in risk-based decision making (defined as “Trust Algorithm” by NIST), and expose the risk posture of all parts of the organisation. Treating documents as assets and using logs to monitor all interactions associated with any managed documents via this data lake also enables Data Centric Security (DCS) and Data Loss Prevention (DLP). A real one stop shop for all your company’s security operation needs.

As you’ve read, operationalising Zero Trust is the inevitable outcome of applying the SIEM paradigm to asset management thanks to shared synergies. Implementing Zero Trust without a solid asset management solution will leave you feeling like you’re lost in a labyrinth.

So, if you’d like your own Cybersecurity Virgil, contact Nexor to kickstart an epic journey into a more cybersecure world.

If you’d like to learn more about cybersecurity, our blogs offer a wealth of information at your fingertips.