CSC 1.5: Useful Information

Ensure that the hardware asset inventory records the network address, hardware address, machine name, data asset owner, and department for each asset and whether the hardware asset has been approved to connect to the network. Ensure that the hardware asset inventory records the network address, hardware address, machine name, data asset owner, and department for each asset and whether the hardware 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.

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.

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