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

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.

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 for infrastructure elements such as servers, routers, switches, and such, to as detailed a level as possible. Precious time can be wasted during an incident response by having to search for which room, which rack, and which unit or position in the rack is the device that's been sending up alarms (preferably not sending up smoke signals). It's also especially important to note which power distribution panel or circuit breaker box serves each equipment rack or bay and which power conditioning systems feed which distribution panels or breaker boxes.

Software and firmware come in many different forms; almost without question, all of these forms should be under the right combination of configuration control, configuration management, and asset management. Between those three processes, you'll have a very good chance to know that all of your software elements:

Have been protected from unauthorized changes

Have had all required changes, patches, and updates correctly applied

Have had all outstanding discrepancy reports or change requests reviewed and dispositioned by the right set of stakeholders and managers

Where each element is, physically and logically, how it's being used, and whether or not it is up to date

You'll also know, for each software element, whose intellectual property it is and whether there are license terms associated with that ownership interest. For each license, you'll need to know the detailed terms and conditions that apply and whether they apply to all copies you've installed on any number of devices or to a specific maximum number of devices; the license may also restrict your ability to move an installed copy to another system. The license might be seat limited to a specific number of individual users or capacity limited to a maximum number of simultaneous users, maximum number of files or records, or other performance ceilings.

Many modern applications programs (and operating systems) facilitate this by using digital signatures in their installation processes so that each installed and licensed copy has a unique identifier that traces to the license identifier or key. Software license inventory management tools can easily poll systems on your network, find copies of the application in question, and interrogate that installation for its license and identifier information. This can also find unlicensed copies of software, which might be legitimate but have yet to activate and register their licenses or might be bootleg or unauthorized copies being used.