Asset Categorization: Classification Logic and Taxonomy

Introduction

The Asset Categorization system is designed to automatically classify every asset in the network. Rather than relying on a single rule, the system uses a weighted hierarchy of multiple observations, ranging from machine learning models to API integrations, to assign a specific Type and Subtype to every asset.

This document outlines the operation of the classification engine and defines the standard taxonomy used for reporting and policy creation.

Categorization Engine: A Hierarchy of Experts

The classification logic is not a single algorithm but an Ensemble Hierarchy of Experts. Think of this as a committee where different "experts" analyze specific attributes of an asset to determine its identity.

The logic follows a "Last Man Standing" principle: decisions made in earlier steps (like the Base Prediction) can be overwritten by later steps (like Cloud Integrations or Manual Overrides).

How Assets Get Classified

The system evaluates multiple signals to determine the nature of an asset. These signals are processed in order of reliability—when a more authoritative source provides classification data, it takes precedence over less certain methods.

Classification Priority (highest to lowest):

1. Manual Classification: When a user or administrator explicitly sets an asset's type, that decision is final. This is the highest authority because humans understand context that automated systems cannot infer.

2. Cloud Provider Data: If the asset exists in AWS, Azure, or GCP, the cloud provider's API provides definitive identification. AWS knows with certainty that a resource is a Lambda function or an RDS database—this is more reliable than inferring from network behavior.

3. Pattern-matching Rules: Predefined pattern-matching logic for well-known asset signatures. For example, "Cisco IOS in the OS field indicates a networking asset" or "a Meraki MR model number indicates a wireless access point."

4. Operating System: The most reliable automated signal. When we detect a specific OS like "Windows Server 2019" or "Cisco IOS", we can confidently classify the asset. Generic operating systems (like "Linux" alone) are less conclusive and defer to other signals.

5. Asset Tags: Labels from third-party integrations (Armis, Claroty, Medigate) or internal tagging systems. Particularly valuable for specialized equipment, such as medical assets, where OS detection is often unavailable or proprietary.

6. Manufacturer: The asset manufacturer, derived from the network adapter's MAC address. Certain manufacturers produce specific asset types; for example, Axis Communications primarily manufactures security cameras, while Zebra Technologies specializes in barcode scanners.

7. Hostname Patterns: Semantic clues in the asset’s name. Organizations often follow naming conventions: "MBP" typically indicates a MacBook Pro, "VDI" suggests virtual desktop infrastructure.

8. Software Inventory: The installed software stack provides hints about the asset’s purpose. A machine running Redis Server is likely a database; one running Cisco Unity is likely a VoIP system.

9. Combined Feature Analysis: When no single signal is definitive, the system evaluates all available data together to make the most accurate classification possible. If confidence remains low, the asset is marked as needing review.

After determining the primary type, the system refines the subtype using additional context. For example, a "Server" is further classified as a Virtual Machine (VMware), Cloud Virtual Machine (Amazon/Azure/GCP), or Physical Server based on manufacturer and deployment indicators.

Asset Visibility: Understanding Data Quality

What Qualifies as "Poor Visibility"?

Poor visibility occurs when an asset lacks sufficient distinguishing characteristics for reliable categorization. Assets with poor visibility are marked as 'Unexamined' until they are enriched with better data.

The following conditions indicate poor visibility:

• Insufficient Identifying Information

• No operating system detected, or only a generic OS (like "Linux") without additional context

• No hostname, or hostname contains only an IP address

• No MAC address available to determine manufacturer

• No tags from third-party integrations or manual labeling

Conflicting Signals

When different data sources suggest contradictory classifications with no clear winner. For example, OS information suggests "Server" while hostname patterns suggest "Desktop", and no manufacturer data is available to break the tie.

Sparse Data

Assets where only minimal data is available, such as a generic Linux OS with no hostname, no tags, and no manufacturer information. These assets cannot be confidently classified and require enrichment.

Data Requirements for Categorization

What Data Enables Classification?

To successfully categorize an asset, the system needs at least one of the following:

Where Does This Data Come From?

Asset Tag Analysis for Asset Categorization

Asset tags are key-value labels that help classify assets. Tags follow a prefix: value format where the prefix indicates the source or category, and the value describes the asset.

Default Supported Prefixes

The following tag prefixes are automatically recognized:

Example Tags

Custom Tag Prefixes

Organizations using custom tagging conventions can request configuration of additional prefixes. Contact support to enable recognition of organization-specific tag formats.

Improving Categorization Coverage

To reduce the number of Poor Visibility/Low-Fidelity assets, focus on enriching data based on asset type:

For Servers and Desktops

• Deploy endpoint agents to collect OS, hostname, and software inventory

• Integrate with cloud providers (AWS, Azure, GCP) for cloud VM classification

• Enable SNMP for network asset discovery

For IoT, Medical, and OT Assets

• Configure asset tags in third-party security tools (Armis, Claroty, Medigate)

• Use manual tagging to classify specialized equipment

• Ensure network visibility to capture MAC addresses for manufacturer identification

For Cloud Assets

• Enable cloud connectors with appropriate API permissions

• Apply consistent resource tagging in cloud environments

• Configure account-level integrations for complete visibility into IAM and serverless resources

Asset Categorization: Samples by Type