Description of the German Advisory Format (DAF)

Abstract

The "German Advisory Format" (DAF, "Deutsches Advisory Format" [5] (Deutscher CERT Verbund, “The DAF Homepage,” 2004.)) is based on the EISPP Advisory Format [6] (The EISPP Consortium, “The EISPP Common Advisory Format Description,” March 2004.). The authors assume that the document may also be of interest for the European and international CERT community, especially because DAF actively maintains dynamic parts of the advisory standard (see Section 4 (Up-to-date versions of dynamic parts of the EISPP standard)). As a service to the European and international CERT community, this document is therefore held in English rather than German.

Table of Contents

1.  Introduction
2.  Standard Translation of EISPP Terms
3.  DAF Constraints to EISPP
    3.1  Constraints within Element 'Identification Data'
    3.2  Constraints within Element 'Vulnerability Classification'
    3.3  Constraints within Element 'Description'
        3.3.1  Publication Context
        3.3.2  Technical Context
        3.3.3  Description
        3.3.4  Technical Information and Diagnostic
4.  Up-to-date versions of dynamic parts of the EISPP standard
    4.1  Risk schemata and risk groups
    4.2  Standardized identifiers and reference-number formats
        4.2.1  List of EISPP/DAF issuers
        4.2.2  List of standard resources
5.  Model of System Information
6.  DAF Extensions to EISPP
    6.1  Modification of description element
7.  Recommendation for getting started with DAF
    7.1  Minimal use of DAF
    7.2  'Light-weight DAF
8.  References
§  Author's Address

1. Introduction

The "German Advisory Format" (DAF, "Deutsches Advisory Format" [5] (Deutscher CERT Verbund, “The DAF Homepage,” 2004.)) is based on the EISPP Advisory Format [6] (The EISPP Consortium, “The EISPP Common Advisory Format Description,” March 2004.). This document describes DAF. It is held in English, because parts of it may be of interest for the European and international CERT community. Because DAF introduces a few small extensions to EISPP, a new XML DTD [1] (Deutscher CERT Verbund, “DAF DTD,” August 2004.) has been produced; see Section 6 (DAF Extensions to EISPP) for a description of the DAF-extensions to EISPP.

The role of DAF with respect to EISPP can be described as follows:

• DAF provides a translation of terms and concepts used within EISPP
  
  Confusion in communicating about advisories can be avoided by using the same terms consistently. Thus, a standard translation into German is useful.
  
  
• DAF constrains the use of the EISPP format
  
  EISPP is very flexible and offers a large degree of freedom. A more constraint use of the format is helpful for co-operation between CERTS.
  
  
• DAF maintains up-to-date versions of dynamic parts of the EISPP standard
  
  The EISPP advisory format defines several so-called open lists-of-values, that is lists of standardized identifiers that are extendable. Because EISPP does not have an active maintainer at the moment (the EISPP advisory format has been stabilized in version 2.0), the maintainers of DAF are required to organize maintenace of these lists to keep up-to-date.
  
  
• DAF adds a model of system information to EISPP
  
  The EISPP advisory format recognizes the need for machine-readable information about systems (usually combinations of operating system and software), e.g., to enable automated filtering with respect to the systems affected by a given vulnerability. EISPP, however, only provides a hook for tying in a standardized model of system information. Within DAF, CMSI (Common Model of System Information) is developed.
  
  
• DAF provides a few cautious extensions to EISPP
  
  A few small extensions to EISPP have been identified that enhance the usefulness of EISPP to several German CERTs. DAF defines these extensions and provides mappings from DAF to EISPP.
  
  

2. Standard Translation of EISPP Terms

Table 1 (Tranlation of terms used in EISPP) translates the terms used in the overview table presented in Section 3 of the EISPP Format Description [6] (The EISPP Consortium, “The EISPP Common Advisory Format Description,” March 2004.)

3. DAF Constraints to EISPP

The following Section describes constraints on the use of EISPP that have been agreed upon by the maintainers of DAF. The constraints have been introduced in order to ease co-operation between CERTs using DAF.

3.1 Constraints within Element 'Identification Data'

Within DAF, the field 'abstract' is not used; instead, the use of the 'description' field within the 'Description' element is constrainted such that its contents serve also as abstract of the advisory. (See also Section 3.3.3 (Description).

3.2 Constraints within Element 'Vulnerability Classification'

For DAF, the following constraints within the element 'Vulnerability Classification' have been agreed upon:

• The EISPP format allows the use of several 'vulnerability' elements within 'Vulnerability Classification'. For DAF, always exactly one such field is used, which contains a summary-assessment of all vulnerabilities treated in the advisory.
• No use is made of the top-level fields 'current_impact' and 'risk_ratings'; rather, the corresponding attributes within the single 'vulnerability' element are used.
• The 'explanation' field within classification elements 'immediacy', 'impact', and 'current_impact' is used in case the advisory issuer deviates from the EISPP recommendation of how to derive values for these classification elements: an explanatory comment explaining the reason for the deviation is given.
• The 'explanation' field within the other classification elements is used in case the advisory issuer thinks that additional information about that classification element is necessary. For example, if the advisory issuer classifies the 'vulnerability status' as 'exploit published', he might add information as to where he found a publicly available exploit.
• If teams chose to exchange risk-ratings for defined user-groups, the rating schema 'default' as described in Section 4.1 (Risk schemata and risk groups) is used.

3.3 Constraints within Element 'Description'

Within the 'Description' element of the advisory format, the following standard order of description-parts is observed:

1. publication context
2. technical context
3. description
4. technical information
5. diagnostics

If more than one vulnerability is described in the advisory, the latter two fields, 'technical information' and 'diagnostics', can be repeated several times to give information per vulnerability. In all other fields, the information regarding all described vulnerabilities is summarized.

In the following, DAF-constraints for each description part is described.

3.3.1 Publication Context

The publication context is used as described by the EISPP format.

3.3.2 Technical Context

The publication context is used as described by the EISPP format.

3.3.3 Description

The description provides a summary of all vulnerabilities communicated with the advisory. The description is short enough to also serve as advisory abstract, e.g., for a short version of the advisory. Therefore, the optional abstract section present within the EISPP advisory format is not used in DAF (see also Section 3.1 (Constraints within Element 'Identification Data')).

3.3.4 Technical Information and Diagnostic

If only one vulnerability is described in the advisory, a single "technical information" section may hold detailed information regarding the advisory -- usually including the description of possible attack vectors. A "diagnostic" section explaining of how to determine whether one is vulnerable may follow.

If several vulnerabilities are described:

1. the technical information can either be summed up in a single "technical information" section (if necessary, followed by a single "diagnostic" section), or
2. the technical information and diagnostic information can be provided by several separate "technical information" and "diagnostic" sections.

DAF allows the association of vulnerability ids with description parts (see Section 6.1 (Modification of description element)). In case several "technical information" sections are given, vulnerability identifiers can be used to indicate the vulnerability each section refers to -- this feature is useful, in case a link to a vulnerability database is to be maintained.

4. Up-to-date versions of dynamic parts of the EISPP standard

Some parts of the EISPP standard are dynamic. Because, to our knowledge, the dynamic parts are not actively maintained, DAF maintains up-to-date versions of these dynamic parts.

4.1 Risk schemata and risk groups

In the EISPP format, risk must be associated with a schema for risk assessment and the group of users/systems for which an assessment is carried out. No schemata and groups are defined by EISPP.

DAF defines the risk schema "default" with the following groups:

• general
  
  General risk assessment, for which an attack probability is determined from the exploit preconditions and combined with the potential threat.
  
  
• home_user
  
  A risk assessment carried out for the average home user.
  
  
• corporate_user
  
  A risk assessment carried out for the average corporate user.
  
  

4.2 Standardized identifiers and reference-number formats

Within EISPP/DAF, Standardized identifiers and reference-number formats are used for three purposes.

• To identify the issuer of an EISPP/DAF advisory. For example, the standardized identifier for Siemens CERT is 'Siemens-CERT'.
• To reference vulnerability-identifiers of standard identification-schemes such as CVE and Bugtraq. For example, the standardized identifier for the CVE scheme is 'CVE'; CVE reference-numbers are standardized as 'CVE-yyyy-nnnn' for CVE-entries and 'CAN-yyyy-nnnn' for CVE-candidates (where 'yyyy' stands for a year and 'nnnn' for a four-digit number).
• To reference frequently-referenced resources. For example, the standardized identifier for vendor bulletins from Microsoft is 'MS', and the reference-number format for these bulletins is 'MSnn-nnn' (where 'nn' and 'nnn' represent two-digit and three-digit numbers, respectively).

Although for the examples given above, it seems pretty clear which identifiers and which reference-number format should be taken, an actively maintained list of standardized identifiers and reference-number formats is necessary to ensure consistent use. In an annex-document to the EISPP format description [7] (The EISPP Consortium, “The EISPP Common Advisory Format Description: Values Lists,” March 2004.), EISPP defines such a list of standardized identifiers that is not actively maintained at the moment. Therefore, DAF maintains up-to-date lists with (1) standard identifiers for EISPP/DAF issuers and (2) standard identifiers and reference-number formats for vulnerability identification schemes and frequently-referenced resources. Both lists are maintained in a simple XML-format, the DTD of which is displayed in Figure 1 (DTD for issuer-information data) (also available from the DAF homepage [2] (Deutscher CERT Verbund, “DAF DTD for Issuer-Information Format,” 2004.)). The DTD identifies the following information to be maintained for every issuer/reference:

• Issuer/Resource ID
  
  A standard identifier for referencing the isser/resource
  
  
• Name
  
  Name of the issuer/resource
  
  
• Example Ref. Num.
  
  For standard resources, an example of what a reference number for that resource looks like.
  
  
• Regular Expression
  
  A regular expression (in Python-syntax) to which valid reference numbers for this resource must conform. The regular expression could be used in an authoring tool to restrict the input to valid reference numbers
  
  
• Comment
  
  A comment/short descriptio of the issuer/resource
  
  
• URI
  
  A URI pointing to the issuer/resource
  
  

4.2.1 List of EISPP/DAF issuers

For EISPP/DAF issuers that are members of FIRST, the standard identifier is identical to their entry in the FIRST team contact information [8] (FIRST, “FIRST Team Information,” 2004.); all teams issuing EISPP/DAF advisories are invited to register an identifier with the DAF maintainers. The list of EISPP/DAF issuers known to the DAF maintainers is available as XML-file from the DAF homepage [3] (Deutscher CERT Verbund, “List of EISPP/DAF Issuer IDs,” 2004.)

4.2.2 List of standard resources

An up-to-date list of standardized identifers and reference-number formats for frequently-referenced resources [4] (Deutscher CERT Verbund, “DAF List of Standard Resources,” 2004.) is available as XML-file from the DAF homepage.

<!--
  DTD for maintaining issuer-identifier information
  -->


<!--
  DTD data types:

        entity        description
        ======        ===============================================
        URI           e.g., "http://invisible.net/"

        CTEXT         printable ASCII text (no line-terminators)

        TEXT          character data
  -->


<!ENTITY % URI        "#PCDATA">

<!ENTITY % CTEXT      "#PCDATA">

<!ENTITY % TEXT       "#PCDATA">



<!ELEMENT issuer_info         (issuer+)>


<!ELEMENT issuer       (identifier,name,regexp,example,comment,uri)>


<!ELEMENT identifier (%CTEXT;)>
<!ELEMENT name (%CTEXT;)>
<!ELEMENT regexp (%CTEXT;)>
<!ELEMENT example (%CTEXT;)>
<!ELEMENT comment (%TEXT;)>
<!ELEMENT uri (%URI;)>

5. Model of System Information

Vulnerability handling requires information about which systems are affected by a given vulnerability. If suppliers of vulnerability information use proprietary models for specifying system information, correlating or filtering with respect to system information from different sources is difficult. A working group within the "Deutscher CERT Verbund" is currently developing a common model of system information (CMSI) -- see the [9] (Deutscher CERT Verbund, “The CMSI Homepage,” 2005.) for more information.

6. DAF Extensions to EISPP

6.1 Modification of description element

DAF modifies the 'Description' element of the EISPP format in two ways:

1. Each part of the 'Description' element ('publication context', 'technical information', 'description', ...) can be given a 'title' to be used for rendering the advisory. This is useful in cases where the authors of the advisory want to override a title that might be automatically generated by the rendering mechanism. Consider the case that several 'technical information' fields are used to describe several vulnerabilities. Then, a title such as "Technical Description", which might be generated by the rendering mechanism, can be replaced, e.g., by "Technical Description for Vulnerability Foobar".
2. Each part of the 'Description' element can be associated with a list of vulnerability identifiers. This is useful, e.g., to maintain an association between a vulnerability database and the 'technical information' fields within advisories.

The description element of EISPP v2.0 is modified as shown in Figure 2 (DAF-Modification of 'description' Element in EISPP v2.0 DTD).

   <!-- A description contains

     -  an optional title (defined exactly the same as the
        advisory title as freetext field) (NEWLY INTRODUCED IN DAF)

     - an optional list of vulnerability ids (NEWLY INTRODUCED IN DAF)
       in case several vulnerabilities are described and the
       author wants to indicate to which vulnerability this particular
       element refers to,

     - and the content.
    -->

   <!ELEMENT description (title?, vuln_ids?, content)>

   <!-- In addition to the 'content type' mentioned in the informal description,
        an attribute for specifying a content 'subtype' has been added. Co-operating
        CERTs can define a proprietary use for this attribute.
   -->

   <!ATTLIST description
           type %oLOV; #IMPLIED
           subtype %oLOV; #IMPLIED
   >

   <!-- 'title' and 'vuln_ids' are already defined; 'content' is
        defined as FormattedText field
   -->

   <!ELEMENT content (FormattedText+)>

7. Recommendation for getting started with DAF

The specification of the EISPP/DAF format describes how the format should be used: the description section should be split into logical subsections, references should be specified using a standard identifier for the issuer/resoruce and a reference number in a given format, etc. Reaching full compliance in a single step may not always be possible. In the following, possibilities for making use of a light-weight version of DAF are made.

7.1 Minimal use of DAF

Minimal use of DAF features could be especially useful for converting old advisories from a proprietary format into DAF. Because DAF is bound to be more structured than the proprietary format in question (which might just be an ASCII- or HTML-file), an automated conversion into fully compliant EISPP will not be possible. On the other hand, also an unstructured ASCII or HTML-format usually offers enough implicit structure in the form of standard headers, etc, that it should be relatively easy to extract at least the following data:

• in 'Identification Data'
  • date of issue
  • issuer identifier and reference number
  • title
• in 'Vulnerability Classification'
  • risk rating
• in 'Description': the complete, rendered advisory can be stored in a description element marked as 'complete_advisory'.

Although minimal use of DAF supports very few of the possibilities for automated processing that become possible with fully compliant DAF-advisories, at least exchange between and storage within DAF-enabled authoring systems is possible.

7.2 'Light-weight DAF

In order to leverage at least some of the possibilities that DAF offers, at least the following elements of the DAF format should be used:

• Inclusion of standard vulnerability identifiers
  
  Standard vulnerability identifiers such as CVE numbers or Bugtrag IDs allow searching and grouping of advisories by vulnerabilities
  
  
• Complete vulnerability classification
  
  Vulnerability analysis (what are the preconditions for exploiting a vulnerability, what are the effects of successful exploitation, how imminent is the threat posed by a given vulnerability, etc.) is carried out by almost every advisory issuer to some extend. The EISPP advisory format provides a common language for exchanging the findings about a vulnerability, which can be used for quality control or even the sharing of workload.
  
  
• Division of the problem description into logical subfields
  
  By dividing the advisory text into logical subfields such as a description of the technical context, diagnostic information, etc., the re-use of advisory parts becomes easier. Additionally, advisories can be tailored to the audience by supressing those fields that are of little or no interest to a given audience when displaying the advisory.
  
  

For full compliance with DAF, the use of solution sections, reference structures for handling links, etc., is still missing. Nevertheless, "light-weight DAF" already offers many opportunities for better advisory handling and co-operation on advisories between issuers.

8. References

Author's Address