Ambient Asset Management

Asset Management can be a time-consuming and disconnected process. As a result, Shadow IT resources slip through the gaps and threaten compliance objectives. Compliance objectives are more than box ticking, they affect brand, marketing, and sales. I present a simple solution to this: Ambient Asset Management.

One of the biggest barriers to asset management is the burden of updating multiple systems.  This is made even more complicated by autoscaling in Cloud environments.  A practical solution to this problem is to bake asset management into the deployment process.

In a single Public Cloud with tagging capabilities the CSP's tagging API can become your asset management system.  In a hybrid Cloud environment like the one I work with this is not going to work by itself.  This raises two concerns which will be familiar both to programmers and operations folks:

  1. Naming: how do we name resources? How do we prevent naming collisions?
  2. SSOT: Single Source of Truth: where do we store the tags?

Naming is tricky, but these names aren't for people so that simplifies the problem considerably.  Names not intended for people, but which are unique across environments are easily obtained via the use of UUIDs (Universally Unique Identifiers).  We can give every resource a UUID.  The really tricky bit is assuring a mapping from the UUID to the naming system of each underlying infrastructure whether it be a Public Cloud, Private Cloud, or bare metal servers. This requires some discipline, but physical servers are handleable via service tags or serial numbers and Public/Private Cloud instances are handleable by their instance IDs.  In some cases, the Public/Private Cloud instances already have UUIDs in which case we can use them directly.

SSOT is made easier by UUIDs, because it means there is an extremely slim chance of asset update conflicts.  Why does this matter?  Practically speaking you want your SSOT to be available in the event of an outage of a portion of your environment.  This requirement leads to having a highly-available, partition-tolerant (aka AP) data store.  Strong implementation candidates for this include Riak and Cassandra as they are proven multi-datacenter AP systems.  What is the consequence of AP?  Eventual consistency.  And eventual consistency necessitates either independent updates or conflict resolution strategies.  Independent updates are much easier and our UUIDs grant us those.

How would this work in practice?  When a resource is deployed, it would be assigned a UUID and information about its Name, Owner, Purpose, Location, and Foreign ID (the naming of the underlying system) would be stored as a DeploymentRecord item in the SSOT.  The results of periodic audits, possibly performed with a vulnerability scanner, would be stored as AuditRecord items.  The destruction or decommissioning of a resource would be tracked as a TerminationRecord.  The repurposing of a physical resource would be reflected as a TerminationRecord followed by a DeploymentRecord.  All records would have time stamps and could use Keyless Signature Infrastructure to provide tamper evidence.

With these records in place it is possible to get the entire history of every asset deployed since inception.  This greatly simplifies evidence gathering for audits.

This is not really a new concept, but I wanted to highlight how relatively straight-forward it is with automated deployment and DevOps.  Ambient Asset Management makes a fundamental pillar of audit compliance business as usual.