Back
IT Asset Management – Where to Start
Not enough emphasis is given to IT asset management. This is one of the first things an organization needs to get under control before they can really implement any security program. Yet few people do it well, if at all. How can you possibly protect an environment if you don’t know what assets make up that environment?
Lets quickly define what I mean by “IT asset.” An asset can be any computer, server, network device, application, database, archive of uncompiled code, or whatever that has monetary or perceived value to the business. It’s easy to justify why a piece of hardware or software is an asset, as there is a direct cost involved with procurement, management, and maintenance. You also depreciate your hardware investments in your accounting books, so even those with the checkbooks are acutely aware of hardware costs and value. The not-so-obvious items are web applications and databases. Some disagree that a database is an “asset” but what if that database contains your entire customer list? Isn’t that important to the business? Essentially, if your IT department spends time working on, fixing, installing, or maintaining it as a part of their day-to-day duties, it’s probably an asset.
There are some very basic questions you should be able to answer with a high level of precision about your assets and, if you can’t, IT assets aren’t being managed properly in your organization.
Let me give you an example:
- How many physical servers do you have?
- How many laptops does the business own?
- When were assets purchased?
- How many servers are physical vs. virtual?
- What operating systems are your systems running (and what are their patch levels)?
- What MAC addresses are assigned to each system?
- Who owns each server? How do you get ahold of them? Who is the second point of contact if they’re not available?
- How many web applications do you have?
- How many licenses of Microsoft Office do you have?
- What is your total annual maintenance commitment for software?
- What is the circuit ID of your main Internet connection and what is the best number to call in case of an outage? (You don’t want to have to look through years of bills to try and identify this when your business is down.)
You should be able to answer all of those questions pretty quickly by looking at an IT asset management database. You don’t have to spend millions on the shiniest box with the prettiest light array. You can do an adequate job with a spreadsheet, SharePoint, and/or a home-grown application.
Here are some items you may find useful to track:
- AssetID
- Asset type: circuit, server, desktop, laptop, router, switch, web application, standalone application, database, SAN head, NAS head, disk shelf, firewall, bridge, thin WAP, thick WAP, wifi controller, other.
- Purchased from?
- Sales contact name
- Sales contact number
- Sales contact email
- Purchase date
- Purchase order number
- Purpose
- Physical location (Minneapolis, 511, rack 12, position 13-15)
- Unit cost
- Maintenance cost
- Deploy date
- Retirement date / lifecycle information
- Data classification
- Server classification
- Circuit ID
- Emergency contact name
- Emergency contact number
- Emergency contact email
- Service Level Agreement (SLA)
- Make
- Model
- PSU (single, dual, n+1, n+2, other)
- CPU
- Memory
- IP addresses associated
- Hostnames
- MAC addresses
- Operating system (very specific)
- Virtual/physical
- Physical host ID (another AssetID if virtual)
- Has virtual guests? (is a virtual host)
- Owner & contact info
- Secondary owner & contact info
- Upstream dependencies
- Downstream dependencies
- Hardware change history
- Software change history
- Failure history
- Patch history
- Notes
This is not exhaustive. It’s just meant to help organizations get an idea of where to start. The more specific and detailed your asset management database, the more sound the rest of your decisions will be when implementing and enforcing specific company policies. I also like a single database with version control for everything, so you only have a single location where you can find the answers you need. How you normalize your data is up to you, but I prefer a single table for everything. Obviously, if you have tens of millions of assets, this may not be reasonable.
From here you should also consider defining:
- How your organization is going to perform asset discovery;
- How you plan to capture the data to populate the database;
- How you plan to keep it up-to-date and verify the integrity of the data;
- Acceptable use of assets;
- Your organization’s official IT asset lifecycle for each major type of asset; and
- Data and server classification policies.
There are a ton of other policies you probably need to define here as well, but this discussion could quickly fill a library.
Get started today! You’ll find that this isn’t an easy project to get started with but, the sooner you get started and the more effort you put into the process, the easier things will get over time. If you need standards to lean on, have a look at section A.8 of the ISO/IEC 27001:2013 standard, and section 8 of the ISO/IEC 27002:2013 standard. ISO/IEC 27005 in section 8.2.2 helps identify assets your business should include in its risk assessment. PCI DSS version 3.0, requirement 2.4 requires “maintain an inventory of system components that are in scope for PCI.” Cataloging only PCI systems doesn’t seem to fulfill the spirit of the requirement, so I think it’s safe to say PCI requires IT asset management. Additionally requirement 12.2 states, “implement a risk-assessment that Identifies critical assets, threats, and vulnerabilities, and results in a formal risk assessment.” Risk assessments are not possible without first identifying the assets you need to protect. Consider management of all IT assets as a shadow requirement of becoming PCI compliant.
