[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [was] The ID generation issue
Jeff, Ivan, excellent observations and suggestions. -- In order to analyze and understand what exactly we are solving here and what might be the scope of a comprehensive solution, here is my interpretation and comment. The original post and response deal with these issues: 1 - ID uniqueness and creation a - make sure they are unique b - make sure they are not confusing (e.g because of wasteful redundancy) c - ID and vuln instance versioning - i.e. ID evolution, if any, through modification of a vulnerability instance caused by auditing process and addition of new domain descriptions, e.g. adding detect to analysis 2 - access of EVDL databases a - access to vulnerability document identified by an ID and URL b - access to individual security domain components, such as protect, detect, analysis Other issues that are not addressed here but whose resolution may drive decision making to resolve 1 and 2: 3 - what's going to be a typical storage model of EVDL at an enterprise? a - will the company want to store multiple security domains in one document instance or separate document instances? - this will influence if they'd prefer 1c to be solved My inline comments and questions are marked by "PM>" and accompanies by issue number. > I agree with the idea to delete the date from the ID. PM> Date: Issues 2b, date could be deleted (but it doesn't improve anything). Another approach would be to change the wording of ID creation to suggest that date is optional. {company-specific-prefix}-foundstone.com-0001 or foundstone.com-0001-{optional-date}-{company-specific-data} I think the reasoning behind the original ID formula and inclusion of date was similarity with CVE ids which I think contains dates to make IDS more human-readable. > I also like the idea behind the URI approach to ID's. But I think > that the ID should be separate from the location of the repository > where the evdl entries are stored. > http://repository.com/evdl/thinkingstone/protect/123456 > Issue 1c and 2b As far as having different IDs for different components, keeping it simple would be nice. Another way of accessing security domain specific part within a EVDL instance is using XPATH expression, e.g.: $repositoryURL?id=123456#evdl/protect (see more on 1c below) > Your point about different parts of the EVDL having different IDs is > interesting. Personally, I would like to make sure that all the EVDL > parts related to a single vulnerability can be correlated somehow. So > if there's an analyze element, a protect element, and two different > protect elements that all are related to the same problem, I want to > find them all. But I think there may be many-to-one relationships > among these different pieces. That leads me to something like: > http://repository.com/evdl/123456/protect/thinkingstone > http://repository.com/evdl/123456/analyze/aspectsecurity > http://repository.com/evdl/123456/detect/webkreator > > Essentially the 123456 becomes the reference to the underlying problem > being discussed. I do not know how to solve the problem of dealing > with related issues (other than listing them in the schema somewhere > -- which I seem to recall we already do). > > --Jeff > > ----- Original Message ----- From: "Ivan Ristic" <ivanr@webkreator.com> > To: <was@lists.oasis-open.org> > Sent: Friday, February 04, 2005 5:46 AM > Subject: [was] The ID generation issue > > >> >> Here are my thoughts on this issue: >> >> I don't think the current algorithm is satisfactory because it uses >> the release date as part of the ID. As a reminder here's what the >> schema says about this: >> >> --- >> The ID element provides a mechanism to declare uniquely identifiable >> attributes for cataloging and referencing. >> >> The provider, author and vendor IDs allow cross referencing and trust >> models to be developed based on the source of the test case. >> >> Note: Need to define the XML:DigSig for these attributes and provide >> for a mechanism to sign an entire file (ie provide authenticity and >> integrity of the file outside of transport security). >> >> The ID Element should be derived from the following pieces of >> information: >> >> 1. Organization Label / Name - ex: Foundstone, in the case of large >> organization it is their responsibility to maintain organization >> level uniqueness. ... TODO: Define legal characters. >> >> 2. Current date - YYYY-MM-DD TODO: >> >> Thus a sample ID is: 2004-03-31-foundstone.com-0001 >> >> The id part after the company name should be unique within the >> company (i.e. last part of id namespace needs to be managed by the >> company. >> --- >> >> What happens when there is a revision? Is the ID supposed to change >> to incorporate the date of the revision release or not? In any case, >> I don't see a strong point for having the date as part of the ID. > PM> Issue 1c: Versioning as proposed in this version doesn't change the original ID. The "history" tag is intended to allow modifications to an instance while keeping ID the same. See http://www.evdl.net/latest/examples/example-sca-1.xml >> >> >> Furthermore, we need to consider the requirement of every EVDL part >> to have an ID of its own. Personally I would like to see something >> like this (as an ID): > >> >> http://www.thinkingstone.com/evdl/protect/123456 >> >> or >> >> * http://www.thinkingstone.com/evdl = unique ID of the publisher >> * 123456 - instance ID (unique on the publisher level) >> * protect - EVDL part name >> >> In fact, maybe it's probably better to use the following format: >> >> http://www.thinkingstone.com/evdl/123456/protect >> http://www.thinkingstone.com/evdl/123456/protect > >> >> Using an ID of this form would achieve the following: >> >> 1. Assign a unique ID to a schema instance >> >> 2. Allow different parts to have different IDs but >> related parts to have a common base >> >> 3. Allow a device to retrieve an instance from a publisher's >> web site just by accessing the URL. Therefore an ID is all >> a device needs to retrieve the XML data. >> PM> Issues 1c Ivan in 3.: What happens if the same instance if stored in a different location? We could treat individual security domains / components as revision to the primary instance. Then we could first solve approach to revision identification which would automatically include being able to identify component. To access a particular component within an instance, given a repository location and the vulnID, we could use XPATH. For those of you who haven't seen the EVDL Overview doc, please note that defining how vulnerabilities are stored is a chapter (currently empty) we are working on in the EVDL overview document: http://www.oasis-open.org/apps/org/workgroup/was/download.php/11288/EVDL-0.1-draft.doc > >> -- >> Ivan Ristic (http://www.modsecurity.org) >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]