$Id: scl.xsd,v 1.76 2004/05/10 12:13:04 mic Exp $ This schema is the normative source of the "software classification language". Note that comments like this one are normative parts of the definition and must be obeyed by conforming applications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This MUST be the root element for every conforming document. The "origin" element describes the origin of a report, i.e. where and when it was created, etc. Although most of these elements are optional, it is recommended to use them all. Note that a "creator" element is missing intentionally, because only the creating program and system is needed to identify the source of a report while reporting a human user may violate some privacy laws. This is a similiar time format as used by the XHTML standard. The general format is "YYYY-MM-DDThh:mm:ss" followed by a optional timezone specified as "Z" (for UTC), "+hh:mm" or "-hh:mm" (for the difference from UTC). A timezone MUST be specified if it is known (to avoid comparison problems). See "XML SChema - Datatypes" 3.2.7 for an exact type definition and algorithms to compare dateTime values. The program that created the report. This SHOULD be a constant value, so make sure to keep all changing attributes ("XYZ 2004") only in the "version" element. Used to identify the system that contains the reported software (...that is scanned). It is recommended to use an IP address, hostname or NetBIOS name. This should be used to give the exact version of the program that created a report. This SHOULD be used to identify the version of the data basis that is used for the classification. Antimalware products should insert the date/version of their malware definitions/patterns here. Should be used to give all program options and settings that are required to reproduce a report. Who can be contacted (mail, phone, ...) if there are any questions about a report or the program that created the report. Each "object" element identifies and classifies a data object. An object may contain other objects, to provides a method to classify separate parts of an data object. This SHOULD NOT be used describe each data object in its greatest detail but to provide only enough details to be able to classsify the interesting data objects. Either this is an atomic object (for the analysis) then only a classification is required. Or this object is a container for other other objects, that must be reported within a 'content' element. No overall status report is allowed in the latter case (Although such status reports may be contructed by the interpreting program, they MUST MOT be included in this report format). Each content element MUST contain at least one object. And now all identification types: Use this to report files by an well-formed URI (as defined in RFC 2396) with the "file" scheme (defined in RFC 1738). "name" and "path" should be used to report a filename and its (absolute) path separatly. If it not possible to use separate elements, the complete path and filename may be reported in the name element (although that SHOULD be avoided). There MUST be no path element in this case. Note 1: Linebreaks are treated as part of the filename (like any other character too), because of the "string" datatype. Note 2: It is not required that the path ends with a path separator (for example "\"). For correct interpretation, it may be necessary to insert a path separator between the contents of the "path" and the "name" element. Length of this file in bytes. Contains a mail header field as specified in RFC 2822 (including the non-ASCII header extensions defined in RFC 2047). Header fields included here MUST be handled unfolded, because all whitespace characters (space = #x20, tab = #x09, LF = #x0A, CR = #x0D) will be replaced with space (#x20) by the XML parser. The most interesting headers for complete messages are "Message-ID" and "Date". For messages in MIME format it is recommended to include the header "Content-Transfer-Encoding". For MIME messageparts (only "Content-"... headers exist), it is recommended to include "Content-Transfer-Encoding". There is a separate element available for the "Content-Type" header because it is considered more important. Note that the implementation here allows headers that are illegal for RFC 2822 and RFC 822 because violations of these standards occur in current mail usage. MIME type of a mail body or a bodypart (as defined in RFC 2045-2049). Because the "Content-Type" header is considered most important for classification, its value SHOULD be included here and not in another header element. Note that parameters are not allowed to be included here. If a parameter is important for the identification or classification of a mail body, it may be reported with the "mimeparameter" element (see below). If it is known that the "Content-Type" header is forged, the correct value SHOULD be used here. This is the only case, where it is useful to include an additional header element with the forged header. If no MIME type is known, the default type "text/plain" SHOULD be used (in accordance with RFC 2045, 5.2). This may be used to report important parameters that are appended to the MIME type in a "Content-Type" header. Commonly used parameters include "charset" for "text" types and "boundary" for "multipart" types. if there is no "charset" parameter for a "text" type, the default value "charset=us-ascii" may be asssumed. The "boundary" parameter is only useful, if the bodyparts of a multipart message are reported withon a "content" element. As with the header implementation, this implementation has much less restrictions than the RFCs due to current practice. The length of the mail body (excluding any headers) in bytes. A checksum of the mail body (excluding any headers). This specifies the physical device of this sector. Examples: "hda", "fd0", "multi(0)disk(0)rdisk(0)" or "disk drive a:" More detailed specifications (e.g. "hda5") are allowed. Number of sectors in this object including startaddress and endaddress. Number of sectors in this object including startaddress and endaddress. Possibility to add a description of this data object (for example: "partition table", "BIOS Parameter Block" or "Master File Table"). Sector length in bytes. The "Logical Block Address" (LBA) of this sector. To be compatible with the current LBA standard, 64 bit values must be supported. The old C/H/S disk sector addressing method. ATA-5 restricts cylinder values to 16 bit, head values to 4 bit and sector values to 8 bit. This datatype allows bigger values to make this addressing method useful for other disktypes too. Number of packets in this object. The name of the network protocol. May not include most punctuation characters (similar to XML element names). A common name SHOULD be used (Examples: "http", "dns", "tcp", "icmp", "arp"). Timestamp when this packet was received or captured. For packet sequences, this is the timestamp of the first packet. Some application may require specification of fractions of a second although this is optional for the "xsd:dateTime" datatype. Packet length in bytes. For a sequence of packets this must be the sum of all paket lengths. The MAC address MUST be given as a hexadecimal value (for example "123456789abc" for the MAC address "12:34:56:78:9a:bc"). The IETF EUI-64 address. Other interface identifiers may be given with this element. The IP address MUST be given in hexadecimal ("c0a82a00") or dotted-decimal format ("192.168.42.0"). The IPv6 address MUST be given as hexadecimal value or in a format defined in RFC 2372 (see declaration of datatype "ipv6adddress for examples). The DNS hostname The WINS / NetBIOS hostname. Any other host identification method. The service address SHOULD be specified by a common service name ("http") or as a decimal port number (for example "80" for http). Length of this memory range in bytes. This includes the startaddress and the endaddress. Possibility to add a description of this data object. Length of this octectstream in bytes. Possibility to add a description of this data object. And now all classification types: There are different possibilities to give a classification for a malicious object: - use an ID from a database like CVE or Bugtraq - use a CARO name - use different elements to specify the various name parts: type, platform, (familiy) name, variant and (all other) modifiers. It is possible to use only some of these parts. - use only the "malwarename" element with arbitrary content. This is NOT RECOMMENDED because it hides the internal name structure and requires more external logic to interpret such reports correctly. May be used to specify an ID of a malware or vulnerability database (for example a CVE or Bugtraq ID). The attribute "type" MUST identify the database. One of the following strings SHOULD be used (if appropriate): virus worm intended trojan generator dropper One of the common names or abbreviations for malware platforms SHOULD be used (as listed in the revised CARO naming scheme). If used together with all other name part elements, this SHOULD contain only the malware family. "unknown" MUST be used as name for any malware that can't be identified by a more exact name. Although whitespace is allowed in malware names for compatibility reasons, it SHOULD NOT be used without very good reason. Variants are commonly enumerated by using uppercase letters: A, B, ..., Z, AA, AB, .., ZZ, AAA, ... This should be used for any other name parts like @mm suffixes, language codes, etc. This is a possibility to report other object properties, that are considered important. The method used to detect or identify this malware. This datatype is based on the revised CARO naming scheme (as published by Nick FitzGerald in Virus Bulletin Jan 2003). The complete structure must match the syntax: TYPE://PLATFORM/FAMILY.GROUP.VARIANT[MODIFIERS] Every name part may contain only the characters: A-Za-z0-9_- Allowed modifiers are (in this order): :LOCALE #PACKER @M or @MM !VENDOR_SPECIFIC_COMMENT The following regular expressions are used for the name parts: TYPE, PLATFORM, FAMILY, GROUP, PACKER: [-_A-Za-z0-9]{1,20} LOCALE: ([A-Za-z]{2}|[Uu][Nn][Ii]) VARIANT: (Inflen|SubvarDevo?) Inflen: [0-9]{1,20} Subvar: [A-Za-z]{1,20} Devo: [0-9]{1,20} @M[M]: @[Mm][Mm]? VENDOR_SPECIFIC_COMMENT: .* Multiple TYPE or PLATFORM parts may be given as comma-separated list that is enclosed in braces (defined by the additional patterns). WARNING: Because this is something not in use today, the structure and datatype contained here MAY change in future versions This optional element may be used together with the element "name" to give hints about the purpose/usage of this software object on the computer system. This optional element may be used together with the element "type" to give hints about the purpose/usage of this software object on the computer system. The verification method. For example "certificate" or "checksum" Identifies the data basis, that is used to verify the software object. For example the issuer of a certificate, if you're verifing software by cryptographic signatures. This is a possibility to specify the presence or absence of known security relevant object properties. Example properties: "not infected" "not analysed" "may be a corrupted file" "contains inactive malicious code fragments" "signature verification failed" NOTE: "not analysed" has the special meaning, that the data object has not been analysed. This property MUST be used, whenever there was a problem analysing a data object. "not infected" SHOULD be used if it is desired to report objects that are found to be "clean" (which means that the analysis is sufficient to be sure that the object is not infected by some replicating malware). This is similar to the "ok" messages used by many antimalware products. This SHOULD always be used if an object can not be analysed. Examples: "compression format not supported" "object is encrypted" "time limit reached" "size limit reached" Report a modified object property here. Report the expected value here. The verification method. For example: "checksum" Identifies the base of the modification checks against which the objects where checked. For example: "local database" or "online catalogue" Identify the curently installed version. Identify the up-to-date version. Location where the update is available. The method used to determine pending updates. For example: "checksum" or "version number" Identifies the source of the list of up-to-date objects. For example: "online catalogue" Here are customized datatypes for attribute values and simple element content. Defines a string that must contain at least one character. This is used to exclude only the emtpy string from the value space. Defines a string without any whitespace characters ("space", "tab","line feed" and "carriage return"). Defines a hexadecimal number. Uppercase and lowercase letters are allowed as well as leading zeros. Note that this definition includes decimal numbers. Defines a 48-bit MAC interface address either as a single hexadecimal value or as hexadecimal byte values separated by colon or hyphen (for example "12:34:56:78:9A:BC"). Defines a 64-bit EUI-64 interface address either as a single hexadecimal value or as hexadecimal byte values separated by colon or hyphen (for example "01-23-45-67-89-AB-CD-EF"). (See http://standards.ieee.org/regauth/oui/tutorials/EUI64.html for details about EUI-64). Defines an IP address of a single host in either hexadecimal (for example "c0a80101") or dotted-decimal notation (for example "192.168.1.1"). Defines an IPv6 address of a single host either as 128-bit hexadecimal number or as one of the notations defined in RFC 2373. Matches a hexadecimal value. For example "108000000000000000088000200C417A" Matches the syntax defined in RFC 2373, section 2.2.1 For example "1080:0:0:0:8:800:200C:417A" Matches an address in compressed form as defined in RFC 2373, section 2.2.2. For example "1080::8:800:200C:417A" Matches a mixed IPv6/IPv4 notation as defined in RFC 2373, section 2.2.3. For example "1080:0:0:0:8:800:32.12.65.122" Matches allowed combinations of sections 2.2.2 and 2.2.3 For example "1080::8:800:32.12.65.122" Matches allowed combinations of sections 2.2.2 and 2.2.3 For example "1080::32.12.65.122" A URI scheme for file locations as defined in RFC 1738. Because xsd:anyURI already defines a general URI syntax it is sufficient to restrict only the scheme prefix here. This datatype holds a checksum for a specified algorithm (given as attribut value). The algorithm must be one of the following list. The syntax of MIME content types is defined in RFC 2045, section 5.1. As specified every token consists of one or more ASCII characters with the exclusion of control characters, SPACE, the characters ()@,;:\"/[]?= and < and > To avoid problems with unicode characters this restriction is expressed as an list of explicitly allowed characters here: 0-9A-Z!#$%'*+-.^_`a-z{|}~ and & The top level media types are restricted to the types defined in RFC 2045, section 5.1 and RFC 2046 including the "X-" extension method): text, image, audio, video, application, message, multipart ATTENTION: Top level media types defined according to the IETF registration process (described in RFC 2048) are NOT included here and can't be described with this schema version. RFC 2045 allows media types to be appended with parameters (separated by semicolon, for example: "text/plain; charset=us-ascii") Parameters are not allowed here to keep things simple. Instead there is an additional element for mime parameters, that may be used if parameters are considered important for the current task (see below for the "mimeParameterType"). The regular expression is more complex, because RFC 2045 allows all uppercase/lowercase combinations for media types.