Re: [was] The ID generation issue

[Peter Michalek <peter@michalek.org>]

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)
>>