Clarification of an Initial Release

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Clarification of an Initial Release

Andrew Buttner
Administrator
All,

There has been a lot of talk about how to create CPE Names for initial
releases.  This conversation is often had under the notion of a given
platform that does not have a notion of a specific component.  For
example, an application that does not support different languages, or
an operating system that does not have updates.

The issue is that there are some uses within the CPE Community that
need to use CPE Names that do NOT leave that component blank.  Remember
that a blank component is used in a CPE Name to identify a platform
type regardless of the value for that component.  E.G. an application
CPE Name with a blank edition would represent the platform type for the
application regardless of the edition.  Unfortunately we often find
within the industry that an initial release of a platform might not
have editions, but future releases will.  Use of the CPE Name with a
blank edition would match both the initial release and any future
releases.  The question is how do we create the CPE Name for that
initial release.

The current CPE Specification (version 2.1) clarifies this point for
the update component and directs us to use a vendor term like 'gold' or
'ga'.  Unfortunately, the specification does not say how to handle the
situation when there is no vendor term or for components other than
update.  I have been asked to provide some official clarification for
this.  Please note that this clarification will be added to any future
version of the specification.

-------------------------------------------------

Clarification:

If attempting to create a CPE Name for a given platform that does not
have or define a certain component, and it is desired to enumerate a
specific release guarding against future releases that may introduce
the component (e.g. the release of a new edition), then the value
'_nil_' should be used.  Note that some vendors do in fact define a
term of an initial release but do not use this term in the marketing
name. In these cases, that term should be used instead of '_nil_'.  An
example of this is with the Microsoft Windows operating system where
the initial release is known without a service pack.  In this case, the
vendor does in fact have a term for this release (gold) and that vendor
term should be used instead of '_nil_'.

-------------------------------------------------

I hope this clarifies the issue at hand.  Again, this clarification
will be added to any future version of the CPE Specification.  Until
that time, I hope this email serves as a reference to help create CPE
Names under version 2.1.  I will make sure to post this clarification
to the FAQ section of the CPE web site.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

DoD DRAFT Assessment Results Format for comment

Wolfkiel, Joseph
All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable
tools in the near future and will need to require a common reporting
language for SCAP-related assessment results.  Since there is no
existing language or publishing interface that meets our requirements,
we are planning to require reporting using the ARF language and web
services specification in the attached.  

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.5 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
        <name>
                <vendor confidence=.9>mozilla</vendor>
                <product confidence=.9>firefox</product>
                <major_version confidence=.9>4</major_version>
                <minor_version confidence=.3>4</minor_version>
                <minor_version confidence=.3>5</minor_version>
                <minor_version confidence=.3>6</minor_version>
        </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in
our acquisitions, they will be supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel




ARF Spec 08 Nov 08.doc (941K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Wolfkiel, Joseph
Just as a clarification, while I am interested in comments on the entire
document, it is the device record, and particularly the cpe_record that
I would like comments on from the CPE list.

- Joe

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, November 17, 2008 4:34 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for
comment

All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable tools in the near future and will
need to require a common reporting language for SCAP-related assessment
results.  Since there is no existing language or publishing interface
that meets our requirements, we are planning to require reporting using
the ARF language and web services specification in the attached.  

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.5 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
        <name>
                <vendor confidence=.9>mozilla</vendor>
                <product confidence=.9>firefox</product>
                <major_version confidence=.9>4</major_version>
                <minor_version confidence=.3>4</minor_version>
                <minor_version confidence=.3>5</minor_version>
                <minor_version confidence=.3>6</minor_version>
        </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in our acquisitions, they
will be supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of an Initial Release

Waltermire, David A.
In reply to this post by Andrew Buttner
All,

Thank you Drew for moving this issue forward.  This issue is important to us
for the stated and other reasons.  It is our opinion that _nil_ should
replace any vendor term used within the CPE Name where the semantic meaning
is the same.  Consistency is important here.  This will greatly simplify the
naming guidance and will result in greater consistency in naming which is a
win overall.  If this isn't done, it makes naming much more complicated than
it needs to be.  When using the _nil_ approach, any titles provided can
still use the vendor terminology preserving the vendor name for the human
readable form.  In fact, this should be encouraged.  I would recommend that
we deprecate the old vendor proprietary entries in the near future to keep
everything consistent.

I disagree that no change to the specification is necessary.  The
specification is important to allow coordinated CPE Name creation by vendors
and other originators of CPE Name content.  The CPE naming guidance in the
CPE Specification should be updated to provide instruction on using this
approach.  With new vendors and other contributors providing content on a
regular basis, it is unreasonable to expect them to refer to the CPE
Discussion List and/or FAQ for clarifications.  Instead the CPE
Specification should be updated to provide the sole reference for all CPE
Naming guidance on a regular basis.

There appears to be a common consensus within the CPE community that CPE
Names are needed to identify products that can be downloaded, installed,
managed, licensed, patched, etc.  In order to support this use case, our
original proposal recommended that _nil_ components could be used as a
placeholder for components that are not needed to describe a distinct
product.  This allows all 7 components of a CPE Name to be provided, which
we call a canonical CPE Name.  I have attached this proposal for anyone who
would like to read more about it.

Lastly, it would be useful to have a formal comment period for all current
and future proposals to keep things moving forward.  Perhaps two weeks would
work with more time allocated if needed to resolve discussion.  My hope is
that we can move forward in a deliberate fashion in addressing the
shortcomings of the current CPE Specification in a way that enhances its
applicability to all the use cases for which it is needed.  I encourage all
of you to provide timely feedback on this and future proposals.  We need
your comments to move the standard forward.

Sincerely,

Dave Waltermire
NVD Development Team Lead
(301) 975-8441

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Saturday, November 15, 2008 7:17 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Clarification of an Initial Release

All,

There has been a lot of talk about how to create CPE Names for initial
releases.  This conversation is often had under the notion of a given
platform that does not have a notion of a specific component.  For
example, an application that does not support different languages, or
an operating system that does not have updates.

The issue is that there are some uses within the CPE Community that
need to use CPE Names that do NOT leave that component blank.  Remember
that a blank component is used in a CPE Name to identify a platform
type regardless of the value for that component.  E.G. an application
CPE Name with a blank edition would represent the platform type for the
application regardless of the edition.  Unfortunately we often find
within the industry that an initial release of a platform might not
have editions, but future releases will.  Use of the CPE Name with a
blank edition would match both the initial release and any future
releases.  The question is how do we create the CPE Name for that
initial release.

The current CPE Specification (version 2.1) clarifies this point for
the update component and directs us to use a vendor term like 'gold' or
'ga'.  Unfortunately, the specification does not say how to handle the
situation when there is no vendor term or for components other than
update.  I have been asked to provide some official clarification for
this.  Please note that this clarification will be added to any future
version of the specification.

-------------------------------------------------

Clarification:

If attempting to create a CPE Name for a given platform that does not
have or define a certain component, and it is desired to enumerate a
specific release guarding against future releases that may introduce
the component (e.g. the release of a new edition), then the value
'_nil_' should be used.  Note that some vendors do in fact define a
term of an initial release but do not use this term in the marketing
name. In these cases, that term should be used instead of '_nil_'.  An
example of this is with the Microsoft Windows operating system where
the initial release is known without a service pack.  In this case, the
vendor does in fact have a term for this release (gold) and that vendor
term should be used instead of '_nil_'.

-------------------------------------------------

I hope this clarifies the issue at hand.  Again, this clarification
will be added to any future version of the CPE Specification.  Until
that time, I hope this email serves as a reference to help create CPE
Names under version 2.1.  I will make sure to post this clarification
to the FAQ section of the CPE web site.

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

cpe-canonical-names-proposal.doc (68K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Dawn Adams
In reply to this post by Wolfkiel, Joseph
I like the system you are describing here and I think it could be very
useful. I am not sure if the following would be helped or hindered by this
approach so I am throwing it out to you.

I have a question regarding software component CPE identification. If, for
example, you had a software product consisting of Service V1.0 and a Client
v2.0 but together they made Product V3.0, what would the CPE ID actually be
assigned to and if you ran checks for versions like the Windows checks,
which version should the product be reporting? Also, if Client v2.0 can run
on its own without Server v1.0 would this be a different product wrt CPE?
Could different clients be added in easily? Thanks in advance.

Dawn Adams
SCAP Lead
EWA-Canada
613-230-6067 x. 1249

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: November 17, 2008 5:22 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for
comment

Just as a clarification, while I am interested in comments on the entire
document, it is the device record, and particularly the cpe_record that
I would like comments on from the CPE list.

- Joe

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, November 17, 2008 4:34 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for
comment

All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable tools in the near future and will
need to require a common reporting language for SCAP-related assessment
results.  Since there is no existing language or publishing interface
that meets our requirements, we are planning to require reporting using
the ARF language and web services specification in the attached.  

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.5 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
        <name>
                <vendor confidence=.9>mozilla</vendor>
                <product confidence=.9>firefox</product>
                <major_version confidence=.9>4</major_version>
                <minor_version confidence=.3>4</minor_version>
                <minor_version confidence=.3>5</minor_version>
                <minor_version confidence=.3>6</minor_version>
        </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in our acquisitions, they
will be supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Wolfkiel, Joseph
My assumption is that you would report all three.  This is important
because we may have vulnerabilities or configuration guidance defined
for the service, client, and/or product independently.  Given a choice
we would lean toward getting more, possibly redundant, information over
trying to build some sort of filtering/combination rules for community
use.  It's possible that NIST may host and distribute a set of rules
governing how to combine multiple low-level platform names into
higher-level CPEs, but I don't think we're anywhere near that level of
maturity.

- Joe Wolfkiel

-----Original Message-----
From: Dawn Adams [mailto:[hidden email]]
Sent: Tuesday, November 18, 2008 6:25 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format
for comment

I like the system you are describing here and I think it could be very
useful. I am not sure if the following would be helped or hindered by
this approach so I am throwing it out to you.

I have a question regarding software component CPE identification. If,
for example, you had a software product consisting of Service V1.0 and a
Client v2.0 but together they made Product V3.0, what would the CPE ID
actually be assigned to and if you ran checks for versions like the
Windows checks, which version should the product be reporting? Also, if
Client v2.0 can run on its own without Server v1.0 would this be a
different product wrt CPE?
Could different clients be added in easily? Thanks in advance.

Dawn Adams
SCAP Lead
EWA-Canada
613-230-6067 x. 1249

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: November 17, 2008 5:22 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format
for comment

Just as a clarification, while I am interested in comments on the entire
document, it is the device record, and particularly the cpe_record that
I would like comments on from the CPE list.

- Joe

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, November 17, 2008 4:34 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for
comment

All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable tools in the near future and will
need to require a common reporting language for SCAP-related assessment
results.  Since there is no existing language or publishing interface
that meets our requirements, we are planning to require reporting using
the ARF language and web services specification in the attached.  

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.5 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
        <name>
                <vendor confidence=.9>mozilla</vendor>
                <product confidence=.9>firefox</product>
                <major_version confidence=.9>4</major_version>
                <minor_version confidence=.3>4</minor_version>
                <minor_version confidence=.3>5</minor_version>
                <minor_version confidence=.3>6</minor_version>
        </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in our acquisitions, they
will be supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Ernest Park
In reply to this post by Wolfkiel, Joseph
Hi Joe,

Will you be having a call to review this, or do you prefer everything in documentary format?

Secondly, do you want comments in this thread, or appended inline to the document?



Regards,


Ernie
 

On Mon, Nov 17, 2008 at 4:34 PM, Wolfkiel, Joseph <[hidden email]> wrote:
All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable
tools in the near future and will need to require a common reporting
language for SCAP-related assessment results.  Since there is no
existing language or publishing interface that meets our requirements,
we are planning to require reporting using the ARF language and web
services specification in the attached.

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.5 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
       <name>
               <vendor confidence=.9>mozilla</vendor>
               <product confidence=.9>firefox</product>
               <major_version confidence=.9>4</major_version>
               <minor_version confidence=.3>4</minor_version>
               <minor_version confidence=.3>5</minor_version>
               <minor_version confidence=.3>6</minor_version>
       </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in
our acquisitions, they will be supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel




Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Ernest Park-2
In reply to this post by Wolfkiel, Joseph
Hi Joe,

some comments inline . . .



 
On Mon, Nov 17, 2008 at 4:34 PM, Wolfkiel, Joseph <[hidden email]> wrote:
All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable
tools in the near future and will need to require a common reporting
language for SCAP-related assessment results.  Since there is no
existing language or publishing interface that meets our requirements,
we are planning to require reporting using the ARF language and web
services specification in the attached.

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.5 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
       <name>
               <vendor confidence=.9>mozilla</vendor>
               <product confidence=.9>firefox</product>
               <major_version confidence=.9>4</major_version>
               <minor_version confidence=.3>4</minor_version>
               <minor_version confidence=.3>5</minor_version>
               <minor_version confidence=.3>6</minor_version>
       </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

E - Without an explicit algorithm to specially sort releases, versions, products, the results become subjective and hard to compare to one another. I have an algorithm that does sort releases and products, and scores probability. I can show you how this works.

E - The XML should then be a data exchange format that feeds and draws from a deep and wide data structure. The URI supports deep, but only in a single myopic path at a time, with no visibility on all the other similar deep data.

E - As an aside, is the confidence index machine generated following a published algorithm? Otherwise, is this the output of a tool or set of tools?  

E - What is the definition of the elements within this XML?

E - Is XML the final data storage medium, or is there a SQL database behind this? If so, can I review a copy of the structure?


2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

E - Flexible tagging does allow a schema extension and the addition of value add information. As long as the basic data elements are there, the value add components can be how special applications, business and government units layer proprietary information. Regarding naming, if the attribute or element is beyond the required mandatory to support the schema, then any name for any element or attribute should be accepted, aside from reserved names.
 
E - What might be accepted is that any "non-standard" tag  follows a special naming syntax, such as
 
<special___type
 
special___type/>
 
 
where any no-standard, or proprietary schema extension would preface the name with "special___ "
 
 
E - Are you using the URIs to "query" the information, or store it?  What do expect ot get back?
 
I believe that the XML schema would need to have mandatory attributes and elements within the data structure. Anything beyond that is a value add, and can be added by working group members, users and vendors for value add and proposed enhancement.
 
 
Note the example herein . . .

 

<cpe-item name="cpe:///apache_software_foundation:http_server:2.2.0"

  name_2=cpe:/a: apache_software_foundation:http_server:2.2.0 ">

  <title>Application Apache Software Foundation, HTTP Server, 2.2.0</title>  

<vendor 

vendor="apache_software_foundation"

license_type="unknown"

type="enterprise"

alias="Apache"

alias="Apache Foundation"

name="cpe:///apache_software_foundation">

<application

is_master="true"

application="http_server"

license_type="unknown"

type="web server"

alias="httpd:Web Server"

name="cpe:///apache_software_foundation:http_server">

<release

release="2.2.0"

license="GPLv2"

type="open source"

alias="2.2 alpha"

alias_to="cpe:///apache_software_foundation:http_server:2.2_alpha"

license_url="http://license"

license_text="xsdddssdsdsd

name="cpe:///apache_software_foundation:http_server:2.2.0">

<releasefile 

<1 

name="apache-httpd-2.2.0.tar.gz"

md5="abcdef12345xxx">

</1>

</releasefile>

</release>

</application>

</vendor>

</cpe-item>

 

 

If we had a basic "accepted schema, I could output the data "required" for compliance with your needs, while still being able to deliver value added data from my tool. The example above was the result of a scan using my tool, and a query against two databases to output the results.

 


3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?
 
 
E - There are third party scanning and identification tools. Palamida makes tools for this. Palamida's tool stores information in CPE format, and uses additional SCAP data to provide a deep and wide view of what is discovered. The product is pre-populated with all known open source software, and then you can add proprietary software, based on what is licensed, or custom built. Not to seem like a commercial, but much of this is COTS, requiring only customization for report formatting.
 
E - completely unknown, where an entire tree of files exists, can be flagged as "unknown". Requiring user intervention, a name could be "suggested" using what may be found within a group of files, but this would allow user verified creation of new CPE names.
 
E - One thing that is not mentioned is that if my server is inventing CPE names, there should be a central registry format, like a federated directory, that I can do a lookup, and register a new name, or register an alias to an existing name. In this way, the repository grows with the community use feeding a single common database, and becomes more useful and accurate each day that it is used.


4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?
 
 
E - My example above includes a hash - which I edited for this. I store SHA, MD5 and proprietary hashes. A product may have hundreds of hashes tied to it, and a hash, points back to the array of products and releases known to contain it. It is a definative identifier.
 
 

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in
our acquisitions, they will be supportable by SCAP vendors.
 
 
E - I have a audit server accessible via the internet. If you want to look, it may give you a different perspective on setting guidelines and requirements for audit, data reporting requirements, and dealing with "unknown" software. FOSSBazaar also hosts some white papers on this topic and the need to normalize and standardize this kind of data.
 

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel



 
Regards,
 
Ernest Park
VP, Research
Palamida, Inc.
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Wolfkiel, Joseph
Thanks Ernest,  I'm going to have to put some thought into your responses, so please don't interpret silence as indifference or disagreement.


From: Ernest Park [mailto:[hidden email]]
Sent: Wednesday, November 19, 2008 1:53 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment

Hi Joe,

some comments inline . . .



 
On Mon, Nov 17, 2008 at 4:34 PM, Wolfkiel, Joseph <[hidden email]> wrote:
All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable
tools in the near future and will need to require a common reporting
language for SCAP-related assessment results.  Since there is no
existing language or publishing interface that meets our requirements,
we are planning to require reporting using the ARF language and web
services specification in the attached.

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.5 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
       <name>
               <vendor confidence=.9>mozilla</vendor>
               <product confidence=.9>firefox</product>
               <major_version confidence=.9>4</major_version>
               <minor_version confidence=.3>4</minor_version>
               <minor_version confidence=.3>5</minor_version>
               <minor_version confidence=.3>6</minor_version>
       </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

E - Without an explicit algorithm to specially sort releases, versions, products, the results become subjective and hard to compare to one another. I have an algorithm that does sort releases and products, and scores probability. I can show you how this works.

E - The XML should then be a data exchange format that feeds and draws from a deep and wide data structure. The URI supports deep, but only in a single myopic path at a time, with no visibility on all the other similar deep data.

E - As an aside, is the confidence index machine generated following a published algorithm? Otherwise, is this the output of a tool or set of tools?  

E - What is the definition of the elements within this XML?

E - Is XML the final data storage medium, or is there a SQL database behind this? If so, can I review a copy of the structure?


2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

E - Flexible tagging does allow a schema extension and the addition of value add information. As long as the basic data elements are there, the value add components can be how special applications, business and government units layer proprietary information. Regarding naming, if the attribute or element is beyond the required mandatory to support the schema, then any name for any element or attribute should be accepted, aside from reserved names.
 
E - What might be accepted is that any "non-standard" tag  follows a special naming syntax, such as
 
<special___type
 
special___type/>
 
 
where any no-standard, or proprietary schema extension would preface the name with "special___ "
 
 
E - Are you using the URIs to "query" the information, or store it?  What do expect ot get back?
 
I believe that the XML schema would need to have mandatory attributes and elements within the data structure. Anything beyond that is a value add, and can be added by working group members, users and vendors for value add and proposed enhancement.
 
 
Note the example herein . . .

 

<cpe-item name="cpe:///apache_software_foundation:http_server:2.2.0"

  name_2=cpe:/a: apache_software_foundation:http_server:2.2.0 ">

  <title>Application Apache Software Foundation, HTTP Server, 2.2.0</title>  

<vendor 

vendor="apache_software_foundation"

license_type="unknown"

type="enterprise"

alias="Apache"

alias="Apache Foundation"

name="cpe:///apache_software_foundation">

<application

is_master="true"

application="http_server"

license_type="unknown"

type="web server"

alias="httpd:Web Server"

name="cpe:///apache_software_foundation:http_server">

<release

release="2.2.0"

license="GPLv2"

type="open source"

alias="2.2 alpha"

alias_to="cpe:///apache_software_foundation:http_server:2.2_alpha"

license_url="http://license"

license_text="xsdddssdsdsd

name="cpe:///apache_software_foundation:http_server:2.2.0">

<releasefile 

<1 

name="apache-httpd-2.2.0.tar.gz"

md5="abcdef12345xxx">

</1>

</releasefile>

</release>

</application>

</vendor>

</cpe-item>

 

 

If we had a basic "accepted schema, I could output the data "required" for compliance with your needs, while still being able to deliver value added data from my tool. The example above was the result of a scan using my tool, and a query against two databases to output the results.

 


3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?
 
 
E - There are third party scanning and identification tools. Palamida makes tools for this. Palamida's tool stores information in CPE format, and uses additional SCAP data to provide a deep and wide view of what is discovered. The product is pre-populated with all known open source software, and then you can add proprietary software, based on what is licensed, or custom built. Not to seem like a commercial, but much of this is COTS, requiring only customization for report formatting.
 
E - completely unknown, where an entire tree of files exists, can be flagged as "unknown". Requiring user intervention, a name could be "suggested" using what may be found within a group of files, but this would allow user verified creation of new CPE names.
 
E - One thing that is not mentioned is that if my server is inventing CPE names, there should be a central registry format, like a federated directory, that I can do a lookup, and register a new name, or register an alias to an existing name. In this way, the repository grows with the community use feeding a single common database, and becomes more useful and accurate each day that it is used.


4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?
 
 
E - My example above includes a hash - which I edited for this. I store SHA, MD5 and proprietary hashes. A product may have hundreds of hashes tied to it, and a hash, points back to the array of products and releases known to contain it. It is a definative identifier.
 
 

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in
our acquisitions, they will be supportable by SCAP vendors.
 
 
E - I have a audit server accessible via the internet. If you want to look, it may give you a different perspective on setting guidelines and requirements for audit, data reporting requirements, and dealing with "unknown" software. FOSSBazaar also hosts some white papers on this topic and the need to normalize and standardize this kind of data.
 

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel



 
Regards,
 
Ernest Park
VP, Research
Palamida, Inc.
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Wolfkiel, Joseph
In reply to this post by Ernest Park
I hadn't really thought about having a call.  I could host one if there's a demand.  Do you think it would be worth the effort?
 
- Joe


From: Ernest Park [mailto:[hidden email]]
Sent: Wednesday, November 19, 2008 11:36 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment

Hi Joe,

Will you be having a call to review this, or do you prefer everything in documentary format?

Secondly, do you want comments in this thread, or appended inline to the document?



Regards,


Ernie


On Mon, Nov 17, 2008 at 4:34 PM, Wolfkiel, Joseph <[hidden email]> wrote:
All,

Please find the attached specification the DoD is considering as the
basis of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in
the market to acquire SCAP-capable
tools in the near future and will need to require a common reporting
language for SCAP-related assessment results.  Since there is no
existing language or publishing interface that meets our requirements,
we are planning to require reporting using the ARF language and web
services specification in the attached.

What I need from SCAP vendors is an assessment of whether ARF will work
for reporting the outputs of their tools, and (if not) what changes will
be required to provide generalized SCAP reporting capabilities.  Our
primary use cases are for host-based vulnerability scanning and
compliance checking and for network-based vulnerability/compliance
scanners.  Though, in general, any assessment tool that builds an
inventory of devices, installed hardware, OS, applications, settings,
vulnerabilities, patches, running services, and/or device behaviors
would be expected to use this reporting format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported
as component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to
tag each component name with metadata tags independently -- E.g we have
several cases where we have a software package that may be one of a
range of different versions that can be assigned different
probabilities.  As an example, if we know a certain CPE is Mozilla
Firefox version 4 with a sub-version in the range of 4-6, with a 90%
probability the major version is 4 and equal probabilities the minor
versions are 4,5, or 6, we could either report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.5 confidence=.3/>
<cpe-record name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
       <name>
               <vendor confidence=.9>mozilla</vendor>
               <product confidence=.9>firefox</product>
               <major_version confidence=.9>4</major_version>
               <minor_version confidence=.3>4</minor_version>
               <minor_version confidence=.3>5</minor_version>
               <minor_version confidence=.3>6</minor_version>
       </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for
one-off use cases, such as "last seen" or "hit count" or other metrics
that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again),
I'm not convinced that out-of-band negotiations on what are valid tag
names, enumerations, and constraints are a good way to manage a
standard.

3.  We want to return a list of all installed software on a given box,
even if it's not previously identified via an OVAL check or enumerated
in the CPE dictionary.  Is it reasonable to expect to be able to report
newly discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a
demand for these tags?  What restrictions can be placed on their data
types?

5.  This is our first widespread dissemination of the web-service
behaviors we expect from assessment tools that are fielded inside of DoD
firewalls and report to external consumers.  It's our best effort to
support both the security issues of firewall policy (outbound only) as
well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we
start putting these reporting requirements in
our acquisitions, they will be supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to
go final so we can begin to build ARF into one or more of our GOTS
tools.

I appreciate your feedback.

- Joe Wolfkiel




Reply | Threaded
Open this post in threaded view
|

Re: Clarification of an Initial Release

Andrew Buttner
Administrator
In reply to this post by Andrew Buttner
All,

I have been asked to re-open this clarification for further discussion, and set a defined review period before a final decision will be reached.  In the rest of this email, I will try to outline the issues at hand and the different views that exist.  The discussion will then be open for two weeks.  After two weeks, I will either post a new clarification if consensus has been reached, or if consensus was not reached, then I will forward the discussion to our Government sponsors for a decision.  Please note that in the near future I will be formalizing this review process and documenting it on the CPE web site.

The main issue is explained in the previous email (see the bottom of this email).  It deals with which term to use when creating a CPE for an initial release.  We often find cases where a given component does not apply to the specific platform type we want to name.  We are trying to clarify which term to use.

Some options that have been proposed in the past are:

ga
null
no_component
blank
_nil_

In addition, another aspect of this is whether to use a vendor specific term if one exists, or to always use the term stated above.  There have been arguments for using vendor terms when applicable as it makes the CPE Name more understandable by a human user.  Having vendor terms can make searching (within an application) for an appropriate CPE easier since one would search with common terms.  E.g. a user might not know if Acme Red (IR) would be cpe:/a:acme:red:ir or cpe:/a:acme:red:null.  It also makes the process of creating names easier as one simply uses the known terms.  Two examples in the current dictionary are:

cpe:/o:redhat:enterprise_linux:5:ga
cpe:/o:microsoft:windows_2003_server::gold

There have also been arguments against using vendor terms.  If a non-vendor is creating new CPE Names then that individual will be forced to research the different vendors to know if there is a vendor term or not.  Additionally, users that have access to the Official CPE Dictionary can still search for a specific CPE Name by looking at the <title> field.

One additional point to consider is that the current CPE Specification (version 2.1) does say in the UPDATE component section to use vendor terms.  This has lead to the creation of CPE Names that use vendor terms.  The exclusion of vendor terms going forward would force us to either have CPE Names that don't follow the spec (they would still be unique identifiers) or to deprecate those existing names and replace them with new names.

Moving forward ... I would love to hear comments from the community on the following two points:

1) What term should be used in a component when creating a new CPE Name in instances where a platform doesn't specify that component (no current edition) or when the platform being described is an initial release and the component may be used to differentiate future releases (an unplanned service pack)?

2) Should vendor terms (e.g. 'ga' or 'gold') be used when appropriate or should the term specified above be used in all cases regardless, even if a different term is commonly used by the vendor?

Again, this discussion will be open until noon on Thursday December 4th, 2008.

Thanks
Drew




>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Saturday, November 15, 2008 7:17 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
>All,
>
>There has been a lot of talk about how to create CPE Names for initial
>releases.  This conversation is often had under the notion of a given
>platform that does not have a notion of a specific component.  For
>example, an application that does not support different languages, or
>an operating system that does not have updates.
>
>The issue is that there are some uses within the CPE Community that
>need to use CPE Names that do NOT leave that component blank.  Remember
>that a blank component is used in a CPE Name to identify a platform
>type regardless of the value for that component.  E.G. an application
>CPE Name with a blank edition would represent the platform type for the
>application regardless of the edition.  Unfortunately we often find
>within the industry that an initial release of a platform might not
>have editions, but future releases will.  Use of the CPE Name with a
>blank edition would match both the initial release and any future
>releases.  The question is how do we create the CPE Name for that
>initial release.
>
>The current CPE Specification (version 2.1) clarifies this point for
>the update component and directs us to use a vendor term like 'gold' or
>'ga'.  Unfortunately, the specification does not say how to handle the
>situation when there is no vendor term or for components other than
>update.  I have been asked to provide some official clarification for
>this.  Please note that this clarification will be added to any future
>version of the specification.
>
>-------------------------------------------------
>
>Clarification:
>
>If attempting to create a CPE Name for a given platform that does not
>have or define a certain component, and it is desired to enumerate a
>specific release guarding against future releases that may introduce
>the component (e.g. the release of a new edition), then the value
>'_nil_' should be used.  Note that some vendors do in fact define a
>term of an initial release but do not use this term in the marketing
>name. In these cases, that term should be used instead of '_nil_'.  An
>example of this is with the Microsoft Windows operating system where
>the initial release is known without a service pack.  In this case, the
>vendor does in fact have a term for this release (gold) and that vendor
>term should be used instead of '_nil_'.
>
>-------------------------------------------------
>
>I hope this clarifies the issue at hand.  Again, this clarification
>will be added to any future version of the CPE Specification.  Until
>that time, I hope this email serves as a reference to help create CPE
>Names under version 2.1.  I will make sure to post this clarification
>to the FAQ section of the CPE web site.
>
>Thanks
>Drew
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Wolfkiel, Joseph
In reply to this post by Dawn Adams

smime.p7m (550K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment

Ernest Park
Hi Joe,

Did you intend to send more content than was received in this message?



Ernie 

On Fri, Nov 21, 2008 at 4:17 PM, Wolfkiel, Joseph <[hidden email]> wrote:

Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment (UNCLASSIFIED)

Mackanick, Jason W CTR DISA GIG-OP
In reply to this post by Wolfkiel, Joseph
Classification:  UNCLASSIFIED
Caveats: NONE

I have just a minor implimentation suggestion with the SSL/PKI capablities.
Recently within the DoD we have seen a push to move away from SSL and move
over to TLS.  Just a minor suggestion.


Jason Mackanick, CISSP
DISA FSO Support & Standards Section
Technical Support Team

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, November 17, 2008 4:34 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for
comment

All,

Please find the attached specification the DoD is considering as the basis
of SCAP-based assessment tool data export and reporting.

I am releasing it to the CPE list and to the SCAP Developers' list for
comment and discussion.

The rationale behind the creation of this document is that the DoD is in the
market to acquire SCAP-capable tools in the near future and will need to
require a common reporting language for SCAP-related assessment results.
Since there is no existing language or publishing interface that meets our
requirements, we are planning to require reporting using the ARF language
and web services specification in the attached.  

What I need from SCAP vendors is an assessment of whether ARF will work for
reporting the outputs of their tools, and (if not) what changes will be
required to provide generalized SCAP reporting capabilities.  Our primary
use cases are for host-based vulnerability scanning and compliance checking
and for network-based vulnerability/compliance scanners.  Though, in
general, any assessment tool that builds an inventory of devices, installed
hardware, OS, applications, settings, vulnerabilities, patches, running
services, and/or device behaviors would be expected to use this reporting
format.

Please note there are several issues we are still debating:

1.  Should be CPE names be reported as URIs, or should they be reported as
component names individually.  URIs most closely follow the CPE
specification, but we are running into some use cases where we want to tag
each component name with metadata tags independently -- E.g we have several
cases where we have a software package that may be one of a range of
different versions that can be assigned different probabilities.  As an
example, if we know a certain CPE is Mozilla Firefox version 4 with a
sub-version in the range of 4-6, with a 90% probability the major version is
4 and equal probabilities the minor versions are 4,5, or 6, we could either
report it as:

<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.5 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>

or

<cpe-record>
        <name>
                <vendor confidence=.9>mozilla</vendor>
                <product confidence=.9>firefox</product>
                <major_version confidence=.9>4</major_version>
                <minor_version confidence=.3>4</minor_version>
                <minor_version confidence=.3>5</minor_version>
                <minor_version confidence=.3>6</minor_version>
        </name>
</cpe-record>

The current draft uses the URI notation, but I'd like to hear some other
thoughts.

2.  We are also proposing the use of flexible tag-value pairs for one-off
use cases, such as "last seen" or "hit count" or other metrics that only
apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again), I'm
not convinced that out-of-band negotiations on what are valid tag names,
enumerations, and constraints are a good way to manage a standard.

3.  We want to return a list of all installed software on a given box, even
if it's not previously identified via an OVAL check or enumerated in the CPE
dictionary.  Is it reasonable to expect to be able to report newly
discovered software in CPE format?

4.  We didn't put in labels for MD5 hashes or licenses.  Is there a demand
for these tags?  What restrictions can be placed on their data types?

5.  This is our first widespread dissemination of the web-service behaviors
we expect from assessment tools that are fielded inside of DoD firewalls and
report to external consumers.  It's our best effort to support both the
security issues of firewall policy (outbound only) as well as providing
flexible parameters to control bandwidth utilization.
What are your thoughts?

Overall, I'd like comments so we have some confidence that, when we start
putting these reporting requirements in our acquisitions, they will be
supportable by SCAP vendors.

I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to go
final so we can begin to build ARF into one or more of our GOTS tools.

I appreciate your feedback.

- Joe Wolfkiel



Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment (UNCLASSIFIED)

Wolfkiel, Joseph

smime.p7m (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DoD DRAFT Assessment Results Format for comment -- Unsigned re-transmit of Friday Nov 21, 2008 e-mail

Wolfkiel, Joseph
In reply to this post by Ernest Park
I think there's something screwy with how my e-mail applies digital signatures or something.  Here it is again, unsigned.
 
- Joe
 
-----Original Message-----
From: Wolfkiel, Joseph
Sent: Friday, November 21, 2008 4:18 PM
To: 'CPE Community Forum'
Subject: RE: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment
 
All,
 
After some initial feedback, I've determined that the cpe-record schema in the ARF specification needs to be updated.  Seems that using the cpe name as an index value isn't such a good idea, primarily because of two use cases -- one: the cpe ID isn't known; and two: the cpe ID may be a range of values or an indeterminate value.  Based on that rationale, and the kind of strange behaviors you would get with matching, I also determined that putting the "_unknown_" value in for products whose name is unknown would cause problems with pulling the right configs and vulnerabilities, so the concept of "unknown" has been pulled out of the cpe name and put in as an attribute of the platform name, which may now contain 0 to many assessed names with confidence values associated with each one.  This implies a certain amount of business logic which will have to be documented.  Specifically, if the platform name has a confidence value expressed, the total confidence of each component name in the assessed cpe names should be added together in some consistent manner (TBD) to a total that shall not exceed the total confidence for the platform name.
 
Tags that follow will all be assumed to apply equally to all the cpe names in the platform name.  There are also some assumptions that can be made about timestamps, sources, and other attributes being inherited from higher-level elements unless they are overridden.
 
Just for grins, I've built two sample documents showing how the cpe-record can be used to describe:
 
1.  An FTP server whose name was unascertainable and returned an error condition for the checkref that the assessment tool attempted to use.  The tool determined that the layer 4 protocol is FTP using RFC matching algorithms and reports the device is acting as a server on IP Protocol 6 with a port range of 20-21.
 
2.  An Apache Tomcat server running software version 4 with a minor version in the range of 4-6.  The sensor ascertained that it is functioning as a web server and that it is providing a service for http on ports 80-81 and port 8080 and for https on port 443.  The service was active during the last assessment.  If confidence values are added using a straight addition method, you would assume that confidence(part="a")=0.9, confidence(vendor="apache")=0.9, confidence(product="tomcat")=0.9, confidence(major_version="4")=0.9, confidence(minor_version="4")=0.3,
confidence(minor_version="5")=0.3, and confidence(minor_version="6")=0.3
 
An updated UML diagram for the new cpe-record schema is attached as well as draft XML schemas.
 
Does this make sense?  Is it re-usable for passive sensing tools, active scanners, authenticated scanners, and agent-based tools?
 
I appreciate your feedback.
 
Thanks,
 
- Joe Wolfkiel
 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office 9800 Savage Rd Ste 6767 Ft Meade, MD 20755-6767 Commercial 410-854-5401 DSN 244-5401 Fax 410-854-6700
 
-----Original Message-----
From: Dawn Adams [mailto:[hidden email]]
Sent: Tuesday, November 18, 2008 6:25 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment
 
I like the system you are describing here and I think it could be very useful. I am not sure if the following would be helped or hindered by this approach so I am throwing it out to you.
 
I have a question regarding software component CPE identification. If, for example, you had a software product consisting of Service V1.0 and a Client v2.0 but together they made Product V3.0, what would the CPE ID actually be assigned to and if you ran checks for versions like the Windows checks, which version should the product be reporting? Also, if Client v2.0 can run on its own without Server v1.0 would this be a different product wrt CPE?
Could different clients be added in easily? Thanks in advance.
 
Dawn Adams
SCAP Lead
EWA-Canada
613-230-6067 x. 1249
 
-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: November 17, 2008 5:22 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment
 
Just as a clarification, while I am interested in comments on the entire document, it is the device record, and particularly the cpe_record that I would like comments on from the CPE list.
 
- Joe
 
-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Monday, November 17, 2008 4:34 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment
 
All,
 
Please find the attached specification the DoD is considering as the basis of SCAP-based assessment tool data export and reporting.
 
I am releasing it to the CPE list and to the SCAP Developers' list for comment and discussion.
 
The rationale behind the creation of this document is that the DoD is in the market to acquire SCAP-capable tools in the near future and will need to require a common reporting language for SCAP-related assessment results.
Since there is no existing language or publishing interface that meets our requirements, we are planning to require reporting using the ARF language and web services specification in the attached. 
 
What I need from SCAP vendors is an assessment of whether ARF will work for reporting the outputs of their tools, and (if not) what changes will be required to provide generalized SCAP reporting capabilities.  Our primary use cases are for host-based vulnerability scanning and compliance checking and for network-based vulnerability/compliance scanners.  Though, in general, any assessment tool that builds an inventory of devices, installed hardware, OS, applications, settings, vulnerabilities, patches, running services, and/or device behaviors would be expected to use this reporting format.
 
Please note there are several issues we are still debating:
 
1.  Should be CPE names be reported as URIs, or should they be reported as component names individually.  URIs most closely follow the CPE specification, but we are running into some use cases where we want to tag each component name with metadata tags independently -- E.g we have several cases where we have a software package that may be one of a range of different versions that can be assigned different probabilities.  As an example, if we know a certain CPE is Mozilla Firefox version 4 with a sub-version in the range of 4-6, with a 90% probability the major version is
4 and equal probabilities the minor versions are 4,5, or 6, we could either report it as:
 
<cpe-record name=cpe:/a:mozilla:firefox:4.4 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.5 confidence=.3/> <cpe-record
name=cpe:/a:mozilla:firefox:4.6 confidence=.3/>
 
or
 
<cpe-record>
 <name>
  <vendor confidence=.9>mozilla</vendor>
  <product confidence=.9>firefox</product>
  <major_version confidence=.9>4</major_version>
  <minor_version confidence=.3>4</minor_version>
  <minor_version confidence=.3>5</minor_version>
  <minor_version confidence=.3>6</minor_version>
 </name>
</cpe-record>
 
The current draft uses the URI notation, but I'd like to hear some other thoughts.
 
2.  We are also proposing the use of flexible tag-value pairs for one-off use cases, such as "last seen" or "hit count" or other metrics that only apply to specific tools and not all SCAP reporting tools.
This sort of supports the NIST proposed flexible tagging, but (again), I'm not convinced that out-of-band negotiations on what are valid tag names, enumerations, and constraints are a good way to manage a standard.
 
3.  We want to return a list of all installed software on a given box, even if it's not previously identified via an OVAL check or enumerated in the CPE dictionary.  Is it reasonable to expect to be able to report newly discovered software in CPE format?
 
4.  We didn't put in labels for MD5 hashes or licenses.  Is there a demand for these tags?  What restrictions can be placed on their data types?
 
5.  This is our first widespread dissemination of the web-service behaviors we expect from assessment tools that are fielded inside of DoD firewalls and report to external consumers.  It's our best effort to support both the security issues of firewall policy (outbound only) as well as providing flexible parameters to control bandwidth utilization.
What are your thoughts?
 
Overall, I'd like comments so we have some confidence that, when we start putting these reporting requirements in our acquisitions, they will be supportable by SCAP vendors.
 
I will respond to discussions and comments on the CPE Discussion list.
I'll leave this out for discussion until December 17th, then attempt to go final so we can begin to build ARF into one or more of our GOTS tools.
 
I appreciate your feedback.
 
- Joe Wolfkiel

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

 


From: Ernest Park [mailto:[hidden email]]
Sent: Monday, November 24, 2008 10:42 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] DoD DRAFT Assessment Results Format for comment

Hi Joe,

Did you intend to send more content than was received in this message?



Ernie 

On Fri, Nov 21, 2008 at 4:17 PM, Wolfkiel, Joseph <[hidden email]> wrote:


cpe-record_0.1.zip (19K) Download Attachment
cpe-record_0.1.jpg (361K) Download Attachment
Apache Tomcat version 4.4-6 running http and https Sample cpe-record.xml (4K) Download Attachment
Unnamed FTP Server Sample cpe-record.xml (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of an Initial Release

Waltermire, David A.
In reply to this post by Andrew Buttner
Please find my comments inline.  I would appreciate any feedback.

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, November 20, 2008 1:36 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release

All,

I have been asked to re-open this clarification for further discussion, and
set a defined review period before a final decision will be reached.  In the
rest of this email, I will try to outline the issues at hand and the
different views that exist.  The discussion will then be open for two weeks.
After two weeks, I will either post a new clarification if consensus has
been reached, or if consensus was not reached, then I will forward the
discussion to our Government sponsors for a decision.  Please note that in
the near future I will be formalizing this review process and documenting it
on the CPE web site.

The main issue is explained in the previous email (see the bottom of this
email).  It deals with which term to use when creating a CPE for an initial
release.  We often find cases where a given component does not apply to the
specific platform type we want to name.  We are trying to clarify which term
to use.

Some options that have been proposed in the past are:

ga
null
no_component
blank
_nil_

In addition, another aspect of this is whether to use a vendor specific term
if one exists, or to always use the term stated above.  There have been
arguments for using vendor terms when applicable as it makes the CPE Name
more understandable by a human user.  Having vendor terms can make searching
(within an application) for an appropriate CPE easier since one would search
with common terms.  E.g. a user might not know if Acme Red (IR) would be
cpe:/a:acme:red:ir or cpe:/a:acme:red:null.  It also makes the process of
creating names easier as one simply uses the known terms.  Two examples in
the current dictionary are:

cpe:/o:redhat:enterprise_linux:5:ga
cpe:/o:microsoft:windows_2003_server::gold

There have also been arguments against using vendor terms.  If a non-vendor
is creating new CPE Names then that individual will be forced to research
the different vendors to know if there is a vendor term or not.
Additionally, users that have access to the Official CPE Dictionary can
still search for a specific CPE Name by looking at the <title> field.

One additional point to consider is that the current CPE Specification
(version 2.1) does say in the UPDATE component section to use vendor terms.
This has lead to the creation of CPE Names that use vendor terms.  The
exclusion of vendor terms going forward would force us to either have CPE
Names that don't follow the spec (they would still be unique identifiers) or
to deprecate those existing names and replace them with new names.

Moving forward ... I would love to hear comments from the community on the
following two points:

1) What term should be used in a component when creating a new CPE Name in
instances where a platform doesn't specify that component (no current
edition) or when the platform being described is an initial release and the
component may be used to differentiate future releases (an unplanned service
pack)?

[DW: We need to use a single term consistently.  The use of _nil_ seems to
be a good candidate.  It should not occur in normal use when naming
products.]

2) Should vendor terms (e.g. 'ga' or 'gold') be used when appropriate or
should the term specified above be used in all cases regardless, even if a
different term is commonly used by the vendor?

[DW: It is our opinion that _nil_ should replace any vendor term used within
the CPE Name where the semantic meaning is the same (e.g. ga, gold, initial,
etc.)  This will greatly simplify the naming guidance and will result in
greater consistency in naming which is a win overall.  If this isn't done,
it makes naming much more complicated and time consuming than it needs to
be.  Given that there are thousands of vendors, researching the vendor term
for CPE Names that need to be created is not a trivial task.

Based on this analysis, I would recommend that we deprecate the old vendor
proprietary entries in the near future to keep everything consistent.  When
the _nil_ approach is used, human-readable titles can be based on the vendor
terminology.  In fact, this should be encouraged.]

Again, this discussion will be open until noon on Thursday December 4th,
2008.

Thanks
Drew




>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Saturday, November 15, 2008 7:17 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
>All,
>
>There has been a lot of talk about how to create CPE Names for initial
>releases.  This conversation is often had under the notion of a given
>platform that does not have a notion of a specific component.  For
>example, an application that does not support different languages, or
>an operating system that does not have updates.
>
>The issue is that there are some uses within the CPE Community that
>need to use CPE Names that do NOT leave that component blank.  Remember
>that a blank component is used in a CPE Name to identify a platform
>type regardless of the value for that component.  E.G. an application
>CPE Name with a blank edition would represent the platform type for the
>application regardless of the edition.  Unfortunately we often find
>within the industry that an initial release of a platform might not
>have editions, but future releases will.  Use of the CPE Name with a
>blank edition would match both the initial release and any future
>releases.  The question is how do we create the CPE Name for that
>initial release.
>
>The current CPE Specification (version 2.1) clarifies this point for
>the update component and directs us to use a vendor term like 'gold' or
>'ga'.  Unfortunately, the specification does not say how to handle the
>situation when there is no vendor term or for components other than
>update.  I have been asked to provide some official clarification for
>this.  Please note that this clarification will be added to any future
>version of the specification.
>
>-------------------------------------------------
>
>Clarification:
>
>If attempting to create a CPE Name for a given platform that does not
>have or define a certain component, and it is desired to enumerate a
>specific release guarding against future releases that may introduce
>the component (e.g. the release of a new edition), then the value
>'_nil_' should be used.  Note that some vendors do in fact define a
>term of an initial release but do not use this term in the marketing
>name. In these cases, that term should be used instead of '_nil_'.  An
>example of this is with the Microsoft Windows operating system where
>the initial release is known without a service pack.  In this case, the
>vendor does in fact have a term for this release (gold) and that vendor
>term should be used instead of '_nil_'.
>
>-------------------------------------------------
>
>I hope this clarifies the issue at hand.  Again, this clarification
>will be added to any future version of the CPE Specification.  Until
>that time, I hope this email serves as a reference to help create CPE
>Names under version 2.1.  I will make sure to post this clarification
>to the FAQ section of the CPE web site.
>
>Thanks
>Drew
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of an Initial Release

Wolfkiel, Joseph

smime.p7m (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of an Initial Release

Vladimir Giszpenc
At Developer Days, everyone seemed to have solved this problem by using
version numbers.  They use a version or update of 0 for an initial
release.  If there is no edition, so be it.

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959

> Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
> While I'm not fundamentally opposed to using "_nil_" in this way, it
> does
> seem counter-intuitive.  My initial take on the "_nil_" identifier was
> that
> it would be used to remedy a deficiency in the specification caused by
> the
> decision to use blank component names to imply "match everything"
> versus
> "blank."  In which case, we now have to choose a reserved word to take
> the
> place of blank component names (i.e. in cases where the vendor either
> doesn't use that component in their naming scheme, or didn't populate
> it for
> a given software release).
>
> With the new logic, we now have the case where "_nil_" = "",
> "_nil_"="ga",
> "_nil_"="gold", and the indefinite case of nil="tbd" for any other
> vendor
> label inserted to indicate an initial release.
>
> One alternative, of course is to just use whatever label has been
> applied by
> the vendor.  Another might be to choose another reserved word that
> means
> "initial release" so that "_nil_" can continue to mean "blank" or
> "unpopulated."
>
> I'm also having some problems coming to grips with the use case that
> makes
> the initial release significantly more important to uniquely identify
> than
> any subsequent release.  Also some issues with the implied business
> logic.
> Would "_nil_" only be used in the version field or only in the update
> field?
> What would happen if "_nil_" appeared in the language field?  Would it
> imply
> language general release?  What do we do with a vendor who has a
> product
> with a "silver", "platinum", and "gold" ?...
>
> That said, I'd like to have more feedback from the community on this.
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
> Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> -----Original Message-----
> From: David Waltermire [mailto:[hidden email]]
> Sent: Tuesday, November 25, 2008 4:05 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
> Please find my comments inline.  I would appreciate any feedback.
>
> -----Original Message-----
> From: Buttner, Drew [mailto:[hidden email]]
> Sent: Thursday, November 20, 2008 1:36 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
> All,
>
> I have been asked to re-open this clarification for further
discussion,

> and
> set a defined review period before a final decision will be reached.
> In the
> rest of this email, I will try to outline the issues at hand and the
> different views that exist.  The discussion will then be open for two
> weeks.
> After two weeks, I will either post a new clarification if consensus
> has
> been reached, or if consensus was not reached, then I will forward the
> discussion to our Government sponsors for a decision.  Please note
that

> in
> the near future I will be formalizing this review process and
> documenting it
> on the CPE web site.
>
> The main issue is explained in the previous email (see the bottom of
> this
> email).  It deals with which term to use when creating a CPE for an
> initial
> release.  We often find cases where a given component does not apply
to
> the
> specific platform type we want to name.  We are trying to clarify
which

> term
> to use.
>
> Some options that have been proposed in the past are:
>
> ga
> null
> no_component
> blank
> _nil_
>
> In addition, another aspect of this is whether to use a vendor
specific
> term
> if one exists, or to always use the term stated above.  There have
been

> arguments for using vendor terms when applicable as it makes the CPE
> Name
> more understandable by a human user.  Having vendor terms can make
> searching
> (within an application) for an appropriate CPE easier since one would
> search
> with common terms.  E.g. a user might not know if Acme Red (IR) would
> be
> cpe:/a:acme:red:ir or cpe:/a:acme:red:null.  It also makes the process
> of
> creating names easier as one simply uses the known terms.  Two
examples

> in
> the current dictionary are:
>
> cpe:/o:redhat:enterprise_linux:5:ga
> cpe:/o:microsoft:windows_2003_server::gold
>
> There have also been arguments against using vendor terms.  If a non-
> vendor
> is creating new CPE Names then that individual will be forced to
> research
> the different vendors to know if there is a vendor term or not.
> Additionally, users that have access to the Official CPE Dictionary
can

> still search for a specific CPE Name by looking at the <title> field.
>
> One additional point to consider is that the current CPE Specification
> (version 2.1) does say in the UPDATE component section to use vendor
> terms.
> This has lead to the creation of CPE Names that use vendor terms.  The
> exclusion of vendor terms going forward would force us to either have
> CPE
> Names that don't follow the spec (they would still be unique
> identifiers) or
> to deprecate those existing names and replace them with new names.
>
> Moving forward ... I would love to hear comments from the community on
> the
> following two points:
>
> 1) What term should be used in a component when creating a new CPE
Name
> in
> instances where a platform doesn't specify that component (no current
> edition) or when the platform being described is an initial release
and
> the
> component may be used to differentiate future releases (an unplanned
> service
> pack)?
>
> [DW: We need to use a single term consistently.  The use of _nil_
seems

> to
> be a good candidate.  It should not occur in normal use when naming
> products.]
>
> 2) Should vendor terms (e.g. 'ga' or 'gold') be used when appropriate
> or
> should the term specified above be used in all cases regardless, even
> if a
> different term is commonly used by the vendor?
>
> [DW: It is our opinion that _nil_ should replace any vendor term used
> within
> the CPE Name where the semantic meaning is the same (e.g. ga, gold,
> initial,
> etc.)  This will greatly simplify the naming guidance and will result
> in
> greater consistency in naming which is a win overall.  If this isn't
> done,
> it makes naming much more complicated and time consuming than it needs
> to
> be.  Given that there are thousands of vendors, researching the vendor
> term
> for CPE Names that need to be created is not a trivial task.
>
> Based on this analysis, I would recommend that we deprecate the old
> vendor
> proprietary entries in the near future to keep everything consistent.
> When
> the _nil_ approach is used, human-readable titles can be based on the
> vendor
> terminology.  In fact, this should be encouraged.]
>
> Again, this discussion will be open until noon on Thursday December
> 4th,
> 2008.
>
> Thanks
> Drew
>
>
>
>
> >-----Original Message-----
> >From: Buttner, Drew [mailto:[hidden email]]
> >Sent: Saturday, November 15, 2008 7:17 PM
> >To: cpe-discussion-list CPE Community Forum
> >Subject: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
> >
> >All,
> >
> >There has been a lot of talk about how to create CPE Names for
initial

> >releases.  This conversation is often had under the notion of a given
> >platform that does not have a notion of a specific component.  For
> >example, an application that does not support different languages, or
> >an operating system that does not have updates.
> >
> >The issue is that there are some uses within the CPE Community that
> >need to use CPE Names that do NOT leave that component blank.
> Remember
> >that a blank component is used in a CPE Name to identify a platform
> >type regardless of the value for that component.  E.G. an application
> >CPE Name with a blank edition would represent the platform type for
> the
> >application regardless of the edition.  Unfortunately we often find
> >within the industry that an initial release of a platform might not
> >have editions, but future releases will.  Use of the CPE Name with a
> >blank edition would match both the initial release and any future
> >releases.  The question is how do we create the CPE Name for that
> >initial release.
> >
> >The current CPE Specification (version 2.1) clarifies this point for
> >the update component and directs us to use a vendor term like 'gold'
> or
> >'ga'.  Unfortunately, the specification does not say how to handle
the
> >situation when there is no vendor term or for components other than
> >update.  I have been asked to provide some official clarification for
> >this.  Please note that this clarification will be added to any
future

> >version of the specification.
> >
> >-------------------------------------------------
> >
> >Clarification:
> >
> >If attempting to create a CPE Name for a given platform that does not
> >have or define a certain component, and it is desired to enumerate a
> >specific release guarding against future releases that may introduce
> >the component (e.g. the release of a new edition), then the value
> >'_nil_' should be used.  Note that some vendors do in fact define a
> >term of an initial release but do not use this term in the marketing
> >name. In these cases, that term should be used instead of '_nil_'.
An

> >example of this is with the Microsoft Windows operating system where
> >the initial release is known without a service pack.  In this case,
> the
> >vendor does in fact have a term for this release (gold) and that
> vendor
> >term should be used instead of '_nil_'.
> >
> >-------------------------------------------------
> >
> >I hope this clarifies the issue at hand.  Again, this clarification
> >will be added to any future version of the CPE Specification.  Until
> >that time, I hope this email serves as a reference to help create CPE
> >Names under version 2.1.  I will make sure to post this clarification
> >to the FAQ section of the CPE web site.
> >
> >Thanks
> >Drew
> >
> >---------
> >
> >Andrew Buttner
> >The MITRE Corporation
> >[hidden email]
> >781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of an Initial Release

Waltermire, David A.
To me it matters less what reserved word we use as a placeholder for the
initial release as long as it is standardized.  What matters most is that
whatever approach we decide on reduces, as much as possible, the content
creation and maintenance burden of forming and moderating CPE Names.  Using
the vendor term introduces some potential resource costs in these areas that
using a common term would avoid.  This philosophy applies evenly to all
components were efficiencies can be found in this way.

I see _nil_ used for all components were the vendor product naming has no
data.  So, yes, the _nil_ in the language component would mean a general,
non-language specific release.  The same would apply to edition if no
edition existed.  This is critical to forming fully-qualified, canonical CPE
Names.

Dave

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, November 26, 2008 8:31 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release

At Developer Days, everyone seemed to have solved this problem by using
version numbers.  They use a version or update of 0 for an initial
release.  If there is no edition, so be it.

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959

> Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
> While I'm not fundamentally opposed to using "_nil_" in this way, it
> does
> seem counter-intuitive.  My initial take on the "_nil_" identifier was
> that
> it would be used to remedy a deficiency in the specification caused by
> the
> decision to use blank component names to imply "match everything"
> versus
> "blank."  In which case, we now have to choose a reserved word to take
> the
> place of blank component names (i.e. in cases where the vendor either
> doesn't use that component in their naming scheme, or didn't populate
> it for
> a given software release).
>
> With the new logic, we now have the case where "_nil_" = "",
> "_nil_"="ga",
> "_nil_"="gold", and the indefinite case of nil="tbd" for any other
> vendor
> label inserted to indicate an initial release.
>
> One alternative, of course is to just use whatever label has been
> applied by
> the vendor.  Another might be to choose another reserved word that
> means
> "initial release" so that "_nil_" can continue to mean "blank" or
> "unpopulated."
>
> I'm also having some problems coming to grips with the use case that
> makes
> the initial release significantly more important to uniquely identify
> than
> any subsequent release.  Also some issues with the implied business
> logic.
> Would "_nil_" only be used in the version field or only in the update
> field?
> What would happen if "_nil_" appeared in the language field?  Would it
> imply
> language general release?  What do we do with a vendor who has a
> product
> with a "silver", "platinum", and "gold" ?...
>
> That said, I'd like to have more feedback from the community on this.
>
>
> Lt Col Joseph L. Wolfkiel
> Director, Computer Network Defense Research & Technology (CND R&T)
> Program
> Management Office
> 9800 Savage Rd Ste 6767
> Ft Meade, MD 20755-6767
> Commercial 410-854-5401 DSN 244-5401
> Fax 410-854-6700
>
> -----Original Message-----
> From: David Waltermire [mailto:[hidden email]]
> Sent: Tuesday, November 25, 2008 4:05 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
> Please find my comments inline.  I would appreciate any feedback.
>
> -----Original Message-----
> From: Buttner, Drew [mailto:[hidden email]]
> Sent: Thursday, November 20, 2008 1:36 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
>
> All,
>
> I have been asked to re-open this clarification for further
discussion,

> and
> set a defined review period before a final decision will be reached.
> In the
> rest of this email, I will try to outline the issues at hand and the
> different views that exist.  The discussion will then be open for two
> weeks.
> After two weeks, I will either post a new clarification if consensus
> has
> been reached, or if consensus was not reached, then I will forward the
> discussion to our Government sponsors for a decision.  Please note
that

> in
> the near future I will be formalizing this review process and
> documenting it
> on the CPE web site.
>
> The main issue is explained in the previous email (see the bottom of
> this
> email).  It deals with which term to use when creating a CPE for an
> initial
> release.  We often find cases where a given component does not apply
to
> the
> specific platform type we want to name.  We are trying to clarify
which

> term
> to use.
>
> Some options that have been proposed in the past are:
>
> ga
> null
> no_component
> blank
> _nil_
>
> In addition, another aspect of this is whether to use a vendor
specific
> term
> if one exists, or to always use the term stated above.  There have
been

> arguments for using vendor terms when applicable as it makes the CPE
> Name
> more understandable by a human user.  Having vendor terms can make
> searching
> (within an application) for an appropriate CPE easier since one would
> search
> with common terms.  E.g. a user might not know if Acme Red (IR) would
> be
> cpe:/a:acme:red:ir or cpe:/a:acme:red:null.  It also makes the process
> of
> creating names easier as one simply uses the known terms.  Two
examples

> in
> the current dictionary are:
>
> cpe:/o:redhat:enterprise_linux:5:ga
> cpe:/o:microsoft:windows_2003_server::gold
>
> There have also been arguments against using vendor terms.  If a non-
> vendor
> is creating new CPE Names then that individual will be forced to
> research
> the different vendors to know if there is a vendor term or not.
> Additionally, users that have access to the Official CPE Dictionary
can

> still search for a specific CPE Name by looking at the <title> field.
>
> One additional point to consider is that the current CPE Specification
> (version 2.1) does say in the UPDATE component section to use vendor
> terms.
> This has lead to the creation of CPE Names that use vendor terms.  The
> exclusion of vendor terms going forward would force us to either have
> CPE
> Names that don't follow the spec (they would still be unique
> identifiers) or
> to deprecate those existing names and replace them with new names.
>
> Moving forward ... I would love to hear comments from the community on
> the
> following two points:
>
> 1) What term should be used in a component when creating a new CPE
Name
> in
> instances where a platform doesn't specify that component (no current
> edition) or when the platform being described is an initial release
and
> the
> component may be used to differentiate future releases (an unplanned
> service
> pack)?
>
> [DW: We need to use a single term consistently.  The use of _nil_
seems

> to
> be a good candidate.  It should not occur in normal use when naming
> products.]
>
> 2) Should vendor terms (e.g. 'ga' or 'gold') be used when appropriate
> or
> should the term specified above be used in all cases regardless, even
> if a
> different term is commonly used by the vendor?
>
> [DW: It is our opinion that _nil_ should replace any vendor term used
> within
> the CPE Name where the semantic meaning is the same (e.g. ga, gold,
> initial,
> etc.)  This will greatly simplify the naming guidance and will result
> in
> greater consistency in naming which is a win overall.  If this isn't
> done,
> it makes naming much more complicated and time consuming than it needs
> to
> be.  Given that there are thousands of vendors, researching the vendor
> term
> for CPE Names that need to be created is not a trivial task.
>
> Based on this analysis, I would recommend that we deprecate the old
> vendor
> proprietary entries in the near future to keep everything consistent.
> When
> the _nil_ approach is used, human-readable titles can be based on the
> vendor
> terminology.  In fact, this should be encouraged.]
>
> Again, this discussion will be open until noon on Thursday December
> 4th,
> 2008.
>
> Thanks
> Drew
>
>
>
>
> >-----Original Message-----
> >From: Buttner, Drew [mailto:[hidden email]]
> >Sent: Saturday, November 15, 2008 7:17 PM
> >To: cpe-discussion-list CPE Community Forum
> >Subject: [CPE-DISCUSSION-LIST] Clarification of an Initial Release
> >
> >All,
> >
> >There has been a lot of talk about how to create CPE Names for
initial

> >releases.  This conversation is often had under the notion of a given
> >platform that does not have a notion of a specific component.  For
> >example, an application that does not support different languages, or
> >an operating system that does not have updates.
> >
> >The issue is that there are some uses within the CPE Community that
> >need to use CPE Names that do NOT leave that component blank.
> Remember
> >that a blank component is used in a CPE Name to identify a platform
> >type regardless of the value for that component.  E.G. an application
> >CPE Name with a blank edition would represent the platform type for
> the
> >application regardless of the edition.  Unfortunately we often find
> >within the industry that an initial release of a platform might not
> >have editions, but future releases will.  Use of the CPE Name with a
> >blank edition would match both the initial release and any future
> >releases.  The question is how do we create the CPE Name for that
> >initial release.
> >
> >The current CPE Specification (version 2.1) clarifies this point for
> >the update component and directs us to use a vendor term like 'gold'
> or
> >'ga'.  Unfortunately, the specification does not say how to handle
the
> >situation when there is no vendor term or for components other than
> >update.  I have been asked to provide some official clarification for
> >this.  Please note that this clarification will be added to any
future

> >version of the specification.
> >
> >-------------------------------------------------
> >
> >Clarification:
> >
> >If attempting to create a CPE Name for a given platform that does not
> >have or define a certain component, and it is desired to enumerate a
> >specific release guarding against future releases that may introduce
> >the component (e.g. the release of a new edition), then the value
> >'_nil_' should be used.  Note that some vendors do in fact define a
> >term of an initial release but do not use this term in the marketing
> >name. In these cases, that term should be used instead of '_nil_'.
An

> >example of this is with the Microsoft Windows operating system where
> >the initial release is known without a service pack.  In this case,
> the
> >vendor does in fact have a term for this release (gold) and that
> vendor
> >term should be used instead of '_nil_'.
> >
> >-------------------------------------------------
> >
> >I hope this clarifies the issue at hand.  Again, this clarification
> >will be added to any future version of the CPE Specification.  Until
> >that time, I hope this email serves as a reference to help create CPE
> >Names under version 2.1.  I will make sure to post this clarification
> >to the FAQ section of the CPE web site.
> >
> >Thanks
> >Drew
> >
> >---------
> >
> >Andrew Buttner
> >The MITRE Corporation
> >[hidden email]
> >781-271-3515
12