Making Security Measurable

›

Matching and the Interpretation of CPE Tags

14 Messages

Mann, Dave

Matching and the Interpretation of CPE Tags

Reply Threaded

I would ask that CPE consider adding a new section to the CPE spec
to clarify the correct usage of CPE names in relationships to
other data elements. "Tagging" other data elements with CPE names
is one form of relationship definition.

In particular, I would ask that the CPE spec be updated to clarify
CPE's position on if or how the "Matching" requirement affects the
use of CPEs in relationship statements and tagging.

In short, I think there are 2 choices for the CPE effort:

1) STRICT REVERSE MATCHING FOR CPE TAGS - In every case that a CPE
name is used to define a relationship (tag), the relationship must
be interpretted as applying inclusively to all children of that CPE
name. That is, if x applies to a CPE name, then x must apply to all
children of that CPE name.

2) FLEXIBLE, USER DEFINED USE OF CPE TAGS - The publisher of
information tagged with CPE names is free to define how the
CPE tag should be interpretted. The options include:
a) Inclusive - The relationship must be interpretted as applying
inclusively to all children of that CPE name. That is, if x
applies to a CPE name, then x must apply to all children of
that CPE name.
b) Non-Inclusive - The relationship should be interpretted as
being ambiguous with respect to the applicability to the
children of that CPE name. That is, if x applies to a CPE name,
then x may or may not apply to any child of that CPE name.

Based on our experience on CCE (and my perspective from CVE), I
strongly advocate the flexible approach. If a strict, inclusive
interpretation of CPE tags is to be enforced, the only reasonable
approach will be to force users of CPEs to restrict their use of
CPE tags to only leaf names, which have no possible children.
This would be cost-prohibitive in many cases and impossible in others,
limiting the potential uses of CPE.

I'll present a short discussion aimed at justifying this position
followed by 2 proposed additions to the CPE spec to be considered.

DISCUSSION
----------
The matching requirement in CPE requires that all children of a CPE
name be proper subsets of the CPE name. For example, Windows XP Pro
is a proper subset of Windows XP. The confusion that needs to be
clarified is whether or not a sort of reverse-matching logic should
be applied to the interpretation of CPE names when used as tags or
when used to define relationships with other data elements.

The basic point to be made is that this reverse-matching logic often
does not work, nor is it desired. Instead, the use of non-leaf
CPE names almost always is motivated out a need to ambiguously
use the higher level CPE names in a non-inclusive manner.

One of the biggest culprits demanding the ambiguity of a non-inclusive
approach is the unknowability of future releases of software versions.

That is, you never know when new versions of software will be
introduced and what their capabilities will be. This makes any
non-leaf CPE tag subject to change if CPE tags are to be interpreted
in a non-inclusive manner.

Let me motivate this with 2 examples. The first example has to
do with what I think of tagging "containers", by which I mean things
that contain other sub-elements. Consider a security guide written
for Windows XP. The natural choice would be to tag this document
with the CPE name:
cpe:/o:microsoft:windows-nt:xp

But, does this document really apply to all versions of Windows XP?
What happened when Service Pack 2 was introduced. Some functionality
in Windows XP was removed and lots of other functionality was added.
How then should the document be tagged? I think there are only 2
defensible approaches.

The strict, inclusive approach (which I think is clearly out of step
with how platform associations are currently made and which I think
is much too labor intensive to be practical) would insist if the
document is tagged with a CPE name, then the document should apply
to all children of that CPE name. But, since future functionality
is unknowable, the only way you can achieve this would be to tag
the document with only those CPEs that are a) leaves in the CPE
namespace with no possible children and b) have been verified as
being covered by the document. Then, when future versions of the
platform are made available, the guide author could decide to add
additional CPE leaf names to the guide as appropriate.

While this approach would add a tremendous amount of specificity and
clarity to the CPE association of the security guide and while we
recognize that some use cases may benefit from this sort of
granularity, we also note that security guides and many other
"containers" of functionality are not currently associated to
platforms in this way.

The second example has to do with what I think of as individual
atomic statements that might be tagged with a CPE. Consider, the
act of tagging vulnerability information with a CPE. The general
practice in vulnerability reporting, especially early in the
vulnerability time line, is to report platform applicability at
a level of granularity that corresponds to non-leaf CPE names.
e.g. This bug is reported in Windows XP. But again, validation of
a bug against all known children of Windows XP is prohibitively
expensive. While we note that for some vulnerabilities on some
systems, this level of validation is eventually reached (usually as
result of QA processes surrounding patch publication), this level
of knowledge is absolutely unknowable during the early reporting
phase of the vulnerability life cycle.

Summarizing both examples, there are cases where there is a need to
tag data elements with non-leaf CPEs and where the interpretation
of the CPE must be ambiguous with respect to the applicability to
children of that CPE. That is, just because x is associated with
a CPE does not imply that x should be associated with all children
of the CPE.

SUGGESTED LANGUAGE FOR THE CPE SPEC
===================================
Here are two possible additions for the CPE spec. If the CPE
community feels that CPE tags should be interpreted inclusively
as applying to all children of a CPE, then the first should be
added to the CPE spec. If the CPE community can accept ambiguous,
non-inclusive use of CPE tags, then the second should be added to
the spec.

STRICT REVERSE MATCHING OF CPE NAMES FOR TAGS AND RELATIONSHIPS - It
will often be the case that relationships between other data elements
and CPE names will be asserted. The "tagging" of data elements with
CPE names is one such case of this. A data element can be tagged
with a CPE name if and only if the relationship holds for all children
of the CPE name. For example, a data element should be tagged
with the CPE name "cpe:/o:microsoft:windows-nt:xp" if and only if
the relationship holds for all variants of Windows XP.

FLEXIBLE USE OF CPE NAMES FOR TAGS AND RELATIONSHIPS - It will
often be the case that relationships between other data elements
and CPE names will be asserted. The "tagging" of data elements
with CPE names is one such case of this. A data element that is
tagged with a CPE name should not necessarily imply that the
relationship holds for all children of the CPE name. The publisher
of information tagged with CPEs should state in their relationship
definition if the relationship should or should not be interpretted
as equally applying to all children of the CPE name.

For example, if a data element is be tagged with the CPE name
"cpe:/o:microsoft:windows-nt:xp", the publisher should explicitly
state whether or not that this relationship relationship holds for
all variants of Windows XP.

-Dave
=================================================================
David Mann | CVE & CCE Project | The MITRE Corporation
-----------------------------------------------------------------
e-mail:damann@... | cell:781.424.6003
=================================================================

Andrew Buttner

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

I think this is a good point. I would think that CPE should not force
a STRICT choice for the relationships, but rather support the FLEXIBLE
choice that allows the user to define how the relationship exists.

Thanks
Drew

>-----Original Message-----
>From: Mann, Dave [mailto:damann@...]
>Sent: Friday, December 14, 2007 4:18 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Matching and the Interpretation
>of CPE Tags
>
>I would ask that CPE consider adding a new section to the CPE spec
>to clarify the correct usage of CPE names in relationships to
>other data elements. "Tagging" other data elements with CPE names
>is one form of relationship definition.
>
>In particular, I would ask that the CPE spec be updated to clarify
>CPE's position on if or how the "Matching" requirement affects the
>use of CPEs in relationship statements and tagging.
>
>In short, I think there are 2 choices for the CPE effort:
>
>1) STRICT REVERSE MATCHING FOR CPE TAGS - In every case that a CPE
> name is used to define a relationship (tag), the relationship must
> be interpretted as applying inclusively to all children of that CPE

> name. That is, if x applies to a CPE name, then x must apply to all
> children of that CPE name.
>
>2) FLEXIBLE, USER DEFINED USE OF CPE TAGS - The publisher of
> information tagged with CPE names is free to define how the
> CPE tag should be interpretted. The options include:
> a) Inclusive - The relationship must be interpretted as applying
> inclusively to all children of that CPE name. That is, if x
> applies to a CPE name, then x must apply to all children of
> that CPE name.
> b) Non-Inclusive - The relationship should be interpretted as
> being ambiguous with respect to the applicability to the
> children of that CPE name. That is, if x applies to a CPE name,
> then x may or may not apply to any child of that CPE name.
>
>
>Based on our experience on CCE (and my perspective from CVE), I
>strongly advocate the flexible approach. If a strict, inclusive
>interpretation of CPE tags is to be enforced, the only reasonable
>approach will be to force users of CPEs to restrict their use of
>CPE tags to only leaf names, which have no possible children.
>This would be cost-prohibitive in many cases and impossible in others,
>limiting the potential uses of CPE.
>
>
>I'll present a short discussion aimed at justifying this position
>followed by 2 proposed additions to the CPE spec to be considered.
>
>
>DISCUSSION
>----------
>The matching requirement in CPE requires that all children of a CPE
>name be proper subsets of the CPE name. For example, Windows XP Pro
>is a proper subset of Windows XP. The confusion that needs to be
>clarified is whether or not a sort of reverse-matching logic should
>be applied to the interpretation of CPE names when used as tags or
>when used to define relationships with other data elements.
>
>The basic point to be made is that this reverse-matching logic often
>does not work, nor is it desired. Instead, the use of non-leaf
>CPE names almost always is motivated out a need to ambiguously
>use the higher level CPE names in a non-inclusive manner.
>
>One of the biggest culprits demanding the ambiguity of a non-inclusive

>approach is the unknowability of future releases of software versions.
>
>That is, you never know when new versions of software will be
>introduced and what their capabilities will be. This makes any
>non-leaf CPE tag subject to change if CPE tags are to be interpreted
>in a non-inclusive manner.
>
>Let me motivate this with 2 examples. The first example has to
>do with what I think of tagging "containers", by which I mean things
>that contain other sub-elements. Consider a security guide written
>for Windows XP. The natural choice would be to tag this document
>with the CPE name:
> cpe:/o:microsoft:windows-nt:xp
>
>But, does this document really apply to all versions of Windows XP?
>What happened when Service Pack 2 was introduced. Some functionality
>in Windows XP was removed and lots of other functionality was added.
>How then should the document be tagged? I think there are only 2
>defensible approaches.
>
>The strict, inclusive approach (which I think is clearly out of step
>with how platform associations are currently made and which I think
>is much too labor intensive to be practical) would insist if the
>document is tagged with a CPE name, then the document should apply
>to all children of that CPE name. But, since future functionality
>is unknowable, the only way you can achieve this would be to tag
>the document with only those CPEs that are a) leaves in the CPE
>namespace with no possible children and b) have been verified as
>being covered by the document. Then, when future versions of the
>platform are made available, the guide author could decide to add
>additional CPE leaf names to the guide as appropriate.
>
>While this approach would add a tremendous amount of specificity and
>clarity to the CPE association of the security guide and while we
>recognize that some use cases may benefit from this sort of
>granularity, we also note that security guides and many other
>"containers" of functionality are not currently associated to
>platforms in this way.
>
>The second example has to do with what I think of as individual
>atomic statements that might be tagged with a CPE. Consider, the
>act of tagging vulnerability information with a CPE. The general
>practice in vulnerability reporting, especially early in the
>vulnerability time line, is to report platform applicability at
>a level of granularity that corresponds to non-leaf CPE names.
>e.g. This bug is reported in Windows XP. But again, validation of
>a bug against all known children of Windows XP is prohibitively
>expensive. While we note that for some vulnerabilities on some
>systems, this level of validation is eventually reached (usually as
>result of QA processes surrounding patch publication), this level
>of knowledge is absolutely unknowable during the early reporting
>phase of the vulnerability life cycle.
>
>Summarizing both examples, there are cases where there is a need to
>tag data elements with non-leaf CPEs and where the interpretation
>of the CPE must be ambiguous with respect to the applicability to
>children of that CPE. That is, just because x is associated with
>a CPE does not imply that x should be associated with all children
>of the CPE.
>
>SUGGESTED LANGUAGE FOR THE CPE SPEC
>===================================
>Here are two possible additions for the CPE spec. If the CPE
>community feels that CPE tags should be interpreted inclusively
>as applying to all children of a CPE, then the first should be
>added to the CPE spec. If the CPE community can accept ambiguous,
>non-inclusive use of CPE tags, then the second should be added to
>the spec.
>
>STRICT REVERSE MATCHING OF CPE NAMES FOR TAGS AND RELATIONSHIPS - It
>will often be the case that relationships between other data elements
>and CPE names will be asserted. The "tagging" of data elements with
>CPE names is one such case of this. A data element can be tagged
>with a CPE name if and only if the relationship holds for all children
>of the CPE name. For example, a data element should be tagged
>with the CPE name "cpe:/o:microsoft:windows-nt:xp" if and only if
>the relationship holds for all variants of Windows XP.
>
>
>FLEXIBLE USE OF CPE NAMES FOR TAGS AND RELATIONSHIPS - It will
>often be the case that relationships between other data elements
>and CPE names will be asserted. The "tagging" of data elements
>with CPE names is one such case of this. A data element that is
>tagged with a CPE name should not necessarily imply that the
>relationship holds for all children of the CPE name. The publisher
>of information tagged with CPEs should state in their relationship
>definition if the relationship should or should not be interpretted
>as equally applying to all children of the CPE name.
>
>For example, if a data element is be tagged with the CPE name
>"cpe:/o:microsoft:windows-nt:xp", the publisher should explicitly
>state whether or not that this relationship relationship holds for
>all variants of Windows XP.
>
>
>-Dave
>=================================================================
>David Mann | CVE & CCE Project | The MITRE Corporation
>-----------------------------------------------------------------
> e-mail:damann@... | cell:781.424.6003
>=================================================================
>

Dick_Whitehurst

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

It should be flexible, but not ambiguous. If a relationship is defined
between an entity and a CPE name, the entity should apply to any
"system" on which the application of the name's OVAL definition returns
"true." If only the currently known versions of XP is meant, the
relationship should be specified as the union (OR'ing) of each of the
known xp versions.

Dick

-----Original Message-----
From: Buttner, Drew [mailto:abuttner@...]
Sent: Monday, December 17, 2007 11:44 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Matching and the Interpretation of
CPE Tags

I think this is a good point. I would think that CPE should not force
a STRICT choice for the relationships, but rather support the FLEXIBLE
choice that allows the user to define how the relationship exists.

Thanks
Drew

Mann, Dave

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

Dick Whitehurst wrote:
> It should be flexible, but not ambiguous. If a relationship is
> defined between an entity and a CPE name, the entity should apply to
> any "system" on which the application of the name's OVAL definition
> returns "true." If only the currently known versions of XP is meant,
> the relationship should be specified as the union (OR'ing) of each of
> the known xp versions.

Dick,

I think there is no disagreement that non-ambiguous use
of CPE names is to be supported. The question is whether
or not CPE will also PERMIT THE AMBIGUOUS USE of CPE names
with respect to the set of children.

I'm not sure how you are using the term "flexible" above.
By flexible, I mean that both non-abiguous (as you've
described above) and ambiguous use of CPE names would be
permitted. This is what I was trying to convey when I wrote
[edited to add ambiguous and non-ambiguous]:

>> 2) FLEXIBLE, USER DEFINED USE OF CPE TAGS - The publisher of
>> information tagged with CPE names is free to define how the
>> CPE tag should be interpretted. The options include:
>> a) Inclusive [non-ambiguous] - The relationship must be
>> interpretted as applying inclusively to all children
>> of that CPE name. That is, if x applies to a CPE name,
>> then x must apply to all children of that CPE name.
>> b) Non-Inclusive [ambiguous] - The relationship should be
>> interpretted as being ambiguous with respect to the
>> applicability to the children of that CPE name. That is, if x
>> applies to a CPE name, then x may or may not apply to any child
>> of that CPE name.

It may be that the tension we are wrestling with is between
machine to machine communication and human to human communication.
Machine to machine communication demands that there be no
ambiguity. But person to person communication often
demands ambiguity.

I cited 2 examples where "tagging" is done ambiguously with
respect to children: the traditional titles of configuration
guides and vulnerability reporting.

While I will advocate that CPE allow for both non-ambiguous
tagging (no argument) and ambiguous tagging, I'm even more
concerned that the CPE community come to agreement one way
or the other, even if that means not allowing the ambiguous
use I'm advocating for.

As the CPE community considers this, please note that
non-ambiguous tagging is cost-prohibitive in many cases
and impossible in others. For example, if the CPE community
insists on non-ambiguous use of CPE names with respect to
children for tagging, I can't forsee any way that the CCE
project will be able to incorporate CPE. Ambiguous platform
assertions are the norm among configuration guides and
non-ambiguous tagging really requires a level of testing
and analysis that is beyond CCE's scope.

There may be some possible ways out of this...

One solution might be to add yet another field in the
CPE name to designate whether the name should be
interpretted non-ambiguously or ambiguouly with respect
to its children.

Another compromise might be for those of us who need to
make platform assertions in an ambiguous manner to restrict
our use of CPE to only the human readable CPE titles.
This would at least standardize our expression of platform
spellings while preventing erroneous machine parsing of
ambiguously applied tags.

-Dave
=================================================================
David Mann | CVE & CCE Project | The MITRE Corporation
-----------------------------------------------------------------
e-mail:damann@... | cell:781.424.6003
=================================================================

Ken Lassesen-3

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

I'm in favor of the suggestion below, and would suggest the term "hint"

Ken Lassesen,
Office 206-734-4718 Home: 360-724-3190
Cell: 360-509-2402 Skype: Ken.Lassesen
IM: Ken@... http://www.linkedin.com/in/lassesen
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Mann, Dave [mailto:damann@...]
One solution might be to add yet another field in the CPE name to
designate whether the name should be interpretted non-ambiguously or
ambiguouly with respect to its children.
-Dave
=================================================================
David Mann | CVE & CCE Project | The MITRE Corporation
-----------------------------------------------------------------
e-mail:damann@... | cell:781.424.6003
=================================================================

Andrew Buttner

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

I don't think we should put this info into the name. I think we should
leave it up to the implementation to determine how to use the CPE Name
and define any relationships with this name.

For example, if you want you can state that the CPE relates a possible
(but not proven) relationship between and entity and a system. I think
this is the "ambiguous" relationship being mentioned in this thread.

I think the important thing that we are learning from this thread is
that users of CPE must define how any relationship with CPE is to be
treated. And we need to add this reminder to the spec to help educate
users.

Thanks
Drew

>-----Original Message-----
>From: Ken Lassesen [mailto:ken.lassesen@...]
>Sent: Tuesday, December 18, 2007 11:16 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Matching and the
>Interpretation of CPE Tags
>
>I'm in favor of the suggestion below, and would suggest the
>term "hint"
>
>
>
>
>
>-----Original Message-----
>From: Mann, Dave [mailto:damann@...]
>
>One solution might be to add yet another field in the CPE name to
>designate whether the name should be interpretted non-ambiguously or
>ambiguouly with respect to its children.
>
>-Dave

Mann, Dave

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

Buttner, Drew wrote:
> I don't think we should put this info into the name. I think we
> should leave it up to the implementation to determine how to use the
> CPE Name and define any relationships with this name.
>
> For example, if you want you can state that the CPE relates a
possible
> (but not proven) relationship between and entity and a system. I
> think this is the "ambiguous" relationship being mentioned in this
> thread.

Ah, that is yet another form of ambiguity that I have not
mentioned but that we see from the vulnerability analysis
side of the house on CVE. To clarify, I'll try to define these
2 different forms of ambiguity.

NO REVERSE MATCHING - If x relates to a non-leaf CPE name,
then x may or may not relate to all children of that CPE.
e.g. Just because a security guide is tagged with Windows XP
does NOT imply that all settings within it apply to all
versions of Windows XP.

LOW CONFIDENCE - If x is stated to relate to a CPE name,
this relationship may or may not be true. e.g. If a
bugtraq post claims that a new vulnerability applies
to Mozilla 2.0.0.9, this may or may not be true.

I've been advocating that CPE allow for this No Reverse
Matching type of ambiguity, which I think is a bit different
in form than the Low Confidence type of ambiguity
that I think you've described. For example, when
tagging the DISA Stig for Windows XP, I know with 100%
surity that it was written for Windows XP, not Windows
2000 nor Windows Vista. What is unknowable is which
specific versions (current and future) of XP the guide
will apply to. To reiterate the question, is it legitimate
from CPE's perspective to tag this guide with Windows XP,
despite this No Reverse Matching type of ambiguity?

With respect to Low Confidence type of ambiguity
that you've raised, I think this is a very, very important
point to have been raised. And I think we both agree that this
should be mitigated by information producers making it
more clear what their relationships may imply. For example,
in vulnerability analysis, the application of a CPE tag
may mean any of the the following:
+ Has been reported to apply to
+ Has been reported by a reputable researcher to apply to
+ Has been independently demonstrated to apply to
+ Has been acknowledged by the vendor to apply to
+ Can be reasonably assumed for patching purposes to apply to

The CVE project has been aware of the Low Confidence type
of ambiguity for a long time but I can offer no suggestion
on how CPE should address it. Clearly, capturing the rich
semantics of nuanced relationships is, and very much should
be, beyond the scope of CPE itself. So I think there's nothing
to say other than that consumers of CPE tagged information
should be very sure to understand the implications of the
relationships.

Setting aside the interesting question of Low Confidence
ambiguities, my original question still remains...
Is it legitmate to tag a security guide with Windows XP
even if we don't know that the guide applies to all versions
of Windows XP?

I think Dick has said no and Ken has said yes provided the
CPE name contains some sort of ambiguity flag.

Others?

-Dave
=================================================================
David Mann | CVE & CCE Project | The MITRE Corporation
-----------------------------------------------------------------
e-mail:damann@... | cell:781.424.6003
=================================================================

Andrew Buttner

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

>I've been advocating that CPE allow for this No Reverse
>Matching type of ambiguity, which I think is a bit different
>in form than the Low Confidence type of ambiguity
>that I think you've described. For example, when
>tagging the DISA Stig for Windows XP, I know with 100%
>surity that it was written for Windows XP, not Windows
>2000 nor Windows Vista. What is unknowable is which
>specific versions (current and future) of XP the guide
>will apply to. To reiterate the question, is it legitimate
>from CPE's perspective to tag this guide with Windows XP,
>despite this No Reverse Matching type of ambiguity?

Again, I don't think CPE wants to pass judgment on this type of
question. I think it would be best to leave this up to an
implementation.

All a CPE Name does is identify a set of platform types. Think of this
as a bucket. How the things in this bucket relate to your entity
(vuln, security guide, etc.) is up to you to define. Looking at your
NO REVERSE MATCHING example, there is nothing against defining a
relationship that says "every platform type in the defined bucket may
or may not relate to x". All CPE wants to do is define the bucket.

Note that CPE matching does not technically define relationships, but
rather just helps determine if one bucket is part of a bigger bucket.
For example, the cpe:/o:microsoft:windows_xp bucket contains a huge
number of different platform types. Is
cpe:/o:microsoft:windows_xp::sp2 included in this bucket? Matching
will tell you 'yes'. But just because it is included in the bucket,
doesn't mean we have defined the relationship between your entity and
each platform type in the bucket.

>For example,
>in vulnerability analysis, the application of a CPE tag
>may mean any of the the following:
>+ Has been reported to apply to
>+ Has been reported by a reputable researcher to apply to
>+ Has been independently demonstrated to apply to
>+ Has been acknowledged by the vendor to apply to
>+ Can be reasonably assumed for patching purposes to apply to

... and it is up to the analysis implementation to determine what the
application of the a CPE Name means. It could be any of the meanings
you point out.

>Setting aside the interesting question of Low Confidence
>ambiguities, my original question still remains...
>Is it legitimate to tag a security guide with Windows XP
>even if we don't know that the guide applies to all versions
>of Windows XP?

This is a question for the guide writer or for the standard that is
coordinating guide writing (XCCDF?), not for CPE.

Dave - Does this all make sense? Does this help clear up any
confusion?

Thanks
Drew

Mann, Dave

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

Dave Mann wrote:
>> ..., is it legitimate
>> from CPE's perspective to tag this guide with Windows XP,
>> despite this No Reverse Matching type of ambiguity?

Buttner, Drew wrote:
> Again, I don't think CPE wants to pass judgment on this type of
> question. I think it would be best to leave this up to an
> implementation.

This is great.

> This is a question for the guide writer or for the standard that is
> coordinating guide writing (XCCDF?), not for CPE.

A clarification....

While we agree that it is up to the content producer to
decide to use CPE tags in an ambiguous or non-ambiguous
manner as they see fit, I think it is very important for
CPE to officially address the issue in the CPE spec.

Thanks a bunch!

-Dave
=================================================================
David Mann | CVE & CCE Project | The MITRE Corporation
-----------------------------------------------------------------
e-mail:damann@... | cell:781.424.6003
=================================================================

Wolfkiel, Joseph

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

In reply to this post by Mann, Dave

The DoD is also depending on this property to be able to do CPE matching to
look up vulnerabilities.

If a database gives us some CPE information and the only thing they know
about their box is that it has Windows XP and Office 2003 on it, we'll need
to pull all the CVEs related to MS Windows XP (Vendor:Product) and to MS
Office 2003 (Vendor:Product:Version) and let the OVAL definitions do the
rest of the work. I thought this was defined as the "rollup" property of
CPE. It also biases us toward false positives for vulnerability assessment
versus false negatives, which I think is the general preference from a
security standpoint.

If I understand the discussion right, what's being advocated is that it will
be up to the implementer to interpret whether they treat their CPEs as
having the rollup property or not.

I'm not sure that's entirely a good idea. Seems like we'd run into
interoperability issues pretty quickly. My preference would be that
unspecified=wildcard as the general rule for CPE Components. I think this
would address Dave Mann's use case, mine, and the CPE-matching required to
pull the security checklist for XCCDF as well.

I think we need broad feedback on this. I believe it's critical to CPE that
this behavior is commonly understood.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Mann, Dave [mailto:damann@...]
Sent: Wednesday, December 19, 2007 1:47 PM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Matching and the Interpretation of
CPE Tags

Dave Mann wrote:
>> ..., is it legitimate
>> from CPE's perspective to tag this guide with Windows XP,
>> despite this No Reverse Matching type of ambiguity?

Buttner, Drew wrote:
> Again, I don't think CPE wants to pass judgment on this type of
> question. I think it would be best to leave this up to an
> implementation.

This is great.

> This is a question for the guide writer or for the standard that is
> coordinating guide writing (XCCDF?), not for CPE.

A clarification....

While we agree that it is up to the content producer to
decide to use CPE tags in an ambiguous or non-ambiguous
manner as they see fit, I think it is very important for
CPE to officially address the issue in the CPE spec.

Thanks a bunch!

-Dave
=================================================================
David Mann | CVE & CCE Project | The MITRE Corporation
-----------------------------------------------------------------
e-mail:damann@... | cell:781.424.6003
=================================================================

Andrew Buttner

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

>If I understand the discussion right, what's being advocated
>is that it will
>be up to the implementer to interpret whether they treat their CPEs as
>having the rollup property or not.

I think I would restate as: What is being advocated is that it will be
up to the implementer to determine how their entity relates to the list
of more descriptive platform types that are included in the roll-up.
The roll-up property doesn't change. But how things relate needs to be
defined. The discussion is about making sure we educate users, rather
than about changing the spec.

Again, I think it will help everyone to think of a CPE as an identifier
of a bucket of platform types. For example, the
cpe:/o:microsoft:windows_xp bucket would contain:

Windows XP pro
Windows XP gold
Windows XP sp1
Windows XP sp1 home
<and the list goes on>

If you relate an entity to this bucket (ie you map a vulnerability to
this CPE Name), then what does this mean:

- vuln has been proven to exist on all the platforms in the bucket
- vuln might exist on these platforms, but definitely not others
- vuln is most likely to exist on these but it may not
- vuln has been stated to exist on these but there may be others
<and the list goes on>

When you assign a CPE Name to something, you need to make clear what
the relationship is and what the mapping means. CPE does not want to
define this relationship as that would limit the use cases for CPE.

Robert A. Martin

Re: Matching and the Interpretation of CPE Tags

Reply Threaded

In reply to this post by Mann, Dave

As someone reading the different posts on this thread I think you all
are talking slightly past each other.

When Drew says its up to the user I believe the users he is talking
about is other standards efforts or content creators - i.e., if CCE
wants to use CPE the way Dave has stated then CCE needs to explicitly
educate the various parts of the CCE community that that is how CCE
will use CPEs - and that use is okay with the CPE community.
Alternately, if vulnerability content creators decide to use CPEs and
they want to use them in some manner that ties just the CPE listed to
the vulnerability information then that's okay too but like the CCE
community they must state how they are using CPE so the consumers of
the info use it correctly.

Several people seem to be asking that CPE add a field/tag that would
allow the CPEs used to carry with them how the content creator
intended the CPE to be used which seems reasonable in my mind.

The addition of this "intended use" field/tag should be from a
carefully crafted list of options (which have been discussed on this
list) and by having the tag in the CPE name it will probably reduce
the times that the human reading a CPE name mistakenly interprets the
CPE name as representing something that its not - since the humans
are rarely going to read the OVAL definitions of the CPE names...

Bob's 2 cents.

At 8:18 AM -0500 12/20/07, Buttner, Drew wrote:

> >If I understand the discussion right, what's being advocated
>>is that it will
>>be up to the implementer to interpret whether they treat their CPEs as
>>having the rollup property or not.
>
>I think I would restate as: What is being advocated is that it will be
>up to the implementer to determine how their entity relates to the list
>of more descriptive platform types that are included in the roll-up.
>The roll-up property doesn't change. But how things relate needs to be
>defined. The discussion is about making sure we educate users, rather
>than about changing the spec.
>
>Again, I think it will help everyone to think of a CPE as an identifier
>of a bucket of platform types. For example, the
>cpe:/o:microsoft:windows_xp bucket would contain:
>
> Windows XP pro
> Windows XP gold
> Windows XP sp1
> Windows XP sp1 home
> <and the list goes on>
>
>If you relate an entity to this bucket (ie you map a vulnerability to
>this CPE Name), then what does this mean:
>
> - vuln has been proven to exist on all the platforms in the bucket
> - vuln might exist on these platforms, but definitely not others
> - vuln is most likely to exist on these but it may not
> - vuln has been stated to exist on these but there may be others
> <and the list goes on>
>
>When you assign a CPE Name to something, you need to make clear what
>the relationship is and what the mapping means. CPE does not want to
>define this relationship as that would limit the use cases for CPE.

Wolfkiel, Joseph

Re: Matching and the Interpretation of CPE Tags

Reply Threaded