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: Re: Additions to EVDL Overview Document


Here are some additional changes, this time primarily in examples to 
make them schema-compliant so they can be validated in XML editors and 
some minor fixes in the schema. 

The new revision is in:

http://www.evdl.net/latest/

The zip contains the whole subtree, which allows editing of examples with validation in xml editors.

changes 2/11/2005:
- in evdl xsd and in overview document:
  - changed case of threat and impact risk ranking for INFORMATIONAL etc. to Informational ...
- in evdl xsd:
	made metaData and profile options, to support cases/examples that use security domain alone and only reference
	metadata via ID, such as:
	   http://www.evdl.net/latest/examples/example-protect-by-ref-1.xml
			<xsd:element name="metaData" type="MetaDataType" minOccurs="0"/>
			<xsd:element name="profile" type="ProfileType" minOccurs="0"/>
  
- in example EVDL instances, corrected values to comply with corrected/changed schema as it evolved over the last month:
	<riskRanking>
		<threat>Low<threat>
		<impact>High<threat>
	</riskRanking>
   - ID format compliant with spec, e.g.: evdl.net-2-11-2005-2

   - relatedProcesses (protect example)
   
- adjusted schema to the examples developed previously in WAS TC discussion:
			<xsd:element name="description" >
				<xsd:complexType>
					<xsd:sequence>
						<xsd:element name="title" type="xsd:string"/>
						<xsd:element name="abstract" type="xsd:string"/>
						<xsd:element name="motivation" type="xsd:string"/>
						<xsd:element name="detail" type="xsd:string"/>
					</xsd:sequence>
				</xsd:complexType>
			</xsd:element>
	- see new evdl-0.1.xsd and example-sca-1.xml in http://www.evdl.net/latest/schema and http://www.evdl.net/latest/examples 


-------------

Suggested changes/to do:

Cleanup these values, to make consistent with the style of other enums:
	<xsd:simpleType name="attackSurfaceType">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="system boundary"/>
			<xsd:enumeration value="component boundary"/>
			<xsd:enumeration value="source code"/>
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:simpleType name="attackSurfaceType">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SystemBoundary"/>
			<xsd:enumeration value="ComponentBoundary"/>
			<xsd:enumeration value="SourceCode"/>
		</xsd:restriction>
	</xsd:simpleType>
- review locationOfIssue profile section in examples. It needs cleanup.
- adjust other samples to changes in schema
- in protect, id should be optional, if protect is a subsection of <evdl> instance that already has an id
	- <recipe id="magnolia-9E9BC8AD2338EBBBF6986C4255409A6D">
	

 


> Hello everyone,
>
> As discussed in the last conf. call, several people are working on 
> additional chapters.
>
> I placed the modified document in:
> http://www.evdl.net/latest/doc/EVDL-0.1-draft.doc
> I expect this document to be updated again in the next few days by 
> others, we'll keep old revisions available in
> http://www.evdl.net/old/doc  for reference.
>
> Here is a summary of modifications:
>
> - Added content for Chapter 2.4 and 4
> - Added a new chapter:
> 5    Extending EVDL to new security domains.
>
> EVDL proposes to support embedding documents that support new 
> application security domains and define new application security 
> domain schema descriptions in the future.
> A necessary condition to include new schemas would be if developers of 
> security domains use EVDL metadata and profile in a manner similar to 
> example 2.5 and thus avoid duplication of generic security constructs 
> used in metadata (including ID, license, history) and profile 
> (including classification i.e. vulnTypes and riskRanking).
>
> ------
> When editing the new chapters, I found some minor inconsistencies in 
> the schema, therefore I propose the following additional modifications:
> - cleanup thread data - make informational/warning/... enum instead of 
> arbitrary string
> - protect should use something like "EVDLID" instead of "id" to make 
> clear what it refers to
> - look at xml:id and use it in metadata if appropriate
> - replace "recipe" by "protect" to better represent this is a protect 
> component
> - in overview doc, fix System Impact graph - correct typo (need 
> original picture from Mark Curphey)
>
>
>
> Peter
>
>



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