One document matched: draft-hansbury-sacm-oval-info-model-mapping-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY I-D.coffin-sacm-vuln-scenario SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.coffin-sacm-vuln-scenario.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info"
docName="draft-hansbury-sacm-oval-info-model-mapping-03"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="OVAL and the SACM Information Model">OVAL and the
SACM Information Model</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Matthew Hansbury" initials="M.H."
surname="Hansbury">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>mhansbury@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Haynes" initials="D.H." surname="Haynes">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>dhaynes@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Juan Gonzalez" initials="J.G."
surname="Gonzalez">
<organization>Department of Homeland Security</organization>
<address>
<postal>
<street>245 Murray Lane</street>
<!-- Reorder these if your country does things differently -->
<city>Washington</city>
<region>DC</region>
<code>20548</code>
<country>USA</country>
</postal>
<phone/>
<email>juan.gonzalez@dhs.gov</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="September" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>Security Automation and Continuous
Monitoring</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>security automation</keyword>
<keyword>continuous monitoring</keyword>
<keyword>endpoint</keyword>
<keyword>posture assessment</keyword>
<keyword>oval</keyword>
<keyword>lessons learned</keyword>
<keyword>gaps</keyword>
<keyword>configuration management</keyword>
<keyword>vulnerability management</keyword>
<keyword>information model</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The OVAL community has spent more than ten years developing
and employing the OVAL Language. During this time, the
community has made a number of design decisions and learned a
number of lessons that should be leveraged as the next-generation
endpoint posture assessment standards are formulated. There are also a
number of places where portions of the OVAL Language align
with the SACM Information Model and could serve as a starting
point for related work. Another output of the work executed
under the OVAL project is a number of lessons that are
applicable to the SACM work. These lessons include a clear
separation of data collection and evaluation; a call to focus
on ensuring both primary source vendors and third party
security experts feel invited to the discussion and are
empowered to leverage their unique domain knowledge; and to
strive for simplicity and flexibility, where possible. In
addition, the OVAL community has a set of clear
recommendations with respect to which parts of OVAL should be
used by SACM as a means to make best use of the efforts of
those that have worked on and supported OVAL over the past ten
years. Those recommendations are: <list style="symbols">
<t>Use the OVAL System Characteristics Model to inform the
development of a data model for representing endpoint posture
attributes.</t>
<t>Use the OVAL Definitions Model to inform the development
of data models for representing evaluation and collection guidance.</t>
<t>Do not use the OVAL Results Model to inform the
development of a data model for representing evaluation results.</t>
</list>Lastly, this document will discuss the OVAL
submission, how it is expected to be used, and how
it aligns with the SACM Vulnerability Assessment Scenario.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Security Automation and Continuous Monitoring (SACM) IETF
Working Group <xref target="SACM"/> has been chartered with
standardizing the mechanisms by which endpoint security
assessment is performed. This includes software inventory,
compliance and vulnerability management, and other related
activities. The Working Group has created a series of
artifacts <xref target="SACM-DOCUMENTS"/> to capture the
important concepts required to accomplish this goal. In
addition to Use Cases, Requirements, and Architecture
documents, the Working Group has created an initial draft of
an Information Model that describes the high-level components
and concepts that fulfill the already defined
requirements.</t>
<t>This white paper discusses how the Open Vulnerability and
Assessment Language (OVAL) <xref target="OVAL-DOCUMENTATION"/>
can be used to inform the development of data models that
implement the Information Model defined by the SACM group.
This paper is not meant to suggest that the entire OVAL Data
Model could-or even should-be supported by SACM; rather, it
breaks apart the various components of the OVAL Language and
discusses how each could be used to satisfy parts of the
Information Model.</t>
<t>This document assumes that the reader is already familiar
with OVAL and its structures. For those readers that require
more in-depth information about OVAL, please review the OVAL
Tutorial documentation <xref target="OVAL-DEFINITION-TUTORIAL"
/> and other related documentation. This document describes
how these structures can be thought of as data models whose
scopes and activities overlap with the SACM Information
Model.</t>
<t>Additionally, in later sections, the paper presents lessons
learned from the ten plus years of OVAL development and
curation, related gaps, and how the OVAL submission is
expected to be used and how it aligns with the SACM Vulnerability
Assessment Scenario <xref target="I-D.coffin-sacm-vuln-scenario"/>.</t>
<section title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section title="SACM Information Model"
anchor="sacm-information-model">
<t>The information model defined by the SACM Working Group
captures the types of objects and data required to fulfill the
defined SACM Requirements <xref
target="I-D.ietf-sacm-requirements"/>. It additionally
provides details on the flow of data to and from the different
objects in the system, in conjunction with the SACM
Architecture document <xref
target="I-D.ietf-sacm-architecture"/>. The document
describes all of these things in a protocol and data format
neutral manner.</t>
<t>The document provides descriptions of the various components
that are required to perform endpoint assessments, along with
some usage scenarios, and the potential mapping from OVAL to
any of these defined components wherever OVAL may be
relevant.</t>
</section>
<section title="OVAL Language" anchor="oval-language">
<t>The OVAL Language is made up of several parts, each
responsible for encapsulating a part of the assessment model.
Each part is discussed briefly below <xref
target="STRUCTURE-OF-OVAL"/>.</t>
<t>Note: A word about Core vs. Platform Extensions. OVAL can be
broadly split into Core structures, which are those that are
foundational and give the overall structure to the OVAL
Language, and the Platform Extensions, which are
platform-specific structures that extend the Core in order to
provide ways to encode the underlying low-level,
platform-specific tests used by OVAL Content. This paper is
chiefly focused on mapping the Core into the SACM Information
Model.</t>
<t>In a similar fashion, while thinking about how to implement
the SACM Information Model, two distinct levels must be
considered: <list style="numbers">
<t>Platform-agnostic, high level concepts</t>
<t>Platform-specific concepts</t>
</list>
</t>
<section title="Core OVAL Models" anchor="core-oval-models">
<t>The OVAL Language is made up of three primary core data
models which define the three steps of the assessment
process (desired state, actual state, and the results of
comparing the actual state against the desired state), three
supplemental core data models, and a processing model which
describes how all the core data models work together.</t>
<section title="Core OVAL Data Models"
anchor="core-oval-data-models">
<t>There are a number of data models defined as part of
OVAL. This section discusses the three most important data
models.</t>
<section title="OVAL Definitions Model"
anchor="oval-definitions-model">
<t>The Definitions Model is the central component of the
OVAL Language. The structures in this model allow an
author to encode what posture data to collect, the expected
values for the data, and the rules by which to evaluate
that data. However, the current design requires authors
to include both what data must be collected, and how the
collected data is to be evaluated in a Definition
which couples these two separate, but, related concepts
together. For more information, see <xref
target="collection-and-evaluation-must-be-de-coupled"/> below.</t>
<t>The OVAL Definitions Model provides a Definition
object that is the root element for
any OVAL check. It contains a set of criteria, either
simple or complex, to define how the evaluation should
operate. In addition, the OVAL Definitions Model defines
the base structures that are used by the Platform
Extensions to extend OVAL, as well as Functions, and
other high-level concepts.</t>
</section>
<section title="OVAL System Characteristics Model"
anchor="oval-system-characteristics-model">
<t>The OVAL System Characteristics Model defines
structures to encode the actual posture data that is collected.
It provides basic structures for representing this data,
including the Item construct, which is the base structure for
recording collected data in OVAL. It also provides
structures for capturing information about the endpoint
from which the data was collected, including OS
information, endpoint identification information (such
as IP and MAC addresses), and other relevant endpoint
metadata.</t>
</section>
<section title="OVAL Results Model"
anchor="oval-results-model">
<t>Finally, OVAL provides a third model to encode the
results of the evaluation, the OVAL Results Model. This
model provides structures to capture essential
information about the evaluation results, such as the
overall results of each definition evaluation and when the
assessment occurred. Additionally, the Results model
provides a way to include both the guidance (Definitions) and collected
data (System Characteristics) used for the evaluation.
By capturing this additional data, the Results model provides
a comprehensive way to capture the information used to
determine the result in addition to the results
themselves.</t>
</section>
</section>
<section title="Additional Core OVAL Data Models"
anchor="additional-core-oval-data-models">
<t>Additional data models are defined that support specific
capabilities that are sometimes useful in conjunction with
the OVAL models previously discussed. The models discussed
in this section are not intended to stand alone, and
require the use of one or more of the core OVAL
models.</t>
<section title="OVAL Common Model"
anchor="oval-common-model">
<t>The Common Model is a very simple collection of global
building blocks, such as enumerations used throughout
the other models, along with some other foundational
pieces. Common values are defined in this model once and
then applied within other OVAL models, thus reducing
redundancy between each OVAL data model. Examples of the
elements provided by the OVAL Common Model are
enumerations that provide useful value sets for use
within OVAL, such as family types ("windows", "unix",
etc.), data types (e.g., "string," "boolean," "int,"
etc.), and class types (e.g., "vulnerability,"
"compliance," etc.).</t>
</section>
<section title="OVAL Variables Model"
anchor="oval-variables-model">
<t>The OVAL Variables Model provides a simple framework
for externally specifying variable values used for the
evaluation of an OVAL Definitions document at runtime.</t>
</section>
<section title="OVAL Directives Model"
anchor="oval-directives-model">
<t>The OVAL Directives Model provides a very simple model
with structures to indicate the level of detail that
should be present in an OVAL Results document. This can
be used by an evaluator to produce a desired level of
result detail.</t>
</section>
</section>
<section title="Processing Model" anchor="processing-model">
<t>The OVAL Processing Model describes in detail how the
core OVAL data models are used to produce OVAL
Definitions, OVAL System Characteristics, and OVAL
Results.</t>
</section>
</section>
</section>
<section
title="Relating the OVAL Models to the SACM Information Model"
anchor="relating-the-oval-models-to-the-sacm-information-model">
<t>The following section discusses each piece of the SACM
Information Model, where one or more OVAL models align, wholly
or in part.</t>
<section title="Attribute Collector"
anchor="attribute-collector">
<t>The SACM Information Model defines both Internal and
External Attribute Collectors. Both are components that
perform the collection of posture information from an
endpoint. The Information Model lists a number of examples
of Collectors such as Network Intrusion Detection Systems
(NIDS), NEA posture collectors, and vulnerability scanners.
While OVAL is not directly applicable for some types of
Attribute Collectors such as NIDS, it is certainly
applicable for NEA posture collectors and vulnerability
scanners that require the collection and evaluation of
configuration and other endpoint state information.</t>
<t>An Attribute Collector needs to be instructed as to what
specific posture attributes must be collected, when or how
often those attributes must be collected, and how to share
the collected attributes. In some cases, an Attribute
Collector may simply collect data and directly respond to
the caller with the required results. In others, it may
monitor the endpoint for changes and report these changes
when the change occurs, or may execute the data collection
at a future time or at some interval. In these last two
cases, the collector will need to know how to share the
collected data. The OVAL Language does not provide any
mechanism for instructing tools where to send collected
data, but the OVAL Definitions Model can (among other
things) encode what data must be collected; however, it does
not allow (as currently constructed) for providing any
notion of what constitutes valid data collection (i.e., how
recent data must be to be considered acceptable, and how and
where it was collected).</t>
<t>Additionally, the OVAL Definitions Model could be modified
to support monitoring of events. As it is today, OVAL
doesn't have any explicit way to include these instructions,
but it would be simple to modify the model to include this
notion.</t>
<t>The OVAL System Characteristics Model allows the encoding
of collected information and can be used to implement a data
format for sharing collected data. While OVAL does not
require that tools store data using a standardized format
(though they are free to do so), a standardized format is
required to allow tools to exchange data. The OVAL System
Characteristics Model provides a standardized way to encode
this information for exchange.</t>
</section>
<section title="Evaluator" anchor="evaluator">
<t>An Evaluator is the component that analyzes inputs such as
Posture Attributes and Evaluation Guidance to determine the
result of a particular assessment. It is the piece that
answers a question about the security posture of one more
endpoints. The Evaluator must be able to ingest inputs of
various types, understand the question or questions asked of
it, and analyze the inputs to make a determination.</t>
<t>In this case, OVAL could be used to provide several of the
required inputs to an Evaluator. The format defined in the
OVAL Definitions Model could be used to express Evaluation
Guidance. Note that when mapping the OVAL Definitions Data
Model to the SACM Information Model, it is important to
distinguish between Collection and Evaluation within the
OVAL Definitions Model. The OVAL Definitions Model
structures currently combine both the Collection ("what to
collect") and Evaluation ("what the data should look like").
One of the key concepts within the SACM Information Model is
that Collection and Evaluation should be separate concepts.
Nonetheless, OVAL contains building blocks that could inform
solutions that satisfy this need.</t>
<t>Similarly, the structures defined in the OVAL System
Characteristics Model and the OVAL Results Model could be
used to inform the solutions that define the Attributes
input to the Evaluator and the results of an assessment
respectively.</t>
</section>
<section title="Endpoint Attribute Assertion"
anchor="endpoint-attribute-assertion">
<t>According to the SACM Information Model, an Endpoint
Attribute Assertion is a way to indicate that a specified
set of posture attributes or events were present on an
endpoint during a specific interval of time. For example, an
Assertion could be made that a particular Windows server had
the following attributes from 1/1/2015 - 1/8/2015: <list
style="symbols">
<t>os = Windows 7</t>
<t>mac-address = 01:24:42:58:34:2b</t>
</list>
</t>
<t>OVAL does not have a direct corollary to this construct;
however, the structures defined by the OVAL System
Characteristics Model could provide a base from which such a
construct could be built. The System Characteristics Data
Model is designed to capture posture attributes, and as
such, could be extended or modified to include the concept
of a time interval.</t>
<t>Additionally, it is important to note that the SACM
Information Model also states that Events can be included
within an Endpoint Attribute Assertion. While "event" and
"attribute" are often used interchangeably, in the SACM
Information Model, these two concepts are considered
distinct. The distinction is that an "event" is something
that has a value that does not change until something causes
a change, whereas an "attribute" is something that is
observed at
a moment in time. The Endpoint Attribute Assertion deals
with both posture attributes and events during a time
interval. No special treatment is given to Events within
OVAL as it is currently constructed, although, as stated
previously, adding a time interval to support Events is
simple to do.</t>
</section>
<section title="Evaluation Result" anchor="evaluation-result">
<t>An Evaluation Result is the representation of the analysis
of a given set of Posture Attributes against Evaluation
Guidance. The OVAL Results Model structures can be used to
encode one or more Evaluation Results.</t>
</section>
<section title="Collection Guidance"
anchor="collection-guidance">
<t>Within the SACM Information Model, Collection Guidance is
defined as information that describes which Posture
Attributes must be collected from one or more endpoints. It
is the means by which an Attribute Collector determines what
information it must collect, as well as when that
information must be collected (including intervals for
repeated collection activities).</t>
<t>The OVAL Definitions Model provides structures capable of
expressing information about what data must be collected for
an assessment. It is important to note that the method by
which the OVAL Definitions Model accomplishes this will not
necessarily directly apply to the SACM Information Model in
its current state. In many cases, which specific posture
attributes should be collected is not distinct from its
evaluation guidance. For the OVAL Definitions Model to be
used to implement the SACM Information Model, work would
need to be undertaken to de-couple these concepts.</t>
<t>While the model provides the ability to encode details such
as what data must be collected from the endpoint, it does
not currently provide the ability to include information
such as collection interval. The model can be extended,
however, to add this capability. Adding the concept of an
"interval" to the model to capture the concept may be a way
to accomplish this goal.</t>
<t>Important Note: One of the key drawbacks to OVAL is that
Platform Extensions (using the OVAL Definitions Model as a
base) must be created for each platform and data source to
capture any Posture Attributes that must be collected for a
given platform and data source. As a result, it is not easy
or scalable to create or update extensions for rapidly
changing platforms and products in a timely manner.</t>
<t>With this in mind, it is important that any use of the OVAL
Definitions Model to satisfy Collection Guidance for SACM
should warrant consideration of updates that change this
from a solution where the low-level platform details are
part of the language itself, to one where the format
provides a way for domain experts (ideally primary source
vendors) to instruct tools what Posture Attributes to
collect.</t>
<t>This also applies to the next section (Evaluation
Guidance).</t>
</section>
<section title="Evaluation Guidance"
anchor="evaluation-guidance">
<t>The Evaluation Guidance component contains the information
that directs an Evaluator how to perform one or more
assessments based on collected data. Evaluation Guidance
must direct the Evaluator on what the expected state of
collected data should be. Additionally, it must be able to
specify desired characteristics of the data. That is, it
must be able to not only cite the specific posture
attributes under evaluation, but also to specify
characteristics such as the type of tool that was used to
collect the data, how old the data is, etc.</t>
<t>The Evaluator must then ingest this guidance, locate the
required data-whether locally or remotely available-and then
execute the analysis required.</t>
<t>OVAL offers the OVAL Definitions Model to provide the
structures for encoding the expected state or values for
evaluating collected data. The OVAL Language does not currently provide
a way to specify the expected characteristics of the data,
but the OVAL Definitions Model could be augmented to include
this type of information. Alternatively, the concept could
be added elsewhere and re-used as appropriate. Allowing for
the description of characteristics information will be important to allow
evaluation to do things like only use data if it's been
collected within the past x days or only query data that is
collected by a credentialed collector.</t>
<t>Again, as Collection and Evaluation are intertwined
currently in the OVAL Language, some work will be required to
de-couple them for use with the Evaluation Guidance
component.</t>
</section>
<section title="Provenance" anchor="provenance">
<t>While the SACM Information Model does not attempt to define
provenance, it does describe metadata that should be
included when exchanging and evaluating posture attribute
information (e.g., source of origin, time of collection,
observation, etc.). This metadata aims to provide SACM users
with enough information to make a determination about the provenance
of data as it applies to their enterprise.</t>
<t>Within the OVAL Common Model, a Generator structure is
defined to express both what created the content, and when
it was created. While the purpose of this structure does not
meet all the metadata needs for SACM, it could be used
as a building block and be extended to achieve this goal.</t>
</section>
</section>
<section title="SACM Constructs with No OVAL Mapping"
anchor="sacm-constructs-with-no-oval-mapping">
<t>Finally, while there are many similarities between what is
defined by the SACM Information Model and the OVAL data
models, there are some things discussed in the SACM
Information Model document that are either different from
or not supported within OVAL.</t>
<section title="Tasking" anchor="tasking">
<t>The SACM Information Model discusses Tasks in a few places,
including the Collector, Evaluator, and Reporting sections.
Tasks represent of notion of "do something at this time",
"do something until told otherwise", or "do X when Y
occurs". OVAL does not support any notion of a tasking model as
currently defined.</t>
<t>While the OVAL Definitions Model (or some derivative) could
be referenced by a model that captures tasking, it may be
difficult to support all of the needs of tasking in this
way. Tasking may already be well defined by another,
existing model, and if so, it might be best to leverage that
existing work.</t>
</section>
<section title="Event-driven Actions"
anchor="event-driven-actions">
<t>Within the SACM Information Model, in addition to posture
attributes, events are also often part of the data
collection activities. Events are discussed as both part of
an Endpoint Attribute Assertion, and an Endpoint Attribute
Collector. In each case, it is clear that, in addition to
the collection of posture attribute data, event data must
also be taken into account.</t>
<t>The OVAL Language does not have any notion of capturing
events directly. It is constructed to allow the
representation of Posture Attribute data within the OVAL
System Characteristics Model, but event data is absent from
that model. OVAL can be modified to support Events in large
part by simply extending it to include a time interval.</t>
</section>
<section title="User and Authorization"
anchor="user-and-authorization">
<t>The Information Model talks about Users (i.e., one or more
end users or roles) and Authorizations (i.e., their
authority to undertake actions). While OVAL includes some
entities that may relate to these types of concepts, they
appear in very specific low-level tests like Windows and
UNIX user-related tests. OVAL lacks any general concept of
Users or Authorizations that could be applied across its
core data structures. The recommendation is to identify and
integrate an external solution into relevant OVAL models
to achieve required capabilities in this area.</t>
</section>
<section title="Location" anchor="location">
<t>Similar to Users and Authorization, Locations are defined
in the Information Model. Locations include physical
location (e.g., department, room, Global Positioning System
(GPS), wall-jack, etc.) and logical location (e.g., authentication
points, which network infrastructure endpoints it is
connected to, etc.).</t>
<t>Again, as for Users and Authorization, the recommendation
is for the relevant OVAL models to be integrated with other
solutions to meet these requirements.</t>
</section>
</section>
<section title="Lessons Learned and Gaps"
anchor="lessons-learned-and-gaps">
<t>Over the course of ten-plus years in moderating the OVAL
project, those involved in the project have released over 15
distinct versions of the Language, 25 versions of the OVAL
Interpreter, and have processed over 25,000 OVAL Definitions
in the OVAL Repository. In addition, the team has spent a lot
of time interacting with security tool vendors, researchers,
primary source vendors, and commercial and government end
users, discussing their needs and struggles. As such, the
following lessons learned are presented to help ensure that
the collective experience of the group is shared with the
larger community.</t>
<t>In addition to a description of the lesson, each also has a
suggested application for the SACM work.</t>
<section title="Simplicity is Key" anchor="simplicity-is-key">
<section title="Lesson" anchor="simplicity-is-key-lesson">
<t>Endpoint assessment covers a broad set of activities.
From organization to organization, assessment has
different meanings, and what is "good enough" for one
group, barely scratches the surface for another.
Experience suggested that caution must be used to avoid
unnecessary complexity as a means to address this
diversity.</t>
<t>The team has seen that when information sharing is
required across diverse parties, the simpler the exchange
mechanism design, the more successful the sharing effort
will be.</t>
</section>
<section title="SACM Implications"
anchor="simplicity-is-key-sacm-implications">
<t>Review both the diversity of the different organizations
that are sharing information within the SACM framework,
and the types and volume of information that must be
shared. Include only the information that is required to
successfully implement the desired use cases. The modular
organization of OVAL supports use of parts of OVAL for
different use cases. This organizational structure allows
for use of only the parts that are needed to support a use
case and nothing more.</t>
</section>
</section>
<section title="Collection and Evaluation Must Be De-coupled"
anchor="collection-and-evaluation-must-be-de-coupled">
<section title="Lesson"
anchor="collection-and-evaluation-must-be-de-coupled-lesson">
<t>As OVAL - and the security automation space in general -
has evolved, it has become clear that the close coupling
found in OVAL between the OVAL Object and OVAL State
(i.e., what to collect and what the collected data is
expected to look like) is an undesirable feature. By forcing these two
concepts into a single model, the Language does not easily
allow for easy extension, dynamic querying of previously collected data,
or efficiencies in data collection and data exchanges.</t>
</section>
<section title="SACM Implications"
anchor="collection-and-evaluation-must-be-de-coupled-sacm-implications">
<t>Keep the mechanism by which data is collected and
evaluated separate.</t>
</section>
</section>
<section title="Keep Separate Core and Extensions"
anchor="keep-separate-core-and-extensions">
<section title="Lesson"
anchor="keep-separate-core-and-extensions-lesson">
<t>OVAL, by design, must be frequently updated to keep up
with new and expanding sets of assessment platforms.
However, tool vendors incurred great cost in updating to
new versions of the Language, including implementing new
tests in the updated version, as well as general quality
testing, updating release and deployment, etc.</t>
<t>As the project matured, so too did the Core Models that
define the building blocks for endpoint assessment. Over
the past few years, the Core Models rarely changed-in some
cases, going years without any required update. The
Platform Extension Models, however, will always require a
frequent revision cycle, and often were out of date very
quickly. Despite the fact that these two models had
distinct release cycle requirements, with one continually
getting longer in the Core Models, and one requiring
agility in the Platform Extensions, a full release of both
was required to include changes to any part of the OVAL
Language.</t>
</section>
<section title="SACM Implications"
anchor="keep-separate-core-and-extensions-sacm-implications">
<t>SACM should focus on providing the foundational building
blocks that allow those that know how best to express what
data must be collected to assess an endpoint. The SNMP
standard <xref target="RFC1157"/> could be used as a model
for this type of separation. SNMP defines the building
blocks for sharing information about network devices, but
defers the low-level details of this information sharing
to those that best understand the products via Management
Information Bases (MIBs). While this is not a perfectly
analogous model for the SACM work, this clean separation
of core building blocks and protocols from the low-level
details of products should be emulated, if possible.</t>
</section>
</section>
<section title="Empower Subject Matter Experts"
anchor="empower-subject-matter-experts">
<section title="Lesson"
anchor="empower-subject-matter-experts-lesson">
<t>As the security automation field has matured, more
primary source vendors and other subject matter experts
have taken increased responsibility in ownership of how
their products are assessed. This step in maturity is
critical and, within OVAL, as these vendors have become
more involved, the quality in tests available to tools and
end users has greatly increased.</t>
</section>
<section title="SACM Implications"
anchor="empower-subject-matter-experts-sacm-implications">
<t>Ensure that usage of SACM means that those that best
understand the component being assessed are empowered to
instruct what data must be collected for the assessment,
along with the meaning of this data. As much as possible,
keep the mechanism by which this information is conveyed
as simple as possible to ensure that it is as easy as
possible for subject matter experts to participate.</t>
</section>
</section>
<section title="Carrots Work Better than Sticks"
anchor="carrots-work-better-than-sticks">
<section title="Lesson"
anchor="carrots-work-better-than-sticks-lesson">
<t>As much as possible, ensure that usage and compliance
with the defined standards is encouraged by offering
primary source vendors and subject matter experts
incentive to do so. Forced compliance typically encourages
organizations to do the least possible, and does not
entice them to continually stay engaged.</t>
</section>
<section title="SACM Implications"
anchor="carrots-work-better-than-sticks-sacm-implications">
<t>Find ways to encourage participation that drives long
term engagement and willing participation. Engage with
vendors to understand their problems and, where possible,
construct SACM use cases and requirements that not only
address the needs of the SACM end users, but also those of
the vendors. Build a compelling story for use of SACM that
not only shows value to end users, but shows a clear
return on investment for vendors.</t>
</section>
</section>
<section title="Use Caution Defining Data Collection"
anchor="use-caution-defining-data-collection">
<section title="Lesson"
anchor="use-caution-defining-data-collection-lesson">
<t>When providing information about what data must be
collected as part of an assessment, it can be quite easy
to provide this information in a way that dictates how to
collect the required data. Doing so can limit innovation
and architectural choices for organizations implementing
security automation tools.</t>
<t>On the other hand, it is not always feasible to express
what data must be collected without implying or
instructing specific data collection mechanisms. Over the
years, there have been a few cases where the OVAL
community could not agree on significant issues related to
data collection. Discussions on whether to allow open
scripting in the Language and how best to support both
third party and primary source contributions were very
challenging. With good arguments on both sides of these
issues, it was difficult to achieve consensus.</t>
</section>
<section title="SACM Implications"
anchor="use-caution-defining-data-collection-sacm-implications">
<t>This will be one of the bigger challenges for SACM to
navigate. SACM must allow those that best understand
platforms and products to instruct what data must be
collected for assessment. At the same time, third party
support will be critical in some cases as well, and
allowances must be made for this.</t>
<t>Additionally, deciding how many, if any, collection
methods are allowed as part of the collection instructions
will be challenging. Again, a balance should be struck to
best allow clarity in data collection instructions,
without limiting innovation and product-specific
decisions.</t>
</section>
</section>
<section title="Perspective Matters"
anchor="perspective-matters">
<section title="Lesson" anchor="perspective-matters-lesson">
<t>When evaluating collected posture attributes, it is
important to be able to include additional context to this
evaluation in some cases. For example, the method by which
data was collected could be an important piece of
information when performing evaluation. If the scanner was
a remote, unauthorized scanner of an endpoint, it is
entirely possible that the scanner could not properly scan
for a number of posture attributes. If, however, the
scanner ran locally on the endpoint as an administrative
user, it is much more likely that it accurately collected
posture attributes from the endpoint.</t>
<t>Other examples of this type of perspective and context
include how old the collected data is, and whether the
scanner was active or passive.</t>
</section>
<section title="SACM Implications"
anchor="perspective-matters-sacm-implications">
<t>Ensure information that provides necessary context can be
provided as part of data collection, thereby allowing
context-based decisions to be made.</t>
</section>
</section>
<section title="Flexible Results Fidelity is Important"
anchor="flexible-results-fidelity-is-important">
<section title="Lesson"
anchor="flexible-results-fidelity-is-important-lesson">
<t>After data collection and evaluation is complete,
evaluation results must be shared, often with
multiple parties, and in multiple ways. It is important
to provide a reasonable amount of flexibility with
respect to what levels of fidelity are allowed with
evaluation results. While OVAL did try to achieve a
reasonable amount of flexibility with evaluation
results fidelity, challenges still exist.</t>
</section>
<section title="SACM Implications"
anchor="flexible-results-fidelity-is-important-sacm-implications">
<t>As much as possible, allow the end users of evaluation
results to determine exactly what level of fidelity
they need to achieve their goals.</t>
</section>
</section>
<section title="Evaluation Guidance is Platform-Specific"
anchor="evaluation-guidance-is-platform-specific">
<section title="Lesson"
anchor="evaluation-guidance-is-platform-specific-lesson">
<t>In the early days of OVAL, initial adoption of the effort
was spearheaded by third party security vendors, as
opposed to the primary source vendors for software. As the
effort matured, more primary source vendors became
involved and adopted OVAL in some way. It quickly became
evident that, while third party vendors made great strides
in determining how to evaluate the security posture of
many platforms and products, understanding the best way to
evaluate is hard, and very platform-specific.
Additionally, OVAL content is costly to create, even for
seasoned content authors, due to the need to understand
these very low-level product and platform
complexities.</t>
</section>
<section title="SACM Implications"
anchor="evaluation-guidance-is-platform-specific-sacm-implications">
<t>As cited above, the primary source vendors are best
suited to provide evaluation guidance. It is very
challenging for third party organizations to truly
understand platform-specific evaluation. Empower primary
source vendors and other subject matter experts by
providing simple and effective ways to provide this
information. Also, as discussions on complex topics arise,
engage these primary source vendors to understand their
valuable views.</t>
</section>
</section>
</section>
<section title="Recommendations" anchor="recommendations">
<t>In order to successfully standardize the mechanisms by which
endpoint posture assessment is performed, the following
recommendations are offered to SACM for consideration.</t>
<section
title="Use the OVAL System Characteristics Model for Encoding Collection Data"
anchor="use-the-oval-system-characteristics-model-for-encoding-collection-data">
<t>The OVAL System Characteristics Model is used within the
OVAL Language in order to encode the underlying data
collected as part of endpoint posture assessment. Each of
the posture attributes collected by an OVAL-enabled tool can
be represented using the OVAL System Characteristics Model.
As such, this model should be used to inform the development
of a data model to encode collected posture attributes
within SACM.</t>
<t>Within the OVAL System Characteristics Model, information
such as metadata about the document (who/what created the
document, creation timestamp, etc.), endpoint identification
information (OS name, host name, and other asset-related
information), and the foundational constructs to allow the
encoding of posture attributes can be found. It is
understood that modifications to the model will be required
in order for it to fully implement all of the requirements
for SACM. However, the use of this well-supported,
standardized mechanism for encoding collected data is
recommended as SACM begins moving from Information Model
into Data Models and actual implementations.</t>
<t>The expectation is that SACM will need to make use of
multiple types of standardized formats to encompass a
complete solution for endpoint posture assessment. As such,
the OVAL System Characteristics Model could be used
to inform the development of a data model for encoding collected
data from an endpoint.</t>
</section>
<section
title="Use the OVAL Definitions Model for Collection and Evaluation Guidance"
anchor="use-the-oval-definitions-model-for-collection-and-evaluation-guidance">
<t>Similar to the OVAL System Characteristics Model, the OVAL
Definitions Model also has aspects that could be very useful
in guiding the development of a data model to capture
Collection Guidance. Collection Guidance is the mechanism by
which a content author can dictate what rules should be used
for collecting data from an endpoint. While the OVAL
Definitions Model, as it is today, is used for guidance of
both Collection and Evaluation, it is well suited to inform
the development of a data model for Collection Guidance.</t>
<t>This model provides several key features that should be
used as building blocks for this capability. For instance,
within the OVAL Definitions Model, there is a series of
structures that can serve as the base for instructing tools
as to what data must be collected, including abstract
structures for identifying required posture attributes,
Variables, and Functions (which allow several types of data
manipulation during collection). The model also supports a
number of different data types, such as strings, Booleans,
integers, records, and others.</t>
<t>While the recommendation is to make use of many of the
structures found within the OVAL Definitions Model, it is
equally important to note that the current approach for
extending OVAL into various platforms is flawed, and should
be fixed. Specifically, for every new check that is to be
added to the Language, a new concrete test must be created.
OVAL provides an abstract Test structure that must be
extended to create checks (e.g., "registry_test,"
"file_test," "ldap_test," etc.). For SACM, it is imperative
that a more scalable and flexible approach be
implemented.</t>
<t>One aspect of SACM that has been discussed, but only
partially worked into the Information Model at the time, is
the concept of high-level, platform-agnostic configuration
items and low-level platform-specific configuration items.
In the discussed concept, the high-level items will capture
the concepts of configuration that must be defined by those
who write the guidance, while the low-level items will be
provided by the appropriate vendors and/or subject matter
experts to allow those that best know the platforms and
products to instruct data collection. With this approach in
place, some of the concepts defined within the OVAL
Definitions Model (e.g., Objects, which instruct tools as to
what data to collect) will need to be modified or removed to
accommodate the shift in how posture attributes are defined
for Collection. As such, the recommendation is to use many
of the underlying structures in the OVAL Definitions Model,
including the data types, Variables, Functions, etc., as a
base from which to build a complete solution for fulfilling
the SACM Information Model.</t>
<t>In addition to utility in supporting Collection Guidance,
the same OVAL Definitions Model should also be used to
inform the development of a data model for Evaluation
Guidance. Again, with the current OVAL Language,
Collection and Evaluation are wrapped together in
the single model. The OVAL Definitions Model provides a
series of structures that can be used to support Boolean
logic statements, which could be useful for defining
evaluation criteria and could be used as the basis for a
further enhanced data model for Evaluation Guidance.</t>
</section>
<section
title="Do NOT Use the OVAL Results Model for Results Sharing"
anchor="do-not-use-the-oval-results-model-for-results-sharing">
<t>Despite the fact that the Results Model could be used to
share the results of the evaluation part of an endpoint
posture assessment, the recommendation is to not use this
model to represent this information within SACM. The OVAL
Results Model has, over the years, been a source of
contention at times within the OVAL Community. Some feel
like it provides too little information, while others
believe that it offers too much. While there is some
flexibility, in the form of OVAL Directives, in how much or
how little information is included in the results, it really
is not flexible enough to handle the broad set of
requirements for SACM without extensive re-working.</t>
<t>Furthermore, SACM is working hard at separating data
collection and evaluation, which makes the OVAL Results
Model a poor fit, as it was constructed with a more combined
Collection and Evaluation framework. It is expected that to
properly model all of the results requirements within SACM,
an alternative solution will be required.</t>
<t>While considering an alternative way to encode the results
of an assessment, the following requirements have been
stated by the OVAL Community as critical factors and should
be considered in the development of a new data model for
representing evaluation results: <list
style="symbols">
<t>Allow evaluation results with appropriate
granularity</t>
<t>Ensure support for enterprise scale uses</t>
<t>Provide results that include only the actionable
information</t>
<t>Ensure that data is clear and identifiable within the
results</t>
<t>Ensure interoperability</t>
</list>
</t>
</section>
</section>
<section anchor="OVAL-Submission" title="OVAL Submission">
<t>The OVAL submission to the IETF consists of seven
Internet-Drafts (I-Ds) that define the six core data models and
the processing model as described in <xref target="core-oval-models"
/>. Each of the core data model I-Ds include the
text from the OVAL Specification that defines the
the specific data model as well as the corresponding XML Schema that
implements it. The I-D for the processing model
includes the text from the OVAL Specification that
defines how each of the core data models work together. Given
that the processing model describes how the core data models
work together, there is no XML Schema associated with it.</t>
<t>The decision to split the OVAL Specification up into separate
Internet-Drafts was made to encourage SACM to leverage the parts of OVAL
that make the most sense and to emphasize that OVAL is not a
monolithic data model but rather several distinct data models.</t>
<t>Moving forward, SACM should review each of the OVAL models, consider the
recommendations in this document, and determine what concepts from OVAL
make sense to build upon. From there, SACM should prioritize its data model
efforts with respect to Collection Guidance, Evaluation Guidance,
Posture Attributes, and Evaluation Results as well as
determine how the data models should be implemented (e.g.
JSON, XML, etc.). Lastly, SACM should begin development on
its highest priority data model leveraging OVAL concepts where
appropriate and making improvements and design decisions based on
lessons learned.</t>
</section>
<section
title="Alignment with the SACM Vulnerability Assessment Scenario"
anchor="Alignment-with-the-SACM-Vulnerability-Assessment-Scenario">
<t>The SACM Vulnerability Assessment Scenario <xref
target="I-D.coffin-sacm-vuln-scenario"/>
describes a concrete, operational vulnerability management
scenario in an effort to break the SACM problem space into one
of several more manageable pieces. Specifically, the scenario
focuses on the following steps to determine which endpoints on
an enterprise's network are in a vulnerable state: <list
style="numbers">
<t>Endpoint identification and initial (pre-assessment) data
collection</t>
<t>Vulnerability description data</t>
<t>Endpoint applicability and secondary assessment</t>
<t>Assessment results</t>
</list>
The OVAL submission provides concepts and lessons learned that
will be valuable in developing the data models for Collection
Guidance, Evaluation Guidance, Posture Attributes, and
Evaluation Results which are necessary to support Steps 1, 2,
and 4 of the scenario. However, OVAL does not provide any
protocols or interfaces for communicating the configuration
information that would be expressed using these data models.
As a result, the Endpoint Compliance Profile [ECP]<!--TODO: Add reference here <xref
target=""/>--> which provides an extensible framework for
collecting, communicating, and evaluating endpoint information
could be extended to support these data models as it was for
software inventory information expressed using Software
Identification tags <xref target="ISO.19770-2"/>.
</t>
<t>The following sections describe how the OVAL submission fits
into each of these steps.</t>
<section title="Endpoint Identification and Initial Data
Collection"
anchor="Endpoint-Identification-and-Initial-Data-Collection">
<t>The first step of the SACM Vulnerability Assessment Scenario
relies on the ongoing collection of basic information about an
endpoint (e.g., type, criticality, hardware inventory,
software inventory, configuration settings, etc.) to identify
and characterize an endpoint. In order to do this, an
Attribute Collector must first know what information to collect
from an endpoint. This can either be hard-coded in an
Attribute Collector or it can be driven by Collection Guidance
with the latter being the more scalable approach. The OVAL
submission, more specifically the Objects section of the OVAL
Definitions Model, provides a data model for expressing what
configuration information should be collected from an
endpoint. This can be leveraged as a starting point for
Collection Guidance that can be modified to accommodate the
lessons learned around empowering subject matter experts (
i.e. primary source vendors) to identify what configuration
information should be collected on their platforms and
not dictating how tools must collect this information off
of an endpoint.</t>
<t>Once the configuration information has been collected
from an endpoint, it needs to be expressed in a format
that is consumable by other tools (i.e. Posture Attributes)
for identification, correlation, and evaluation purposes.
The OVAL submission includes the OVAL System
Characteristics Model which can serve as a starting point
for expressing this collected configuration information as
Posture Attribute in a way that is scalable and enables
subject matter experts to define it in a manner that makes
sense to them.</t>
</section>
<section title="Endpoint Applicability and Secondary Assessment"
anchor="Endpoint-Applicability-and-Secondary-Assessment">
<t>In this step, the Posture Attribute information collected,
in Step 1, is evaluated to determine the applicability of
vulnerability description data to an endpoint and to
determine if an endpoint is in a vulnerable state. If
additional information is required to make these
determinations, it can be collected during this step of
the scenario. The OVAL Submission aligns with this step in that it
provides the concepts and lessons learned to drive the
development of the
Collection Guidance and Posture Attributes data models
as described above. Furthermore, the OVAL Definitions Model
and OVAL Processing Model, in the OVAL submission, provide
a starting point for expressing the expected state of Posture
Attribute information as well as defining the logical framework and
algorithms necessary to compare the actual Posture Attribute
information to the expected state defined in the Evaluation
Guidance.</t>
</section>
<section title="Assessment Results" anchor="Assessment-Results">
<t>Lastly, the OVAL submission aligns with the Assessment Results
step of the scenario in that it identifies several problem
areas that have impacted the usefulness of the OVAL Results
Model which in turn led to several community-defined
requirements for the next-generation assessment results data model.
These shortcomings and requirements supplement the
information needs defined in the scenario and should be
significant in shaping the next-generation data model for
assessment results.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Brant Cheikes (MITRE), Juan
Gonzalez (DHS), Adam Montville (CIS), Charles Schmidt (MITRE),
David Waltermire (NIST), and Kim Watson (JHU APL) for reviewing
this document and providing helpful feedback.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This memo documents, for informational purposes, the mapping
between the OVAL Data Models and the SACM Information Model as
well as the lessons learned from the past 10+ years of
developing OVAL. As a result, there are no specific security
considerations.</t>
</section>
<section anchor="ChangeLog" title="Change Log">
<section anchor="latest" title="-02 to -03">
<t>There are no textual changes associated with this revision.
This revision simply reflects a resubmission of the document
so that it remains in active status.</t>
</section>
<section title="-01 to -02">
<t>Updated to reflect the latest changes to the SACM
Information Model.</t>
<t>Added text that describes how the OVAL submission is
expected to be used by the SACM WG.</t>
<t>Discusses how OVAL aligns with the SACM Vulnerability
Assessment Scenario.</t>
<t>Updated references to documents on the MITRE OVAL website
to the OVAL community documentation site on GitHub.io.</t>
<t>Added the OVAL Processing Model to the list of core models
supported in OVAL.</t>
</section>
<section title="-00 to -01">
<t>There are no textual changes associated with this revision.
This revision simply reflects a resubmission of the document
so that it goes back into active status. The document
expired on November 6, 2015.</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
&I-D.coffin-sacm-vuln-scenario;
<reference anchor="ISO.19770-2">
<front>
<title abbrev="ISO/IEC 19770-2:2009">Information technology -- Software asset
management -- Part 2: Software identification tag</title>
<author/>
<date year="2009"/>
</front>
<seriesInfo name="ISO/IEC" value="19770-2"/>
</reference>
<reference anchor="SACM"
target="https://datatracker.ietf.org/wg/sacm/charter/">
<front>
<title>IETF Security Automation and Continuous Monitoring
(sacm) Working Group Charter</title>
<author>
<organization>The IETF SACM WG</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="SACM-DOCUMENTS"
target="https://datatracker.ietf.org/wg/sacm/documents/">
<front>
<title>IETF Security Automation and Continuous Monitoring
(sacm) Working Group Documents</title>
<author>
<organization>The IETF SACM WG</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="OVAL-DEFINITION-TUTORIAL"
target="http://ovalproject.github.io/getting-started/tutorial/">
<front>
<title>The OVAL Definition Tutorial</title>
<author>
<organization>United States Government</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="OVAL-DOCUMENTATION"
target="http://ovalproject.github.io/">
<front>
<title>The OVAL Definition Tutorial</title>
<author>
<organization>United States Government</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="I-D.ietf-sacm-requirements"
target="http://www.ietf.org/id/draft-ietf-sacm-requirements-04.txt">
<front>
<title>Secure Automation and Continuous Monitoring (SACM)
Requirements</title>
<author>
<organization>Cam-Winget, N. and L.
Lorenzin</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="I-D.ietf-sacm-architecture"
target="http://www.ietf.org/id/draft-ietf-sacm-architecture-03.txt">
<front>
<title>Secure Automation and Continuous Monitoring (SACM)
Architecture</title>
<author>
<organization>Cam-Winget, N., Ford, B., Lorenzin, L.,
McDonald, I., and l. loxx@cisco.com</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="STRUCTURE-OF-OVAL"
target="http://ovalproject.github.io/getting-started/best-practices/#2-structure-of-the-oval-language">
<front>
<title>Structure of the OVAL Language</title>
<author>
<organization>The MITRE Corporation</organization>
</author>
<date year="2015"/>
</front>
</reference>
<reference anchor="RFC1157"
target="https://www.ietf.org/rfc/rfc1157.txt">
<front>
<title>A Simple Network Management Protocol (SNMP)</title>
<author>
<organization>Case, J., Fedor, M., Schoffstall, M., and J.
Davin</organization>
</author>
<date year="1990"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes
problems).
2015-04-17 AR updated ipr attribute. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:30:34 |