In addition, operational security details should be collected, such as the type of data stored and processed on the asset, the asset classification and special handling requirements, the business processes or missions it supports, and the owner, administrators, end users, or user groups nominally authorized to use it, and their contact information.
There are of course many tools available that do these tasks or portions of these tasks. Most organizations already own many such tools. Consider the following:
An Active Directory or Lightweight Directory Access Protocol (LDAP) server can provide a large portion of this information.
Other integrated identity management and access control systems can provide some of this information and can be especially useful in identifying assets that aren't under management but are attached (or attempting to attach themselves) to your systems.
Vulnerability scanners, configuration scanners, and network mapping tools can find and provide basic information about all the hosts in the organization's IP ranges.
Tools that manage/track software licenses can perform a large portion of this task.
Data loss prevention (DLP) solutions typically have a discovery capability that can serve this purpose.
For gaps in their available tools, organizations can and do compensate with manual efforts, spreadsheets, and scripting to pull and tabulate asset data. Dedicated asset inventory tools usually provide this functionality and preclude the need for manual data pulls and tool integration.
Regardless of the tool or combination of tools used, there should be one the organization deems authoritative and final so that it can be referenced throughout the organization. The information in this tool needs to be definitive. This is the data source to trust if there is conflict between what other tools are reporting. This should also be the source used for official reports and other data requests, such as part of an audit.
Process Considerations
Let's now look at some inventory management best practices. First, the organization must define the authoritative inventory list or system of record and define the frequency with which the inventory should be refreshed or updated. In addition to the regular interval inventory updates, it is also a good practice to ensure that the inventory management system is updated, and its administrator notified when assets are installed, removed, or updated/changed in a significant way.
This can be accomplished in a different way for environments that make heavy use of virtualized components, including managed cloud service implementations. In these cases, use of automated tools to seek out, tabulate, and provision assets is often preferable; popular tools include Puppet, Chef, and Ansible.
For on-premises assets, it is often helpful to augment the inventory process with the use of geolocation information/geotags or the use of RFID inventory tags. This can increase the speed and accuracy of locating an asset, especially during an incident when time is critical.
Lifecycle (Hardware, Software, and Data)
Although some legacy systems may seem to be lasting forever, it's much more common that information systems assets of every kind have a useful economic life span, beyond which it is just not useful or cost-effective to continue to use it and keep it working. Once past that point, the asset should be disposed of safely, so as to terminate exposing the organization to any risks associated with keeping it or failing to care for it. The typical systems development lifecycle model (SDLC) can be applied to hardware, systems software, applications software, and data in all of its many forms; let's look at this from an asset manager's perspective:
The requirements phase identifies the key functional and physical performance needs that the system should meet and should link these to the organization's mission, goals, and objectives. When any of these change, the asset manager is one of the stakeholders who evaluates whether the asset is at or past its useful economic life.
During the design phase, the functional requirements are allocated to individual elements of the design; it's worth considering at this point whether these components of the total system should be tracked as assets by themselves versus tracking the system as a whole or as a single asset.
Development, integration, and acceptance testing quite often conclude with a list of identified discrepancies that must be tracked and managed. In effect, each open discrepancy at the time of systems acceptance is a lien on the overall value of the system (much as a mortgage or mechanic's lien on your home reduces the equity you would realize from selling your home). Tracking those discrepancies is a form of tracking residual risk.
Operational use presents an opportunity to appraise the value of the system; finding new uses for it increases its value to the organization as an asset, but if users find better, faster ways to do the same jobs instead, this in effect decreases the value of the asset.
Maintenance and upgrade actions can extend the useful life of the system while adding to its cost. This is also true for ongoing license payments, whether as per-seat or site-wide licenses for software use.
Retirement and safe disposal, and the costs associated with these, bring this particular asset's lifecycle and its asset management account to a closed state.
Disposal must deal with the issue of data remanence, which refers to information of any kind remaining in the memory, recording surfaces, physical configuration settings, software, firmware, or other forms. This applies to more than just the familiar disks, tapes, and thumb drives; all hardware devices have many different internal nooks and crannies through which live data flows during use. Old-fashioned cathode ray tube (CRT) displays risked having images burned into their display surfaces. Printers have been known to go to the scrap dealer with fragments of previously printed documents, or impressions on their printing drums and ribbons of what they last printed, still legible and visible. Printed documents may need to be shredded or pulped. As a complication, you may end up having to store these retired assets, at a secure location, while awaiting the time (and money) to have a proper zeroization, purge, or destruction of the element to prevent an unauthorized disclosure from happening.
Hardware Inventory
In many work environments, people and whole workgroups can move around within a large facility. People shift from one workstation to another or to larger (or smaller) spaces in another room or another building; some may even move to a different city or country or travel extensively. Hardware inventory needs to know logically and physically about each device, be it an endpoint, a server, a peripheral such as a printer or scanner or a removable storage device. Assuming for a moment that no MAC address spoofing or alteration is allowed, the identity of an individual device should remain constant; knowing that it's currently attached via a certain IP address and that it is (or is not) connecting through a VPN is part of knowing logically where it is. But…knowing physically what desk or tabletop, rack, room, building, or continent it's on (or in) can be problematic. It's prudent to avoid procedurally intensive ways to address this problem, as the German military found out a few years ago. They went from simply allowing their military and civilian staff to just pick up and move their desktop and laptop computers from office to office, as temporary shifts in duties arose, and instituted a work-order process as a way of capturing location information for their asset inventory. This added days of work as each move had to have a form filled in, which was sent to an approvals and dispatch center; then had to have a worker move the equipment; and finally have the form sent back to the user to sign off that the move was now complete. Attribute-based access control (ABAC) may be a smarter solution to such problems, although it may require endpoints that can be trusted to accurately report their physical location without end-user intervention.
I cannot overstress the need to know the physical location