Mike Wills - The Official (ISC)2 SSCP CBK Reference

ISO 55000 provides extensive guidance for the proper management of physical assets, including buildings, facilities, and infrastructure elements such as electrical power, plumbing, and heating, ventilation, and air conditioning (HVAC) systems. COBIT5, from ISACA (previously known as the Information Systems Audit and Control Association, but now by its acronym only), is another framework of structured guidance for information systems and information asset management, which your organization may already be using.

Broadly speaking, an information systems asset is any element of a system for which it is useful to assess or estimate a value, a cost, and a loss or impact. The value should relate to the gains to the organization that can be realized through effective use of that asset. Costs should reflect all that was spent, including time and effort, to create or acquire, install, use, and maintain the asset. The loss or impact can reflect either the replacement cost, the decrease in value, or some other assessment of how damage, destruction, or degradation of the asset will affect the organization.

Nominally, an asset has one point of management: You manage a single server or you manage a data center, but two data centers integrated via a VPN connection supported by a third party is most likely easier to manage as a set of related assets.

At some point it is easier and more meaningful to track and manage a system as an asset but consider all of the replaceable bits and pieces of it as units or parts. Your network backbone, for example, may consist of high-capacity, redundant routing and switching elements tied together with fiber, cable, WiFi, or other media. As a system, it's useful to track it as an asset, while having a logically distinct inventory of its spare parts.

Information systems asset management starts with the asset inventory, which must completely and unambiguously identify every information systems element to be managed as an asset. The inventory should include hardware, firmware, software, virtual machine environments, cloud systems services, databases, websites, and the supporting documentation for end users and maintainers.

Having a current and complete inventory is the absolute bedrock for implementing and monitoring technical security controls.

Robust asset inventory tools and processes will also inform the organization of unauthorized assets. These may be unlicensed copies of software or uncontrolled devices, software, or systems used by employees, clients, or visitors that thus become parts of your system. They may also be elements of an intrusion in progress. Each of these situations could be risks to the overall safety, security, and reliability of your IT systems.

Note that almost any device that can attempt to access your networks or systems is an object to be inventoried, placed under configuration control, and incorporated into your access control systems' databases as an authenticated identity. Failing to tie these three processes together—and keep them tied together—leaves an unnecessary degree of access open to potential intruders.

Because of the size, complexity, and frequency of the task, an organization should use automated tools to assist in creating and maintaining the asset inventory. The tools should have awareness of all assets in the organization's enterprise and the ability to discover new assets introduced to the environment that have not been properly documented in the inventory. This data comes from either an asset management agent or a client installed on each asset or “baked in” to each system image. It can also be generated with various scanner and sensor tools, or, in the case of hosted or cloud assets, from a data feed or recurring report from the vendor (which may or may not be shared with clients, depending on the terms of their service-level agreements [SLAs] or terms of reference [TORs] with their clients).

An asset inventory tool should have a way to distinguish authorized devices and applications from unauthorized devices and an ability to send alerts when the latter are discovered. The tool should also collect and track individual asset details necessary for reporting, audits, risk management, and incident management. These details need to cover technical specifications, such as the following:

HardwareManufacturerModel numberSerial numberPhysical locationNumber and type of processorsMemory sizeNetwork interfaces and their MACs and IPsHostnameHypervisor, operating systems, containers, virtual images running on this devicePurchase date, warranty informationLast update dates (firmware, hypervisor, etc.)Asset usage metrics

SoftwarePublisherVersion number, service pack/hotfix number, and date of last updateDigital signatures on installation packagesLicense informationPurchase dateInstall date

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.

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.