The UCF Metrics XML specification
This describes a standardized metric format for describing metrics. It is a subset of the complete XML format for describing all of the attributes of controls tracked by the Unified Compliance Framework. This standard aims to facilitate the exchange of metric information between organizations that license the UCF content, organizations that work with this standard but might not necessarily license the UCF content, and applications that utilize the UCF XML standards whether they are licensing the UCF content or not.
Where the Metrics schema fits in
The Metrics schema, as stated above, is a subset of the Controls schema, in that it does not need to contain all of the attributes found within the Controls schema. While they might be used in other use cases (the audit attributes might be used to define auditing a metric), some of the attributes within the Control schema are not necessary to describe or share metrics.
The use-cases of the Metrics XML schema
Already the UCF Metrics XML schema is being used to create an interchange format between multiple organizations who wish to create and map their own metrics. The UCF team has been collaborating with PowerFrameworks in order to define metric presentation formats. In-so-doing, the XML schema showed us quickly that some of the metrics mapped by the UCF team didn’t have proper calculation formulas. Other organizations are using the UCF Metrics XML schema to map their private metrics standards and create additional metrics.
The UCF Control Entry elements
The UCF’s Control XML schema is made up of the following elements:
UCF_CE_Basic_Info
UCF_CE_Metric_Info
-
UCF_CE_Audit_Info
UCF_CE_Guidance_List
Of these elements, the UCF_CE_Basic_Info will have some pertinent information, while the majority of the information will be found within the UCF_CE_Metric_Info element.
UCF_CE_Basic_Info
The UCF_CE_Basic_Info element has exactly what you’d expect – the most critical information that pertains to all types of controls, whether those controls are also metrics or those controls are also audit questions.
How does this element apply to metrics? There are a more than a few of the attributes below that apply to all controls, whether those controls are metrics or not. In the description area I’ve listed the basic description and then I’ve followed that up with information specific to metrics (if there is any), or at least the importance the attribute has for describing metrics.
| Attribute | Type | Multiplicity | Description |
|---|---|---|---|
| UCF_CE_ID | UCF_ID_Type |
1 |
This is the UCF’s unique and persistent identifier that we test for. If you wish to share controls or add to the UCF’s works (as those from the MetricsCenter will be doing), we’ll need to coordinate our ID conventions with yours during the cross harmonization process. This is important for metrics descriptions because we are using this field to track the unique IDs of all metrics. A use-case scenario for this attribute will be to ensure when sharing metrics between various organizations that might have their own ID system is that the UCF team will map all of the various local IDs to its master list of unique IDs. By doing that, we’ll ensure that we can have a cross reference between any group(s) ID and a master list to show overlap.
|
| UCF_CE_Parent_ID | UCF_ID_Type |
1 |
Because the UCF’s database is structured as a taxonomic hierarchy, we use the UCF_CE_Parent_ID element to track each control’s parent (there are a certain amount that are root parents). From there, each control’s child can also be ascertained, as well as the control’s current level within the hierarchy. This allows us to move whole families of controls with each other when reorganizing the database.
This isn’t really important to describe a metric per se. It is only used when displaying the taxonomic hierarchy of one metric to another. And because most metric definitions are not organizing them hierarchically, this is irrelevant at this time.
|
| UCF_CE_Control_Title | xs:string |
1 |
This is a 255 character or less harmonized control title. Each time a unique control is added to the database, it must have a control title. Each time a matching control is threaded into the database, the control title is again checked to ensure its continued accuracy.
This is important for metrics descriptions because it is used as the title of the metric itself. A sample use-case might be “Report on the number of key IT assets for which an assurance strategy has been implemented.” |
| UCF_CE_Policy_Statement | xs:string |
1 |
This is a 255 character or less harmonized policy statement that expresses the intent of the control in a policy format. This field only became mandatory around 2006. We are slowly backfilling all controls without policy statements.
This is important for metrics descriptions because it describes the organization’s policy for handling that specific metric.
|
| UCF_CE_Date_Added | xs:dateTime | 1 |
A simple date and time stamp for when the record was initially created. |
| UCF_CE_Date_Modified | xs:dateTime | 1 |
A simple date and time stamp for when the record was last modified. The date modified field is used to calculate the changes for the database and create the roll-forward and roll-backward mechanisms. |
UCF_CE_Metric_Info
This area of the database was added in Q1 of 2008 and tracks the various authority document’s take on the types of metrics information that should be used within a compliance program. In partnering with the MetricsCenter.org, SecurityMetrics.org, and the Center for Internet Security, the UCF is mapping a wealth of metric information.
| Attribute | Type | Multiplicity | Description |
|---|---|---|---|
| UCF_CE_Metric_ Calculation |
xs:string |
1 |
This is the calculation used to define the metric. A sample calculation that fits the control title might be “# of key IT assets for which an assurance strategy has been implemented / # IT assets.”
|
| UCF_CE_Metric_ Information_Source |
xs:string | 1 |
This is where the person(s) creating the metric would need to go to find the data to support the calculation. A sample that fits the above metric might be “The assets in your CMDB as the base / # of assets that have assigned configuration standards and controlling procedures.” |
| UCF_CE_Metric_ Target_Result |
xs:string | 1 |
This is usually indicated by “low is good” or “low is bad” type of statement, or as a percentage. |
| UCF_CE_Metric_ Presentation_Format |
UCF_Metric_ Chart_Type |
1 |
This element defines the chart type that should be used when presenting the metric in question. It uses the list format for the chart type defined by the UCF_Metric_Chart_Type. The types we’ve found so far are “Bar, Pie, Stacked Bar, Waterfall.” |
| UCF_CE_Control_ Match_List |
UCF_CE_Control _Match_Item |
0 - n |
This is represented by a list of UCF_ID_Types that correlate with the particular metric so that the metrics can be cross-correlated with the controls that call for them.
This one is a bit more difficult to track and takes a coordinated effort. That’s why the UCF team is working with the folks at OCEG, the MetricsCenter.org, SecurityMetrics.org, and the Center for Internet Security – because they’ve jointly agreed upon how to talk about metrics and now they are working on linking those metrics to the compliance controls that call for them. |
If you would like to participate in editing or contributing to this standard, please contact the UCF team by clicking HERE.
Post a comment