Is hard. That’s it. Asset management is hard. Fucking hard is probably a more apt term. I have been brainstorming a better way to do this, but there really isn’t one. Every day new assets appear on the network: laptops, phones, tablets, smart crap, etc, etc. Here at RSA I have heard many vendors try to claim they can help cut down on the problem with this by using agent-less scanning, monitoring active directory queries, and simply tracking outgoing connections. None of these things work in my opinion.
A good asset management plan should have a few different components:
- Asset name and description
- Asset owner
- Asset purpose
- Asset lifetime
- Software inventory
These few things are actually pretty limited to server and desktop bases those. Perhaps that is a good way of thinking, though. Our networks today should be logically separated, VLANned. For instance a guest network is on a different subnet than the one our production databases run on. Same with mobile devices. Same with IoT devices. So perhaps the first step in developing an asset management program is defining what an asset is.
An asset is a deployed piece of infrastructure , whose business purpose is to further the needs of the organization.
An asset is a deployed piece of infrastructure: This is a purposeful statement that is meant to rule out devices that are coming and going. Those devices are not deployed, they are brought on and off at the will of the end user. Which is scary.
Whose business purpose: This is another purposeful statement to ensure that these assets have documented purposes and are not simply test machines left on for too long. If you have a test machine running in your network without a true purpose then it needs shut down. It is not purpose driven.
Further the needs of the organization: Everything the separate business units do should further the needs of the organization. This is more a verifying statement than purposeful, as an asset that is not furthering the needs of the business has no place in an inventory or in a business.
So after setting out a definition, inventorying becomes a little easier and narrows the scope to something more manageable for administrators and security operators.
Next comes the question of how do you track items inside of scope? An Excel sheet (tried this, and it wasn’t the best thing in the world!)? Purpose-built software? What about other tools? There are all sorts of pieces that can contain this information. Where you store this information should reflect the business purpose of keeping an asset inventory. AND the business processes that will rely on this list.
Business purpose: Keep track of assets. At the end of the day this tool is to minimize loss, not create a profit. Loss comes in the form of: theft, loss property, breached machines (this is a security blog remember?). The business process is auditing, and the tool should be able to be easily edited and referenced.
A deployed asset is going to be setup by an internal administrator, hopefully. This administrator should be responsible for deploying control software to the new asset. The control software itself should be able to notify stakeholders of new nodes. This can just be an email alert letting the security engineer know that a new node needs scanned.
If a team is using the Excel/Database method then someone has to manually update that sheet every time that an asset is added. This means time. It also means that whenever an asset is killed off, the sheet needs updated again. What will eventually happen is that the sheet is simply ‘trued up’ during audit periods. This will hurt the use case of the inventory, as users cannot quickly reference it for up to date information.
This is a hard problem for sure. It will take man hours, it will take dollars, and it will take a team willing to work through to develop a solid process.
Guided Security 