[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [was] Current WAS XML Schemas
Mark Curphey Consulting Director Foundstone, Inc. Strategic Security 949.297.5600 x2070 Tel 781.738.0857 Cell 949.297.5575 Fax http://www.foundstone.com This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you. -----Original Message----- From: Peter Michalek [mailto:peter@fortifysoftware.com] Sent: Friday, February 27, 2004 12:49 PM To: Mark Curphey Subject: RE: [was] Current WAS XML Schemas Mark, I am not sure if you published a correction (there were some syntax errors). Here is a lightly modified version with a syntax and a typo fix. Questions/suggestions: - For the sake of clarity, I would replace "The Data element" with "This data element" everywhere. <xs:documentation>The Data element provides the risk ranking . I am not sure if this would be much simpler but I allocated an element for now</xs:documentation> - I don't understand this: <xs:element name="bufferOverflow"> <xs:documentation>The Data element provides a mechanism to reference the provider of the signature. This maybe a trusted source of signatures or a commercial provider such as an iDefense. This allows fast indexing of entries based on the provider without having to check signatures</xs:documentation> - and this <xs:element name="infrastructureConfigurationManagement"> <xs:documentation>The Data element provides a mechanism to reference othe sources of data about the issue. The WAS Thesaurus for instance maybe one, Vuln DB's like CVE and Bugtraq maybe others</xs:documentation> - risk ranking documentation node is repeated for other nodes, e.g.: <xs:element name="sessionManagement"> <xs:documentation>The Data element provides the risk ranking . I am not sure if this would be much simpler but I allocated an element for now</xs:documentation> Peter -----Original Message----- From: Mark Curphey [mailto:mark.curphey@foundstone.com] Sent: Thursday, January 29, 2004 8:19 AM To: was@lists.oasis-open.org Subject: [was] Current WAS XML Schemas Hi, OK back from the dead ;-) I am attaching what I have as the latest schema we developed before Christmas and wanted to send a basic summary of where I think we are so that others can start thinking and even working on updates before the next meeting. We agreed to spilt the WAS Schema into four main sections Meta-Data Profile Test Protect The Meta-Data and Profile will be developed by the WAS Core Group The Test will be developed by the WAS Test Group The Protect will be developed by the WAS Protect group The schema attached to this mail is a first draft of WAS Meta-Data and Profile. The deliverables for this section will be 1. Documented Schema 2. Thesaurus / Dictionary of Terms 3. Risk Ranking Model 4. Developers Guide to WAS 5. Managers Guide to WAS This group will also work with OWASP to enhance the current VulnXML database to accept and managed WAS signatures. OWASP's VulnXML was being considered as the basis WAS Test. This is currently in DTD format. The WAS Test group can decide whether to enhance the DTD or convert to schema at this stage or later. It was generally agreed that some enhancements to functionality would be desirable but no conclusions as to what they are or how they would manifest were made. The deliverables for this group are 1. Documented Schema 2. Reference Implementation of a WAS Execution engine in Java. No work has yet been done on the protect element. The deliverables will be 1. Documented Schema 2. Reference implementation (mod_security and CodeSeeker) Notes: 1. We have set provisional dates of August to deliver all of the above 2. We can define WAS 1.0 and WAS 2.0 in order to manage scope ! 3. The next meeting we will formalize who is working in each group. So far Mark Curphey will run Core, Ivan Ristic Protect and TBC Ingo Struck Test. 4. We will meet monthly but use the mailing list as much as possible. I think that's it. Look forward to getting this kicked off again on Feb 9th and working with you all again. Mark Mark Curphey Consulting Director Foundstone, Inc. Strategic Security 949.297.5600 x2070 Tel 781.738.0857 Cell 949.297.5575 Fax http://www.foundstone.com This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:group name="Meta-Data"> <xs:annotation> <xs:documentation>This group defines the high-level grouping of information that is used for searching, storage and retrival of signatures. There are two main groups, Meta-Data and Test </xs:documentation> </xs:annotation> <xs:all> <xs:element name="ID"> <xs:annotation> <xs:appinfo/> <xs:documentation>The ID element provides a mechanism to declare uniquely identifiable attributes for cataloging and referencing. The provider, author and vendor IDs allow cross referencing ands 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 mecahism to sign an entire file (ie provide authenticity and integrity of the file)</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="authorID" type="xs:ID" use="required"/> <xs:attribute name="vendorID" type="xs:ID" use="optional"/> <xs:attribute name="providerID" type="xs:ID" use="optional"/> </xs:complexType> </xs:element> <xs:element name="Date"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Date element provides a mechanism to declare time and historical related data. An example use case maybe "show me all of the issues within the last 3 months "</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="originalReleaseDate" type="xs:dateTime" use="required"/> <xs:attribute name="lastRevisionDate" type="xs:dateTime" use="required"/> <xs:attribute name="versionRevisionDateHistory" type="xs:dateTime" minOccurs="1"/> </xs:complexType> </xs:element> <xs:element name="Author"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Author element provides a mechanism to reference the original author of the test case.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="company" type="xs:string"/> <xs:attribute name="email" type="xs:string"/> <xs:attribute name="URL" type="xs:URI"/> </xs:complexType> </xs:element> <xs:element name="Provider"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Provider element provides a mechanism to reference the original provider of the signature. This maybe a trusted source of signatures or a commercial security intelligence provider or an internal source. This allows fast indexing of entries based on the provider without having to check signatures</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="company" type="xs:string"/> <xs:attribute name="email" type="xs:string"/> <xs:attribute name="URL" type="xs:URI"/> </xs:complexType> </xs:element> <xs:element name="Restrictions"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Restrictions element provides a mechanism to reference any usage restrictions on the test case itself. These may include copyright, licensing or potentially things like export restrictions where a test case contains cryptographic information</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="license" type="xs:string" use="required"/> <xs:attribute name="copyrightHolder" type="xs:string"/> <xs:attribute name="copyrightNotice" type="xs:string"/> <xs:attribute name="email" type="xs:uri"/> </xs:complexType> </xs:element> <xs:element name="Reference"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Reference element provides a mechanism to reference other sources of pre-defined data about the issue. The WAS Thesaurus that is extracted from this schema will be one that provides reuseable language to describe the issue. Other Vulnerability databases like CVE and Bugtraqcan also be referenced</xs:documentation> </xs:annotation> <xs:complexType> <xs:element name="thesaurusEntry" use="required"> <xs:attribute name="thesaurusGroupName" type="xs:string"/> <xs:attribute name="thesaurusSubGroupName" type="xs:string"/> <xs:attribute name="additionalInformation" type="xs:string" /> </xs:element> <xs:element name="vulnDatabase"> <xs:attribute name="databaseName" type="xs:string" /> <xs:attribute name="databaseLocation" type="xs:uri" /> <xs:attribute name="databaseRef" type="xs:string"/> </xs:element> <xs:element name="shortDescription" type="xs:string"/> <xs:element name="longDescription" type="xs:string"/> </xs:complexType> </xs:element> <xs:element name="Remedy"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Remedy element provides a mechanism to reference constructive information about how to fix the issue if found. This data would be extracted into automatically to create reports or alerts. This would inlcude references to patches, how to fix etc</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="Patch" type="xs:string" use="required"/> </xs:complexType> </xs:element> <xs:element name="Risk Ranking"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides the risk ranking . I am not sure if this would be much simpler but I allocated an element for now</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="riskLevel" type="xs:int" use="required" default="0"/> <xs:attribute name="Impact" type="xs:boolean" use="required" default="0"/> </xs:complexType> </xs:element> </xs:all> </xs:group> <xs:group name="Profile"> <xs:annotation> <xs:documentation>This group defines the high-level grouping of information that is used for searching, storage and retrieval of signatures. There are two main groups, Meta-Data and Test</xs:documentation> </xs:annotation> <xs:all> <xs:element name="applicationLogic"> <xs:annotation> <xs:appinfo/> <xs:documentation>Application Logic Flaws General Description</xs:documentation> </xs:annotation> <xs:complexType/> </xs:element> <xs:element name="applicationConfigurationManagement"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Date element provides a mechanism to declare time and historical related data. An example use case maybe "show me all of the issues within the last 3 months "</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction/> </xs:simpleType> </xs:element> <xs:element name="accessControl"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides a mechanism to reference the original author </xs:documentation> </xs:annotation> </xs:element> <xs:element name="bufferOverflow"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides a mechanism to reference the provider of the signature. This maybe a trusted source of signatures or a commercial provider such as an iDefense. This allows fast indexing of entries based on the provider without having to check signatures</xs:documentation> </xs:annotation> </xs:element> <xs:element name="dataProtection"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides a mechanism to reference any useage restrictions on the signature. These may include copyright, licensing or potentially things like export restrictions</xs:documentation> </xs:annotation> </xs:element> <xs:element name="infrastructureConfigurationManagement"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides a mechanism to reference othe sources of data about the issue. The WAS Thesaurus for instance maybe one, Vuln DB's like CVE and Bugtraq maybe others</xs:documentation> </xs:annotation> </xs:element> <xs:element name="inputValidation"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides a mechanism to reference constructive information about how to fix the issue if found. This data would be extracted into automatically generated reports and alerts. This would include patch downloads, how to fix etc</xs:documentation> </xs:annotation> <xs:complexType name="sqlInjection"/> </xs:element> <xs:element name="sessionManagement"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides the risk ranking . I am not sure if this would be much simpler but I allocated an element for now</xs:documentation> </xs:annotation> </xs:element> <xs:element name="raceConditions"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides the risk ranking . I am not sure if this would be much simpler but I allocated an element for now</xs:documentation> </xs:annotation> </xs:element> <xs:element name="userPrivacy"> <xs:annotation> <xs:appinfo/> <xs:documentation>The Data element provides the risk ranking . I am not sure if this would be much simpler but I allocated an element for now</xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:group> <xs:group name="Test"> <xs:annotation> <xs:documentation>This group defines the executeable test case. It will be developed after the Meta-Group is near completion</xs:documentation> </xs:annotation> <xs:all/> </xs:group> </xs:schema>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]