OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Finally making progress


I finally cleared my desk for the rest of the week to make some progress on
this.

I will send daily updates for the next few days (just FYI) as I get this to
where I would like it to be for group review by the weekend. If anyone wants
to help I would not say no (hint, hint!)

Basically as I have it today there are 3 main sections. 

Meta-Data - used to manage the test case files themselves
Profile - used to describe the test case. This will include the thesaurus,
remedy, descriptions, risk ranking etc. We can generate the thesaurus using
an app (like Andy Jaquith wrote) or an XSLT.
Test - to hold the test data itself

I opted to put it all in one schema for simplicity. I am sure we can spilt
it out easily if people think that is appropriate or it will optimize parser
performance. 

Things I have to do
Define the types for some remaining elements.
Create annotation documentation for the thesaurus entries that will make up
the actual text of the thesaurus. 
Optimize Schema for performance and reuse

One of the elements left to create is the risk ranking. 

I am thinking about a simple model like this

A, B, C for three criteria. An AAA issue would be the most severe.

My rationale is based on Risk = # of Vulns x % (prob of threat maturing) x
Impact  

Criteria 1 - Impact (A - total root system compromise, B - could lead to
root system compromise, C - Partial system Compromise)
Criteria 2 - Threat (A - Easy to Automate, B - Difficult to Automate, C -
Requires Manual Exploit)
Criteria 3 - Target (A - Application Data, B - Application Component, C -
System User)

I like this approach as it can be drafted into a matrix that would be easy
to understand and references visually. It is also granular. However the
proposal above is obviously *too* simple. Any thoughts ? 

Another way to look would be an A, B, C or High Medium and Low 

High Risk - Will lead to total system compromise, is easy to automate 
Medium Risk - Could lead to total system compromise
Low Risk - Partial System Compromise 

This seems to not be granular enough and is open to all issues being High
Risk. Thoughts ?

wasglobal.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]