Asset Inventory: Do you have yours?

Published: 2015-02-01
Last Updated: 2015-02-02 00:01:56 UTC
by Chris Mohan (Version: 1)
13 comment(s)

The year is hardly a month old and we have people racing around as if their hair is on fire, demanding to know if the GLibc vulnerability CVE-2015-0235 (aka GHOST) [1] affects them. It’s a reasonable certainty that this won’t be the only time this year someone will be hammering on your door* wanting answers. And they want them now.

It’s a fair question, given the impact certain vulnerabilities can have, but seemingly a large percentage of businesses can’t immediately answer this. This is the part that doesn’t make much sense. Knowing what software you have and which system it inhabits should be a basic business requirement, which is supported by IT[2]. Whether it be in a fancy cloud-based database or a simple spreadsheet (CSV format even) this information should be up to date and easily accessible. 

This leads to another question; shouldn’t someone in the IT team/group/department/dark room in the basement know this already? Why are they asking the security team? Odd, isn’t it, when a problem pops today and it’s something to do with “security”, the expectation is that the security team should know the answer? Perhaps that a simple testament to how good you are getting answers, or, more likely you’re the most logical person to ask. (Well, it is an IT security problem, that nice media story/article/tweet has said so...). It becomes pretty easy to do the wrong thing here and play politics here by pointing fingers and blaming someone else. So how to avoid get in this mess in the first place?

An up to date and complete asset list is worth its weight in gold for numerous folk with in a company, so if the nice people in Audit and Compliance are maintaining it, it’s time to make new friends. If one doesn’t exist, then go meet with the people that can help create one and show them the value of doing this. You have to show the value to them and understand their perspective as this can be a lot of work to keep current. Getting others to build and maintain the asset inventory because they see value and actual use in it avoids the “Because my boss is making me do it” loathing issue. Anytime someone fails to understand or realise the value of an asset inventory, it then becomes the last thing on a very long “to do” list. This means it never gets properly completed or updated, and we’re back to the same problem again.

Socializing security requirements is about building a community of people that understand and ultimately care about being part of a more secure working environment. It’s about talking to your workmates and explaining helping you out with something as simple as an asset inventory, can be good for the whole company. And what’s good for the company, is good for them. 

So the next time someone bursts through your door, wide eyed and panting over today’s wittily titled vulnerability, you’ll be able to give them the definitive answer. Then you can drop in “this wouldn’t be possible without the help of…” and give those other folks their due credit too.

The basics for an asset inventory lists are straight forward, it needs: what is it, where is it, who owns it and what’s on it. This will get answer most of the basic questions or provide a starting point to initiate more in-depth and complex questions with the right system owners. Basic asset inventories won’t give you the answer to how many systems are vulnerable to something like CVE-2015-0235, but it will show how many systems, and which systems, are potentially vulnerable. That’s a much better place to be.

Basic requirements of an asset Inventory data fields:

  • Make of the device
  • Model of the device
  • Serial Number of the device
  • Assigned asset tag number 
  • System Name (assigned host name)
  • System Owner (who is responsible for the asset, both business and technical contacts)
  • Physical Location
  • Operating System
  • OS version level
  • Function (apps web server
  • Network location (e.g. internal workstation LAN, DMZ, Protected Internal network, etc.)
  • Business criticality (e.g. Low, Medium, High, Critical) 

This is a very simple list and it has to be expanded dramatically to be useful to your business and needs. So go forth and inventory!

If you have any other suggestions or advice on getting a decent asset inventory in place and updated, please feel free to add a comment.


For the Australian Readers - Support your local Con - CrikeyCon is back!

CrikeyCon is on the Saturday,21st February and held in Brisbane, Australia. For more details go to


Chris Mohan --- Internet Storm Center Handler on Duty

[1] Critical GLibc Vulnerability CVE-2015-0235 (aka GHOST) 
[2] And is on most of the critical controls list, including:
* Real or virtual (email, IM, fax or telegram now seem to be doorways too…) 


13 comment(s)


IPs and MACs are also required.

This one is a real pain (as were heartbleed, shellshock) because of all the appliances running various versions of who-knows-what. They range from security appliances to the Internet radio folks installed in the kennel so the animals could hear music. A good inventory does help, but... keeping them isolated as best I can...
I would love a pointer to an unbiased discussion of what tools (freeware and commercial) address this need and how well they work in an enterprise setting.
Beyond a spreadsheet are their any applications that people prefer to use to help with inventory?
Some other things useful to add to your asset tracking tool are build notes (anything whoever setup the system thinks might be useful to an on-call), backup server (where do I go if I gotta recover from backups - at my $DAYJOB$ we have more than one backup server), and how to obtain remote console access (such as "IPMI:hostname" or "DRAC:IP" or whatever). We also note what sort of authentication the server uses (NIS:domain or LDAP:domain or LOCAL, etc).

If, like me, you're cheap and don't want to spend a boatload of cash for an asset tracking tool, OpenDNS can be turned into one that'll track whatever data you want pretty easily. We had a tool built with perl CGIs on top of a Sybase DB written by a long-gone ex-employee... which naturally broke when we needed it most. And using our LDAP servers to track assets turned out to be pretty easy. Plus I don't have to worry about inflicting some internally developed interface on the rest of the IT team - it's just LDAP. Don't like the interface? Find some other LDAP browser/editor - any one will do. :-)
Other useful and sometimes necessary information to gather includes:
System Admin (name, phone, location), Backup System Admin
System Type (Production, Test, Development, etc.)
IP address(es)
MAC address(es)
OS Service Pack
System Connectivity (Standalone, VLAN, Business Network, etc.)
In addition to Make, Model, SN, get the Manufacturer name
Software Inventory (Nessus plugin 20811 will reveal this list)
Vulnerability Scanning frequency (weekly, monthly, quarterly, etc.)
Vulnerability Patching frequency
Outage frequency and date
Yeah, one of the other nice things about using OpenLDAP for our asset tracking tool, was that server records could contain attributes that pointed right at a person's record in LDAP as the owner, or manager or emergency contact or whatever. So contact info (emails, phones, pagers, etc) was all readily available. And since it's just LDAP, it was pretty easy to bang out a script to automatically populate things like cpu cores, memory, OS/version, mac addresses, etc.

I didn't want to bury my tiny little embedded system acting as a web server in hits but I wrote up a page on how to use OpenLDAP to build an asset tracking tool for some friends of mine who were curious. I don't really want to post a URL here but if you google for OpenLDAP asset tracking you'll likely find it. :-)

If there's enough interest I might even make an updated page with details on using the new (faster) backend instead of BerkeleyDB or how to make OpenLDAP do "pass-thru auth" in case you want your asset tracking tool in one LDAP server but your authentication proxied to somewhere else (AD, kerberos, whatever)...
As long as we are dreaming...
How about documenting where and when the data or configuration for the device is backed up?
As long as we are dreaming...
How about documenting where and when the data or configuration for the device is backed up?
I've been using Open Audit for years. Open Source & Agentless, and works with all types of Operating Systems. So much better than thick client inventory alternatives like SMS & LanDESK!

Diary Archives