The following use case scenarios show what you can (and at times should) be doing with the Assets List. The first and foremost use of the Assets List is to ensure a strict naming standard for all assets being tracked. The naming standard ensures that each and every asset name is unique and persistent. The second naming standard ensures that each asset name has at least a "common name" variant wherein the name cannot exceed 100 characters and ensures that non-usable characters in the asset's name are as follows:

, + - * / ^ & = ≠ ( ) [ ] \ ; : $ AND OR NOT XOR TRUE FALSE

In addition, the first character in any asset's common name cannot be any of the following: space, period, or number.

This will ensure that OEMs working with asset names can use the names in calculations, references, etc. Each asset may have a "formal" name which is less restrictive than the common name, but that's optional.

Taxonomic ontology

A taxonomy is more or less a hierarchical relationship of words, categories, and concepts. Before we delve any further into this definition, let's talk for a second about what we do naturally. It is in our nature to classify what we encounter, if only to help make sense of our surroundings. We look at a chair and think "wooden chair", or "comfortable chair", both of which are subordinate terms to the category of "chair". We all categorize that which we encounter.

Within the Assets List, we will maintain a hierarchical order of assets that track their genealogy from the point of view of whether an asset is classified as a Operating System [includes drivers], Application [includes drivers], Storage, Hardware, Network, Power or Air, or Facility [including containers]. Additional ontological classifications will be determined by our end user and OEM partner audience as a part of normal list governance practices. Furthermore, we will track whether or not the asset is called out as an artifact for auditing purposes. And lastly, the genealogy itself will provide the necessary cues as to asset versioning.

Using the genealogy data to denote asset versioning

Within the UCF, each distinct record that has an ID also has a genealogy and a sort ID.

Because the UCF database is a taxonomic ontology (fancy words for hierarchically ordered list), it can be used to track asset versioning. The cues for both genealogy and sorting are found in those fields. The genealogy field will show for this example that both Microsoft Word 2003 and 2007 are children of Microsoft Word, as they both have that asset's ID in their genealogy. To get them to display properly, one only needs to sort on the Sort ID (which is a combination of the record's parent Sort ID and its own Sort ID).

ID	Genealogy	Sort ID	Title	Version
0001		001	Microsoft Word
0002	0001	001 001	Microsoft Word	2003
0003	0001	001 002	Microsoft Word	2007

Normalizing the database design

One of the things you'll notice in the XML specification is that within the CAE List, there are three main element groupings - Vendor Info, Asset Info, and Asset Documentation Info. We grouped the elements this way as to make the XML easier to build out and to allow for table separation in your solution.

In fact, within the UCF's own database structure, we have our information split into two separate tables of the same naming structure as above, shown below:

Assets List split into three data tables

As with each and every table in the UCF, the primary key is always the ID key. This number is both unique and persistent in every table instance we create and maintain.

Tracking the vendors

We suggest breaking out the Vendor Info and tracking it in its own table. You don't have to, but it seems to us to be easier to have a list of vendors in its own table for its own use rather than simply tying the vendors to each product. There is no reason that you can't track the vendors with the products, but we've designed the XML structure so that if you want to track them separately you can.

Tracking the assets

Again, as with the vendors, you'll probably want to maintain a separate table for the assets themselves. Remember that assets can be normal organizational assets or they can be audit artifacts. We'll explain an easy way to separate the two in a moment, but for now, you can (and should) track both in the same asset table.

Joining the assets to their vendors

The Assets List can act in the same capacity, and as an extension to, MITRE's Common Platform Enumerator (CPE) list wherein they track both a vendor name and a product name. In our case, the product would be treated as an asset (as all hardware and software products fall into their asset categorization. Where MITRE's CPE currently has only hardware and software asset categories, the Assets List has even more. However, both lists are the same in the respect of being able to tie vendors into their respective products.

Within the Assets List, vendors are a natural part of our taxonomic ontology. Each vendor is tracked separately, and each product belonging to the vendor is listed as a member of that vendor's product family.

Microsoft
Internet Explorer

This is pretty easy in that the Vendor info table maintains its own ID for each record and the Asset info table maintains its own ID for each record. To create the join, simply add a Vendor ID Foreign Key field to the Asset info table and join the two at that point. The relationship is one vendor to many products.

Building out CPE names

MITRE's Common Platform Enumerator naming scheme is very powerful and is a key part of the Making Security Measurable program. Below is a diagram showing the CPE naming scheme and how to derive that data using the CAE List information. As the UCF only tracks English documents, that will be assumed.

Using the UCF's CAE element information to build out a CPE name

The only thing to note is that the CPE Part element as managed by MITRE only contains hardware, operating system, and application, whereby the UCF team has extended beyond that.