Quantcast

FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

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

FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

Brant Cheikes

CPE Community,

 

See note from Nicolas Reichert below—it’s an interesting suggestion for a piece of extended metadata, though it begs the question of how such “end of life” information could be reliably obtained and maintained in the CPE dictionary.  Comments welcome.

 

/Brant

 

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: REICHERT, Nicolas [mailto:[hidden email]]
Sent: Monday, August 15, 2011 10:44 AM
To: CPE
Subject: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]
Importance: High

 

Dear all,

 

During intensive work with CPE’s we were faced with one problem in general.

The “End of Life” of products is currently not part of any spec. within the hole framework.

 

For Legacy components were vulnerabilities are published but the Software will no longer be supported due “to end of life”, or cutted vendor support i.e.:

 

cpe:/o:microsoft:windows:2000:sp4

Vendor: microsoft

Product: windows

Version: 2000

Revision: sp4

 

It would be very useful to have an „end of life“ - flag i.e. an ISO Timestamp (UTC) to identify if the product is supported or “end of life”.

 

cpe:/o:microsoft:windows_xp:-:sp3:professional

Vendor: microsoft

Product: windows_xp

Version: -

Revision: sp3

Edition: professional

EOL: 2011-04-01 00:00:00

 

Please don’t hesitate to contact me directly or call me if you have any further questions or if you would like to start discussions about.

We guess that this kind of extension to the spec. could be very useful and interesting for a large number of users / clients.

 

 

 

Mit freundlichen Gruessen - Best regards,

 

 

Nicolas Reichert

Aircraft In-Service Security Engineer

Aircraft In-Service Security - EIDS

AIRBUS

 

Phone:  +49 40 743 56209

Fax: +49 40 743 870 56209

Mailto: nicolas.reichert@...

 

AIRBUS Operations GmbH

Kreetslag 10

21129 Hamburg

Deutschland

 

Sitz der Gesellschaft / Legal Domicile: Hamburg

Registergericht / Registration Court: Amtsgericht Hamburg HRB 43527

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Thomas Enders

Geschäftsführung / Board of Management:

Günter Butschek, Vorsitzender / Chairman & CEO;

Joachim Sauer; Harald Wilhelm

 

PGP:

Key ID: 0xD9D41BA1
Fingerprint: FD 3F 41 B4 AE B0 1B 3E F8 23  78 36 CF 40 72 44 D9 D4 1B A1

 

SMIME:

Serial: 11 21 4d fa 66 73 1a f3 92 6c f9 b3 62 6f dc b7 b4 73
Fingerprint: 9a a9 91 77 f8 3e 4b 9b b2 31 5f 14 cc 4e ee e1 b5 a1 88 5e

 

 

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

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

Re: FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

McCormick, Christopher [USA]
Interesting idea, but can't EOL information effectively be captured with a note? 

From: Cheikes, Brant A. [[hidden email]]
Sent: Thursday, September 01, 2011 1:22 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

CPE Community,

 

See note from Nicolas Reichert below—it’s an interesting suggestion for a piece of extended metadata, though it begs the question of how such “end of life” information could be reliably obtained and maintained in the CPE dictionary.  Comments welcome.

 

/Brant

 

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: REICHERT, Nicolas [mailto:[hidden email]]
Sent: Monday, August 15, 2011 10:44 AM
To: CPE
Subject: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]
Importance: High

 

Dear all,

 

During intensive work with CPE’s we were faced with one problem in general.

The “End of Life” of products is currently not part of any spec. within the hole framework.

 

For Legacy components were vulnerabilities are published but the Software will no longer be supported due “to end of life”, or cutted vendor support i.e.:

 

cpe:/o:microsoft:windows:2000:sp4

Vendor: microsoft

Product: windows

Version: 2000

Revision: sp4

 

It would be very useful to have an „end of life“ - flag i.e. an ISO Timestamp (UTC) to identify if the product is supported or “end of life”.

 

cpe:/o:microsoft:windows_xp:-:sp3:professional

Vendor: microsoft

Product: windows_xp

Version: -

Revision: sp3

Edition: professional

EOL: 2011-04-01 00:00:00

 

Please don’t hesitate to contact me directly or call me if you have any further questions or if you would like to start discussions about.

We guess that this kind of extension to the spec. could be very useful and interesting for a large number of users / clients.

 

 

 

Mit freundlichen Gruessen - Best regards,

 

 

Nicolas Reichert

Aircraft In-Service Security Engineer

Aircraft In-Service Security - EIDS

AIRBUS

 

Phone:  +49 40 743 56209

Fax: +49 40 743 870 56209

Mailto: nicolas.reichert@...

 

AIRBUS Operations GmbH

Kreetslag 10

21129 Hamburg

Deutschland

 

Sitz der Gesellschaft / Legal Domicile: Hamburg

Registergericht / Registration Court: Amtsgericht Hamburg HRB 43527

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Thomas Enders

Geschäftsführung / Board of Management:

Günter Butschek, Vorsitzender / Chairman & CEO;

Joachim Sauer; Harald Wilhelm

 

PGP:

Key ID: 0xD9D41BA1
Fingerprint: FD 3F 41 B4 AE B0 1B 3E F8 23  78 36 CF 40 72 44 D9 D4 1B A1

 

SMIME:

Serial: 11 21 4d fa 66 73 1a f3 92 6c f9 b3 62 6f dc b7 b4 73
Fingerprint: 9a a9 91 77 f8 3e 4b 9b b2 31 5f 14 cc 4e ee e1 b5 a1 88 5e

 

 

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

Tim Keanini
In reply to this post by Brant Cheikes

It is worth making two assertions that everyone is welcomed to challenge

 

Assertion 1: We require a temporal tag to be readable by machine and by human

I carefully say temporal tag because it might not be necessary to tightly couple it to End-of-Life

Assertion 2: In tags like 19770-2 and SCSI-ID, there is a time associated with the tag so that the reasoning around time can be done externally and for a broader purpose.

Example would be any certain tags made from company_A before the date when they were acquired by company_B would be machine identifiable and the appropriate semantics could be applied (same_as).  Or if we are talking about lifecycle changes like (First Customer Shipped, Last Customer Shipped, End of Sale, End of Life), all of these can be modeled for domains that really care about this and not hardwired into CPE.

The concern is that what goes into CPE should be as generic and simple as possible.  CPE should only contain enough of a vocabulary so that “that which has a configuration” or “that which has a vulnerability” can be identified.  By this line of reasoning, it would be best to stick a temporal tag in CPE and then have a standard which contained all the product lifecycle vocabulary (metadata on FCS, LCS, EoS, EoL) extend CPE.

 

--tk

 

From: Mccormick, Christopher [USA] [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 1:07 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

Interesting idea, but can't EOL information effectively be captured with a note? 


From: Cheikes, Brant A. [[hidden email]]
Sent: Thursday, September 01, 2011 1:22 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

CPE Community,

 

See note from Nicolas Reichert below—it’s an interesting suggestion for a piece of extended metadata, though it begs the question of how such “end of life” information could be reliably obtained and maintained in the CPE dictionary.  Comments welcome.

 

/Brant

 

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: REICHERT, Nicolas [hidden email]
Sent: Monday, August 15, 2011 10:44 AM
To: CPE
Subject: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]
Importance: High

 

Dear all,

 

During intensive work with CPE’s we were faced with one problem in general.

The “End of Life” of products is currently not part of any spec. within the hole framework.

 

For Legacy components were vulnerabilities are published but the Software will no longer be supported due “to end of life”, or cutted vendor support i.e.:

 

cpe:/o:microsoft:windows:2000:sp4

Vendor: microsoft

Product: windows

Version: 2000

Revision: sp4

 

It would be very useful to have an „end of life“ - flag i.e. an ISO Timestamp (UTC) to identify if the product is supported or “end of life”.

 

cpe:/o:microsoft:windows_xp:-:sp3:professional

Vendor: microsoft

Product: windows_xp

Version: -

Revision: sp3

Edition: professional

EOL: 2011-04-01 00:00:00

 

Please don’t hesitate to contact me directly or call me if you have any further questions or if you would like to start discussions about.

We guess that this kind of extension to the spec. could be very useful and interesting for a large number of users / clients.

 

 

 

Mit freundlichen Gruessen - Best regards,

 

 

Nicolas Reichert

Aircraft In-Service Security Engineer

Aircraft In-Service Security - EIDS

AIRBUS

 

Phone:  +49 40 743 56209

Fax: +49 40 743 870 56209

Mailto: nicolas.reichert@...

 

AIRBUS Operations GmbH

Kreetslag 10

21129 Hamburg

Deutschland

 

Sitz der Gesellschaft / Legal Domicile: Hamburg

Registergericht / Registration Court: Amtsgericht Hamburg HRB 43527

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Thomas Enders

Geschäftsführung / Board of Management:

Günter Butschek, Vorsitzender / Chairman & CEO;

Joachim Sauer; Harald Wilhelm

 

PGP:

Key ID: 0xD9D41BA1
Fingerprint: FD 3F 41 B4 AE B0 1B 3E F8 23  78 36 CF 40 72 44 D9 D4 1B A1

 

SMIME:

Serial: 11 21 4d fa 66 73 1a f3 92 6c f9 b3 62 6f dc b7 b4 73
Fingerprint: 9a a9 91 77 f8 3e 4b 9b b2 31 5f 14 cc 4e ee e1 b5 a1 88 5e

 

 

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

Brant Cheikes

Ok, so let’s say we agree to add a “temporal tag” (timestamp) to each CPE.  How should the value of that tag be determined, i.e., timestamp of what?  Timestamp when the CPE went into the dictionary, timestamp when the product was released, …?

 

/Brant

 

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: Tim Keanini [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 2:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

It is worth making two assertions that everyone is welcomed to challenge

 

Assertion 1: We require a temporal tag to be readable by machine and by human

I carefully say temporal tag because it might not be necessary to tightly couple it to End-of-Life

Assertion 2: In tags like 19770-2 and SCSI-ID, there is a time associated with the tag so that the reasoning around time can be done externally and for a broader purpose.

Example would be any certain tags made from company_A before the date when they were acquired by company_B would be machine identifiable and the appropriate semantics could be applied (same_as).  Or if we are talking about lifecycle changes like (First Customer Shipped, Last Customer Shipped, End of Sale, End of Life), all of these can be modeled for domains that really care about this and not hardwired into CPE.

The concern is that what goes into CPE should be as generic and simple as possible.  CPE should only contain enough of a vocabulary so that “that which has a configuration” or “that which has a vulnerability” can be identified.  By this line of reasoning, it would be best to stick a temporal tag in CPE and then have a standard which contained all the product lifecycle vocabulary (metadata on FCS, LCS, EoS, EoL) extend CPE.

 

--tk

 

From: Mccormick, Christopher [USA] [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 1:07 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

Interesting idea, but can't EOL information effectively be captured with a note? 


From: Cheikes, Brant A. [[hidden email]]
Sent: Thursday, September 01, 2011 1:22 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

CPE Community,

 

See note from Nicolas Reichert below—it’s an interesting suggestion for a piece of extended metadata, though it begs the question of how such “end of life” information could be reliably obtained and maintained in the CPE dictionary.  Comments welcome.

 

/Brant

 

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: REICHERT, Nicolas [hidden email]
Sent: Monday, August 15, 2011 10:44 AM
To: CPE
Subject: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]
Importance: High

 

Dear all,

 

During intensive work with CPE’s we were faced with one problem in general.

The “End of Life” of products is currently not part of any spec. within the hole framework.

 

For Legacy components were vulnerabilities are published but the Software will no longer be supported due “to end of life”, or cutted vendor support i.e.:

 

cpe:/o:microsoft:windows:2000:sp4

Vendor: microsoft

Product: windows

Version: 2000

Revision: sp4

 

It would be very useful to have an „end of life“ - flag i.e. an ISO Timestamp (UTC) to identify if the product is supported or “end of life”.

 

cpe:/o:microsoft:windows_xp:-:sp3:professional

Vendor: microsoft

Product: windows_xp

Version: -

Revision: sp3

Edition: professional

EOL: 2011-04-01 00:00:00

 

Please don’t hesitate to contact me directly or call me if you have any further questions or if you would like to start discussions about.

We guess that this kind of extension to the spec. could be very useful and interesting for a large number of users / clients.

 

 

 

Mit freundlichen Gruessen - Best regards,

 

 

Nicolas Reichert

Aircraft In-Service Security Engineer

Aircraft In-Service Security - EIDS

AIRBUS

 

Phone:  +49 40 743 56209

Fax: +49 40 743 870 56209

Mailto: nicolas.reichert@...

 

AIRBUS Operations GmbH

Kreetslag 10

21129 Hamburg

Deutschland

 

Sitz der Gesellschaft / Legal Domicile: Hamburg

Registergericht / Registration Court: Amtsgericht Hamburg HRB 43527

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Thomas Enders

Geschäftsführung / Board of Management:

Günter Butschek, Vorsitzender / Chairman & CEO;

Joachim Sauer; Harald Wilhelm

 

PGP:

Key ID: 0xD9D41BA1
Fingerprint: FD 3F 41 B4 AE B0 1B 3E F8 23  78 36 CF 40 72 44 D9 D4 1B A1

 

SMIME:

Serial: 11 21 4d fa 66 73 1a f3 92 6c f9 b3 62 6f dc b7 b4 73
Fingerprint: 9a a9 91 77 f8 3e 4b 9b b2 31 5f 14 cc 4e ee e1 b5 a1 88 5e

 

 

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

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

Re: FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

Tim Keanini
In reply to this post by Brant Cheikes

This is why I was questioning the act of timestamping the death (End of Life) when the birth (First Customer Shipped or Release Date) would seem to be more stable for:

-          Retroactively going back and adding this for historical releases that have yet to be CPE’ed

-          Current software in circulation that have not been end of lifed

-          Future software releases will be the easiest to be marked because their release and the CPE tag will likely be named at the same time.

 

Because of the large body of tags that are yet to be tagged, I cannot see the value of the timestamp being the date of the tagging itself unless there is some value in knowing when society recognized the CPE naming itself.  I think that would just add a huge amount of confusion because it is so decoupled from that which is being tagged and since there is no one central authority tagging, there would be conflicts and differences everywhere. 

 

--tk

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 2:20 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

Ok, so let’s say we agree to add a “temporal tag” (timestamp) to each CPE.  How should the value of that tag be determined, i.e., timestamp of what?  Timestamp when the CPE went into the dictionary, timestamp when the product was released, …?

 

/Brant

 

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: Tim Keanini [hidden email]
Sent: Thursday, September 01, 2011 2:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

It is worth making two assertions that everyone is welcomed to challenge

 

Assertion 1: We require a temporal tag to be readable by machine and by human

I carefully say temporal tag because it might not be necessary to tightly couple it to End-of-Life

Assertion 2: In tags like 19770-2 and SCSI-ID, there is a time associated with the tag so that the reasoning around time can be done externally and for a broader purpose.

Example would be any certain tags made from company_A before the date when they were acquired by company_B would be machine identifiable and the appropriate semantics could be applied (same_as).  Or if we are talking about lifecycle changes like (First Customer Shipped, Last Customer Shipped, End of Sale, End of Life), all of these can be modeled for domains that really care about this and not hardwired into CPE.

The concern is that what goes into CPE should be as generic and simple as possible.  CPE should only contain enough of a vocabulary so that “that which has a configuration” or “that which has a vulnerability” can be identified.  By this line of reasoning, it would be best to stick a temporal tag in CPE and then have a standard which contained all the product lifecycle vocabulary (metadata on FCS, LCS, EoS, EoL) extend CPE.

 

--tk

 

From: Mccormick, Christopher [USA] [hidden email]
Sent: Thursday, September 01, 2011 1:07 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

Interesting idea, but can't EOL information effectively be captured with a note? 


From: Cheikes, Brant A. [[hidden email]]
Sent: Thursday, September 01, 2011 1:22 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

CPE Community,

 

See note from Nicolas Reichert below—it’s an interesting suggestion for a piece of extended metadata, though it begs the question of how such “end of life” information could be reliably obtained and maintained in the CPE dictionary.  Comments welcome.

 

/Brant

 

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: REICHERT, Nicolas [hidden email]
Sent: Monday, August 15, 2011 10:44 AM
To: CPE
Subject: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]
Importance: High

 

Dear all,

 

During intensive work with CPE’s we were faced with one problem in general.

The “End of Life” of products is currently not part of any spec. within the hole framework.

 

For Legacy components were vulnerabilities are published but the Software will no longer be supported due “to end of life”, or cutted vendor support i.e.:

 

cpe:/o:microsoft:windows:2000:sp4

Vendor: microsoft

Product: windows

Version: 2000

Revision: sp4

 

It would be very useful to have an „end of life“ - flag i.e. an ISO Timestamp (UTC) to identify if the product is supported or “end of life”.

 

cpe:/o:microsoft:windows_xp:-:sp3:professional

Vendor: microsoft

Product: windows_xp

Version: -

Revision: sp3

Edition: professional

EOL: 2011-04-01 00:00:00

 

Please don’t hesitate to contact me directly or call me if you have any further questions or if you would like to start discussions about.

We guess that this kind of extension to the spec. could be very useful and interesting for a large number of users / clients.

 

 

 

Mit freundlichen Gruessen - Best regards,

 

 

Nicolas Reichert

Aircraft In-Service Security Engineer

Aircraft In-Service Security - EIDS

AIRBUS

 

Phone:  +49 40 743 56209

Fax: +49 40 743 870 56209

Mailto: nicolas.reichert@...

 

AIRBUS Operations GmbH

Kreetslag 10

21129 Hamburg

Deutschland

 

Sitz der Gesellschaft / Legal Domicile: Hamburg

Registergericht / Registration Court: Amtsgericht Hamburg HRB 43527

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Thomas Enders

Geschäftsführung / Board of Management:

Günter Butschek, Vorsitzender / Chairman & CEO;

Joachim Sauer; Harald Wilhelm

 

PGP:

Key ID: 0xD9D41BA1
Fingerprint: FD 3F 41 B4 AE B0 1B 3E F8 23  78 36 CF 40 72 44 D9 D4 1B A1

 

SMIME:

Serial: 11 21 4d fa 66 73 1a f3 92 6c f9 b3 62 6f dc b7 b4 73
Fingerprint: 9a a9 91 77 f8 3e 4b 9b b2 31 5f 14 cc 4e ee e1 b5 a1 88 5e

 

 

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"] (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

Just to clarify, the change request is for the NIST CPE dictionary metadata, not the actually CPE specs themselves, right?

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]


-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 4:28 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

This is why I was questioning the act of timestamping the death (End of Life) when the birth (First Customer Shipped or Release Date) would seem to be more stable for:

-          Retroactively going back and adding this for historical releases that have yet to be CPE’ed

-          Current software in circulation that have not been end of lifed

-          Future software releases will be the easiest to be marked because their release and the CPE tag will likely be named at the same time.

 

Because of the large body of tags that are yet to be tagged, I cannot see the value of the timestamp being the date of the tagging itself unless there is some value in knowing when society recognized the CPE naming itself.  I think that would just add a huge amount of confusion because it is so decoupled from that which is being tagged and since there is no one central authority tagging, there would be conflicts and differences everywhere.  

 

--tk

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 2:20 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

Ok, so let’s say we agree to add a “temporal tag” (timestamp) to each CPE.  How should the value of that tag be determined, i.e., timestamp of what?  Timestamp when the CPE went into the dictionary, timestamp when the product was released, …?

 

/Brant

 

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: Tim Keanini [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 2:30 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

It is worth making two assertions that everyone is welcomed to challenge

 

Assertion 1: We require a temporal tag to be readable by machine and by human

I carefully say temporal tag because it might not be necessary to tightly couple it to End-of-Life

Assertion 2: In tags like 19770-2 and SCSI-ID, there is a time associated with the tag so that the reasoning around time can be done externally and for a broader purpose.

Example would be any certain tags made from company_A before the date when they were acquired by company_B would be machine identifiable and the appropriate semantics could be applied (same_as).  Or if we are talking about lifecycle changes like (First Customer Shipped, Last Customer Shipped, End of Sale, End of Life), all of these can be modeled for domains that really care about this and not hardwired into CPE.

The concern is that what goes into CPE should be as generic and simple as possible.  CPE should only contain enough of a vocabulary so that “that which has a configuration” or “that which has a vulnerability” can be identified.  By this line of reasoning, it would be best to stick a temporal tag in CPE and then have a standard which contained all the product lifecycle vocabulary (metadata on FCS, LCS, EoS, EoL) extend CPE.

 

--tk

 

From: Mccormick, Christopher [USA] [mailto:[hidden email]]
Sent: Thursday, September 01, 2011 1:07 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

 

Interesting idea, but can't EOL information effectively be captured with a note?  

________________________________

From: Cheikes, Brant A. [[hidden email]]
Sent: Thursday, September 01, 2011 1:22 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]

CPE Community,

 

See note from Nicolas Reichert below—it’s an interesting suggestion for a piece of extended metadata, though it begs the question of how such “end of life” information could be reliably obtained and maintained in the CPE dictionary.  Comments welcome.

 

/Brant

 

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: REICHERT, Nicolas [mailto:[hidden email]]
Sent: Monday, August 15, 2011 10:44 AM
To: CPE
Subject: CPE - Change request for new CPE spec. release/version - [Add "end of life support"]
Importance: High

 

Dear all,

 

During intensive work with CPE’s we were faced with one problem in general.

The “End of Life” of products is currently not part of any spec. within the hole framework.

 

For Legacy components were vulnerabilities are published but the Software will no longer be supported due “to end of life”, or cutted vendor support i.e.:

 

cpe:/o:microsoft:windows:2000:sp4

Vendor: microsoft

Product: windows

Version: 2000

Revision: sp4

 

It would be very useful to have an „end of life“ - flag i.e. an ISO Timestamp (UTC) to identify if the product is supported or “end of life”.

 

cpe:/o:microsoft:windows_xp:-:sp3:professional

Vendor: microsoft

Product: windows_xp

Version: -

Revision: sp3

Edition: professional

EOL: 2011-04-01 00:00:00

 

Please don’t hesitate to contact me directly or call me if you have any further questions or if you would like to start discussions about.

We guess that this kind of extension to the spec. could be very useful and interesting for a large number of users / clients.

 

 

 

Mit freundlichen Gruessen - Best regards,

 

 

Nicolas Reichert

Aircraft In-Service Security Engineer

Aircraft In-Service Security - EIDS

AIRBUS

 

Phone:  +49 40 743 56209

Fax: +49 40 743 870 56209

Mailto: [hidden email] <Mailto:[hidden email]>

 

AIRBUS Operations GmbH

Kreetslag 10

21129 Hamburg

Deutschland

 

Sitz der Gesellschaft / Legal Domicile: Hamburg

Registergericht / Registration Court: Amtsgericht Hamburg HRB 43527

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Dr. Thomas Enders

Geschäftsführung / Board of Management:

Günter Butschek, Vorsitzender / Chairman & CEO;

Joachim Sauer; Harald Wilhelm

 

PGP:

Key ID: 0xD9D41BA1
Fingerprint: FD 3F 41 B4 AE B0 1B 3E F8 23  78 36 CF 40 72 44 D9 D4 1B A1

 

SMIME:

Serial: 11 21 4d fa 66 73 1a f3 92 6c f9 b3 62 6f dc b7 b4 73
Fingerprint: 9a a9 91 77 f8 3e 4b 9b b2 31 5f 14 cc 4e ee e1 b5 a1 88 5e

 

 

 

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment
Loading...