SANS ISC: Asset Inventory: Do you have yours? - Internet Security | DShield

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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 http://crikeycon.com

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: https://www.sans.org/critical-security-controls/control/2
* Real or virtual (email, IM, fax or telegram now seem to be doorways too…)