The CIS Controls (formerly known as the Critical Security Controls and the CIS Top 20) say the most important thing to do to secure your computers is to have a list of all your stuff.

They’re a little unclear by what this means and how it helps.

The title tries to be specific: “Inventory and Control of Hardware Assets." Per Merriam Webster, asset means an owned item of value. Even if we add “hardware,” this could include lots of things: pizza boxes, mice, cables, radios, floppy diskettes, CNC lathes, security cameras, and monitors.

This is not what CIS is after.


There are four big benefits to knowing what stuff you have.

  • Almost every subsequent CIS control relies on this inventory in some way.
  • All the subsequent controls that rely on this inventory need owners.
  • Security is only as strong as your weakest link. A complete inventory is the starting point to completely applying some control to your environment.
  • You want to know when new things show up on the network.

With these goals in mind, it’s clear that your inventory shouldn’t just have hardware assets – it should have everything that could be broken into.

Some may argue that at its core, all computing is actually done on physical hardware, so maybe it’s enough to only track those. This is a bad plan; here are three examples:

  • Containering - If an application is containered and moving around on nodes in a cluster with 30 other containered apps, it’s not very helpful to say that one of the physical nodes had an out-of-date version of Java last Thursday – the vulnerability was probably within the container, and should be addressed by the container owner/publisher.
  • Virtualization - It’s not uncommon for a machine with a hypervisor to host hundreds of virtual machines, each with unique vulnerabilities.
  • Web hosting – a single webserver can host thousands of websites, and serves the correct one based on the url listed in an incoming request.

So what?

It is difficult to formulate a single explanation describing all and only the things that should be in your inventory.

Prioritizing our asset inventory by the capabilities that need it can help narrow things down. Most of those processes depend on two pieces of information about each asset:

  • Where to find it (“address”)
  • Who can fix problems on it (“owner”)

Those processes also don’t care much about components – mice and monitors and northbridges and cables.

What counts?

In our age of layered computing abstractions, what does it mean to “act like a computer”?

Coupled with the above priorities, we get:

A thing that stores and processes data accessible from a primary address and accountable to a single unique person.

It doesn’t really matter how you define “thing” – owner is often the best place to start.

There are some good rules of thumb.


Ownership can also get complicated. Often teams will divide computings by layer:

  • Bob and his team might own an ESX cluster and its component rackmounts and SAN.
  • Jane and her team manage the 10 Linux VMs (all hosted on Bob’s cluster)
  • Edith’s team develops and supports 4 JVMs hosted on 10 of those Linux VMs using Tomcat
  • Sanjay owns the reverse proxy, caching server, and WAF that present those web applications at a public address (all hosted on Bob’s cluster).
  • Gloria manages the customer service team that help the Sales Reps and customers that use a CRM hosted by each of the IT teams above.
  • Chad is the Executive VP of Sales, sponsored the CRM buildout, and manages the sales team.

Who “owns” the resulting CRM application or overall capability it helps deliver?

Many security teams will ignore the way teams have organized ownership and blindly assign security problems to those who maintain the bottom or top of the stack. Security teams need to educate themselves on how their IT customers organize themselves and engage them only in areas they can affect.

If devices have never had an owner, it usually means that ownership doesn’t take a lot of time, which means that it’s not a big deal to assign someone to it.  Across the whole organization, there’s no downside to assigning owners.  When deciding who should own something, err on the side of lower on the totem pole.  If an IP clock is assigned to the CIO, there’s no way that CIO will practically do anything to manage it.  

Assigning ownership can reduce blind spots in an organization.

See other posts for detailed techniques to build and maintain an accurate and dependable Inventory of IT Stuff, including: