Ensure the inventory records the network address (if static), hardware address, machine name, enterprise asset owner, department for each asset, and whether the asset has been approved to connect to the network.

As crazy as it sounds, a long list of IPs and MACs isn’t gonna help anybody. Your Inventory needs useful information about each thing in it.

CIS used to have this requirement split out into its own idea - CIS 1.5. While I’ve updated these articles to match the latest CIS v8, the topic is still big enough to warrant its own article.
I differ slightly from CIS in the recommended fields, but the intent is the same: provide a profile to people who don’t know about the thing and need a picture in a hurry. A security incident responder will find it really helpful to know whether the thing they found spitting out spam and intrusion attempts last night is a critical app server, a manufacturing floor timeclock, or some Alexa-enabled See-n-Say their CMO plugged in.

see-n-say from the 80s

  • Address: how to get to the thing. This could be a URI, DNS name, lpar, container, or IP address
  • Owner: who is accountable for the security and health of the thing. Optional bonus: the team that supports it.
  • Active: is it on? Usually maintained by the discovery tools (CSC 1.1-1.3). Optional bonus: last-alive datestamp.
  • Authorized: has this thing been vetted? Is it supposed to be here? A future post on standard processes such as triage will explain why this is important.
  • Membership: hierarchy data describing if this thing is part of or contains other things (think databases as part of an overall application, or maybe a single host within a cluster). Can sometimes contain host/membership information: this VM sits in that cluster. 
  • Scariness rating: usually called “Inherent Risk” by GRC wonksor “Priority” by everyone else, this helps everyone understand how important this thing is. Don’t go overboard; choose maybe 3-5 choices. Optional bonus: list availability and data scariness ratings separately.
  • Type: some kind of descriptive labels breaking down types of assets. Common options include:
    • hosted application
    • SaaS application
    • PaaS compute instance
    • bare metal server
    • VM
    • user laptop
    • phone
    • network switch
    • kiosk workstation
    • IoT device
    • Cluster
    • container
    • database
  • Environment: is it prod, test, or dev?

You and your customers will think of more fields that will be helpful for some use cases. A word of warning: you can go crazy with this. Don’t do that.

Start small and lean. The more fields you require someone to fill out, the more likely they are to avoid doing it. As I’ve discussed previously: do not underestimate people’s creativity in avoiding your process. IT Department project graveyards are full of overbuilt forms that capture information for every possible scenario. You’ll get the best engagement if you accurately explain to everyone the value of filling out your form.

There’s a very good chance that other governance teams will try to add their priorities to your inventory when they see that you’ve built something accurate. Examples include license management teams, desktop and server engineering teams, and support teams of all sorts. Odds are good that they will try to destroy what you’ve built because they don’t understand how you made it successful, and they just see you as a vehicle for accomplishing their goals. The most common way this happens is by increasing the “required fields” in the governance form. This heavy-handed approach will dissuade your customers from keeping it accurate because they don’t see the value in manually typing in every piece of software and its minor version number, so they’ll skip the whole thing, and you both lose.

There are tremendous advantages to maintaining a common inventory that serves multiple teams - this is the idea of Master Data Management, after all. By combining resources or influence, your teams can create a better one than any of you indidually. The balancing act is to ensure no one team’s priorities make it useless to the other customers else. You must remain vigilant - good metrics about your list will be the canary that indicates that people have started to resent it. One of the benefits of pushing the ownership of your Inventory onto a data team is that often they can be the reasonable voice of quality on your behalf, allowing you to speak to only yoursecurity priorities.

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