Vendor Component Ambiguity
|
|
| 1 2 |
Gary Newman-2
|
The CPE spec calls for use of "the" second level domain name of a company as
the vendor component. However, it is widespread practice for companies to register many different forms of company name as domains. For example, Hewlett-Packard has registered hewlett-packard.com hewlettpackard.com hp.com not to mention that most companies also register misspelligns [sic] of their trademarks and corporate names. I suggest that the spec either resolve this ambiguity or defer the topic until the discussion of aliases comes up, as Joe has suggested. -Gary- |
Andrew Buttner
|
This is a great point and one that definitely needs to be addressed by
the specification. Would it be enough to say that in these cases you use the address where these additional registered names get redirected to? Thanks Drew >-----Original Message----- >From: Gary Newman [mailto:[hidden email]] >Sent: Thursday, October 11, 2007 11:50 AM >To: cpe-discussion-list CPE Community Forum >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >The CPE spec calls for use of "the" second level domain name >of a company as >the vendor component. However, it is widespread practice for >companies to >register many different forms of company name as domains. > >For example, Hewlett-Packard has registered > > hewlett-packard.com > hewlettpackard.com > hp.com > >not to mention that most companies also register misspelligns >[sic] of their >trademarks and corporate names. > >I suggest that the spec either resolve this ambiguity or defer >the topic until >the discussion of aliases comes up, as Joe has suggested. > > -Gary- > |
||||||||||||||||
|
Gary Newman-2
|
Hi Drew,
That kind of redirection isn't anything consistent, and could easily change over time. For my HP example, they don't redirect any of the three I listed so that wouldn't help determine which to use for them. I also considered whether we could use the legal entity name. That could work better, but can be hard to determine without looking up corporate registrations. At least that method would winnow down the alternatives, though not always to one name. -Gary- > This is a great point and one that definitely needs to be addressed by > the specification. Would it be enough to say that in these cases you > use the address where these additional registered names get redirected > to? > > Thanks > Drew > > > >-----Original Message----- > >From: Gary Newman [mailto:[hidden email]] > >Sent: Thursday, October 11, 2007 11:50 AM > >To: cpe-discussion-list CPE Community Forum > >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > >The CPE spec calls for use of "the" second level domain name > >of a company as > >the vendor component. However, it is widespread practice for > >companies to > >register many different forms of company name as domains. > > > >For example, Hewlett-Packard has registered > > > > hewlett-packard.com > > hewlettpackard.com > > hp.com > > > >not to mention that most companies also register misspelligns > >[sic] of their > >trademarks and corporate names. > > > >I suggest that the spec either resolve this ambiguity or defer > >the topic until > >the discussion of aliases comes up, as Joe has suggested. > > > > -Gary- > > > > > |
||||||||||||||||
|
Andrew Buttner
|
It never is that simple :)
Maybe the best we can do in these situations (assuming we don't get help from the vendor itself) (and assuming there isn't already a name in the CPE Dictionary pertaining to this vendor) is to ask the community for their thoughts and try to work together to determine what is best. In these cases my guess is that we would tend to use the domain name that is the most commonly used name for the vendor. We would look at print material, returns for api calls and the systems themselves, etc. and try to make our best guess. Without the vendor's help, we are going to have to guess at a lot of this. But as long as we pick something and standardize on it, we all should benefit. Does anyone have a different alternative on how to handle this? Thanks Drew >-----Original Message----- >From: Gary Newman [mailto:[hidden email]] >Sent: Thursday, October 11, 2007 4:09 PM >To: cpe-discussion-list CPE Community Forum >Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >Hi Drew, > >That kind of redirection isn't anything consistent, and could >easily change >over time. For my HP example, they don't redirect any of the >three I listed so >that wouldn't help determine which to use for them. I also >considered whether >we could use the legal entity name. That could work better, >but can be hard to >determine without looking up corporate registrations. At >least that method >would winnow down the alternatives, though not always to one name. > > -Gary- > >> This is a great point and one that definitely needs to be >addressed by >> the specification. Would it be enough to say that in these cases >> use the address where these additional registered names get >redirected >> to? >> >> Thanks >> Drew >> >> >> >-----Original Message----- >> >From: Gary Newman [mailto:[hidden email]] >> >Sent: Thursday, October 11, 2007 11:50 AM >> >To: cpe-discussion-list CPE Community Forum >> >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity >> > >> >The CPE spec calls for use of "the" second level domain name >> >of a company as >> >the vendor component. However, it is widespread practice for >> >companies to >> >register many different forms of company name as domains. >> > >> >For example, Hewlett-Packard has registered >> > >> > hewlett-packard.com >> > hewlettpackard.com >> > hp.com >> > >> >not to mention that most companies also register misspelligns >> >[sic] of their >> >trademarks and corporate names. >> > >> >I suggest that the spec either resolve this ambiguity or defer >> >the topic until >> >the discussion of aliases comes up, as Joe has suggested. >> > >> > -Gary- >> > >> >> >> > |
||||||||||||||||
Wolfkiel, Joseph
|
In reply to this post
by Gary Newman-2
Aliases. I think we'll end up conceding that we need to track this
information across the community. Seems there are so many different names per vendor and product we'll need to be able to look them up and correlate back to the "real" CPE name. This is a very trivial database problem, so I'm not really sure why we keep trying to solve it in the CPE specification. In release 2.x of the CPE spec, I would submit we may be served by considering using the fully spelled-out name as the "CPE name" and treating all the abbreviations, foreign language spellings, OVAL object descriptions, and hyphenated spellings as aliases that can be looked up and referred back to the "CPE name." 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: Buttner, Drew [mailto:[hidden email]] Sent: Thursday, October 11, 2007 4:19 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity It never is that simple :) Maybe the best we can do in these situations (assuming we don't get help from the vendor itself) (and assuming there isn't already a name in the CPE Dictionary pertaining to this vendor) is to ask the community for their thoughts and try to work together to determine what is best. In these cases my guess is that we would tend to use the domain name that is the most commonly used name for the vendor. We would look at print material, returns for api calls and the systems themselves, etc. and try to make our best guess. Without the vendor's help, we are going to have to guess at a lot of this. But as long as we pick something and standardize on it, we all should benefit. Does anyone have a different alternative on how to handle this? Thanks Drew >-----Original Message----- >From: Gary Newman [mailto:[hidden email]] >Sent: Thursday, October 11, 2007 4:09 PM >To: cpe-discussion-list CPE Community Forum >Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >Hi Drew, > >That kind of redirection isn't anything consistent, and could >easily change >over time. For my HP example, they don't redirect any of the >three I listed so >that wouldn't help determine which to use for them. I also >considered whether >we could use the legal entity name. That could work better, >but can be hard to >determine without looking up corporate registrations. At >least that method >would winnow down the alternatives, though not always to one name. > > -Gary- > >> This is a great point and one that definitely needs to be >addressed by >> the specification. Would it be enough to say that in these cases >> use the address where these additional registered names get >redirected >> to? >> >> Thanks >> Drew >> >> >> >-----Original Message----- >> >From: Gary Newman [mailto:[hidden email]] >> >Sent: Thursday, October 11, 2007 11:50 AM >> >To: cpe-discussion-list CPE Community Forum >> >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity >> > >> >The CPE spec calls for use of "the" second level domain name >> >of a company as >> >the vendor component. However, it is widespread practice for >> >companies to >> >register many different forms of company name as domains. >> > >> >For example, Hewlett-Packard has registered >> > >> > hewlett-packard.com >> > hewlettpackard.com >> > hp.com >> > >> >not to mention that most companies also register misspelligns >> >[sic] of their >> >trademarks and corporate names. >> > >> >I suggest that the spec either resolve this ambiguity or defer >> >the topic until >> >the discussion of aliases comes up, as Joe has suggested. >> > >> > -Gary- >> > >> >> >> > |
||||||||||||||||
|
Gary Newman-2
|
Hi Joe,
I agree with you on this. -Gary- > Aliases. I think we'll end up conceding that we need to track this > information across the community. Seems there are so many different names > per vendor and product we'll need to be able to look them up and correlate > back to the "real" CPE name. This is a very trivial database problem, so > I'm not really sure why we keep trying to solve it in the CPE specification. > > In release 2.x of the CPE spec, I would submit we may be served by > considering using the fully spelled-out name as the "CPE name" and treating > all the abbreviations, foreign language spellings, OVAL object descriptions, > and hyphenated spellings as aliases that can be looked up and referred back > to the "CPE name." > > 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: Buttner, Drew [mailto:[hidden email]] > Sent: Thursday, October 11, 2007 4:19 PM > To: [hidden email] > Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > It never is that simple :) > > Maybe the best we can do in these situations (assuming we don't get > help from the vendor itself) (and assuming there isn't already a name > in the CPE Dictionary pertaining to this vendor) is to ask the > community for their thoughts and try to work together to determine what > is best. > > In these cases my guess is that we would tend to use the domain name > that is the most commonly used name for the vendor. We would look at > print material, returns for api calls and the systems themselves, etc. > and try to make our best guess. Without the vendor's help, we are > going to have to guess at a lot of this. But as long as we pick > something and standardize on it, we all should benefit. > > Does anyone have a different alternative on how to handle this? > > Thanks > Drew > > > >-----Original Message----- > >From: Gary Newman [mailto:[hidden email]] > >Sent: Thursday, October 11, 2007 4:09 PM > >To: cpe-discussion-list CPE Community Forum > >Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > >Hi Drew, > > > >That kind of redirection isn't anything consistent, and could > >easily change > >over time. For my HP example, they don't redirect any of the > >three I listed so > >that wouldn't help determine which to use for them. I also > >considered whether > >we could use the legal entity name. That could work better, > >but can be hard to > >determine without looking up corporate registrations. At > >least that method > >would winnow down the alternatives, though not always to one name. > > > > -Gary- > > > >> This is a great point and one that definitely needs to be > >addressed by > >> the specification. Would it be enough to say that in these cases > you > >> use the address where these additional registered names get > >redirected > >> to? > >> > >> Thanks > >> Drew > >> > >> > >> >-----Original Message----- > >> >From: Gary Newman [mailto:[hidden email]] > >> >Sent: Thursday, October 11, 2007 11:50 AM > >> >To: cpe-discussion-list CPE Community Forum > >> >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >> > > >> >The CPE spec calls for use of "the" second level domain name > >> >of a company as > >> >the vendor component. However, it is widespread practice for > >> >companies to > >> >register many different forms of company name as domains. > >> > > >> >For example, Hewlett-Packard has registered > >> > > >> > hewlett-packard.com > >> > hewlettpackard.com > >> > hp.com > >> > > >> >not to mention that most companies also register misspelligns > >> >[sic] of their > >> >trademarks and corporate names. > >> > > >> >I suggest that the spec either resolve this ambiguity or defer > >> >the topic until > >> >the discussion of aliases comes up, as Joe has suggested. > >> > > >> > -Gary- > >> > > >> > >> > >> > > > > > |
||||||||||||||||
Eric Fredericksen
|
Hi, All,
Throwing in my $0.02, here. The most important property IMO is that we have the ability to determine a unique identity for the item of interest in a manner that is efficient and unambiguous. I don't mind if the method is a "database lookup" (or an Xpath expression) as long as, given that my copy of the "database" of identifiers for the entity (e.g., Hewlett Packard) is up to date, the resolution of any one of the individual identifiers to the unique identity is efficient and unambiguous. I will also (re)observe that this problem will not have a perfect solution because it is a taxonomic classification methodology for attributes created and managed by humans.:) The attributes and concepts we are encoding may not be (at some point) orthogonal. The more attributes we pack into a positional-parameter format the more difficult it will become to define unambiguous naming rules and to interpret an encoded name. A final note, and not intending to muddy the waters: products and companies will get renamed as they evolve and this classification system should be able to handle that. I would assume that a simple method is to regroup all items under the new cannonical identity, assuming tracking of the "thing" (application or company) across such event boundaries is desirable. As an example, consider when Bobs SW App V4.0 is bought by Google and renamed GoogleBob V1.0 - first release is 99% rebranding. Regards, Eric Fredericksen McAfee, Inc. 949.297.5574 Direct 949.466.5196 Mobile -----Original Message----- From: Gary Newman [mailto:[hidden email]] Sent: Thursday, October 11, 2007 2:05 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity Hi Joe, I agree with you on this. -Gary- > Aliases. I think we'll end up conceding that we need to track this > information across the community. Seems there are so many different names > per vendor and product we'll need to be able to look them up and correlate > back to the "real" CPE name. This is a very trivial database problem, so > I'm not really sure why we keep trying to solve it in the CPE specification. > > In release 2.x of the CPE spec, I would submit we may be served by > considering using the fully spelled-out name as the "CPE name" and treating > all the abbreviations, foreign language spellings, OVAL object descriptions, > and hyphenated spellings as aliases that can be looked up and referred back > to the "CPE name." > > 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: Buttner, Drew [mailto:[hidden email]] > Sent: Thursday, October 11, 2007 4:19 PM > To: [hidden email] > Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > It never is that simple :) > > Maybe the best we can do in these situations (assuming we don't get > help from the vendor itself) (and assuming there isn't already a name > in the CPE Dictionary pertaining to this vendor) is to ask the > community for their thoughts and try to work together to determine > is best. > > In these cases my guess is that we would tend to use the domain name > that is the most commonly used name for the vendor. We would look at > print material, returns for api calls and the systems themselves, etc. > and try to make our best guess. Without the vendor's help, we are > going to have to guess at a lot of this. But as long as we pick > something and standardize on it, we all should benefit. > > Does anyone have a different alternative on how to handle this? > > Thanks > Drew > > > >-----Original Message----- > >From: Gary Newman [mailto:[hidden email]] > >Sent: Thursday, October 11, 2007 4:09 PM > >To: cpe-discussion-list CPE Community Forum > >Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > >Hi Drew, > > > >That kind of redirection isn't anything consistent, and could > >easily change > >over time. For my HP example, they don't redirect any of the > >three I listed so > >that wouldn't help determine which to use for them. I also > >considered whether > >we could use the legal entity name. That could work better, > >but can be hard to > >determine without looking up corporate registrations. At > >least that method > >would winnow down the alternatives, though not always to one name. > > > > -Gary- > > > >> This is a great point and one that definitely needs to be > >addressed by > >> the specification. Would it be enough to say that in these cases > you > >> use the address where these additional registered names get > >redirected > >> to? > >> > >> Thanks > >> Drew > >> > >> > >> >-----Original Message----- > >> >From: Gary Newman [mailto:[hidden email]] > >> >Sent: Thursday, October 11, 2007 11:50 AM > >> >To: cpe-discussion-list CPE Community Forum > >> >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >> > > >> >The CPE spec calls for use of "the" second level domain name > >> >of a company as > >> >the vendor component. However, it is widespread practice for > >> >companies to > >> >register many different forms of company name as domains. > >> > > >> >For example, Hewlett-Packard has registered > >> > > >> > hewlett-packard.com > >> > hewlettpackard.com > >> > hp.com > >> > > >> >not to mention that most companies also register misspelligns > >> >[sic] of their > >> >trademarks and corporate names. > >> > > >> >I suggest that the spec either resolve this ambiguity or defer > >> >the topic until > >> >the discussion of aliases comes up, as Joe has suggested. > >> > > >> > -Gary- > >> > > >> > >> > >> > > > > > |
||||||||||||||||
|
Gary Newman-2
|
Hi Eric,
I agree that software renaming/rebranding is an important issue. Ken Lassensen also mentioned this issue in his August 3rd post, though I don't recall there being any follow-up discussion. Our experience is that it's best to maintain the original shipment branding of a software product (aka CPE "platform") independent of renaming/rebranding of the company or product name. Among other benefits, this method removes the need to revisit the naming of old software over time. It's rare for a product name to change without there also being a version change, so this method also doesn't create ambiguity. As one example of product brand changing over time, Seagate Software, Crystal Reports, versions up to 8.5.0 Crystal Decisions, Crystal Reports, versions 8.5.2 thru 10 Business Objects, Crystal Reports, versions 11.0 thru 11.5 SAP, Crysal Reports, versions ??? (this last entry is anticipated due to SAP buying Business Objects) Note that there is rebranded, yet seemingly identical, software out there. Our experience suggests that each keep its own identity, avoiding untenable attempts to "guess" whether they're really the same. Identifying all such "same" software is better handled with something like the CPE language. IMHO, we should include guidance on the renaming of companies and products in the CPE spec. As you can see above, I suggest that we maintain the authoritative name at time of the software's original shipment. -Gary- > Hi, All, > > [snip] > > A final note, and not intending to muddy the waters: products and > companies will get renamed as they evolve and this classification system > should be able to handle that. I would assume that a simple method is to > regroup all items under the new cannonical identity, assuming tracking > of the "thing" (application or company) across such event boundaries is > desirable. As an example, consider when Bobs SW App V4.0 is bought by > Google and renamed GoogleBob V1.0 - first release is 99% rebranding. > > Regards, > Eric Fredericksen > McAfee, Inc. > 949.297.5574 Direct > 949.466.5196 Mobile |
||||||||||||||||
|
Andrew Buttner
|
>IMHO, we should include guidance on the renaming of companies
>and products in >the CPE spec. As you can see above, I suggest that we maintain the >authoritative name at time of the software's original shipment. The rebranding issue is an important point and one that I hope we at least given some guidance for. As Gary has mentioned, the CPE Name are not changed when a vendor or product is rebranded. See the Vendor Component and Product Component sections of Section 5.2 of the CPE 2.0 Spec. Thanks Drew |
||||||||||||||||
Ken Lassesen-3
|
In reply to this post
by Gary Newman-2
Oneissue illustrated with this:
Seagate Software, Crystal Reports, versions up to 8.5.0 Crystal Decisions, Crystal Reports, versions 8.5.2 thru 10 Business Objects, Crystal Reports, versions 11.0 thru 11.5 SAP, Crysal Reports, versions ??? Is that without a language/properties element, it's not possible to reference ALL VERSIONS of Crystal Report (this means that a CVE must cite each of the above AND --the CVE must be updated on each rebranding, which may not be acceptable to the CVE folks, the intent of CPE was to avoid this). Of course, having a "all crystal reports identifier" would be needed to link all of the instances. This cannot be the product name because with other products there are product name collisions, neither can it be the manufacturer (which one?) If we go for a language, then why not assign an arbitrary identifier and have all of the information put in the properteries. To me the worst scenario is company A acquiring a product (or company) B and then merging the two into one product going forward (aka multiple inferitance). That is the scenario in progress with some Lumension products... Every way that I look at this, I keep coming to the conclusion that the CPE ID's should be arbitrary identifiers with a language (i.e. use the OVAL model).... The CPE specification should contain worked examples of all of these scenarios. If the example cannot be worked, then we have a problem Ken Lassesen, Office 206-734-4718 Home: 360-297-4717 Cell: 360-509-2402 Skype: Ken.Lassesen IM: [hidden email] 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: Gary Newman [mailto:[hidden email]] Sent: Friday, October 12, 2007 7:54 AM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity Hi Eric, I agree that software renaming/rebranding is an important issue. Ken Lassensen also mentioned this issue in his August 3rd post, though I don't recall there being any follow-up discussion. Our experience is that it's best to maintain the original shipment branding of a software product (aka CPE "platform") independent of renaming/rebranding of the company or product name. Among other benefits, this method removes the need to revisit the naming of old software over time. It's rare for a product name to change without there also being a version change, so this method also doesn't create ambiguity. As one example of product brand changing over time, Seagate Software, Crystal Reports, versions up to 8.5.0 Crystal Decisions, Crystal Reports, versions 8.5.2 thru 10 Business Objects, Crystal Reports, versions 11.0 thru 11.5 SAP, Crysal Reports, versions ??? (this last entry is anticipated due to SAP buying Business Objects) Note that there is rebranded, yet seemingly identical, software out there. Our experience suggests that each keep its own identity, avoiding untenable attempts to "guess" whether they're really the same. Identifying all such "same" software is better handled with something like the CPE language. IMHO, we should include guidance on the renaming of companies and products in the CPE spec. As you can see above, I suggest that we maintain the authoritative name at time of the software's original shipment. -Gary- > Hi, All, > > [snip] > > A final note, and not intending to muddy the waters: products and > companies will get renamed as they evolve and this classification > system should be able to handle that. I would assume that a simple > method is to regroup all items under the new cannonical identity, > assuming tracking of the "thing" (application or company) across such > event boundaries is desirable. As an example, consider when Bobs SW > App V4.0 is bought by Google and renamed GoogleBob V1.0 - first > > Regards, > Eric Fredericksen > McAfee, Inc. > 949.297.5574 Direct > 949.466.5196 Mobile |
||||||||||||||||
|
Ken Lassesen-3
|
In reply to this post
by Eric Fredericksen
As a further "QI" comment.
"a taxonomic classification methodology" originates with natural scientists in the 18th century. Today with DNA analysis, many of the classifications were determined to be very wrong. Taxonomy as a memory/cognitive tool is fine, taxonomy as an accurate representation of ANYTHING is extremely suspect in my humble opinion. I think this is the gordian knot of the CPE discussion. Ken Lassesen, Office 206-734-4718 Home: 360-297-4717 Cell: 360-509-2402 Skype: Ken.Lassesen IM: [hidden email] 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: Eric Fredericksen [mailto:[hidden email]] Sent: Thursday, October 11, 2007 5:19 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity Hi, All, Throwing in my $0.02, here. The most important property IMO is that we have the ability to determine a unique identity for the item of interest in a manner that is efficient and unambiguous. I don't mind if the method is a "database lookup" (or an Xpath expression) as long as, given that my copy of the "database" of identifiers for the entity (e.g., Hewlett Packard) is up to date, the resolution of any one of the individual identifiers to the unique identity is efficient and unambiguous. I will also (re)observe that this problem will not have a perfect solution because it is a taxonomic classification methodology for attributes created and managed by humans.:) The attributes and concepts we are encoding may not be (at some point) orthogonal. The more attributes we pack into a positional-parameter format the more difficult it will become to define unambiguous naming rules and to interpret an encoded name. A final note, and not intending to muddy the waters: products and companies will get renamed as they evolve and this classification system should be able to handle that. I would assume that a simple method is to regroup all items under the new cannonical identity, assuming tracking of the "thing" (application or company) across such event boundaries is desirable. As an example, consider when Bobs SW App V4.0 is bought by Google and renamed GoogleBob V1.0 - first release is 99% rebranding. Regards, Eric Fredericksen McAfee, Inc. 949.297.5574 Direct 949.466.5196 Mobile -----Original Message----- From: Gary Newman [mailto:[hidden email]] Sent: Thursday, October 11, 2007 2:05 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity Hi Joe, I agree with you on this. -Gary- > Aliases. I think we'll end up conceding that we need to track this > information across the community. Seems there are so many different names > per vendor and product we'll need to be able to look them up and correlate > back to the "real" CPE name. This is a very trivial database problem, so > I'm not really sure why we keep trying to solve it in the CPE specification. > > In release 2.x of the CPE spec, I would submit we may be served by > considering using the fully spelled-out name as the "CPE name" and treating > all the abbreviations, foreign language spellings, OVAL object descriptions, > and hyphenated spellings as aliases that can be looked up and referred back > to the "CPE name." > > 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: Buttner, Drew [mailto:[hidden email]] > Sent: Thursday, October 11, 2007 4:19 PM > To: [hidden email] > Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > It never is that simple :) > > Maybe the best we can do in these situations (assuming we don't get > help from the vendor itself) (and assuming there isn't already a name > in the CPE Dictionary pertaining to this vendor) is to ask the > community for their thoughts and try to work together to determine > is best. > > In these cases my guess is that we would tend to use the domain name > that is the most commonly used name for the vendor. We would look at > print material, returns for api calls and the systems themselves, etc. > and try to make our best guess. Without the vendor's help, we are > going to have to guess at a lot of this. But as long as we pick > something and standardize on it, we all should benefit. > > Does anyone have a different alternative on how to handle this? > > Thanks > Drew > > > >-----Original Message----- > >From: Gary Newman [mailto:[hidden email]] > >Sent: Thursday, October 11, 2007 4:09 PM > >To: cpe-discussion-list CPE Community Forum > >Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > > > >Hi Drew, > > > >That kind of redirection isn't anything consistent, and could easily > >change over time. For my HP example, they don't redirect any of the > >three I listed so that wouldn't help determine which to use for them. > >I also considered whether we could use the legal entity name. That > >could work better, but can be hard to determine without looking up > >corporate registrations. At least that method would winnow down the > >alternatives, though not always to one name. > > > > -Gary- > > > >> This is a great point and one that definitely needs to be > >addressed by > >> the specification. Would it be enough to say that in these cases > you > >> use the address where these additional registered names get > >redirected > >> to? > >> > >> Thanks > >> Drew > >> > >> > >> >-----Original Message----- > >> >From: Gary Newman [mailto:[hidden email]] > >> >Sent: Thursday, October 11, 2007 11:50 AM > >> >To: cpe-discussion-list CPE Community Forum > >> >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >> > > >> >The CPE spec calls for use of "the" second level domain name of a > >> >company as the vendor component. However, it is widespread > >> >practice for companies to register many different forms of company > >> >name as domains. > >> > > >> >For example, Hewlett-Packard has registered > >> > > >> > hewlett-packard.com > >> > hewlettpackard.com > >> > hp.com > >> > > >> >not to mention that most companies also register misspelligns > >> >[sic] of their trademarks and corporate names. > >> > > >> >I suggest that the spec either resolve this ambiguity or defer the > >> >topic until the discussion of aliases comes up, as Joe has > >> >suggested. > >> > > >> > -Gary- > >> > > >> > >> > >> > > > > > |
||||||||||||||||
Tim Keanini Sr.
|
Some javascript/style in this post has been disabled (why?)
Very well said. Much of the discussion I will say again requires the discipline and methods of modern LIS (Library and Information Science). I say modern because there is no longer a need for the "shelf" We should be striving for categorization and not classification. The difference is that the latter requires that an object belong to one and only one class which we know never holds in the information space. If we must think of structures, we need to think of graphs and not trees. We can derive a tree for cognitive purposes but the source structure itself must be a graph. --tk On Oct 12, 2007, at 10:23 AM, Ken Lassesen wrote:
-- Timothy 'TK' Keanini. CTO 101 Second Street, Suite 400 San Francisco, CA 94105 Office: +1 415 625 5939 Mobile: +1 415 328 2722 Fax: +1 415 625 5984 Check out our Blog: http://blog.ncircle.com/patterns |
||||||||||||||||
Vladimir Giszpenc
|
Some javascript/style in this post has been disabled (why?)
Hi all, Please allow me to add my voice to the
opposition of hierarchies and proposition of normalized identifiers. When we evaluate a platform using OVAL and
determine it is whatever it is, a meaningless unique identifier is fine by me.
The important part is the OVAL. The problem is that a meaningless identifier is
the opposite of something everyone would arrive at by themselves. I say
numbers are cheap, guids and uuids are aplenty and we can give blocks of them
to those responsible for new identifiers. We could also hash some file that is
unique to a version. This solution has the advantage that it can be figured
out independently of the vendor. The only difficulty is figuring out what to
hash. Basically, uniqueness is important; the rest is a mapping to that id and
attributes to help you make that mapping possible/meaningful. As far as making things easy for CVE
authors, CPE arithmetic is the way to go. If we create identifiers that are
purely used to and/or/xor/etc other identifiers, then they can refer to just
one identifier (or a reasonable limited set) with no problem. Since SCAP 1.0 is roughly upon us and it
seems it will mandate CPE 2.0, this discussion seems like it will be ignored
for a few years. Oh well. It seems to me that the tool vendors evaluating
systems like the abstraction whereas the analyzers of existing content want an
easy transition given their relative lack of definitive information in current
systems. I am not sure why we can’t go to CPE3.0 where identifiers are
meaningless and hold CPE2.0 name. We could have an adoption period to allow
everyone to use either. As a separate point, I would like to add
that this discussion is geared towards stable monolithic distributions (and
mostly the Microsoft one at that). However no thought has gone into kernels
that are customized, not to mention build from scratch. If you disable Bluetooth
in the kernel, it is a lot more secure than turning off the service. How do we
get there? Best regards, DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical
Network Protection Branch (732) 532-8959 |
||||||||||||||||
Dave McKinney
|
In reply to this post
by Gary Newman-2
On Fri, Oct 12, 2007 at 10:54:18AM -0400, Gary Newman wrote:
> Hi Eric, > > I agree that software renaming/rebranding is an important issue. Ken Lassensen > also mentioned this issue in his August 3rd post, though I don't recall there > being any follow-up discussion. > > Our experience is that it's best to maintain the original shipment branding of > a software product (aka CPE "platform") independent of renaming/rebranding of > the company or product name. Among other benefits, this method removes the > need to revisit the naming of old software over time. It's rare for a product > name to change without there also being a version change, so this method also > doesn't create ambiguity. > > As one example of product brand changing over time, > > Seagate Software, Crystal Reports, versions up to 8.5.0 > Crystal Decisions, Crystal Reports, versions 8.5.2 thru 10 > Business Objects, Crystal Reports, versions 11.0 thru 11.5 > SAP, Crysal Reports, versions ??? > (this last entry is anticipated due to SAP buying Business Objects) > > Note that there is rebranded, yet seemingly identical, software out there. Our > experience suggests that each keep its own identity, avoiding untenable > attempts to "guess" whether they're really the same. Identifying all such > "same" software is better handled with something like the CPE language. > > IMHO, we should include guidance on the renaming of companies and products in > the CPE spec. As you can see above, I suggest that we maintain the > authoritative name at time of the software's original shipment. I agree that there should be guidance *and* support to cover these cases of rebranding. While each name must be unique, duplicate entries that refer to something that is technically the same product version across different vendors or rebrandings are problematic. The CPE dictionary maintainers either have to ensure that there is no possibility of duplicates or the system must have enough flexibility to handle the possibility of duplicate entries through deprecation and linking aliases/deprecated entities to the current name. As an example use-case, presume someone wanted to generate a list of CPE names related to Symantec products (past and present). Should we be assuming that the user is familiar with the entire M&A history of Symantec and will query the dictionary for each individual vendor in Symantec's portfolio? Or should they be able to make a single query for Symantec and get a listing of platform names for all the vendors Symantec has acquired (VERITAS, BindView, etc.)? The former is obviously easier for the CPE dictionary maintainers and the original vendor/product name could be used in that case. Perhaps the latter situation is a database/search issue for the CPE maintainers (or adopters) or perhaps it should be reflected in the standard itself via the XML spec for the CPE language/dictionary. I guess it really depends on the scope of the CPE and what problems the CPE dictionary is intended to solve. So while I am suggesting certain cases where I would find the CPE to be useful, I am also questioning whether or not it is intended to solve these problems. -- Dave McKinney Symantec keyID: E461AE4E key fingerprint = F1FC 9073 09FA F0C7 500D D7EB E985 FAF3 E461 AE4E |
||||||||||||||||
|
Andrew Buttner
|
In reply to this post
by Ken Lassesen-3
>Taxonomy as a memory/cognitive tool is fine, taxonomy as an
>accurate representation of ANYTHING is extremely suspect in >my humble opinion. I think this is the gordian knot of the >CPE discussion. I would agree with you Ken, but I would like to point out that we have not been trying to create a taxonomy for platforms. We have been trying to create a unique identifier. The reason for the hierarchy type feel is two fold: - a means for creating unique ids that helps remove the requirement of a numbering authority (a man in the middle that slows things up) - enable matching to occur across different CPE Names Personally, I do agree that a numeric id has a lot of advantages. We see these advantages with CVE and CCE. But to solve the use cases laid out for CPE in the beginning, I don't think a numeric id will not work. A numeric id would require tools to contact a database of some sort to perform matching and this was something we wanted to avoid since not all implementations can afford to make this round trip. Given all the conversation in the last two weeks, I think we might want to revisit our use cases and see if a change is needed. I am excited by all the passion being expressed over this topic and hope that we can channel this into continued improvement for CPE. Thanks Drew |
||||||||||||||||
|
Andrew Buttner
|
In reply to this post
by Dave McKinney
>I agree that there should be guidance *and* support to cover these
>cases of rebranding. While each name must be unique, duplicate entries >that refer to something that is technically the same product version >across different vendors or rebrandings are problematic. agree >The CPE >dictionary maintainers either have to ensure that there is no >possibility of duplicates The vision is that there would be a one to one relationship between a CPE Name and an OVAL inventory definition. What this means is that for each platform type (as defined by a specific OVAL Definition) there is only one CPE Name associated with it. >or the system must have enough flexibility >to handle the possibility of duplicate entries through deprecation and >linking aliases/deprecated entities to the current name. Granted, we know we are going to make mistakes and so the idea of deprecation has been built into the CPE Dictionary. >As an example use-case, presume someone wanted to generate a list of >CPE names related to Symantec products (past and present). Should we >be assuming that the user is familiar with the entire M&A history of >Symantec and will query the dictionary for each individual vendor in >Symantec's portfolio? Or should they be able to make a single query >for Symantec and get a listing of platform names for all the vendors >Symantec has acquired (VERITAS, BindView, etc.)? This is a really good use case. I don't think we know how to fully answer it at this time. Hopefully as we use CPE and the dictionary more we will be able to improve things to be able to satisfy these types of use cases. Thank you for bringing this use case to our attention! >The former is >obviously easier for the CPE dictionary maintainers and the original >vendor/product name could be used in that case. Perhaps the latter >situation is a database/search issue for the CPE maintainers (or >adopters) or perhaps it should be reflected in the standard itself via >the XML spec for the CPE language/dictionary. Maybe we need to think about standing up another repository of information whose goal is to supply all the known metadata associated with a particular platform type. Things like alias names, old vendor names, related CPE names, etc. I would suggest putting this in a separate repository (linked by CPE Name) so we don't clutter up the CPE Dictionary and let the dictionary focus on doing its task well. >I guess it really depends on the scope of the CPE and what problems >the CPE dictionary is intended to solve. So while I am suggesting >certain cases where I would find the CPE to be useful, I am also >questioning whether or not it is intended to solve these problems. agree. We need to do a better job of relaying what the goals of the CPE Dictionary are and what it is NOT trying to do. Thanks Drew |
||||||||||||||||
|
Gary Newman-2
|
In reply to this post
by Dave McKinney
Hi Dave,
The example use-case seems easy to me. One need only look in a software asset database and can easily find many products with their original vendor names. In most CVE cases, a user knows of a vulnerability and has the product labelled with the original vendor and product name. That vendor and product name is also visible on a vulnerable system. Assigning responsibility for the CVE to a current vendor (if even possible) seems separate from the CPE issue. Unless... are you saying that the CPE must always identify a current responsible party? I don't understand your concern with "duplicate entries" though. Do you believe that it's common to rebrand the same product version and CPE must track that? -Gary- On 12 Oct 2007 at 12:53, David McKinney wrote: > I agree that there should be guidance *and* support to cover these > cases of rebranding. While each name must be unique, duplicate entries > that refer to something that is technically the same product version > across different vendors or rebrandings are problematic. The CPE > dictionary maintainers either have to ensure that there is no > possibility of duplicates or the system must have enough flexibility > to handle the possibility of duplicate entries through deprecation and > linking aliases/deprecated entities to the current name. > > As an example use-case, presume someone wanted to generate a list of > CPE names related to Symantec products (past and present). Should we > be assuming that the user is familiar with the entire M&A history of > Symantec and will query the dictionary for each individual vendor in > Symantec's portfolio? Or should they be able to make a single query > for Symantec and get a listing of platform names for all the vendors > Symantec has acquired (VERITAS, BindView, etc.)? The former is > obviously easier for the CPE dictionary maintainers and the original > vendor/product name could be used in that case. Perhaps the latter > situation is a database/search issue for the CPE maintainers (or > adopters) or perhaps it should be reflected in the standard itself via > the XML spec for the CPE language/dictionary. > > I guess it really depends on the scope of the CPE and what problems > the CPE dictionary is intended to solve. So while I am suggesting > certain cases where I would find the CPE to be useful, I am also > questioning whether or not it is intended to solve these problems. > > -- > Dave McKinney > Symantec > > keyID: E461AE4E > key fingerprint = F1FC 9073 09FA F0C7 500D D7EB E985 FAF3 E461 AE4E |
||||||||||||||||
|
Ken Lassesen-3
|
In reply to this post
by Andrew Buttner
Redirection is a false assumption. Lumension.com is where PatchLink.Com
gets redirected. But SecureWave.com does not get redirected there. There can be motivation for none of the sites to redirect. Ken Lassesen, Office 206-734-4718 Home: 360-297-4717 Cell: 360-509-2402 Skype: Ken.Lassesen IM: [hidden email] 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: Buttner, Drew [mailto:[hidden email]] Sent: Thursday, October 11, 2007 12:39 PM To: [hidden email] Subject: Re: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity This is a great point and one that definitely needs to be addressed by the specification. Would it be enough to say that in these cases you use the address where these additional registered names get redirected to? Thanks Drew >-----Original Message----- >From: Gary Newman [mailto:[hidden email]] >Sent: Thursday, October 11, 2007 11:50 AM >To: cpe-discussion-list CPE Community Forum >Subject: [CPE-DISCUSSION-LIST] Vendor Component Ambiguity > >The CPE spec calls for use of "the" second level domain name of a >company as the vendor component. However, it is widespread practice >for companies to register many different forms of company name as >domains. > >For example, Hewlett-Packard has registered > > hewlett-packard.com > hewlettpackard.com > hp.com > >not to mention that most companies also register misspelligns [sic] of >their trademarks and corporate names. > >I suggest that the spec either resolve this ambiguity or defer the >topic until the discussion of aliases comes up, as Joe has suggested. > > -Gary- > |
||||||||||||||||
|
Ken Lassesen-3
|
In reply to this post
by Andrew Buttner
So, if we are talking domain names, then we may/will see CPE Entries such as:
الكلب الغذاء.com Since internet domains can now be in any UTF-8 characters (a recent change) Ken Lassesen, Office 206-734-4718 Home: 360-297-4717 Cell: 360-509-2402 Skype: Ken.Lassesen IM: [hidden email] 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. |
||||||||||||||||
Neal Ziring-2
|
In reply to this post
by Gary Newman-2
Dear Colleagues,
I've been watching the various discussions swirling around CPE the past couple of weeks. Many of them concern the content of particular components, such as the debate about windows:xp versus windows-xp, while others concern the philosophy of CPE naming. I'd like to throw my $0.02 in on those, but first I'd like to make a general plea. CPE was never intended to cover 100% of product and platform naming situations. I don't think any single naming mechanism can do that -- the IT product landscape is too complicated. As I said to Drew the other day: I believe that we need to move forward with CPE 2.0 as it stands, and get some experience with using it before we make more major changes. Then we can come back in a year or two and create a much better spec that will last for a long time. --- On domain names, we chose the current mechanism in the spec, "use of the second level domain name", because we felt it would give a short, clear, unambiguous name. Most big companies register multiple names (e.g. "hewlett-packard.com" and "hp.com") but in all cases I know of, the company uses one of them as the official name in their advertisements and documentation. That is the name we should use. If it is still ambiguous after that, then we can just let the company self-identify. Using the full corporate name will create much longer names, as well as potential character encoding issues. I think the right solution here is to clarify the rules for picking the domain name to bind to the supplier identity, and leave the company itself as the final arbiter. --- On the topic of abbreviations, I don't feel very strongly either way, but short names are a virtue. Would you and your customers rather read cpe:/o:microsoft:windows:xp:sp4:pro or cpe:/o:microsoft:windows:xp:service_pack_4:professional Ultimately, a CPE name is an structured identifier that points back into the community dictionary. The full name, possibly in multiple languages, belongs in the dictionary. The identifier itself can be and should be short. ---- On the re-branding of products, and mergers, I agree with Ken that CPE cannot handle all possible cases. There are actually a lot of far simpler cases that CPE cannot handle directly (in a single Name). We know that companies will continue to get acquired, change names, merge/split products, etc. I believe that CPE offers enough flexibility to accommodate this through use of the CPE Language. While I am a big fan of the roll-up aspects of CPE, I must concede that they cannot cover all cases. I think that "cpe:/a:macromedia:flash_player:4.0" and "cpe:/a:adobe:flash_player:8.0" will not easily roll up. ---- On the notion of short numeric identifiers (for use in URLs and the like), I believe that CPE could be extended to handle this without breaking the core specification. The key concept, in my mind, is that the CPE Name, like "cpe:/o:sun:java:1.6:jre", would be the canonical name, and any short identifiers would be aliases or nicknames. I believe Dave Mann was going to post a proposal about this, but maybe I missed it? It is possible that a general-purpose alias extension to the dictionary spec might also satisfy the need for associating a vendor "official" long name with the CPE name. ---- On the windows naming conventions debate, I think it will work either way. I just don't like the idea of making the stuff we deal with every day, like Windows XP and Vista, have longer CPE names when the stuff we now deal with rarely, like Windows 3.1, gets to have a shorter name. However, I think we'll be okay with whatever consensus emerges from the voting. ---- On the issue of library and application framework naming, I think that we could certainly come up with CPE prefixes for those. That won't change the basic structure of the specification. The suggestion I saw proposed "l:" for libraries and "j:" for Java. The "j:" for Java seems a little narrow, because I think we'd like to catch other programming platforms in there too. Perhaps "f:" for framework or "e:" for execution platform? ---- On the issue of virtualization, CPE probably has a role to play. It is kinda tricky, too. Is VMWare workstation an application, or a kind of computer? Perhaps we need a new CPE prefix for virtual environments, like "v:". For example: cpe:/v:xensource:xenenterprise:4.0 I don't have a good feeling for how many vulnerability and configuration guidance issues apply directly to virtual machine environments. Perhaps somebody with more experience in that arena could post some stats or a summary? ---- That's all for now... ...nz (Neal Ziring, NSA, [hidden email]) |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
