What is an asset? A no-nonsense guide to asset management

I was recently at a financial services company who wanted to improve how assets are aligned with risks in their annual FFIEC risk assessment. In the kindest way possible, I asked, “how’s your asset inventory these days?” A look of frustration accompanied his reply: “What is an asset? An application, firewall, server? What is an application?!” 

I think we all have baggage around asset management because there isn’t a clear, concise definition. When you do define it, you find that most organizations under-invest in asset management processes. 

With this vaguely defined regulatory requirement sitting lower in priority over business initiatives, we enter a negative compliance cycle: 1) ignore the requirement, 2) get an audit finding, 3) conduct a fire drill to comply, and 4) go back to ignoring the requirement. 

Over the years, I’ve seen asset management operating as a well-managed service only a few times. Here’s my three-part breakdown of how these organizations successfully approached this requirement: 

1. Define assets. 
2. Formalize an IT service called Asset Management. 
3. Make difficult prioritization decisions. 

Part I: Defining assets, applications, and more  

Let’s start with authoritative glossary definitions. First up, FFIEC defines an asset as the following: 

“In computer security, a major application, general-support system, high-impact program, physical plant, mission-critical system, personnel, equipment, or a logically related group of systems. Source: NIST: CNSSI-4009” 

Um, okay. How about a definition for an application?  

Here’s how TOGAF defines an application: 

“Application: An operational IT system that supports business functions and services. For example, think of a payroll system. Applications utilize data and are supported by multiple technology components. However, they are distinct from the technology components that support the application itself.”   

It’s up to you to further define these concepts for your organization. Here are some of the best practices that I’ve seen: 

1. Embrace the high-level definition of asset, like the above.
   • Data: information that is consumed, stored, printed, or processed that can be classified per our data classification policy. 
   • Applications: An IT system that supports business functions and services. Applications may contain multiple interfaces or services that support a business function. This includes source code repositories for internally developed applications. 
   • IT infrastructure: This can be long or short depending on your organization. NIST defines IT infrastructure as the collection of hardware and software components that enable the essential characteristics of information technology systems.  This includes: 
     1. Hardware: This includes physical devices such as servers, computers, storage devices, routers, switches, and other network equipment.
     2. Software: The software layer encompasses operating systems, applications, databases, and middleware. 
     3. Networks: The interconnected communication pathways that allow data to flow between devices. 
     4. Data Centers: Facilities that house servers, storage, and networking equipment. 
     5. Cloud Services: Cloud infrastructure, which provides computing resources like processing power, storage, and networks on a pay-per-use basis. (Feel free to shorten this with a definition like, “hardware or software that processes, controls, transports, or stores data assets.”) 
2. Define “asset categories” to aid classification and inventory. Leverage a standard like NIST or TOGAF but be bold and narrow down the definition for your organization. As a guide, I like to ask myself: “is this something I can classify using our asset classification policy?” Asset categories may include: 
3. Define business impact classes, for example: 
   • High business impact: PII, other regulated data (PCI, Sox), and company confidential information. This class may also include attributes that affect the threat landscape e.g. Internet-facing. 
   • Medium: Internal communications. 
   • Low: Publicly available. 

Part II: Formalizing an IT service called Asset Management

  NIST defines asset management as “a systematic process that involves identifying, categorizing, and tracking an organization’s information assets.” (I’ll assume “categorizing” includes the task of classifying.) 

 In my view, asset management should be an IT Service that is included in your IT Service Catalog. 

1. Identify assets: Normally, IT is accountable for identifying assets with manual and automated processes.
   • Manual: Since application assets contain other asset categories, a manual process is needed to define and classify. IT may be accountable for the process, but business owners are often responsible for classifying the application. Mature asset management services will also link the Infrastructure Assets to the Application Asset to automate classification (i.e., if an application is High Impact, its infrastructure inherits the High Impact classification). 
   • Automated: IT is accountable for enumerating IT infrastructure. Cloud makes this easier, but tagging and labeling must be established to classify. On-premises assets can be enumerated using various asset identification tools. 
2. Categorize (and classify) assets: As noted above, meta data or labeling is required to enable manual and automated classification (i.e. if it’s internet-facing, then it’s High Impact).  
   • Use your architecture and/or governance process to codify asset categories and impact classification levels. This includes the meta data or tags that are needed to properly classify assets. In addition to business and IT owner, I like to include data classification level, business impact level (which may include recovery objectives), and relevant regulatory fields like PII, PCI, and SOX. For internally developed applications, include source code repository links.  
3. Track assets: Tracking separates the continuous compliance organizations from the firefighters who must stop supporting the business to address an audit finding.
   • Manual tracking: Since business owners need to identify and classify application assets, the best practice I’ve seen is an automated workflow to contact owners and verify that the asset still exists and is properly classified. This includes a workflow when the owners change or leave the organization.
   • Automated: As with manual tracking, automated tracking needs a closed-loop process to remove assets from the inventory when they’re no longer live on the network/cloud or when there’s a change in ownership. These exceptions require manual intervention but can be refined over time until they’re (hopefully) fully automated. For elastic IT assets, I prefer to label them and omit them from automated tracking. 

Part III: Making difficult decisions when business priorities shift away from asset management

All the above is great when your business is adequately resourced. What happens when business priorities shift resources away from the Asset Management Service? What I usually see is that CIOs will simply shift the resources. They are leaders supporting the business, and they won’t be rewarded for saying “no” because their Asset Management Service will grow stale (non-compliant). Under a couple of conditions, I think shifting resources is fine. These conditions are: 

1. When the leader communicates the change with IT and Information Security. 
2. When Information Security records the change in the risk register, which is then tracked and managed until the risk is either accepted or mitigated. 

Information Security can help manage the risk of inadequate asset management. Here’s my favorite metric: % difference of Information Security asset enumeration from IT Asset Management. 

In my experience, Information Security should have an independent asset enumeration service (some folks call this Attack Surface Management). It’s best to start with High Impact assets, such as those that are internet-facing, and then expand to all of Cloud and on-premises.  

A metric is only as good as its ability to drive decisions. Sharing this metric at the appropriate level of leadership is essential for managing the risk of an incident due to vulnerable unknown or misclassified assets. 

What are your favorite asset management practices?