Quantcast

FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

Brant Cheikes

x-post from scap-dev list on topic of interest to CPE community.

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Wednesday, May 04, 2011 1:13 PM
To: Multiple recipients of list
Subject: Re: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

 

Personally I feel this just unnecessarily complicates things.  I really don't like the idea of things having the capability and potential to change out from underneath us (vendors and customers).

 

Vendors do not control the MITRE definitions nor the quality of them. NIST, making changes that could adversely affect a needed CPE entry, could cause a great deal of problems across all SCAP enabled products globally.  NIST's site being unavailable could cause economic issues if organizations can not get the information needed when it is needed.  Does this make sense to anyone, really?

 

Vendors do control what is in our packages and our QA does a great job of ferreting out issues. When we don't it costs us money in support. Vendors have had to make local corrections to the content of the CPE dictionary in the past and while we waited for corrections to be made to the official dictionary. Customers do not like to wait.

 

I do not believe this proposal does anything useful for the vendor community or customers of SCAP enabled products.  Centralizing access to this kind of core capability would be a bad thing. The US Legislative and Executive branches are having budget issues that could in the future affect the ability of the Federal Government to be able to supply access to critical facilities. There were real questions as to whether the NVD would be staffed during a recent potential government shutdown. We cannot develop standards that require a single point of failure.

 

I know that this is just an idea but it is one that is overreaching and detrimental to advancing the standards we are all working for…

 

Kent Landfield

Director Content Strategy, Architecture and Standards

 

McAfee, Inc.

5000 Headquarters Dr.

Plano, Texas 75024

 

Direct: +1.972.963.7096

Mobile: +1.817.637.8026

Web: www.mcafee.com<http://www.mcafee.com/>

 

From: "Halbardier, Adam" <[hidden email]<mailto:[hidden email]>>

Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>

Date: Wed, 4 May 2011 11:23:45 -0500

To: Multiple recipients of list <[hidden email]<mailto:[hidden email]>>

Subject: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

Community,

 

We are beginning work on SCAP 1.2 and we’d like your thoughts on an item related to the CPE dictionary.  In SCAP 1.0 and 1.1, each CPE referenced in the XCCDF platform was required to be defined in the CPE Dictionary component included with the data stream.  Each item in the CPE Dictionary component was required to reference an inventory OVAL definition in the CPE Inventory component.  That OVAL definition is the check that determines if the CPE exists on a target.

 

Since many CPE entries exist in the official CPE dictionary (http://static.nvd.nist.gov/feeds/xml/cpe/dictionary/), and many of those have checks that reference the MITRE OVAL repository (see below), would it be beneficial if SCAP 1.2 supports the ability to reference the official dictionary instead of defining all of the dictionary entries for the data stream local to the data stream?

 

  <cpe-item  name="cpe:/a:microsoft:content_management_server:2001:sp1">

    <title xml:lang="en-US">Microsoft content_management_server 2001 sp1</title>

    <check href="http://oval.mitre.org/repository/data/DownloadDefinition?id=oval:org.mitre.oval:def:1631" system="http://oval.mitre.org/XMLSchema/oval-definitions-5">oval:org.mitre.oval:def:1631</check>

    <meta:item-metadata modification-date="2008-04-15T19:56:18.660" status="FINAL" nvd-id="67328" />

  </cpe-item>

If referencing the official dictionary is a beneficial addition to SCAP, it will still be necessary to support local dictionaries as well for situations where remote file access is not possible or permitted.  In addition, I suspect that it would be desirable to have a “failover” capability from a remote (official) dictionary to a local dictionary should the remote dictionary be unreachable.

Please send your feedback direct to me ([hidden email]>).

 

Thank you,

Adam

 

 

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

 

To unsubscribe from this mailing list, please send an e-mail to

[hidden email] with the words "unsubscribe scap-dev" in the body. You

will need to send this from the email account that you used to initially

subscribe to scap-dev.

 


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

Robert Hollis

Well, my concern *is* that failover.

When a failover situation occurs, there is *no* guarantee that the secondary source has the identical definition to the primary.  That’s where the inconsistency and ambiguity enters.

 

The way SCAP references patch content is a perfect example.  The patch process already has such a failover built in.  Use the online patch definition file if available.  If not, use a local file.  With this in mind, take a single asset that has no internet connectivity.

 

In one case, the SCAP engine could run locally.  Without Internet access, it uses the local, secondary (possibly out-dated) patch file.  When a remote scan is run against the asset from a source that *does* have Internet access, the online, primary patch file is used.  If those files differ, then the same SCAP assessment against the same target produces different results.

 

I’d really prefer us not introduce this complication in another facet of SCAP.

 

                -rob

 

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, May 04, 2011 2:38 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

x-post from scap-dev list on topic of interest to CPE community.

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Wednesday, May 04, 2011 1:13 PM
To: Multiple recipients of list
Subject: Re: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

 

Personally I feel this just unnecessarily complicates things.  I really don't like the idea of things having the capability and potential to change out from underneath us (vendors and customers).

 

Vendors do not control the MITRE definitions nor the quality of them. NIST, making changes that could adversely affect a needed CPE entry, could cause a great deal of problems across all SCAP enabled products globally.  NIST's site being unavailable could cause economic issues if organizations can not get the information needed when it is needed.  Does this make sense to anyone, really?

 

Vendors do control what is in our packages and our QA does a great job of ferreting out issues. When we don't it costs us money in support. Vendors have had to make local corrections to the content of the CPE dictionary in the past and while we waited for corrections to be made to the official dictionary. Customers do not like to wait.

 

I do not believe this proposal does anything useful for the vendor community or customers of SCAP enabled products.  Centralizing access to this kind of core capability would be a bad thing. The US Legislative and Executive branches are having budget issues that could in the future affect the ability of the Federal Government to be able to supply access to critical facilities. There were real questions as to whether the NVD would be staffed during a recent potential government shutdown. We cannot develop standards that require a single point of failure.

 

I know that this is just an idea but it is one that is overreaching and detrimental to advancing the standards we are all working for…

 

Kent Landfield

Director Content Strategy, Architecture and Standards

 

McAfee, Inc.

5000 Headquarters Dr.

Plano, Texas 75024

 

Direct: +1.972.963.7096

Mobile: +1.817.637.8026

Web: www.mcafee.com<http://www.mcafee.com/>

 

From: "Halbardier, Adam" <[hidden email]<mailto:[hidden email]>>

Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>

Date: Wed, 4 May 2011 11:23:45 -0500

To: Multiple recipients of list <[hidden email]<mailto:[hidden email]>>

Subject: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

Community,

 

We are beginning work on SCAP 1.2 and we’d like your thoughts on an item related to the CPE dictionary.  In SCAP 1.0 and 1.1, each CPE referenced in the XCCDF platform was required to be defined in the CPE Dictionary component included with the data stream.  Each item in the CPE Dictionary component was required to reference an inventory OVAL definition in the CPE Inventory component.  That OVAL definition is the check that determines if the CPE exists on a target.

 

Since many CPE entries exist in the official CPE dictionary (http://static.nvd.nist.gov/feeds/xml/cpe/dictionary/), and many of those have checks that reference the MITRE OVAL repository (see below), would it be beneficial if SCAP 1.2 supports the ability to reference the official dictionary instead of defining all of the dictionary entries for the data stream local to the data stream?

 

  <cpe-item  name="cpe:/a:microsoft:content_management_server:2001:sp1">

    <title xml:lang="en-US">Microsoft content_management_server 2001 sp1</title>

    <check href="http://oval.mitre.org/repository/data/DownloadDefinition?id=oval:org.mitre.oval:def:1631" system="http://oval.mitre.org/XMLSchema/oval-definitions-5">oval:org.mitre.oval:def:1631</check>

    <meta:item-metadata modification-date="2008-04-15T19:56:18.660" status="FINAL" nvd-id="67328" />

  </cpe-item>

If referencing the official dictionary is a beneficial addition to SCAP, it will still be necessary to support local dictionaries as well for situations where remote file access is not possible or permitted.  In addition, I suspect that it would be desirable to have a “failover” capability from a remote (official) dictionary to a local dictionary should the remote dictionary be unreachable.

Please send your feedback direct to me ([hidden email]>).

 

Thank you,

Adam

 

 

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

 

To unsubscribe from this mailing list, please send an e-mail to

[hidden email] with the words "unsubscribe scap-dev" in the body. You

will need to send this from the email account that you used to initially

subscribe to scap-dev.

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

Waltermire, David A.

Cross posting to the XCCDF list.

 

Rob,

 

I agree with your concerns about ambiguity.  This is something we want to address in SCAP 1.2.  The problem is not failover per se, but more so providing information in the results that provides context for what content was used in the case of failover.  This information might include where the content can be found along with integrity information relating to it.  The following JIRA issues deal with this concern as it pertains to check failover:

 

https://services.nvd.nist.gov/jira/browse/SCAPDEV-16

https://services.nvd.nist.gov/jira/browse/XCCDF-72

 

If this information is provided, then tools processing XCCDF results will be able to consider the check results in the appropriate context.  A similar approach could be used to report what dictionary (local, 3rd-party, or official) was used.  This would also reduce the ambiguity that exists today regarding the use of dictionary content when processing SCAP datastreams.

 

Sincerely,

 

Dave Waltermire

SCAP Architect

National Institute of Standards and Technology

(301) 975-3390

[hidden email]

 

From: Robert Hollis [mailto:[hidden email]]
Sent: Wednesday, May 04, 2011 4:05 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

Well, my concern *is* that failover.

When a failover situation occurs, there is *no* guarantee that the secondary source has the identical definition to the primary.  That’s where the inconsistency and ambiguity enters.

 

The way SCAP references patch content is a perfect example.  The patch process already has such a failover built in.  Use the online patch definition file if available.  If not, use a local file.  With this in mind, take a single asset that has no internet connectivity.

 

In one case, the SCAP engine could run locally.  Without Internet access, it uses the local, secondary (possibly out-dated) patch file.  When a remote scan is run against the asset from a source that *does* have Internet access, the online, primary patch file is used.  If those files differ, then the same SCAP assessment against the same target produces different results.

 

I’d really prefer us not introduce this complication in another facet of SCAP.

 

                -rob

 

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, May 04, 2011 2:38 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

x-post from scap-dev list on topic of interest to CPE community.

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Wednesday, May 04, 2011 1:13 PM
To: Multiple recipients of list
Subject: Re: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

 

Personally I feel this just unnecessarily complicates things.  I really don't like the idea of things having the capability and potential to change out from underneath us (vendors and customers).

 

Vendors do not control the MITRE definitions nor the quality of them. NIST, making changes that could adversely affect a needed CPE entry, could cause a great deal of problems across all SCAP enabled products globally.  NIST's site being unavailable could cause economic issues if organizations can not get the information needed when it is needed.  Does this make sense to anyone, really?

 

Vendors do control what is in our packages and our QA does a great job of ferreting out issues. When we don't it costs us money in support. Vendors have had to make local corrections to the content of the CPE dictionary in the past and while we waited for corrections to be made to the official dictionary. Customers do not like to wait.

 

I do not believe this proposal does anything useful for the vendor community or customers of SCAP enabled products.  Centralizing access to this kind of core capability would be a bad thing. The US Legislative and Executive branches are having budget issues that could in the future affect the ability of the Federal Government to be able to supply access to critical facilities. There were real questions as to whether the NVD would be staffed during a recent potential government shutdown. We cannot develop standards that require a single point of failure.

 

I know that this is just an idea but it is one that is overreaching and detrimental to advancing the standards we are all working for…

 

Kent Landfield

Director Content Strategy, Architecture and Standards

 

McAfee, Inc.

5000 Headquarters Dr.

Plano, Texas 75024

 

Direct: +1.972.963.7096

Mobile: +1.817.637.8026

Web: www.mcafee.com<http://www.mcafee.com/>

 

From: "Halbardier, Adam" <[hidden email]<mailto:[hidden email]>>

Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>

Date: Wed, 4 May 2011 11:23:45 -0500

To: Multiple recipients of list <[hidden email]<mailto:[hidden email]>>

Subject: Local CPE Dictionaries vs. the Official CPE Dictionary in SCAP 1.2

 

Community,

 

We are beginning work on SCAP 1.2 and we’d like your thoughts on an item related to the CPE dictionary.  In SCAP 1.0 and 1.1, each CPE referenced in the XCCDF platform was required to be defined in the CPE Dictionary component included with the data stream.  Each item in the CPE Dictionary component was required to reference an inventory OVAL definition in the CPE Inventory component.  That OVAL definition is the check that determines if the CPE exists on a target.

 

Since many CPE entries exist in the official CPE dictionary (http://static.nvd.nist.gov/feeds/xml/cpe/dictionary/), and many of those have checks that reference the MITRE OVAL repository (see below), would it be beneficial if SCAP 1.2 supports the ability to reference the official dictionary instead of defining all of the dictionary entries for the data stream local to the data stream?

 

  <cpe-item  name="cpe:/a:microsoft:content_management_server:2001:sp1">

    <title xml:lang="en-US">Microsoft content_management_server 2001 sp1</title>

    <check href="http://oval.mitre.org/repository/data/DownloadDefinition?id=oval:org.mitre.oval:def:1631" system="http://oval.mitre.org/XMLSchema/oval-definitions-5">oval:org.mitre.oval:def:1631</check>

    <meta:item-metadata modification-date="2008-04-15T19:56:18.660" status="FINAL" nvd-id="67328" />

  </cpe-item>

If referencing the official dictionary is a beneficial addition to SCAP, it will still be necessary to support local dictionaries as well for situations where remote file access is not possible or permitted.  In addition, I suspect that it would be desirable to have a “failover” capability from a remote (official) dictionary to a local dictionary should the remote dictionary be unreachable.

Please send your feedback direct to me ([hidden email]>).

 

Thank you,

Adam

 

 

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

 

To unsubscribe from this mailing list, please send an e-mail to

[hidden email] with the words "unsubscribe scap-dev" in the body. You

will need to send this from the email account that you used to initially

subscribe to scap-dev.

 

Loading...