Specification for Asset 

Identification 1.1

John Wunder

Adam Halbardier

David Waltermire

NIST Interagency Report 7693
Specification for Asset Identification 1.1

John Wunder

Adam Halbardier

David Waltermire

C O M P U T E R S E C U R I T Y

Computer Security Division

Information Technology Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899-8930

June 2011

U.S. Department of Commerce

Gary Locke, Secretary

National Institute of Standards and Technology

Dr. Patrick D. Gallagher, Director

NIST Interagency Report 7693
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

ii

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation‟s 

measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of 

concept implementations, and technical analysis to advance the development and productive use of 

information technology. ITL‟s responsibilities include the development of technical, physical, 

administrative, and management standards and guidelines for the cost-effective security and privacy of 

sensitive unclassified information in Federal computer systems. This Interagency Report discusses ITL‟s 

research, guidance, and outreach efforts in computer security and its collaborative activities with industry, 

government, and academic organizations.

Certain commercial entities, equipment, or materials may be identified in this 

document in order to describe an experimental procedure or concept adequately. 

Such identification is not intended to imply recommendation or endorsement by the 

National Institute of Standards and Technology, nor is it intended to imply that the 

entities, materials, or equipment are necessarily the best available for the purpose.

National Institute of Standards and Technology Interagency Report 7693

36 pages (June 2011)
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

iii

Acknowledgments

The authors, John Wunder of The MITRE Corporation, Adam Halbardier of Booz Allen Hamilton, and 

David Waltermire of the National Institute of Standards and Technology (NIST) wish to thank their 

colleagues who reviewed drafts of this document and contributed to its technical content. The authors 

would like to acknowledge Paul Cichonski and Harold Booth of NIST, Karen Scarfone of Scarfone 

Cybersecurity, Joseph Wolfkiel of the Defense Information Systems Agency (DISA), Jim Ronayne of 

Varen Technologies, Gary Newman of Belarc, Gerard McGuire of The MITRE Corporation, and Mark 

Johnson of Booz Allen Hamilton for their keen and insightful assistance throughout the development of 

the document.

Abstract

Asset identification plays an important role in an organization‟s ability to quickly correlate different sets 

of information about assets. This specification provides the necessary constructs to uniquely identify 

assets based on known identifiers and/or known information about the assets. This specification describes 

the purpose of asset identification, a data model for identifying assets, methods for identifying assets, and 

guidance on how to use asset identification. It also identifies a number of known use cases for asset 

identification.

Trademark Information

CPE is a trademark of The MITRE Corporation.

All other registered trademarks or trademarks belong to their respective organizations.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

iv

Table of Contents

1. Introduction ...................................................................................................................... 1

1.1 Purpose and Scope...................................................................................................1

1.2 Audience ...................................................................................................................2

1.3 Document Structure ..................................................................................................2

1.4 Document Conventions .............................................................................................2

2. Terms and Abbreviations ................................................................................................ 3

2.1 Terms........................................................................................................................3

2.2 Acronyms ..................................................................................................................4

3. Relationship to Existing Standards and Specifications ................................................ 5

4. Conformance.................................................................................................................... 6

4.1 Product Conformance................................................................................................6

4.1.1 Consumers.................................................................................................... 6

4.1.2 Producers...................................................................................................... 6

5. Asset Identification Overview.......................................................................................... 7

5.1 Scope........................................................................................................................7

5.2 Core Specification and Extension Points ...................................................................7

5.3 Data Model Overview ................................................................................................7

5.3.1 Literal Identifiers............................................................................................ 8

5.3.2 Synthetic Identifiers....................................................................................... 8

5.3.3 Relationship Identifiers.................................................................................. 8

5.3.4 Extension Identifiers...................................................................................... 9

5.4 Providing Asset Identifications...................................................................................9

5.5 Consuming Asset Identifications................................................................................9

5.6 Matching....................................................................................................................9

5.7 Sample Correlation Workflow ....................................................................................9

6. Data Model.......................................................................................................................12

6.1 Abstract Elements ...................................................................................................12

6.2 Concrete Asset Elements ........................................................................................13

6.3 Helper Elements......................................................................................................18

6.4 Relating Assets to Other Assets ..............................................................................21

6.4.1 Relationship Data Model ..............................................................................21

6.4.2 Relationship Types.......................................................................................23

6.5 Guidance for Incorporating Asset Identification Elements into Other Data Models...25

Appendix A— Use Cases........................................................................................................26

A.1 Correlation of Sensed Data .....................................................................................26

A.2 Federation of Asset Databases ...............................................................................26

A.3 Directly Targeted Remediation Actions....................................................................26

A.4 Management of Asset Data .....................................................................................27

Appendix B— Extending the Asset Identification Specification..........................................28

B.1 Additional Asset Types............................................................................................28

B.2 Additional Literal Identifiers for Existing Asset Types...............................................28

B.3 Additional Relationships ..........................................................................................28
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

v

B.4 Additional Properties on Existing Data Elements.....................................................28

Appendix C— Normative References ....................................................................................29

List of Figures

Figure 5-1: Sample Correlation Workflow..................................................................................10

List of Tables

Table 1-1: Conventional XML Mappings..................................................................................... 2

Table 6-1: Element – ai:asset....................................................................................................13

Table 6-2: Element – ai:it-asset.................................................................................................13

Table 6-3: Element – ai:circuit...................................................................................................13

Table 6-4: Element – ai:computing-device ................................................................................14

Table 6-5: Element – ai:data .....................................................................................................14

Table 6-6: Element – ai:database..............................................................................................14

Table 6-7: Element – ai:network................................................................................................15

Table 6-8: Element – ai:organization.........................................................................................15

Table 6-9: Element – ai:person .................................................................................................16

Table 6-10: Element – ai:service...............................................................................................16

Table 6-11: Element – ai:software.............................................................................................17

Table 6-12: Element – ai:system...............................................................................................17

Table 6-13: Element – ai:website ..............................................................................................17

Table 6-14: Element – ai:synthetic-id ........................................................................................18

Table 6-15: Element – ai:connections .......................................................................................18

Table 6-16: Element – ai:connection.........................................................................................18

Table 6-17: Element – ai:locations ............................................................................................19

Table 6-18: Element – ai:location-point .....................................................................................19

Table 6-19: Element – ai:location-region...................................................................................20

Table 6-20: Element – ai:ip-net-range.......................................................................................20

Table 6-21: Element – ai:ip-address..........................................................................................20

Table 6-22: Element – ai:port-range..........................................................................................20

Table 6-23: Element – ai:host ...................................................................................................21

Table 6-24: Element – ai:cpe ....................................................................................................21
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

vi

Table 6-25: Element – ai:asset-related......................................................................................22

Table 6-26: Element – ai:assets................................................................................................22

Table 6-27: Element – core:relationships ..................................................................................22

Table 6-28: Element – core:relationship....................................................................................23

Table 6-29: Controlled Vocabulary Defined for Asset Identification ...........................................24
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

1

1. Introduction

One of the primary requirements for performing asset management is the ability to identify assets based 

on some set of data known about them. Asset identification, the use of attributes and methods to uniquely 

identify an asset, allows for correlation of data across multiple sources, reporting of asset information 

across different organizations and databases, targeted actions against specific assets, and usage of asset 

data in other business processes.

Unfortunately, neither a unified method nor a published specification for performing asset identification 

exists at this time. Existing security automation specifications either do not consider asset identification or 

represent identification information differently than other specifications with which they interoperate.

This means that correlation of data relies on a transformation process between each specification, which is 

expensive and unreliable. Creation of such a unified method and specification for performing asset 

identification would allow for greater interoperability, increased capabilities, and easier implementation 

of asset management processes.

This Asset Identification specification describes a framework for how asset management processes and 

other specifications may identify assets using some set of information known or generated about the asset. 

It describes the data model and representation of asset identification information and it provides 

requirements for consuming and producing identification information. Requirements for usage of asset 

information and requirements for how the information that identifies assets is collected or generated are 

out of scope for this specification.

For the purposes of this specification, an asset is considered to be anything that has value to an 

organization. For example, computing devices are one form of asset that many organizations track. This 

specification, however, does not limit asset identification to identifying computing devices; any type of 

asset may be identified. The specification itself provides constructs for identifying many types of assets, 

and users may extend the model to include other asset types if they wish to identify asset types that are 

not addressed in the specification. 

It is expected that other standards, data formats, tools, processes, and organizations will reference this 

specification to describe how to represent asset identification information. This will ensure compatibility 

of asset identifications among these components and allow for improved asset management processes.

While this specification was developed to support the immediate needs of the security automation 

community, it is expected that it will be valuable in general asset management processes both inside and 

outside of the security automation space.

1.1 Purpose and Scope

The purpose of this document is to define the Asset Identification specification, a standardized model for 

representing and identifying assets.

The scope of this document is to give an introduction to Asset Identification, give guidelines on using 

Asset Identification, describe the Asset Identification data model, and document conformance 

requirements to comply with Asset Identification. Other versions of Asset Identification and the 

associated component specifications, including emerging specifications and future versions, are not 

addressed here. 

Future versions of Asset Identification will be defined in distinct revisions of this document, each clearly 

labeled with a document revision number and the appropriate Asset Identification version number.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

2

1.2 Audience

This specification is intended for authors of specifications that must support asset identifications, 

implementers of those specifications, system integrators composing architectures from tools that 

implement those specifications, and end users who wish to understand how these tools work.

1.3 Document Structure

The remainder of this document is organized into the following major sections:

 Section 2 defines the terms used within this specification and provides a list of common 

abbreviations.

 Section 3 describes how this specification fits with related standards and specifications.

 Section 4 defines the conformance requirements for asset identification.

 Section 5 gives an overview of asset identification.

 Section 6 describes the asset identification data model constructs.

 Appendix A describes possible use cases for asset identification.

 Appendix B explains how the specification can be extended.

 Appendix C documents the normative references for this specification

1.4 Document Conventions

Throughout this specification, whenever a specific term from the data model is referenced, as defined in 

Section 6, the term is written in Courier New font. When referencing a specification listed in 

Appendix B, the name will be written between brackets, such as [XML Schema].

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, 

“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be 

interpreted as described in [RFC 2119].

Both inline and indented forms use qualified names to refer to specific XML elements. A qualified name 

associates a named element with a namespace. The namespace identifies the specific XML schema that 

defines (and consequently may be used to validate) the syntax of the element instance. A qualified name 

declares this schema to element association using the format „prefix:element-name‟. The association of 

prefix to namespace is defined in the metadata of an XML document and generally will vary from 

document to document. In this specification, the conventional mappings listed in Table 1-1 are used. 

Table 1-1: Conventional XML Mappings

Mappings Prefix Namespace URI Schema 

ai http://scap.nist.gov/schema/asset-identification/1.1 Asset Identification 1.1

core http://scap.nist.gov/schema/reporting-core/1.1 SCAP Reporting Core 1.1

cpe-name http://cpe.mitre.org/naming/2.0 CPE 2.3 Naming Specification

xal urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 OASIS extensible Address Language

xnl urn:oasis:names:tc:ciq:xsdschema:xNL:2.0 OASIS extensible Name Language
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

3

2. Terms and Abbreviations

2.1 Terms

This section defines a set of common terms used within the document.

Asset: Anything that has value to an organization, including, but not limited to, another organization, 

person, computing device, information technology (IT) system, IT network, IT circuit, software (both an 

installed instance and a physical instance), virtual computing platform (common in cloud and virtualized 

computing), and related hardware (e.g., locks, cabinets, keyboards).

Asset Identification: The use of attributes and methods to uniquely identify an asset.

Asset Identification Element: A complete, bound expression of an asset identification using the 

constructs defined in this specification.

Circuit: A dedicated single connection between two endpoints on a network.

Computing Device: A machine (real or virtual) for performing calculations automatically (including, but 

not limited to, computer, servers, routers, switches, etc.)

Data: Any piece of information suitable for use in a computer.

Database: A repository of information or data, which may or may not be a traditional relational database 

system.

Extension Identifier: Any piece of identifying information provided in an asset identification element 

that is not explicitly defined in the Asset Identification schema.

Identifying Information: The set of an asset‟s attributes that may be useful for identifying that asset, 

including discoverable information about the asset and identifiers assigned to the asset.

Matching: The process of determining whether two or more asset identification expressions refer to the 

same asset.

Network: An information system(s) implemented with a collection of interconnected components. Such 

components may include routers, hubs, cabling, telecommunications controllers, key distribution centers, 

and technical control devices.

Organization: An entity of any size, complexity, or positioning within an organizational structure (e.g., a 

federal agency, or, as appropriate, any of its operational elements).

Person: Any person considered as an asset by the management domain.

Relationship Identifier: Identifying information where the value is a relationship to another asset. 

Service: A set of related IT components provided in support of one or more business processes.

Software: Computer programs and associated data that may be dynamically written or modified during 

execution.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

4

System: A discrete set of information resources organized for the collection, processing, maintenance, 

use, sharing, dissemination, or disposition of information.

Synthetic Identifier: An identifier that is assigned to an asset in the context of some management 

domain.

Website: A set of related web pages that are prepared and maintained as a collection in support of a 

single purpose.

2.2 Acronyms

BIOS Basic Input/Output System

CIDR Classless Inter-Domain Routing

CPE Common Platform Enumeration

FQDN Fully-Qualified Domain Name

GUID Globally Unique Identifier

HTTP Hypertext Transfer Protocol

IETF Internet Engineering Task Force

IP Internet Protocol

IT Information Technology

ITL Information Technology Laboratory

MAC Media Access Control

NIST National Institute of Standards and Technology

OASIS Organization for the Advancement of Structured Information Standards

RFC Request for Comment

URI Uniform Resource Identifier

URL Uniform Resource Locator

W3C World Wide Web Consortium

WFN Well-Formed Name

xAL extensible Address Language

XML Extensible Markup Language

xNL extensible Naming Language

XSD XML Schema
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

5

3. Relationship to Existing Standards and Specifications

This specification defines the constructs and methods for representing asset identification information and 

thus can be leveraged by any other specification where identifying assets is required or beneficial.

This specification uses several industry-standard mechanisms for representing identification information 

and providing conformance requirements.

Common Platform Enumeration (CPE)TM is a structured naming scheme for information technology 

systems, platforms, and packages. Based upon the generic syntax for Uniform Resource Identifiers (URI), 

CPE includes a formal name format. CPE version 2.3 Well-Formed Names (WFN) are used as softwareidentifying information by this specification.

The extensible Address Language (xAL) by the Organization for the Advancement of Structured 

Information Standards (OASIS) is an XML standard format for representing international address 

information. Asset Identification leverages xAL to represent address information for assets.

The extensible Name Language (xNL) by OASIS is an XML standard format for representing the names 

of people and organizations. Asset Identification leverages xNL to represent the names of people and 

organizations.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

6

4. Conformance

A product may want to claim conformance with this specification so that users and organizations can use 

the product with the assurance that the product can identify assets in a consistent and standard manner. 

The ability for a product to identify assets in a standard manner increases the likelihood of interoperability 

between conforming products. This section defines the criteria for products to claim conformance with 

this specification.

4.1 Product Conformance

Products are divided into two roles based on their use of asset identification information: consumers and 

producers.

 Consuming products (“consumers”) must be able to receive and understand information in 

compliance with this specification. 

 Producing products (“producers”) must create asset identification information in a format 

compliant with this specification. 

A product may be both a consumer and producer. The following subsections document the conformance 

requirements for the two types of products.

4.1.1 Consumers

Any consuming product claiming conformance to this specification MUST adhere to the following 

requirements.

 The consumer SHALL be capable of processing the identification information represented in 

constructs consistent with the Asset Identification data model without error. REF: Section 6

 The consumer MAY attempt to consume constructs that are invalid per the Asset Identification 

data model. REF: Section 6

 The consumer MAY consume extension identifiers and use them as an input into a matching 

process. REF: Section 5.3.4

 The consumer MUST NOT abnormally end, crash, or otherwise be unable to fully process asset 

identification elements that include extension identifiers. It MAY ignore any information in 

extension identifiers.

4.1.2 Producers

Any producing product claiming conformance to this specification MUST adhere to the following 

requirements.

 The producer SHALL accurately produce the asset identification element in XML consistent with 

the data model. REF: Section 6

 When representing identification information, the producer SHOULD provide as much 

information as is sufficient to allow for a match. REF: Section 5.3

 When representing identification information, the producer MAY provide as much or as little 

identifying information as allowed in the data model per other recommendations or tool 

capabilities. REF: Section 5.3

 The producer MAY provide extension identifiers for any asset identification element. REF: 

Section 5.3.4
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

7

5. Asset Identification Overview

This section gives an overview of the Asset Identification specification and its key concepts.

5.1 Scope

In order to support the variety of use cases discussed in Appendix A, the scope of this specification is 

limited to a description of how asset management tools can represent asset identification information 

when communicating it to other tools. It is out of scope of this specification to recommend which 

identifiers to use or to require that identification information be collected in a certain way or from a 

certain place. Higher-level specifications, tools, and organizations that implement Asset Identification, 

however, are encouraged to make these recommendations or specify these requirements in order to 

support the particular needs of their use cases.

Additionally, the Asset Identification specification is not a mechanism for expressing information about 

an asset that is not related to asset identification. Only elements that are used for identification are 

included in the core specification. Asset Identification elements MUST NOT be used to represent 

information about an asset unless it is being used to identify that asset.

5.2 Core Specification and Extension Points

The core Asset Identification specification defines eleven asset types and definitions of how those asset 

types may be identified using a set of literal attributes and relationships to other assets. The core 

specification is intended to provide definitions for commonly used asset types and identification 

attributes; it is not intended to be an exhaustive list of all possible asset types and attributes that may be 

used for identification. Anything explicitly defined in the asset identification schema and the asset 

identification controlled vocabulary for relationship identifiers is considered part of the core specification.

There are several extension points in the Asset Identification data model to allow for identification of 

asset types beyond what is included in the core specification and to allow attributes or relationships 

outside of the core specification to be used to identify asset types that are included. These extension 

points are:

 Additional asset types may be created by inheriting from any concrete or abstract “asset” data 

element in the core XML schema.

 The core asset types may be enhanced by adding elements to the appropriate asset type as literal 

values in the “extended-information” element.

 Additional relationships can be defined by creating a separate vocabulary for relationship 

identifiers.

5.3 Data Model Overview

The Asset Identification data model consists of a set of asset types and a set of information that can be 

provided about each asset type. The asset types currently supported in this specification are:

 Person

 Organization

 System

 Software

 Database
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

8

 Network

 Service

 Data

 Computing Device

 Circuit

 Website

For the purposes of this specification the above asset types MUST be understood as defined in Section

2.1.

The specification MAY be extended by Asset Identification producers to allow for other asset types as 

needed; however, it is OPTIONAL for Asset Identification consumers to support asset types not present 

in the core specification.

For each asset type above, the specification has a core set of fields that may be provided in order to 

identify an asset of that type. For example, an asset of type “person” may be identified by an email 

address, full name, telephone number, or birth date. Any number of these fields may be populated in order 

to create an asset identification element. Specifications, management environments, organizations, and

tool vendors implementing Asset Identification are encouraged to recommend, restrict, or require that 

certain fields be populated or not populated; however, the specification itself does not do so.

There are several different types of information that may be used to identify assets: literal identifiers, 

relationship identifiers, synthetic identifiers, and extension identifiers. These four identifier types are 

differentiated only because they are represented differently in the data model. No identifier type is 

intrinsically more or less valuable for performing asset identification than any other identifier type.

5.3.1 Literal Identifiers

Literal identifiers are the pre-defined fields containing literal values that may identify an asset. For 

example, Media Access Control (MAC) address is an example of a literal identifier for a computing 

device. Literal identifiers defined in Asset Identification MUST be properly processed without error by 

Asset Identification consumers.

5.3.2 Synthetic Identifiers

Synthetic identifiers are meant to be used when a database or process assigns an identifier. For example, 

an employee is often assigned an employee identifier which may be used to track him or her across the 

organization. These identifiers should be represented using the synthetic identifier construct: the 

namespace denotes the management domain for which the identifier is valid and the identifier contains 

the identifier itself. Each asset type allows for a list of zero to many synthetic identifiers. Synthetic 

identifiers MUST be properly processed without error by Asset Identification consumers.

5.3.3 Relationship Identifiers

Relationship identifiers are meant to be used when an asset may be identified based on a relationship to 

another asset. For example, a system may be identified based on the fact that it is named “System 1” and 

it is connected to network “INTERNAL”. Relationship types are represented as a controlled vocabulary. 

Any relationships defined in the Asset Identification controlled vocabulary are core and MUST be 

processed without error by Asset Identification consumers. Relationships that are defined in other 

controlled vocabularies are considered extension identifiers and MAY be supported by Asset 

Identification consumers.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

9

5.3.4 Extension Identifiers

Although this specification intends to support the most common types of information that are used to 

identify assets, certain users, organizations, or use cases may find that the core model does not support 

some fields that they need. Asset Identification supports a producer‟s ability to provide these identifiers in 

any asset identification element through extension identifiers; however, it is OPTIONAL for consumers to 

process or understand these identifiers unless some other specification requires it. Extension identifiers 

may include additional literal values as well as relationship identifiers that are outside of the Asset 

Identification controlled vocabulary. Extension identifiers MUST be processed without error by 

consumers; however, consumers are encouraged to ignore identifying information that they do not 

understand and is not defined in the core schema, which ensures accurate correlation.

5.4 Providing Asset Identifications

In the absence of other guidance or requirements, Asset Identification providers SHOULD provide as 

much information as they have available in the core (non-extension) asset identification element. 

Bandwidth constraints, other specifications, and tool intelligence MAY help define how much or which 

information SHOULD be provided beyond this recommendation.

5.5 Consuming Asset Identifications

Asset Identification consumers MUST be able to process literal identifiers, synthetic identifiers, 

relationship identifiers, and extension identifiers without error. In this context, “process” simply means 

ingest without error and optionally use as an input in performing a matching. Asset Identification 

consumers SHOULD process literal identifiers, synthetic identifiers, and relationship identifiers and 

support incorporating them into a matching process. Asset Identification consumers SHOULD NOT 

incorporate unknown extended identifiers into a matching process as they may be misleading or 

misunderstood.

Extended identifiers that are defined in another specification or policy that the consumer implements 

MAY be supported as appropriate and as defined by that specification or policy.

5.6 Matching

Matching is the process of determining whether or not two or more asset identification elements are 

referring to the same asset. Matching is performed across an entire asset identification element, not across 

each individual property of an identifier.

Although matching identifiers is an important part of the asset identification process, due to a wide 

variety of current tool practices, organizational architectures, and the need to allow for innovation, this 

specification does not provide any normative requirements in regards to matching. Tools are free to 

perform matching based on their own logic, and specifications implementing asset identification are 

encouraged to provide their own recommendations or requirements around matching.

5.7 Sample Correlation Workflow

The diagram in Figure 5-1 shows a sample correlation workflow, including matching discoverable 

information and several synthetic identifiers.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

10

In this sample architecture, which is merely one example, several tools report on information about an 

asset. The information is correlated by an asset database, potentially processed or aggregated, and then 

reported to a higher-level database.

Figure 5-1: Sample Correlation Workflow

In step 1, a host-based scanner is reporting on asset information (e.g. vulnerability assessment results) 

using a synthetic identifier in its own namespace and an IP address as identifying information. 

Additionally, a network scanner is reporting on network events by IP address. This allows the asset 

database to correlate information coming from the network with information on the host, potentially 

matching vulnerabilities discovered by the host-based scanner with attacks against that vulnerability 

discovered by the network scanner.

In step 2, another host-based scanner (e.g., an asset inventory tool) reports data using both a synthetic 

identifier in its own namespace and a synthetic identifier in the first host-based tool's namespace. This 

other identifier may have been collected on the system or may have been discovered some other way;
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

11

how that collection happens is out of scope of this specification. By passing both identifiers, however, the 

scanner provides enough data to the asset database to correlate the additional inventory data with the 

vulnerability and event data. Additionally, any other data reported using either the IP address or the two 

synthetic identifiers will be able to be correlated as well. Note that this specification does not require or 

recommend that tools process identifiers in certain ways: for example, an IP address may become stale 

after a period of time, but it is out of scope for this specification to recommend how to deal with that.

In step 3, the asset database provides a report to a higher-level database. Depending on the reporting 

architecture, organizational hierarchy, and reporting requirements, asset databases may want to report on 

data with different sets of synthetic identifiers for each asset. This specification does not restrict or 

recommend architectures or workflows.

In the reporting architecture shown above, all known asset identifiers for each asset are being used to 

report information to the higher level. In this architecture, data provided by other tools to the higher-level 

database may be correlated with the reported data. Other options would be to only report some 

information to the higher-level database or even to generate a new synthetic identifier to perform 

reporting, depending on the reporting requirements and network architectures.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

12

6. Data Model

This section documents the data model for Asset Identification. The XML schema that implements this 

data model is provided separate from this specification.

The Asset Identification model is a fairly flat model that defines the constructs to hold identifying 

information about an asset. A limited number of asset types are defined for which model constructs exist. 

In order to use the Asset Identification model:

 The user SHOULD produce an XML ai:assets or ai:asset-related element consistent with the data 

model described in Section 6.4.1.

 The XML element produced MUST validate against the XML schema (XSD) for Asset 

Identification 1.1 at http://scap.nist.gov/specifications/ai/index.html. In situations where the XML 

schema does not match the documented model in this specification, the XSD takes precedence.

The following tables formalize the logical data model. The data contained in the tables are requirements 

and MUST be interpreted as follows:

 The “Element Name” field indicates the name for the entity being described.

 The “Definition” field indicates the prose description of the text. The field MAY contain 

requirement words as indicated in RFC 2119.

 The “Inherits” field indicates that the element takes on all of the properties of the inherited 

element in addition to the properties defined for the element.

 The “Properties” field is broken into four columns:

o The “Name” column indicates the name of a property that MAY or MUST be included in 

the described element in accordance with the cardinality indicated in the “Count” field.

o The “Type” column indicates the type of data that MUST be the value for the property. 

There are two categories of types: literal and element. A literal type will indicate the type 

of literal. The element type will reference the name of another element that defines the 

content for that property.

o The “Count” column indicates the cardinality of the property within the element. The 

property MUST be included in the element in accordance with the cardinality. If a range 

is given, and “n” is the upper-bound of the range, then the upper limit is unbounded.

o The “Definition” column defines the property in the context of the element. The field 

MAY contain requirement words as indicated in RFC 2119.

Each literal data element MAY have a “source” attribute associated with it. The source attribute is 

intended to capture the source of the information for that data element. The field SHALL be a string type, 

but the value of the field is left to the content producer. The value MAY include, but is not restricted to, a 

synthetic ID of the asset that sourced the information, another ID of the source, or a description of the 

source. See the XSD for additional clarity on the “source” attribute.

Each literal data element MAY have a “timestamp” attribute associated with it. If populated, the 

timestamp attribute indicates when the data was last known to be correct for that element.

6.1 Abstract Elements

The elements described in this section are the top-level abstract elements from which all asset elements 

derive.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

13

Table 6-1: Element – ai:asset

Element Name: ai:asset

Definition The root element from which all other asset elements derive. This element does not 

represent any specific type of asset, and therefore should only be used as a base class for 

other, concrete, asset elements. Any element that claims to be an asset element compliant 

with this specification SHALL directly or indirectly inherit all of the attributes in this 

element. The asset element SHALL NOT be used directly in an asset identification 

instance because it is abstract.

Properties Name Type Count Definition

synthetic-id element – synthetic-id 0-n Holds the synthetic ID information for 

the asset.

locations element - locations 0-1 Holds the location information where 

the asset resides.

extendedinformationelement – any XML 0-1 Holds extension identifiers for the 

asset. The content can be any wellformed XML defined in a namespace

other than the Asset Identification 

namespace.

timestamp literal – dateTime 0-1 The date and time when the 

information was last known to be 

correct.

Table 6-2: Element – ai:it-asset

Element Name: ai:it-asset

Inherits ai:asset

Definition An abstract element that extends from the asset element. it-asset is a placeholder element 

to carry common attributes related to IT assets. For the current iteration of this 

specification no common attributes have been identified, but future iterations of the 

specification MAY contain common attributes for IT assets. All asset elements that are 

describing IT assets SHOULD extend from the it-asset element.

6.2 Concrete Asset Elements

The following elements describe the data elements for the asset types defined in this specification.

Table 6-3: Element – ai:circuit

Element Name: ai:circuit

Inherits ai:it-asset

Definition Captures identifying information about a circuit.

Properties Name Type Count Definition

circuit-name literal – token 0-1 The name of the circuit being identified. 
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

14

Table 6-4: Element – ai:computing-device

Element Name: ai:computing-device

Inherits ai:it-asset

Definition Captures identifying information about a computing device.

Properties Name Type Count Definition

distinguishednameliteral – token 0-1 The X.500 distinguished name of the 

computing device being identified. 

cpe literal – ai:cpe 0-n The Common Platform Enumeration name for 

the computing device being identified. This 

MUST be a hardware CPE. This MUST be a 

CPE 2.2 URI [CPE22] or CPE 2.3 formatted 

string [CPE23].

connections element –

ai:connections

0-1 Information about a network interface on the 

computing device being identified.

fqdn literal – token 0-1 The fully-qualified domain name for the 

computing device being identified.

hostname literal – token 0-1 The hostname of the computing device.

motherboardguidliteral - string 0-1 The motherboard globally unique identifier of 

the computing device.

Table 6-5: Element – ai:data

Element Name: ai:data

Inherits ai:asset

Definition A generic element to describe any type of data. Since this element is generic it does not 

define any of its own properties, but instead relies solely on the properties inherited from 

asset.

Table 6-6: Element – ai:database

Element Name: ai:database

Inherits ai:it-asset

Definition Captures identifying information about a database.

Properties Name Type Count Definition

instance-name literal – token 0-1 The name of the database instance.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

15

Table 6-7: Element – ai:network

Element Name: ai:network

Inherits ai:it-asset

Definition Captures identifying information about a network.

Properties Name Type Count Definition

network-name literal –

normalizedString

0-1 The name of the network being identified. 

ip-net-range element –

ip-net-range

0-1 

(either 

but 

not 

both)

The starting and ending IP addresses for the 

range of IP addresses for the network being 

identified.

cidr literal – token The Classless Inter-Domain Routing 

information for the network being 

identified.

Table 6-8: Element – ai:organization

Element Name: ai:organization

Inherits ai:asset

Definition Captures identifying information about an organization.

Properties Name Type Count Definition

xnl:Organisation

NameDetails

element –

xnl:Organisation

NameDetails

0-n The name of the organization being 

identified. See [xNL] for details on

populating this element.

email-address literal – token 0-n An email address associated with the 

organization being identified.

telephonenumberliteral - token 0-n A phone number associated with the 

organization being identified. For a North 

American number, the number MUST be 

valid and the format MUST be XXXXXX-XXXX where X is a digit. For an 

international number, the number MUST

begin with a '+' symbol, followed by 7 to 

15 digits. A space MAY be used between 

digits, as appropriate. For example: +88

888 888 8 (this is following the ITU-T 

E.123 notation).

Regex: (([2-9][0-8]\d-[2-9]\d{2}-[0-

9]{4})|(\+([0-9] ?){6,14}[0-9]))

website-url literal - URL 0-n A website associated with the organization

being identified.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

16

Table 6-9: Element – ai:person

Element Name: ai:person

Inherits ai:asset

Definition Captures identifying information about a person.

Properties Name Type Count Definition

xnl:PersonName element -

xnl:PersonName

0-1 The name of the person being identified. 

The element type is defined in [xNL] and 

SHALL be used as documented in that 

specification.

email-address literal – token 0-n An email address associated with the 

person being identified.

telephonenumberliteral - token 0-n A phone number associated with the 

person being identified. For a North 

American number, the number MUST be 

valid and the format MUST be XXXXXX-XXXX where X is a digit. For an 

international number, the number MUST

begin with a '+' symbol, followed by 7 to 

15 digits. A space MAY be used between 

digits, as appropriate. For example: +88 

888 888 8 (this is following the ITU-T 

E.123 notation).

Regex: (([2-9][0-8]\d-[2-9]\d{2}-[0-

9]{4})|(\+([0-9] ?){6,14}[0-9]))

birthdate literal - date 0-1 The birth date of the person being 

identified.

Table 6-10: Element – ai:service

Element Name: ai:service

Inherits ai:it-asset

Definition Captures identifying information about a service running on a computing-device.

Properties Name Type Count Definition

host element –

host

0-1 The IP address or fully qualified domain name of the 

host of the service.

port literal –

integer

0-n The port number that the service is bound to. 

Restricted to 0 <= x <= 65535

portrangeelement –

ai:port-range

0-n The lower and upper bound (inclusive) of the range of 

ports the service is bound to.

protocol literal –

string

0-1 The protocol used to interact with the service (e.g.,

HTTP, JMS, SSH, FTP).
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

17

Table 6-11: Element – ai:software

Element Name: ai:software

Inherits ai:it-asset

Definition Captures identifying information about a class of software or a software instance.

Properties Name Type Count Definition

installation-id literal –

token

0-1 Any identifier for a software instance (installation). 

Use when identifying an instance of software and not 

just the class of software.

cpe literal –

ai:cpe

0-1 The Common Platform Enumeration name for the 

class of software being identified. This MUST be a 

software CPE. This MUST be a CPE 2.2 URI 

[CPE22] or CPE 2.3 formatted string [CPE23].

license literal –

string

0-n The license key associated with the software instance 

(installation). Use when identifying an instance of 

software and not just the class of software.

Table 6-12: Element – ai:system

Element Name: ai:system

Inherits ai:it-asset

Definition Captures identifying information about a system.

Properties Name Type Count Definition

systemnameliteral –

token

0-n The name of the system being identified. This property 

can be replicated as systems may have multiple, or 

abbreviated, names. All of the names (including 

acronyms) MAY be captured here. 

version literal –

token

0-1 The version of the system being identified.

Table 6-13: Element – ai:website

Element Name: ai:website

Inherits ai:it-asset

Definition Captures identifying information about a website.

Properties Name Type Count Definition

documentrootliteral -

token

0-1 The absolute path to the document root location of the 

website on the host.

locale literal -

token

0-1 The locale of the website represented as an RFC 5646 

language, and optionally, region code. Language and 

region codes SHOULD be in the Internet Assigned 

Numbers Authority (IANA) Language Subtag Registry 

[ILSR]. 

Regex: [a-zA-Z]{2,3}(-([a-zA-Z]{2}|[0-9]{3}))?
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

18

6.3 Helper Elements

Table 6-14: Element – ai:synthetic-id

Element Name: ai:synthetic-id

Definition Holds the synthetic identifier information for an asset.

Properties Name Type Count Definition

resource literal -

URI

1 A URI for the namespace in which the identifier is 

governed and unique.

id literal -

token

1 The unique identifier for the asset within the resource 

namespace.

Table 6-15: Element – ai:connections

Element Name: ai:connections

Definition Contains a list of ai:connection elements.

Properties Name Type Count Definition

connection element –

ai:connection

1-n Information about a network interface on the 

computing device being identified.

Table 6-16: Element – ai:connection

Element Name: ai:connection

Definition Contains information relevant to a single connection to a network. If multiple IP addresses 

map to the same MAC address, each ai:connection SHALL represent a single MAC 

address-IP address pair.

Properties Name Type Count Definition

ipaddressliteral –

token

0-1 The IP address for the connection.

IPv4 Regex: ([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))

IPv6 Regex: ([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}

macaddressliteral –

ai:macaddress-type

0-1 The Media Access Control address for the network 

interface.

Regex: ([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}

url literal –

URL

0-n A Universal Resource Locator address for the network 

interface.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

19

subnetmaskliteral –

token

0-1 The subnet mask for the connection.

IPv4 Regex: ([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))

IPv6 Regex: ([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}

defaultrouteliteral –

token

0-1 The IP address for the default gateway for the 

connection.

IPv4 Regex: ([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-

9]|5[0-5]))

IPv6 Regex: ([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}

Table 6-17: Element – ai:locations

Element Name: ai:locations

Definition Contains a geographic coordinate system point.

Properties Name Type Count Definition

location element – one of: 

location-point, 

location-region, 

location-address 

(type 

xal:AddressDetails)

1-n ai:location is an abstract element that is the root 

of the substitution group for the elements listed 

in the type field. Use one of those to describe 

the location of the asset. xal:AddressDetails is 

defined in [xAL].

Table 6-18: Element – ai:location-point

Element Name: ai:location-point

Definition Contains a geographic coordinate system point.

Properties Name Type Count Definition

latitude literal –

number

1 The latitude of the point represented as a number between 

-90 and 90. 90 = 90°N, -90 = 90°S.

Value constraint: -90 <= x <= 90

longitude literal –

number

1 The longitude of the point represented as a number 

between -180 and 180. 180 = 180°E, -180 = 180°W.

Value constraint: -180 < x <= 180

elevation literal –

number

0-1 The elevation of the point represented in meters above sea 

level. A negative number would indicate below sea level.

radius literal –

number

0-1 The radius of a horizontal circle centered on the point 

within which the asset resides.

Value constraint: x >= 0
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

20

Table 6-19: Element – ai:location-region

Element Name: ai:location-region

Definition Contains region information.

Properties Name Type Count Definition

region-name literal – normalizedString 1 The name of the region.

Table 6-20: Element – ai:ip-net-range

Element Name: ai:ip-net-range

Definition Contains a start and end IP address to create a range.

Properties Name Type Count Definition

ip-net-range-start element – ai:ip-address 1 The start IP address of the range

ip-net-range-end element – ai:ip-address 1 The end IP address of the range

Table 6-21: Element – ai:ip-address

Element Name: ai:ip-address

Definition Contains an IP address.

Properties Name Type Count Definition

ip-v4 literal –

token

0-1 An IP v4 address.

Regex: ([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-

5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-

5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-

5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))

ip-v6 literal –

token

0-1 An IP v6 address.

Regex: ([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}

Table 6-22: Element – ai:port-range

Element Name: ai:port-range

Definition Contains a start and end port number to create a range.

Properties Name Type Count Definition

lower-bound literal –

token

1 The lower bound (inclusive) of the range of ports. 

Restricted to 0 <= x <= 65535

upper-bound literal –

token

1 The lower bound (inclusive) of the range of ports. 

Restricted to 0 <= x <= 65535. MUST be greater 

than lower-bound.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

21

Table 6-23: Element – ai:host

Element Name: ai:host

Definition Holds a fully-qualified domain name or an IP address

Properties Name Type Count Definition

fqdn literal – token 1 

(either 

but not 

both)

The fully-qualified domain name of the host. 

One of fqdn or ip-address must be specified

ip-address element – ai:ipaddressThe IP address of the host. One of fqdn or ipaddress must be specified.

Table 6-24: Element – ai:cpe

Element Name: ai:cpe

Definition A CPE 2.2 URI [CPE22] or CPE 2.3 formatted string [CPE23].

6.4 Relating Assets to Other Assets

While the assets modeled in Section 6.2, and their related elements, capture the literal values helpful for 

identifying the respective assets, it is often useful or necessary to define one or more relationships 

between assets. Those relationships can give additional context to the identifying algorithm in the 

implementing tool.

The Asset Identification data model allows for explicit relationships to be defined between an asset and 

one or more other assets. Each relationship is defined as {subject} {predicate} {object}, where {subject} 

is the asset from which the relationship begins, {predicate} is the relationship type being established, and 

{object} is one or more other assets. The predicate MUST be a qualified name that refers to a term in a 

controlled vocabulary. Section 6.4.1 documents the data model to represent assets along with 

relationships. Section 6.4.2 defines terms in a controlled vocabulary for Asset Identification.

6.4.1 Relationship Data Model

Asset Identification defines two elements that can be leveraged by specifications desiring to represent 

Asset Identification information. The first element, ai:asset-related, SHOULD be leveraged when the 

implementing specification desires to identify a single asset while demonstrating relationships between 

that asset and other assets. The second element, ai:assets, SHOULD be leveraged when the implementing 

specification desires to identify multiple assets while documenting the relationships between those assets 

and other assets. The two elements are documented in the following tables.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

22

Table 6-25: Element – ai:asset-related

Element Name: ai:asset-related

Definition Identifies a single asset while capturing the relationships between that asset and other 

assets.

Properties Name Type Count Definition

asset-ref literal – NCName 1 Contains the ID value of an ai:asset found on 

this ai:asset-related element. The asset 

referenced from this property is the primary 

asset of this element and SHALL be 

understood to be the asset being identified by 

this ai:asset-related element.

relationships element –

core:relationships

0-1 Contains the relationships between assets 

identified in this element.

asset element – ai:asset 1-n The assets captured in this element. This 

includes at minimum the primary asset 

referenced in asset-ref, as well as any 

additional assets that the primary asset is 

related to through a relationship.

Table 6-26: Element – ai:assets

Element Name: ai:assets

Definition Identifies multiple assets as well as the relationships between the assets.

Properties Name Type Count Definition

relationships element –

core:relationships

0-1 Contains the relationships between assets 

identified in this element.

asset element – ai:asset 1-n The assets captured in this element. 

Table 6-27: Element – core:relationships

Element Name: core:relationships

Definition Contains a collection of relationships between the report content and assets, report 

requests, and other reports.

Properties Name Type Count Definition

relationship element –

core:relationship

1-n Contains a relationship between the subject and 

object(s) assets.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

23

Table 6-28: Element – core:relationship

Element Name: core:relationship

Definition Contains a relationship between the subject and object(s) assets.

Properties Name Type Count Definition

ref literal -

NCName

1-n This element MUST identify the object of this relationship 

by specifying the ID of the asset. Depending on the type of 

relationship being asserted, there may be additional 

restrictions on which types of objects may be referenced, 

but that will be documented with the vocabulary term.

type literal -

QName

1 This element contains the type of relationship that is being 

specified. The QName MUST refer to a term in a 

controlled vocabulary. The controlled vocabulary is 

identified by the namespace URI of the QName, and the 

term in that controlled vocabulary is specified by the local 

name of the QName. It is helpful, though not required, that 

when the namespace URI and local name are concatenated, 

the resulting URI is dereferenceable and points to a 

location that defines the term.

scope literal -

token

0-1 Determines how to interpret multiple ref elements in a 

relationship. If used, this element MUST contain the string 

“inclusive” or “exclusive”. When this element is not 

provided, its default value is “inclusive”. When “inclusive” 

is specified, this relationship should be understood to exist 

between the subject asset and the collection of objects 

identified by the ref elements on this relationship. When 

“exclusive” is specified, this relationship should be 

understood to exist between the subject asset and each 

object asset identified by the ref elements individually.

subject literal –

NCName

1 The property MUST identify the subject of the relationship 

by specifying the ID of the asset. Depending on the type of 

relationship being asserted, there may be additional 

restrictions on which type of asset may be referenced, but 

that will be documented with the vocabulary term.

6.4.2 Relationship Types

Defined below are terms in a controlled vocabulary for Asset Identification. It is OPTIONAL that content 

producers use the terms defined below, but all Asset Identification compliant implementations MUST 

understand the terms defined in this section. Content producers SHOULD use these terms when possible.

All terms listed in Table 6-29 exist in the controlled vocabulary identified by 

http://scap.nist.gov/specifications/ai/vocabulary/relationships/1.0#. The definition of each term can also 

be found at the URL created when concatenating the URL and the term together. The table MUST be 

interpreted as follows:

 The “Term” column indicates the local-name of the term being identified.

 The “Domain” column indicates the exhaustive set of subject types that may be referenced by a 

relationship of that type. A relationship of that type MUST reference a subject of the type 

indicated in “Domain” for that relationship.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

24

 The “Range” column indicates the exhaustive set of object types that may be referenced by a 

relationship of that type. A relationship of that type MUST reference an object of the type 

indicated in “Range” for that relationship.

 The “Description” column contains a prose description of the relationship type. This column may 

contain requirement words as indicated in [RFC 2119]. Those requirement words MUST be 

interpreted as described in [RFC 2119] for the relationship.

Table 6-29: Controlled Vocabulary Defined for Asset Identification

Term Domain Range Description

hasTerminationDevice ai:circuit ai:computingdevice

The circuit is terminated by 

the device.

hasServiceProvider ai:circuit ai:organization The circuit is owner/operated 

by the organization.

hasNetworkTerminationPoint ai:circuit ai:network The circuit ends at the 

network.

servedBy ai:database, 

ai:website

ai:service The database or website is 

served up by the service.

hasServiceProvider ai:service ai:software The service is provided by the 

software.

installedOnDevice ai:software ai:computingdevice

The software is installed on 

the computing device.

connectedToNetwork ai:system ai:network The system is connected to 

the network.

isOwnerOf ai:person, 

ai:organization

ai:it-asset The person or organization 

owns the IT asset.

isAdministratorOf ai:person ai:computingdevice, 

ai:system

The person is the system 

administrator of the 

computing device or system.

partOf ai:person ai:organization The person is in some way a 

part of the organization.

connectedTo ai:computingdevice, 

ai:system

ai:system The computing device or 

system is connected to the 

system.

Content producers that choose to use terms that are not listed in Table 6-29, or to use other terms in 

addition to those listed in Table 6-29, MAY do so while still remaining compliant to this specification. 

Content producers SHALL always use terms defined in a controlled vocabulary. The controlled 

vocabulary SHALL be identified using a URI. Concatenating the controlled vocabulary URI with a term 

in the vocabulary MAY create a dereferencable URI that points to a definition for that term. This is often 

accomplished by using an HTTP URL for the controlled vocabulary URI, and ending that URL in “#” or 

“/”. For instance, http://scap.nist.gov/specifications/ai/vocabulary/relationships/1.0#installedOnDevice is 

a deferenceable link to the definition of “installedOnDevice”.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

25

6.5 Guidance for Incorporating Asset Identification Elements into Other Data Models

The following guidance applies when incorporating the Asset Identification data model into other data 

models.

 If the target data model needs to include a list of assets and the associated relationships between 

the assets, then the ai:assets element SHOULD be included in the target data model. This will be 

the case when the target data model will make explicit references to assets in the asset list.

 If the target data model needs to include a single asset, but other assets are needed to help identify 

that asset, then the ai:asset-related element SHOULD be included in the target data model. The 

@asset-ref attribute on ai:asset-related SHALL refer to the specific asset that is being identified.

 If the target data model needs to include only a single asset, and no relationships are needed to 

identify that asset, then the element defining the asset MAY be included in the target data model. 

While this is allowed, it is preferred that the ai:asset-related element be included instead.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

26

Appendix A—Use Cases

The following use cases describe some common asset management processes that rely on the ability to 

uniquely identify assets. The asset identification specification was developed primarily in order to support 

these use cases, although the specification may be useful for other processes or uses.

A.1 Correlation of Sensed Data

Sensor data is not limited to an automated process: user surveys, manually entered information, and other 

data may also be correlated using this Asset Identification specification. The data must be correlated both 

with other manually collected data and with data collected by automated sensors, in order to build a 

complete representation of all known data about an asset.

Consistent asset identification allows data to be correlated regardless of:

 Collection timeframe

 Data type (vulnerability scan vs. user survey)

 Manual or automated process

 Data format

In this case, the goal of asset identification is to provide as much identifying information as possible 

about an asset in order to ensure the greatest probability of matching asset data from several different 

sources. Constraining which data is provided merely reduces the possibility of a match.

A.2 Federation of Asset Databases

While many smaller organizations may only have a single asset database, larger organizations with many 

asset databases may wish to share information about assets among them. This includes:

 Peer to peer relationships, where asset data is replicated and fused between several asset 

databases

 Hierarchical relationships, where an asset database is aggregated from several lower-level 

databases into fewer higher-level databases

In both use cases, asset identification facilitates detection of duplicate asset representations, correlation of 

asset data across the databases, and direct queries for asset data among tools.

In this use case, asset databases may wish to use a smaller set of data, or even a single identifier, in order 

to properly federate the asset data. For example, use of the motherboard GUID or single synthetic ID, 

such as an asset tag, may be sufficient to allow asset databases to exchange information about assets.

A.3 Directly Targeted Remediation Actions

While assessment and sensor data may be collected from all assets in a particular organization 

environment without specifically identifying a particular asset identifier, remediation actions require a 

more granular identification process that directly targets the asset using identification data. This ensures 

that unintended side effects are avoided and the intended remediation action is able to be completed 

successfully. 
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

27

A single agent identifier or motherboard GUID allows those triggering remediation actions to specify 

exactly which assets should have the remediation applied and allows the tools to unambiguously identify 

those assets in the remediation control language.

A.4 Management of Asset Data

Outside of the collection of sensor data and federation of asset databases, asset data may be used in a 

variety of management processes. This includes both further processing of asset data, such as aggregation 

for the purposes of metrics collection, and display to an end user. Both of these uses require asset 

identification be present to ensure all systems are able to accurately represent the correct assets. For 

purposes of aggregation, for example, asset identification may be used to request detailed data about 

outliers from the sensors that collected the data.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

28

Appendix B—Extending the Asset Identification Specification

Although the core Asset Identification specification should satisfy most users, some organizations may 

find that there are weaknesses or missing elements in the specification. In these cases, the organization 

may extend the Asset Identification specification by extending the XML schema that defines the data 

model. These extensions should be published as an XML schema to ensure that both schema extensions 

and instance documents are valid.

B.1 Additional Asset Types

Some organizations may wish to identify assets that are not contained in the valid asset list as defined in 

Section 5.3. To do this, additional XML elements can be defined that extend (using the XSD extension

mechanism) an appropriate asset type (best practices entail using the most specific asset type that captures 

the necessary elements). Additional identification fields can be defined in the schema and additional 

relationships can be defined by creating new relationship types in a non-core controlled vocabulary.

B.2 Additional Literal Identifiers for Existing Asset Types

Additional literal identifiers for existing asset types may be added by creating schema elements in the 

extended-information element. Although there is no technical restriction of these fields to literal 

identifiers (i.e. information that is used to identify the asset), placing information in an asset element that 

does not help identify the asset is counter to the purpose of this specification.

B.3 Additional Relationships

Organizations may also wish to identify existing or new asset types using relationships that are not 

defined in the core specification. This may be accomplished by defining and publishing a relationship 

vocabulary in a separate namespace than the core Asset Identification relationship vocabulary.

B.4 Additional Properties on Existing Data Elements

The XML schema also provides extension points on most XML elements to allow for tracking metadata 

about Asset Identification information, such as classification level, sensitivity, or other organizationspecific data. As long as Asset Identification elements are able to validate against the core schema and 

conform to the requirements of this specification, these extensions and the Asset Identification elements 

are valid.
SPECIFICATION FOR ASSET IDENTIFICATION 1.1

29

Appendix C—Normative References

The following documents are indispensible references for understanding the application of this 

specification.

[CPE22] The MITRE Corporation (MITRE) Common Platform Enumeration (CPE) Specification 

Version 2.2, March 2009. See: http://cpe.mitre.org

[CPE23] NIST Interagency Report 7695, Common Platform Enumeration: Naming Specification Version 

2.3, April 2011. See: http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7695

[ILSR] IANA Language Subtag Registry. See http://www.iana.org/assignments/language-subtag-registry

[RFC 2119] Internet Engineering Task Force (IETF) Request for Comment (RFC) 2119: Key words for 

use in RFCs to Indicate Requirement Levels, March 1997. See: http://www.ietf.org/rfc/rfc2119.txt

[RFC 2396] Internet Engineering Task Force (IETF) Request for Comment (RFC) 2396: Uniform 

Resource Identifiers (URI): Generic Syntax, August 1998. See: http://www.ietf.org/rfc/rfc2396.txt

[RFC 5646] Internet Engineering Task Force (IETF) Request for Comment (RFC) 5646: Tags for 

Identifying Languages, September 2009. See: http://www.ietf.org/rfc/rfc5646.txt

[xAL] Organization for the Advancement of Structured Information Standards (OASIS) Extensible 

Address Language (xAL) Version 2.0, 24 July 2002. See: http://www.oasisopen.org/committees/ciq/ciq.html#6

[XML] W3C Recommendation Extensible Markup Language (XML) 1.0 (Fifth Edition), 26 November 

2008. See: http://www.w3.org/TR/REC-xml/

[XML Schema] W3C Recommendation XML Schema, 28 October 2004. See: 

http://www.w3.org/XML/Schema.html

[xNL] Organization for the Advancement of Structured Information Standards (OASIS) Extensible Name 

Language (xNL) Version 2.0, 24 July 2002. See: http://www.oasis-open.org/committees/ciq/ciq.html#5