Abstract

This memo describes an XML-based format for security announcements. It defines a basic but comprehensive set of elements that is designed to describe the main aspects of an issue related to security. Besides addressing more than one issue or problem within a single document the format allows to provide information for more than one target group of readers as well as multi-lingual textual descriptions. It can be used to selectively produce different renderings of an announcement for the intended target groups, addressing one, a sub-set, or all problems in one or multiple languages. The set of pre-defined elements can be extended to reflect either temporary, exotic or new requirements on a per-document basis. A special markup element allows to include information for specific constituencies that can be removed before a document is interchanged. CAIF documents may contain data that allow the manual or automatic determination of the affectedness of systems by a specific problem.

Copyright Notice

(c) Copyright Oliver Goebel, The CAIF Project 2004-2005

Conventions Used in this Document

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.

Table of Contents

1.  Introduction
2.  Motivation
3.  Scope of this Document
4.  Paradigms
    4.1.  Information in Relation to an Infrastructural Context
    4.2.  Minimize Restrictions
    4.3.  Normalization and Generic Values
    4.4.  Separate Format and Policy
5.  Design Goals
    5.1.  Announcements Addressing More Than One Problem
    5.2.  Multi-Lingual Announcements
    5.3.  Announcements for Multiple Target Groups of Readers
    5.4.  Extensibility
6.  Basic Terminology
    6.1.  Announcement
        6.1.1.  Urgency
        6.1.2.  Levels
        6.1.3.  Flavors
    6.2.  Rendering
    6.3.  System
    6.4.  Issuer
    6.5.  Issuing
    6.6.  Distribution or Redistribution
    6.7.  Distributor
    6.8.  Constituency
    6.9.  Environment
    6.10.  Reader
    6.11.  Section
    6.12.  Container
    6.13.  Markup Text
    6.14.  Non-Markup Text
    6.15.  The Syntax Used in the Synopses
7.  Using XML to Write Announcements
    7.1.  XML Basics
        7.1.1.  Major XML Components
        7.1.2.  Basic Rules
    7.2.  Document Type Definitions (DTD)
8.  The Main Sections of a CAIF Announcement
    8.1.  Identification
    8.2.  Intended Readers: Target Groups
    8.3.  Constituencies
    8.4.  Revision Data
    8.5.  The Subject of the Announcement
    8.6.  The Summary
    8.7.  "Problem-IDs" - References to the Addressed Problems
    8.8.  Affected and Not Affected
    8.9.  Determination of the Affectedness
    8.10.  Mitigating Factors
    8.11.  The Description in Detail
    8.12.  Context Information
    8.13.  Information about a Possible Solution
    8.14.  References to Other Documents - The Bibliography
    8.15.  Credits
    8.16.  Disclaimer
    8.17.  Including Other Douments in the Announcement
    8.18.  Renderings Included in the Announcement
9.  Text Markup Elements
    9.1.  Text Emphasis
        9.1.1.  Emphasizing Text with The "em" Element
        9.1.2.  Bold Face Text - The "b" Element
        9.1.3.  Very Bold Face Text - The "vb" Element
    9.2.  Special Strings and Text Markup
        9.2.1.  Preformatted Text -The "pre" Element
        9.2.2.  Vendor Names - The "vendor" Element
        9.2.3.  The "code" Element
        9.2.4.  Program Names - The "program" Element
        9.2.5.  Services and Daemons - The "service" Element
        9.2.6.  Protocols - The "protocol" Element
        9.2.7.  System Features - The "sys-feat" Element
        9.2.8.  File Names and Contents - the "file" Element
        9.2.9.  User Text Input - The "user" Element
        9.2.10.  System Text Output - The "output" Element
        9.2.11.  Terminal Interaction - The "terminal" Element and its Sub-Elements
        9.2.12.  Menus - The "menu" Element
    9.3.  Markup Elements for internal and external Referencing
        9.3.1.  Internal Cross-References - The "ilink" Element
        9.3.2.  Targets of Internal Cross-References - The "itarget" Element
        9.3.3.  The External Reference "elink"
        9.3.4.  The "const" Markup Element
        9.3.5.  The "aff" Markup Element
        9.3.6.  The "update" Element
10.  Document Structuring Elements
    10.1.  The Paragraph Element "p"
    10.2.  The "table" Element and its Sub-Elements "tr" and "td"
    10.3.  Lists: The "list" Element and its Sub-Element "li"
    10.4.  The "body" element
    10.5.  The Refencing List "rlist"
        10.5.1.  The "tg-ref" Attribute of "rlist"
        10.5.2.  The "headline" Attribute of "rlist"
        10.5.3.  The "style" Attribute of "rlist"
        10.5.4.  The "rli" Element - Sub-Element to "rlist"
        10.5.5.  An "rlist"-Example
11.  The Announcement: The Top-Level-Element "caif"
12.  REQUIRED Elements in a CAIF Announcement
13.  The Elements Defining the Main Sections
    13.1.  The "identification" Element and its Sub-Elements
        13.1.1.  The "issuer" Element
        13.1.2.  The "announcement" Element
        13.1.3.  The "type" Element
        13.1.4.  The "author" Element
        13.1.5.  The "distribution-allowed" Element
        13.1.6.  The "earliest-release" Element
        13.1.7.  The Overall Syntax and an Overall Example for the "identification" Element
    13.2.  The "target-groups" Element
        13.2.1.  The "target-group" Element
    13.3.  The "constituencies" Element
        13.3.1.  The "constituency" element
    13.4.  The "revision" Element
        13.4.1.  The "issued" Element
        13.4.2.  The "re-issued" Element
        13.4.3.  The "revision" Element
    13.5.  The "category" Element
    13.6.  The "subject" Element
    13.7.  The "summary" Element
    13.8.  The "problems" Element
        13.8.1.  The "problem" Element
    13.9.  The "mitigation" Element
    13.10.  The "affected" Element
    13.11.  The "not-affected" Element
    13.12.  The "possibly-affected" Element
    13.13.  The "determine-affectedness" Element
        13.13.1.  The "detitem" Element
    13.14.  The "context" Element
    13.15.  The "description" Element
    13.16.  The "workaround" Element
    13.17.  The "solution" Element
    13.18.  The "arbitrary" Element
    13.19.  The "bibliography" Element
        13.19.1.  The "bibitem" Element
    13.20.  The "credits" Element
    13.21.  The "disclaimer" Element
    13.22.  The "other-documents" Element
        13.22.1.  The "other-document" Element
    13.23.  The "rendered-copies" Element
        13.23.1.  The "rendered-copy" Element
14.  Security Considerations
15.  References
    15.1.  Normative References
    15.2.  Informal References
Appendix A.  Glossary
    A.1.  Well-Formedness
    A.2.  Validity
Appendix B.  Keys and Standard Values
    B.1.  Pre-Defined Values for the "target-group" element
        B.1.1.  The Set of Pre-Defined Values for the "tech-background" Attribute of the "target-group" Element
        B.1.2.  The Set of Pre-Defined Values for the "orga-overview" Attribute of the "target-group" Element
    B.2.  The Key Values for the "problem" element
        B.2.1.  The Keyset for the "key" Attribute of the "class" Element
        B.2.2.  The Set of Pre-Defined Values for the "key" Attribute of the "attack-requirements" element
        B.2.3.  The Set of Pre-Defined Values for the the "key" Attribute of the "impact" element
        B.2.4.  The Set of Pre-Defined values for the "key" Attribute of the "exploit-status" Element
        B.2.5.  The Pre-Defined Values for the "key" Attribute of the "risk" Element
        B.2.6.  The Set of Pre-Defined Values for the "key" Attribute of the "probability-of-occurrence" Element
        B.2.7.  The Set of Pre-Defined Values for the "key" Attribute of the "threat" Element
Appendix C.  The Document Type Definition (DTD) of CAIF
Appendix D.  Acknowledgements
§  Author's Address

1. Introduction

This document describes the Common Announcement Interchange Format (CAIF), designed to produce, store, and exchange security announcements in a standardized way using the Extensible Markup Language (XML [2] (World Wide Web Consortium, “Extensible Markup Language (XML) 1.0,” February 1998.)). It provides a basic but comprehensive set of elements meeting the requirements that have been defined for CAIF [6] (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.) according the experience gathered over time and that is part of the most announcements issued by the various vendors and security teams currently established.

The format can be extended easily and flexibly on a per-document basis. Extensions can be grouped with existing elements or other extending elements. This mechanism enables authors and issuers to use CAIF for the representation of various existing annoucement formats and putting them into a normalized form without forcing issuers to omit valuable or provide unnecessary information. CAIF also can be used as a basis to develop new document formats since the set of required elements is small. Although flexible, CAIF is a fully featured document format providing an extensive set of pre-defined elements identifying the various sections of a security announcement (The Main Sections of a CAIF Announcement) as well as high-level markup elements. Since there are only few mandatory sections in a CAIF document, the format can be used not only for security announcements but other types like briefings or background documents.

CAIF provides a set of markup elements (Text Markup Elements) enabling authors to produce highly informative and easy-to-read documents. These elements are intended to transport the information on the special meaning or value of the markup text as well as the intention of the author to the various renderings and document formats provided to the constituency of a (re)distributor according her presentation policies.

Various structuring elements (Document Structuring Elements) enable authors to structure announcements as well as to store textual descriptions in multiple languages and for more than one target group of readers (see Section 10.4 (The "body" element) and Section 10.5 (The Refencing List "rlist")). The format also provides mechanisms to address multiple issues in a single document (see Section 10.5 (The Refencing List "rlist")). A rendering of such can produce a single document that addresses all issues or several documents that each address a sub-set of the issues.

By using this XML-based format, announcements can effectively be interchanged between issuers and redistributors without loosing information or meaning. The format itself imposes minimal restrictions upon the rendering of an announcement, thus makes it possible to efficiently reuse of announcements. A redistributor can process an exchanged document according his own presentation policies mechanically.

The format uses a DTD to define the syntax of an announcement. The DTD is provided in Appendix C (The Document Type Definition (DTD) of CAIF).

Issuers and re-issuers can use XSL (XML Style Language) to produce specific renderings.

For authenticity purposes, CAIF can store rendered versions of the original announcement -- digitally signed if necessary -- of the issuer in a container. Also, to provide availability, CAIF documents MAY contain rendered copies of documents that provide source or extra information.

2. Motivation

Due to the way information technology is being deployed, soft- and more seldomly hardware defects relevant to security are and will be a threat to the operation of IT infrastructure, especially if it is connected to the world-wide Internet. Therefore, information on security issues and their solutions are vital for operating such infrastructure.

Information about vulnerabilities is available from many sources, in very different formats. Over time, a specific notification method for security issues has evolved: the security announcement sometimes called "advisory" (see also Section 6.1 (Announcement) for a discussion about the specific meaning of these terms). However, while there is consensus among authors that such a class of documents exists, current security announcements differ substantially in almost any aspect. This diversity leads to three major problems:

• Infrastructure operators who read original security announcements need a considerable amount of time, experience, and expertise, to decide if action is necessary and which countermeasures have to be taken.
• Providers of security-related information have to prepare their own announcement, in a format familiar to their audience or constituency, resulting in a massive multiplication of work.
• It is not immediately obvious if two security announcements address the same problem. Readers have to check carefully every source of information, in order not to fail to notice a different issue or crucial details on the same issue.

Experience shows that a uniform structure for security announcements can help to reduce these problems. Structured announcements also have the potential to facilitate augmented redistribution, e.g. the preparation of derived documents tailored to meet reader- requirements and contain constituency-specific information (see Section 6.8 (Constituency)).

Although there have been several activities going on (e.g. the EISPP Common Format (The European Information Promotion Programme (EISPP), Project co-funded by the European Community, 5th Framework, “The EISPP Common Format,” .) [19] and [17] (Cormack, A., “Writing Advisories,” March 2002.)), that are and have been intended to help structuring the dissemination of information about security issues, no standardized format, that meets the requirements from the various actors and is flexible enough to meet new requirements quickly, has evolved yet. Thus, a huge amount of information is available but still it represents a challenging task for most potential users of such information to collect and evaluate it, and make sure not to miss an essential bit. A mitigation for one of the major problems, that was acute in the past, seems to establish: issuers have adopted reference databases (like the CVE Project (The MITRE Cooperation, “The Common Vulnerabilities and Exposures Project (CVE), http://www.mitre.org/cve/,” .) [12], or the iCAT Metabase (National Institute of Standards and Technology (NIST), “The iCAT Metabase, http://icat.nist.gov/icat.cfm,” .) [13]) to uniquely identify the problems their documents provide information about.

However, distributors of security announcements need to present the documents according to their presentation policy and local typesetting conventions. This is the reason why a presentation-independent interchange format is needed, to avoid that many different announcements are issued regarding the same topic, thus producing extra work and confusing readers.

A standardized structure for security announcements helps authors to include information that readers need to quickly decide the relevance of an announcement. Combined with the familiarity a standard format can be expected to create among readers, this potentially results in easier access to security-relevant information. The format should be not too restrictive in its regulations and extensibility since requirements may change quickly in detail and other formats in the security context should be covered as well. Thus, extensibiliy is a desirable goal to achieve when designing the format.

As a conclusion, a standardized structure for security announcements can help to disseminate essential information on security issues both more quickly and more widely. A canonical way of reading security announcements should help to increase security awareness amongst readers who lack the time and experience needed to cope with the flood of announcement in different formats and using different terminology.

In January 2003 RUS-CERT has issued a paper that outlines a set of requirements such a format should meet [6] (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.). Based on this set and on some further requirements that have been identified, the Common Announcement Interchange Format (CAIF) has been developed.

3. Scope of this Document

This document describes the syntax and sematics of the Common Announcement Interchange Format (CAIF).

The complete set of CAIF documents will presumably consist of the following documents:

• the requirements document, first issued in January 2003
• this document describing the format specification (based on the requirements described in the document mentioned above
• a technical quick-start document, describing how to use the features of the format
• guidelines for issuers (based on previous experience of issuers and early adopters of the CAIF standard)
• guidelines for readers (amongst other things, outlining the data and procedues readers need to know to use CAIF announcements efficiently).

None of these documents will try to enforce a specific policy regarding the disclosure of security-related information. CAIF describes the structure (and, indirectly, the content) of security announcements.

4. Paradigms

4.1. Information in Relation to an Infrastructural Context

Experience shows, that it is very important to distinguish between information that is independent from an infrastructural context (i.e. a given constituency (Constituency)) and information that is depending on such, when writing and exchanging announcements. Especially the risk assessments of the various types, that represent a substantial part of an announcement, divide in those two categories. When an announcement is distributed (Distribution or Redistribution) and SHALL be reusable by a third party, it MUST be possible to decide mechanically which parts of the information provided is depending on the distributors's constituency's IT infrastructure.

In order to avoid confusion, the CAIF document format generally provides information that SHALL be independent from a given infrastructural context. Especially the "risk" element (The sub-element "risk" of "problem") MUST contain such an assessment, i.e. it describes the "technical risk".

Some sections are intended to contain assessment information that is dependent from an infrastructural context. These sections can be removed from an announcement either by the distributor before the distribution or before the rendering of the distributed announcement. The following elements may contain context-dependent assessment information:

probability-of-occurrence

-- This element (see Section 13.8.1.8 (The sub-element "probability-of-occurrence" of "problem")) provides an assessment on the probability the problem or its exploitation by an attacker causes the impacts (The sub-element "impact" of "problem") described.

threat

-- This element (see Section 13.8.1.9 (The sub-element "threat" of "problem")) may contain an assessment on the threat the problem described imposes upon a given infrastructural context.

All other sections SHOULD NOT contain information that is specific to a given constituency unless it is enclosed in the tags of the markup element "const" (Section 9.3.4 (The "const" Markup Element)) which refers to a defined "constituency" (Section 13.3.1 (The "constituency" element )). When the document is distributed outside the constituency, the distributor can decide whether the constituency-specific information is to be kept or removed.

If used carefully the "const" markup element with its reference to the constituency description given in the "constituency" section makes clear which piece of information is specific to which constituency. The "constituency" element can also be used to define abstract IT environments. Thus an issuer can write special text paragraphs referring to the various abstract constituencies.

4.2. Minimize Restrictions

To be usable it is vital for a standardized format to impose only minimal restrictions upon an issuer or distributor of an announcement when writing or rendering announcements. Especially the rendering of an announcement should be possible according local preferences and policies.

CAIF provides a minimal mandatory framework for announcements that allows to identify the document, its issuer, as well as its revision history uniquely. For all other aspects that are considered as being useful data structures are available and may be present optionally in an announcement, thus restrictions are minimal when using the format for documents.

4.3. Normalization and Generic Values

The field of IT-security is very complex and many things and aspects are highly interwoven. Thus identifying the aspects of security issues and defining classifications to describe them to help evaluate and assess their risk and threat is a crucial although hard job.

Since there may arise security issues that have different or new aspects which are important to be described and considered when assessment is done, it is important to identify generic aspects that are as atomic as possible and do not change over time. Besides possible conflicts that may occur when new requirements arise it has proven useful to use atomic elements to describe more complex circumstances, in other words, a normalization of a description scheme minimizes space requirements and provides flexibility when it comes to map hitherto unknown issues.

For example, it is very common to describe an impact a problem has on IT-infrastructure as a "remote root exploit". Its meaning is quite intuitive. If this value would be used as a standard value it would combine several aspects that do not necessarily belong to the "impact" aspect. It says "remote" which is rather a requirement to attack successfully than a part of the impact. Besides the fact that the use of the term "root" is not generic, because only on UNIX derivates there is a user "root" that has system privileges, the term "exploit" rather describes the act of attacking and exploiting the problem than an aspect of the impact. Especially in this case the proper impact would be a "compromise" instead of an "exploit". Hence "remote root exploit" migles up three (more or less) atomic aspects. When it comes to categorize other impacts, these aspects again have to be included in the values, like: "local root exploit", "remote service denial-of-service", "local system denial-of-service", "remote user compromise", and so on.

To avoid such a flood of categorization values normalization is a good approach, having the side effect, that generic new aspects can be defined independently from all existing values. Such then can be combined with the exiting ones to create a set of new expressions describing an issue. E.g. "remote root compromise" could be devided into the values "remote" for the aspect "attack-requirements" and "root compromise" -- being converted in the generic value "system compromise" -- for the aspect "impact".

CAIF tries to identify atomic aspects of security issues as well as generic values for them to achieve the goal of providing a compact, comprehensve and easy-to-extend categorization scheme.

4.4. Separate Format and Policy

When writing documents that describe security relevant problems an assessment of the risk or threat this problem imposes on a given system or infrastructure usually is a relevant part of the document. Such assessments are done using a policy that define the aspects that have to be taken into account as well as their weighting when calculating the result. Currently, there are many different policies in use, in fact most of the issuers use their own way to assess problems.

There are being made efforts to standardize the way such assessments are done (e.g. in the Common Vulnerability Scoring System (CVSS) (The Forum of Incident Response and Security Teams (FIRST), “The Common Vulnerability Scoring System (CVSS),” .) [15]) to make them comparable and enable users to evaluate them more easily. Although this is a highly desirable approach, its implementation is a challenging task since there are many other systems in use and even some of the projects proposing a standardized format for security advisories also define a fixed policy for the assessment (e.g. the the EISPP Common Format (The European Information Promotion Programme (EISPP), Project co-funded by the European Community, 5th Framework, “The EISPP Common Format,” .) [19]) and hence cannot adopt a policy that is defined elsewhere, like CVSS is.

Therefore, one of the paradigms of CAIF is the separation of the format and the policy to assess problems. In some respect this aspect is a part of the paradigm to "minimize restrictions" (Minimize Restrictions) but it is of such prominent importance, that it is made paramount to the development of CAIF. When producing documents with CAIF authors are not forced to use a specific policy and pre-defined values when making an assessment of the issue described in the document.

Nevertheless to be operational in the absence of an external policy, CAIF implements a set of OPTIONAL elements, that are designed to contain results of an assessment of the issues described in the document (see Section 13.8.1.7 (The sub-element "risk" of "problem"), Section 13.8.1.9 (The sub-element "threat" of "problem"), and Section 13.8.1.8 (The sub-element "probability-of-occurrence" of "problem")) as a minimum framework. Besides an OPTIONAL "key" attribute that may have one of four values (see Appendix B.2.5 (The Pre-Defined Values for the "key" Attribute of the "risk" Element), Appendix B.2.6 (The Set of Pre-Defined Values for the "key" Attribute of the "probability-of-occurrence" Element), and Appendix B.2.7 (The Set of Pre-Defined Values for the "key" Attribute of the "threat" Element)), each element also provides a "policy" attribute that allows to reference the policy used to make the assessment.

This rather generic approach allows authors to assess the issues described according to any policy either by using the "key" attributes with their built-in values or any other value within the various elements provided by CAIF. If the set of elements is not sufficient, additional elements can be defined via the "arbitrary" element (The "arbitrary" Element).

5. Design Goals

5.1. Announcements Addressing More Than One Problem

When designing CAIF one of the major goals was the ability to address more than one problem within a single document, e.g. if issues have to be described, that consist of more than one problem, vulnerability or exposure, or an issuer wants to produce a cumulative patch announcement or a bulletin digest.

CAIF provides mechanisms to include information for several distinctive issues within a single XML document. It is possible to individually describe the aspects (Section) for the problems or provide information that fits for a sub-set or all problems at the same time. For example: if a set of three problems is described, the announcement may have three description sections (The "description" Element) each providing information about one of the problems, but only one impact element (The sub-element "class" of "problem") providing information about the impact of all three problems, if it is the same, e.g. a "denial of service" condition (The Set of Pre-Defined Values for the the "key" Attribute of the "impact" element).

To each problem, vulnerability or exposure an ID unique to the document (The "problem" Element) is assigned. Within the document these IDs then can be referenced (The "rli" Element - Sub-Element to "rlist" ), either individually or as a set.

5.2. Multi-Lingual Announcements

In many cases it is useful to provide an announcement in more than one language. Vendors, for example, who deliver their products to more than one speech area may be in need to deliver announcements in several languages. In this case it is useful to be able to render an announcement in multiple languages. Maintaining the various language versions in a single document facilitates the handling of announcements for example if they are interchanged.

CAIF provides mechanisms to maintain various language versions within a single document. The "target-group" mechanism (see Section 5.3 (Announcements for Multiple Target Groups of Readers) and Section 13.2 (The "target-groups" Element)) definines the language a textual description is written in.

Rendering the announcement then can produce several documents in the different languages.

When maintainig an announcement, a former mono-lingual announcement can become multi-lingual by simply adding the appropriate target group and text sections.

5.3. Announcements for Multiple Target Groups of Readers

In some cases, it is useful to provide the information of the announcement for more than one target group of readers. Since these target groups may have different knowledge of the technology that affected systems base on and possibly need a different sight on the problem and its impacts, the issuer probably will have to provide different textual descriptions on the details. It MUST be possible to reference the specially worded text paragraphs to the several target groups so that renderings addressing a special target group can be generated. The default target group usually are system administrators who generally have a certain amount of technical background knowledge. If other target groups like users or non-technical management have to be notified about security problems, less technical descriptions might be useful. Nevertheless all information concerning one issue should be kept within one XML document to minimize administrative overhead when handling announcements.

CAIF provides mechanisms (see Section 13.2 (The "target-groups" Element), Section 10.4 (The "body" element), and Section 10.5 (The Refencing List "rlist")) to include passages for more than one target group in a single announcement, thus enabling renderers to produce either one document addressing all or several documents each addressing one or a sub-set of target group. CAIF addresses the following aspects of target groups:

language

-- besides the other aspects, the language is a basic attribute of a target group.

technical background

-- this aspect describes the technical background the reader has. For example: if the intended reader is a system administrator good technical background knowledge can be assumed whereas little to no background knowledge can be expected from an ordinary user.

organizational overview

-- this aspect describes the overview the intended reader has within the organization an affected system is used. A system administrator usually has less organizational overview than a member of the management, thus the information given within sections to the latter probably differs from the bare technical facts. For example: if a system is affected that is vital for web-based sales, a manager responsible for sales might want to know how the problem described in an announcement affects the web-services essential for her scope of responsibility.

the environment in which the problem occurs

-- in CAIF the term 'environment' indicates the context in which the affected system is used. The context could be a software suite like a personnel management system in which the affected ware is a component. Such could be an application like a web-server or the underlying operating system that is certified for a special version and patch-level by the manufacturer of the suite. In many cases it is a hard job for the administrator of the suite or the hosting computer system(s) to decide whether the countermeasures described (e.g. a patch for the underlying operating system) in an announcement can be applied and which effects they may have on the suite. Defining a target group having this aspect allows issuers to provide such extra information.

5.4. Extensibility

CAIF introduces a mechanism to flexibly reflect new requirements on a per-document basis. Although the format is very generic and is designed to meet the requirements of most major announcement formats currently in use, it may be necessary to extend it.

To enable authors to quickly and easily do so, CAIF introduces the element "arbitrary" (The "arbitrary" Element) that can be used to contain an extra section. The element has the attribute "name" providing the title for the extra section. The OPTIONAL attribute "extends" has the name of a regular CAIF element or another "arbitrary" element as value, thus can be grouped with this element to describe a semantic relation. For example: if the author wants the element "workaround" (see Section 13.16 (The "workaround" Element)) to have an extra sub-element "vendor_status", he could add the following:

   <arbitrary name="vendor-status" extends="workaround">
     <body headline="Vendor Status" tg-ref="en-admin">
     The vendor has been contacted and is developing a patch to
     fix the problem.  The workaround described has been confirmed
     as being a temporary solution to the problem.
     </body>
   </arbitrary>

Rendering software could produce an extra section "Vendor Status" that belongs to the element "workaround". Since this new element has the name "vendor-status" it may be extended by another "arbitrary" element. Note the "tg-ref" attribute that references the "body" element to the target group with the ID "en-admin" (see Section 5.3 (Announcements for Multiple Target Groups of Readers) and Section 13.2 (The "target-groups" Element)).

6. Basic Terminology

To provide a uniform usage of terms this section defines the basic terminology used in this document.

6.1. Announcement

Over time the term "advisory" has become common for documents describing a problem, vulnerability, or exposure that threatens the security of IT infrastructure. Besides a more or less detailed description of the problem itself, such a document usually provides information about a solution. Such could be a vendor patch or a workaround.

Unfortunately "advisory" does not transport a lot of information about the degree of urgency the document should be read or the provided solution should be applied. There are some issuers, who use the terms "alert" and "warning", but there is no uniquely recognized meaning to these terms. On the other hand a background document would not be called an "advisory". Thus we prefer the more general term "announcement" to reflect the more general scope of CAIF, although "advisory" is a very good description for a document that contains advice for operators of IT infrastructure. We do not abandon the term but define its meaning a little bit more precisely.

A "CAIF announcement" is an XML document containing information about one or more IT security problems or solutions of such or provides background information about one ore more IT security issues. An announcement is the source for the various "renderings" (Rendering).

An announcement can have several urgency states, content levels, and flavors (see Section 13.1.3 (The "type" Element)).

6.1.1. Urgency

Depending on the problem the announcement addresses, its "urgency" state describes the urgency to solve the problem or take action to mitigate it.

"alert"

-- An announcement that describes a serious problem requiring immediate action.

"warning"

-- An announcement that describes a potentially serious problem, thus requiring early action.

"advisory"

-- An announcement that describes a problem and advises action. Such could be a theoretical problem which is hard to exploit and therefore does not impose an acute risk. Note that this state may change over time.

"informational"

-- A general document like a background document about a security issue.

6.1.2. Levels

The content "level" defines the detailing of the description.

"brief"

-- A brief announcement about a security issue or problem. This level can be used as a cross-reference announcement if the issue has been described somewhere else.

"full"

-- A fully qualified announcement, providing all or a substantial sub-set of the informative sections (The Main Sections of a CAIF Announcement).

"digest"

-- An annoucement that addresses more than one issue or problem, e.g. a description of a patch bundle.

6.1.3. Flavors

"vulnerability-description"

-- The announcement describes a vulnerability but does not provide a patch as a solution. Nevertheless another solution like a workaround can be provided by an announcement with this flavor.

"patch-notification"

-- The announcement describes a problem and provides a patch as a solution.

"heads-up"

-- The announcement is neither describing a known vulnerability nor a patch but rather a an issue that requires the reader to raise attention on some special activity or circumstances.

6.2. Rendering

A rendering is a document in a presentation format that has been generated from the XML code of an announcement (Announcement). Presentation formats can be Spartan, like plain text, or rich like PDF. Note, that HTML and its derivates are presentation formats too.

6.3. System

The term "system" used in an announcement refers to a platform, soft- or hardware product, a protocol, or any other IT element that can be "affected" of a security problem or issue (see Section 13.10 (The "affected" Element)).

6.4. Issuer

The author of an announcement, or, if the author works for an institution which chooses to attribute announcements to itself, that institution. The issuer initially generates and publishes the announcement.

6.5. Issuing

The act of an issuer (Issuer) giving their constituency (Constituency) or the public access to a rendering of an announcement produced by the issuer. The issuer is said to "issue" an announcement.

6.6. Distribution or Redistribution

The act of letting others access to renderings or the XML-source of an announcement after it has been received from the issuer (Issuer) or another distributor (Distributor)). The distributor is said to "distribute" an announcement, if the latter applies it is also said to "redistribute" an announcement.

6.7. Distributor

A party who distributes or redistributes announcement renderings or XML-sources. For clarification the term "redistributor" can be used for a distributor who redistributes an announement.

6.8. Constituency

The set of users and administrators of the IT infrastructure consulted by the issuer (Issuer) or (re-)distributor of an announcement as well as the infrastructure itself

6.9. Environment

In CAIF an "environment" describes the context in which an affected system is used. Usually this is a set of wares that work together to create a suite. Such could be a piece of application software that relies on an underlying operating system. If there is a problem in this OS it most probably would affect the application as well, even if the latter is bug-free. Besides the problem, the solution of the problem may affect the application as well. Hence, the description of the problem in the OS itself may be quite different from the description of the same problem within the "environment".

6.10. Reader

A person who reads an announcement, usually a member of the constituency (Constituency).

6.11. Section

A part of an announcement containing specific information. "Standard sections" have well-defined content, which sometimes can be processed automatically. CAIF defines a set of sections (The Main Sections of a CAIF Announcement).

6.12. Container

A mechanism for transport and storage that allows to include data in arbitrary formats (like pdf or other) in XML-based announcements. Such also can be documents in XML formats other than CAIF.

6.13. Markup Text

Text that MAY contain CAIF's markup (Text Markup Elements) and structuring elements (Document Structuring Elements) except the rlist element (The Refencing List "rlist") and body element (The "body" element).

6.14. Non-Markup Text

Text that does not contain any of CAIF's elements, neither markup (Text Markup Elements) nor structuring elements (Document Structuring Elements), or any other elements, i.e. plain text.

6.15. The Syntax Used in the Synopses

In this document the syntax of XML elements and their usage are given in a syntax scheme similar the one used in the "man" pages of the UNIX/Linux world. It defines expressions that consist of the following elements:

• Literals -- All characters and strings that are not metacharacters or keywords are to be read literally, i.e. they represent the real text that is present in the code.
• Tokens -- Strings enclosed or separated by metacharacters. They can consist of literals or tokens.
• Metacharacters -- Special characters that allow to define wether and how often a token may occur or define alternatives. The following metacharacters are used:
  1. Square brackets "[]" are used to enclose literals or tokens that may or may not occur in a token. For example

              [token1] token2
     

     matches

              token2
     

     as well as

              token1 token2
     

  2. Winged brackets "{}" are used to enclose literals or tokens that may occur zero or multiple times. For example:

              token1{ token2}
     

     matches

              token1
     

     as well as

              token1 token2 token2 token2 token2
     

     or any other number of " token2". Note the blank space character right after the obenin bracked, it is part of the string, that to be matched.
  3. The separation bar "|" is used to define an alternative. To clarify to which tokens or literals the alternative apply, round brackets "()" can be used grouping the expression. For example:

              token1|token2
             or
              (token1|token2)
     

     match

              token1
     

     or

              token2
     

• Keywords -- are used to describe special values that are used within XML. The following keywords are used:
  1. ID -- An ID is an identifyer string that MUST be unique within a CAIF document. It MUST NOT contain any whitespace characters. The ID is an anchor for IDREFs (see below) that refer to them. E.g. the expression:

              <element id="ID"/>
     

     matches the following code:

              <element id="This_is_an_id"/>
     

     but not

              <element id="This is an id"/>
     

  2. IDREF -- An IDREF refers to an ID (see above). To establish a reference it MUST have the same value as the referenced ID. E.g. the expression:

              <the-other-element ref="IDREF{ IDREF}"/>
     

     matches the following code:

              <the-other-element ref="This_is_an_id"/>
     

     This element refers to the ID "This_is_an_id"

     The expression also matches:

              <the-other-element ref="These are all ids"/>
     

     Here, the element refers to the IDs "These", "are", "all", and "ids".

     
     
     
     If an IDREF in a CAIF document has a value that is not defined by an ID (see above), the validation of the document fails. Note, that this is not characteristic to CAIF but to its nature as an XML format.
  
  
  
  
• The ellipse "..." is used, whenever arbitrary text can be provided. In some cases, the synopses contain explaining text instead of an ellipse.
  
  
  

Note, that this pseudo syntax is not intended to be processed mechanically but rather as a possibility to compactly display the syntax of a CAIF element.

7. Using XML to Write Announcements

In this chapter neither a formal nor comprehensive description of XML is given. The chapter provides some basic knowledge useful when producing announcements according to the syntax described in CAIF's Document Type Definition (see Appendix C (The Document Type Definition (DTD) of CAIF)). For the definition of XML and further reading see [2] (World Wide Web Consortium, “Extensible Markup Language (XML) 1.0,” February 1998.).

If you're already familiar with XML, you might want to skip this section.

7.1. XML Basics

XML requires few but strict rules when writing documents. XML looks very much like HTML because both share the same roots, but unlike usable HTML, writing XML requires more discipline.

7.1.1. Major XML Components

There are four major components XML is made up from (an "empty element" is a special peculiarity of "element" thus passes not for a "major component").

7.1.1.1. Entity

An Entity is a textual macro unique to a document that is replaced with text or XML components, when the document is processed. An element starts with an ampersand character "&" and ends with a semicolon ";".

Example:

        &entity;

Meta characters like the ampersand are expressed as entities: "&" is replaced by the character "&" in a document rendering.

7.1.1.2. Element

Elements are the main components of an XML document. An element usually refers to a start tag, an end tag, and all the characters and/or XML components in between. Each element has a unique name. The element name enclosed in angle brackets -- "<" and ">" -- represents the start tag wheras the element name preceeded by a slash "/" represents the end tag.

Example:

        <element>enclosed text and components</element>

7.1.1.3. Empty Element

There is a special form of an element that is called "empty element". An empty element draws the start and the end tag into one tag and consequently does not enclose any text or XML components. The name of an empty element has a trailing slash "/". Empty elements usually have attributes (see next paragraph). Empty elements are not used in HTML.

Example:

        <empty-element/>

7.1.1.4. Attribute

An "attribute" is an extension to an element. It has a name and a value, where the value MUST be quoted in single or double quotes. An element can have multiple attributes. Attributes MAY only occur in the start tag of an element or in an empty element.

Examples:

        <element attribute="value">
          enclosed text and components
        </element>

        <empty-element attribute="value"/>

7.1.1.5. Comment

Comments are (usually ;-) ignored by XML-processing software. A comment starts with the string "<!--" and ends with the string "-->". All text enclosed in these strings is ignored. Comments can contain arbitrary text except two dashes immediately following each other "--".

Example:

        <!--
          This text is regarded as comment and not to be processed.
        -->

7.1.2. Basic Rules

The following rules apply to produce "well-formed" (Well-Formedness) documents:

1. Elements MUST be nested correctly. Every element's start tag MUST match its end tag like brackets in program code, e.g.

           <first>
                   blah
                   <second>
                           foo
                   </second>
                   <third>
                           bar
                   </third>
                   blubber
           </first>
   

   This is allowed in XML because the elements are nested correctly.

   
           <first>
                   blah
                   <second>
                           foo
           </first>
                   blubber
                   </second>
   

   This is not allowed in XML because the elements are not nested correctly.

   
   
   
   
2. The characters "<", ">", and "&" are meta characters and MUST NOT be used in a document except for enclosing element names and starting entity names. There are generic entities for these characters: "&lt;" for "<", "&gt;" for ">" and "&amp;" for "&".
   
   
   
3. XML is case sensitive; for example: the element "<element>" is different to the element "<Element>". Consequently, the following is not correct:

   
           <element> blah </Element>
   
   

   This is not allowed in XML because the end tag "</Element>" does not match the start tag "&element>".

7.2. Document Type Definitions (DTD)

A "Document Type Definition" (DTD) describes the syntax of the XML elements and entities used in a particular class of documents. It defines an XML-based language serving the needs of the issue it was designed for.

Software that processes an XML document can use a DTD to validate it. A valid (Validity) document is well-formed (Well-Formedness) and matches the definitions of the DTD, i.e. it features all the elements that are REQUIRED by the DTD to be part of a document, and - on top of that - uses only optional elements and entities that are allowed by the DTD. All elements and entities MUST be used in the correct order and syntax.

CAIF's DTD (The Document Type Definition (DTD) of CAIF) describes a language that can be used to write security announcements. It defines the elements to markup text, and the elements for structuring text in the document. Furthermore it defines elements to provide external references as well as document-internal cross-references. Finally and chiefly it defines the overall format of a CAIF document by describing its mandatory and optional sections.

8. The Main Sections of a CAIF Announcement

Based on the requirements to CAIF (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.) [6] published in January 2003 a set of useful sections, reflecting the needs of almost all announcement issuers, has been identified. On top of that, extra sections (Extensibility) can be added to a CAIF document if necessary. Such extra sections can be grouped with CAIF standard sections to let them be processed together. The following chapters give an overview over the main sections and their meaning in an announcement. In CAIF's DTD (The Document Type Definition (DTD) of CAIF) all sections are defined as top-level elements (The Elements Defining the Main Sections), some having sub-elements, some just containing text that is to be displayed in a rendering of the document.

8.1. Identification

This section contains information about the author (The "author" Element), and the issuer (The "issuer" Element) of the announcement. Furthermore it identifies the document by an id (The "announcement" Element) that (at least) MUST be unique to the set of announcements published by the issuer. This section also provides information on the type (The "type" Element) of the announcement.

Finally it contains a flag that indicates if the announcement MAY be interchanged or shall be kept internal to a specific constituency (see Section 13.3.1 (The "constituency" element ) and Section 13.1.5 (The "distribution-allowed" Element)). The "earliest-release" element tells processing systems and parties, when the announcement or a rendering MAY be published for the first time (see Section 13.1.6 (The "earliest-release" Element)).

This section is defined by the "identification" element (The "identification" Element and its Sub-Elements) which is REQUIRED in a CAIF announcement.

8.2. Intended Readers: Target Groups

In the OPTIONAL "target group" section (Section 13.2 (The "target-groups" Element)) the author can define the quality of the intended audience of the document. It is possible to define multiple target groups each having a unique ID as the reference anchor for paragraphs (Section 10.4 (The "body" element), Section 10.5 (The Refencing List "rlist"), Section 13.19.1 (The "bibitem" Element), Section 13.23.1 (The "rendered-copy" Element)) within the document that are intended to be read by the members of one or a set of the target groups. Hence it is possible, to create target group specific renderings of the announcement containig information taylored for the readers (see also Section 5.3 (Announcements for Multiple Target Groups of Readers).).

Besides a free text description some attributes (see Section 13.2.1 (The "target-group" Element)) can be provided with values that allow for the mechanical categorization of and rendering for the target groups. They comprise the language ("lang"), the assumed technical background knowledge ("tech-background"), the overview and responsibility a member has within his organization ("orga-overview"), and some information about a possible "environment" (Environment) in which the problem described has immediate or mediate effects.

8.3. Constituencies

The OPTIONAL "constituency" section (Section 13.3.1 (The "constituency" element )) can be used to describe a specific constituency (Constituency). Since "constituency" MAY occur multiple times in an announcement (see Section 13.3 (The "constituencies" Element)), it is possible to describe more than one IT infrastructure and its users. The element provides an ID that can be referenced by the markup element "const" (Section 9.3.4 (The "const" Markup Element)) to allow the provision of constituency-specific text passages. The constituency-specific pieces MAY be removed before an announcement is interchanged if the issuer does not want them to be distributed. Another valid use of the "constituency" section and the referencing "const" markup element is the description of abstract constituencies that have several technical characteristics like enabled features of affected systems (Section 8.8 (Affected and Not Affected)). The "const" markup then can be used to enclose text passages that reference to these specific characteristics.

8.4. Revision Data

This section contains data on the version in combination with the date of the first issue (The "issued" Element) of the announcement. If the announcement has been revised (but not re-issued) this section provides data on the changes made as well as the dates of all revisions (The "revision" Element). Finally, the section provides information about re-issuings (The "re-issued" Element) of the announcement.

This section is defined by the "revisions" element (The "revision" Element) . It is REQUIRED in a CAIF announcement.

8.5. The Subject of the Announcement

This is the single subject line of the announcement. Since email is a very important distribution mechanism for plain text renderings, the subject of a CAIF announcement MUST meet the same requirements like an email subject line.

The subject is defined by the "subject" element (The "subject" Element) which is REQUIRED in a CAIF announcement.

8.6. The Summary

To provide an overview over the problem described in a CAIF announcement this section SHOULD contain a comprehensive summary. The summary SHOULD be brief and usually SHOULD NOT contain more than two or three phrases. Of course this is not a 'MUST' criterion especially if the announcement describes more than one issue, e.g. in a cumulative patch announcement.

This section is provided in the "summary" (The "summary" Element) element which is REQUIRED in a CAIF announcement. If the document is a "brief" announcement (The "type" Element) the summary SHOULD be more exhaustive, replacing the description (The "description" Element) that then MAY be omitted.

8.7. "Problem-IDs" - References to the Addressed Problems

This is a very important section although OPTIONAL in an announcement. It contains references to issues or problems described. Such references ingeniously are IDs of established projects like the Common Vulnerability and Exposures Project (CVE) (The MITRE Cooperation, “The Common Vulnerabilities and Exposures Project (CVE), http://www.mitre.org/cve/,” .) [12] or vulnerability IDs of vendors or the CERT (R) Coordination Center (CERT/CC, “The CERT (R) Co-ordination Center, http://www.cert.org/,” 1988.) [11]. On top of a definite identification of the issues described, this section also provides IDs internal to the document that identify possible sub-issues or - if the announcement addresses multiple topics - each single topic. Referenced lists (The Refencing List "rlist") can back-reference to the IDs provided by the "problem" elements (The "problem" Element) that are sub-elements of the "problems" element (The "problems" Element).

Within this section the following problem specific characteristics can be described:

-- a classification of the problem for statistical reasons. An example for a common classification is a "buffer overflow bug".

-- the vector by which the problem can be exploited to perform a successful attack, e.g. a specially crafted tcp packet to a port.

-- the prerequisites an attacker would need to sucessfully exploit the problem and achieve the described impact (see below), e.g. access to a network that allows to communicate with an affected system or console access to such a system.

-- informaton on the traces an attack trying to exploit the problem leaves, like specific traffic or log file entries. The signatures can be provided in the syntax of intrusion detection systems (IDS).

-- the impact a successful attack has on an affected system, like its compromise or its non-availability due to a denial of service condition.

-- information about the availability of exploit code like a worm.

-- constituency (The "constituency" element ) specific and non-specific assessments of the risk the problem imposes on affected infrastructure.

8.8. Affected and Not Affected

CAIF provides several elements to contain information about affected (The "affected" Element), possibly affected (The "possibly-affected" Element), and not affected (The "not-affected" Element) systems by the problem described. All three sections are OPTIONAL in an announcement. The term "system" itself is not used within the format specification, thus enables authors to flexibly use these sections: affected may be a platform, a product, either in hard- or software, a protocol, or a concrete implementation of a specific system in use, like one special server. It also could be a rather abstract procedure how data is processed in a more complex environment comprising of severeal systems -- and users -- or a client-server relationship. The format does not impose restrictions here. The "category" (The "category" Element) contains more general information on the quality of the affected systems.

Information about possibly and not affected systems require maintenance in some cases, since these sections SHOULD be updated whenever new versions are available that are not affected or evidence about the affectedness of hitherto possibly affected systems is gained. Each update of an announcement MUST be documented in the "revisions" (The "revision" Element) section.

8.9. Determination of the Affectedness

In many cases it is useful to provide the reader with information on how to determine if the systems she has in use are affected by the problem described or not. Such could be a simple command that returns the version number as well as a more sophisticated set of steps that have to be performed to get the desired answer.

It is also possible to include some information that can be fed into a parser that automatically is trying to determine if a system is affected by the problem dealt with in the announcement.

Within the section defined by the OPTIONAL element "determine-affectedness" (The "determine-affectedness" Element) this infomation can be provided and the method (manual vs. the various automatic ones) can be identified.

8.10. Mitigating Factors

Sometimes it is useful to describe a problem in a system that is not enabled by default or is not configured in a way that makes it possible to exploit the problem using the described attack vector. Such aspects are called "mitigating factors".

According to CAIF's paradigm to be as generic as possile and allow for the description of issues independently from a given constituency (Section 4.1 (Information in Relation to an Infrastructural Context)) as well make the primary risk assessment in a worst case view, the information contained at first SHOULD address the problem or issue regardless if affected systems commonly are deployed in a way that makes them vulnerable or not.

Nevertheless "mitigating factors" are valuable information and SHOULD NOT be omitted especially when compiling an announcement since it helps to determine whether a given System is affected or not.

The section "Mitigating factors" is intended to contain information about factors that mitigate the risk potential or "technical risk" (The sub-element "risk" of "problem") the problem described imposes on affected systems. The presence of this section MUST NOT have an effect on the assessment of the technical risk.

Note, that the information provided in this section SHOULD NOT generally refer to a specific constituency (Constituencies) but be rather impartial and independent from a constituency.

Nevertheless CAIF provides mechanisms to include text paragraphs, that refer to a specific constituency and can be stripped off the document, when distributing it (Section 9.3.4 (The "const" Markup Element)).

This section is implemented by the "mitigation" element (The "mitigation" Element).

8.11. The Description in Detail

In this section a detailed description of the issue is given. CAIF does not restrict the content of this section but it is recommended that the problem is being described comprehensively, including the attack, its requirements and vector the impact and possibly subsequent impacts, if applicable. The information provided SHOULD be sufficient for a reader to decide whether the issue is a threat to her IT infrastructure or not.

This section is defined by the "description" element (The "description" Element) which is OPTIONAL in an announcement.

8.12. Context Information

This section provides background information to enable readers to put a described problem in the technical appropriate context. Issuers MUST be aware of the fact, that potential readers of an announcement are not necessarily experts in systems that are affected (see Section 13.10 (The "affected" Element)), thus may have problems in deciding, whether there is a threat to their infrastructure. Therefore it is vital to the intended effect of an announcement to be not too brief in providing background information about the technical context of a problem.

Note, that the information provided in this section SHOULD NOT generally refer to a specific constituency (Constituencies) but be rather impartial and independent from a constituency.

Nevertheless CAIF provides mechanisms to include text paragraphs, that refer to a specific constituency and can be stripped off the document, when distributing it (Section 9.3.4 (The "const" Markup Element)).

This section is provided by the OPTIONAL "context" element (The "context" Element).

8.13. Information about a Possible Solution

There are two sections containing information about possible reliefs of the problem(s): "solution" (The "solution" Element) and "workaround" (The "workaround" Element). While "solution" provides information about a more or less final remedy to the problem, e.g. a patch or the installation of a not affected version, "workaround" introduces a temporary solution, like the termination of an affected service.

The elements "workaround" and "solution" are OPTIONAL in an announcement.

8.14. References to Other Documents - The Bibliography

This section contains a list of references to external documents. It is provided by the "bibliography" element (The "bibliography" Element) which is OPTIONAL in an announcement. References MAY contain Uniform Ressource Identifiers (URIs), other references like ISBNumbers, or anything else that qualifies as a unique pointer to an external document. Every reference also MAY have a time-stamp that tells the reader, when the referenced document has been considerend by the author. Since external documents can change over time, such a time-stamp may proove useful.

There are "primary" references identifying the main sources of the information described in the announcement and "informal" references that provide additional information e.g. a background paper describing the system that is affected by a problem described in the announcement.

8.15. Credits

This section, implemented by the OPTIONAL "credits" element (The "credits" Element), can be used to document credits, e.g. to the discoverer of the issue.

8.16. Disclaimer

This section can contain a standard or special disclaimer for the announcement limiting warranties and other legal aspects. CAIF does not provide prefabricated disclaimers since legal regulations vary in different countries.

The section is implemented by the OPTIONAL "disclaimer" element (The "disclaimer" Element).

8.17. Including Other Douments in the Announcement

For authenticity purposes as well as for availability reasons the element "other-document" (The "other-document" Element) provides a container to include rendered copies of other documents and/or CAIF announcements related to the topic.

Note, that the inclusion of third-party documents MAY imply the consideration of copyright issues.

8.18. Renderings Included in the Announcement

For authenticity purposes the element "rendered-copy" (The "rendered-copy" Element) provides a container to include a rendered, possibly digitally signed copy of the orginal issue of the CAIF announcement.

9. Text Markup Elements

In order to facilitate the presentation of the description of the issue in various renderings (rendered formats, like HTML or PDF) CAIF provides an extensive set of markup elements.

9.1. Text Emphasis

The CAIF Requirements Document (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.) [6] defines a set of three different types of emphasis for text, a minor type, that can be omitted in Spartan rendering formats, a normal type that MUST be visible in all renderings and a major type, that MUST catch the readers eyes in all rendered documents. The following sections describe the elements, that are implementing these types of text emphasis.

9.1.1. Emphasizing Text with The "em" Element

The markup element "em" ('emphasis') implements the "minor" emphasis defined in Section 6 of the CAIF Requirements Document [6] (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.). Text empasized by "em" SHOULD be visible in renderings of a CAIF announcement but can be omitted in Spartan formats like plain text. Within the "em" element other markup elements are allowed.

Synopsis:

        <em>...</em>

Example:

        It is <em>nice</em> to have pretzels with a pint of beer.

could result in a rendering like this:

        It is nice to have pretzels with a pint of beer.

Note, that this document is in a Spartan format, thus the rendering of this example is in this format too: the emphasis has been omitted.

9.1.2. Bold Face Text - The "b" Element

The markup element "b" ('bold') implements the "normal" emphasis defined in Section 6 of the CAIF Requirements Document [6] (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.). Text empasized by "b" MUST be visible in all renderings of a CAIF announcement. Within the "b" element other markup elements are allowed.

Synopsis:

        <b>...</b>

Example:

        For major pleasure it is <b>important</b> to drink
        <b>fresh</b> beer.

could result in a rendering like this:

        For major pleasure it is *important* to drink *fresh* beer.

9.1.3. Very Bold Face Text - The "vb" Element

The markup element "vb" ('very bold') implements the "major" emphasis defined in Section 6 of the CAIF Requirements Document [6] (Weimer, F. and O. Goebel, “Common Advisory Interchange Format - Requirements V 1.0,” January 2003.). Text emphasized by "vb" MUST be clearly visible in all renderings of a CAIF announcement. Authors and issuers SHOULD use this type of emphasis with care. Within the "vb" element other markup elements are allowed.

Synopsis:

        <vb>...</vb>

Example:

        Usually, no beer in the refrigerator means <vb>red alert</vb>
        and should result in immediate actions to solve this
        severe problem!

could result in a rendering like this:

        Usually, no beer in the refrigerator means *RED ALERT*
        and should result in immediate actions to solve this
        severe problem!

9.2. Special Strings and Text Markup

CAIF provides markup elements for special text strings to increase the readability of renderings.

9.2.1. Preformatted Text -The "pre" Element

The "pre" (pre-formatted) element is similar to the HTML-element of the same name. Formatting rules take no effect to the text enclosed by the "pre"-tags in a rendering, i.e. processing software MUST NOT re-format text within the "pre" element. Within the "pre" element no other elements are allowed.

Synopsis:

        <pre>...</pre>

Example:

        <pre>
        Pre-formatted can text be used for ASCII-art:

        +--------+         --------       +--------+
        | Client |------>/ Packet /------>| Server |
        +--------+       --------         +--------+

        Because it is not re-formatted when rendered.
        </pre>

9.2.2. Vendor Names - The "vendor" Element

The "vendor" element identifies vendor names, e.g. the name of a company or organization that are distributing systems (System). Within the "vendor" element other markup elements are allowed. Formatting rules SHOULD apply to the text enclosed.

Synopsis:

        <vendor>...</vendor>

Example:

        <vendor>Microsoft</vendor> and the
        <vendor>Debian Project</vendor>
        have announced security patches.

9.2.3. The "code" Element

The "code" element marks up source-code snippets within the text flow. It is recommended to use a mono-spaced font to display text marked up with "code" in a rendering. Within the "code" element no other elements are allowed. Formatting rules SHOULD apply to the text enclosed.

Synopsis:

        <code>...</code>

Example:

        <code>#!/bin/bash</code>

9.2.4. Program Names - The "program" Element

The element "program" identifies program names and their options (also if used without the program name). For this element too it is recommended to display text enclosed by the tags of "program" in a mono-spaced font. Within the "program" element no other elements are allowed. Formatting rules SHOULD apply to the text enclosed.

Synopsis:

        <program>...</program>

Example:

        <program>/bin/tcsh</program>

9.2.5. Services and Daemons - The "service" Element

The "service" element identifies services and daemons providing (network) services of an operating system. Of course, names of daemons can be marked up with the "program" element (Program Names - The "program" Element) too, especially if the author wants to describe the program and not the service. Nevertheless if a daemon is mentioned, authors often want to describe the service provided by the daemon. The element "service" then can help to make clear the intention of the author.

Within the "service" element no other elements are allowed. Formatting rules SHOULD apply to the text enclosed.

Synopsis:

        <service>...</service>

Example:

        ...the <service>Tooltalk</service> service...

        ...<service>statd</service> is a daemon used by NFS...

9.2.6. Protocols - The "protocol" Element

The "protocol" element identifies protocols, such as H.325, SMTP or HTTP.

Within the "protocol" element no other elements are allowed. Formatting rules SHOULD apply to the text enclosed.

Synopsis:

        <protocol>...</protocol>

Example:

        <protocol>HTTPS</protocol> is used to transport encrypted
        HTML pages as well as authenticate servers to clients and
        vice versa.

9.2.7. System Features - The "sys-feat" Element

CAIF defines "system features" as aspects of operating systems and programs like UIDs, flags, privileges etc. Within the "sys-feat" element no other elements are allowed. Formatting rules SHOULD apply to the text enclosed.

Synopsis:

        <sys-feat>...</sys-feat>

Example:

        arbitrary code can be executed under the
        <sys-feat>UID=0 (root)</sys-feat>

9.2.8. File Names and Contents - the "file" Element

The "file" markup element is used to identify file names and contents. Within the "file" element no other elements are allowed.

The element has the OPTIONAL attribute "path".

If the author wants to markup filenames or paths within continous text the element "file" MUST be empty and the file name or path is the value of the attribute "path". Formatting rules SHOULD apply to the text in "path".

If used to markup file content the element is not empty and the content is enclosed in the tags of "file". Text enclosed SHOULD be rendered like preformatted text (Preformatted Text -The "pre" Element) (whereat the font can be different), i.e. formatting rules MUST NOT apply to the enclosed text. If "file" is not empty it is up to the rendering policy if the value of the "path" attribute is visible in a rendering or not.

The element has the OPTIONAL attribute "type" that defines the type of the file. The following values may be used:

"text"

-- a regular text file

"log"

-- a log file

"config"

-- a configuration file

"source"

-- a file containing source for a script or a program, e.g. C code or /bin/sh code

"binary"

-- any binary files like pictures, proprietary document formats, or compiled code

Synopsis:

        <file [path="..."]
              [type="(text|log|config|source|binary)"]>
                    ...
        </file>

Examples:

        <file path="/home/rustler/RUS-CERT/CAIF/caif.dtd"
              type="text"/>

        <file path="C:\MyDocuments\CAIF_presentation.ppt"
              type="binary"/>

        <file path="motd"/>

        <file path="/home/rustler/caif/caif.dtd" type="source">
        <!ELEMENT em            %MTEXT;>
        <!ELEMENT b             %MTEXT;>
        <!ELEMENT vb            %MTEXT;>
        </file>

9.2.9. User Text Input - The "user" Element

The markup element "user" contains text a user should put in within a terminal session. It is intended to be used within the "terminal" element (Terminal Interaction - The "terminal" Element and its Sub-Elements) but can be used outside this element as well. The text marked up MUST be rendered like text in the "file" element (File Names and Contents - the "file" Element).

Within the "user" element no other elements are allowed.

The "user" element has an OPTIONAL attribute "prompt" that defines the system prompt, e.g. "root@sun", "#", "user@box", or "$". It is recommended to use "$" as a prompt for an ordinary user and "#" for the user "root", especially within terminal sessions Section 9.2.11 (Terminal Interaction - The "terminal" Element and its Sub-Elements).

Synopsis:

        <user [prompt="..."]>...</user>

Example:

        <user prompt="user@sun">ls /home/rustler/RUS-CERT/CAIF</user>

9.2.10. System Text Output - The "output" Element

The element "output" contains system text output in a terminal session or from a program. It is intended to be used within the "terminal" element (Terminal Interaction - The "terminal" Element and its Sub-Elements) but can be used outside this element as well. The text marked up MUST be rendered like text in the "file" element (File Names and Contents - the "file" Element).

Within the "output" element no other elements are allowed.

Synopsis:

        <output>...</output>

Example:

        <output>
        caif-draft.txt    caif-draft.xml         caif.dtd
        CVS/              example_1155.xml       requirements.txt
        RFC/              todo.txt               YeOldeStuffe/
        </output>

9.2.11. Terminal Interaction - The "terminal" Element and its Sub-Elements

The "terminal" element contains a set of sub-elements to describe a terminal session, e.g. to describe in detail how to change configuration files or execute commands. The elements "user" (User Text Input - The "user" Element), "output" (System Text Output - The "output" Element), and "file" (File Names and Contents - the "file" Element), that can be used outside the "terminal" element, can appear within a "terminal" session. Other markup text MAY appear within the "terminal" element to support remarks between the lines of the session.

Synopsis:

        <terminal>
          {<user>...</user>|
          <output>...</ouput>|
          <file>...</file>|
          other CAIF markup elements}
        </terminal>

Example:

        <terminal>
        Log in as <sys-feat>root</sys-feat>:
        <user prompt="$">
        su
        </user>
        <output>
        Password:
        </output>
        <user prompt="#">
        </user>
        Edit <file path="/etc/inetd.conf" type="config"/>:
        <user prompt="#">
        vi /etc/inetd.conf
        </user>
        Scroll to the following line:
        <file path="/etc/inetd.conf" type="config">
        ident  stream  tcp  wait  identd  /usr/sbin/identd  identd
        </file>
        Change to the <sys-feat>insert mode</sys-feat> by typing
        <user>i</user>. Insert a hash symbol <code>#</code>
        at the beginning of the line:
        <file path="/etc/inetd.conf" type="config">
        #ident  stream  tcp  wait  identd  /usr/sbin/identd  identd
        </file>
        Leave the <sys-feat>insert mode</sys-feat> by pressing the
        &lt;ESC&gt; key.
        Write the file and leave <program>vi</program> by typing
        <user>:wq!</user>. Restart <service>inetd</service>:
        <user prompt="#">
        killall -HUP inetd
        </user>
        Drop <sys-feat>root</sys-feat> privileges:
        <user prompt="#">
        exit
        </user>
        <user prompt="$">
        </user>
        </terminal>

This could be rendered (in the Spartan format of this document) into something like:

      Log in as "root":

       $ su
       Password:
       #

      Edit /etc/inetd.conf:

       # vi /etc/inetd.conf

      Scroll to the following line:

       ident  stream  tcp  wait  identd  /usr/sbin/identd  identd

      Change to the insert mode by typing
      "i". Insert a hash symbol '#' at the beginning of the line:

       #ident  stream  tcp  wait  identd  /usr/sbin/identd  identd

      Leave the insert mode by pressing the <ESC> key.  Write the
      file and leave vi by typing ":wq!".  Restart inetd:

       # killall -HUP inetd

      Drop "root" privileges:

       # exit
       $

9.2.12. Menus - The "menu" Element

This element is intended to describe different types of menus. When documenting steps to apply a solution or configure a system, modern operating systems often require the user to use menus and sub menus to do so. Since there is no generally recommended way to display such menus, especially in different formats, CAIF provides some basic mechanisms to describe menus. It is up to issuers and distributors to render such menus in the preferred way.

The "menu" element has the OPTIONAL attribute "title" and the REQUIRED attribute "style" that has the following pre-defined values:

pull-down

-- describes a pull-down menue like the "File" menue in most applications

pull-up

-- describes a "reverse pull-down" menue like the "Start" menue in Microsoft (tm) Windows

pop-up

-- describes a menue that pops up, e.g the mouse menus that pop up when a button (usually the right button) is pressed somewhere on the background

window

-- a window that pops up, e.g. a warning or error message or a window that contains some "tab" menus

tab

-- a tab menue

tree

-- a tree, e.g. for directory trees or similar

input

-- an input widget, can be used to show the reader where to type in the required input

button

-- a button widget.

Note, that this element SHALL NOT describe a complete window or menue but rather parts of menus that are necessary to instruct readers to execute several actions or understand a special issue.

The element itself can contain markup text, describing the content of the displayed menu. Each paragraph (Section 10.1 (The Paragraph Element "p")) produces a menu item, if only one item is needed, the paragraph element "p" MAY be ommited. The "menu" element can be used recursively to describe nested menus.

Synopsis:

        <menu style="(pull-down|pull-up|pop-up|tab|input|button)"
              [title="..."]>
         ...
        </menu>

Examples:

• A nested pull-down menue can be described by:

          <menu style="pull-down" title="File">
            <p><b>New</b>
            <menu style="pull-down">
            <p><b>Text Document<b></p>
            <p>...</p>
            </menu>
            ...
          </menu>
  

  The "b" element could be used to mark the selected menue entry.

  A rendering could look like:

          File
          +----------+
          | *New*   +-----------------+
          | ...     | *Text Document* |
          |         | ...             |
          |         +-----------------+
          |          |
          +----------+
  

• A tab in a pop-up window:

          <menu style="window" title="Certificate Manager">
            <menu style="tab" title="Your Certificates">
              <menu style="tree" title="Stuttgart University">
              <p>Oliver Goebel</p>
              </menu>
            </menu>
          </menu>
  

  A rendering could look like:

          +-------------------------------------------------+
          | Certificate Manager                             |
          |-------------------------------------------------|
          |                                                 |
          |   -----------------                             |
          | / Your Certificates \                           |
          ||                     --------------------------+|
          || Stuttgart University                          ||
          ||  |                                            ||
          ||  +- Oliver Goebel                             ||
          ||                                               ||
          |+-----------------------------------------------+|
          +-------------------------------------------------+
  

• A directory browser window

          <menu style="window" title="/home/rustler/">
            <menu style="tree" title="/">
              <p>bin/</p>
              <p>boot/</p>
              <p>dev/</p>
              <p>etc/</p>
              <p>floppy/</p>
              <menu style="tree" title="home/">
                <menu style="tree" title="rustler/">
                <p>draft-goebel-caif.txt</p>
                <p>...</p>
                </menu>
              </menu>
              <p>...</p>
            </menu>
            <p>...</p>
          </menu>
  

  A rendering could look like:

          +-------------------------------------------------+
          |/home/rustler/                                   |
          |-------------------------------------------------|
          |  /                                              |
          |  |                                              |
          |  +- bin/                                        |
          |  +- boot/                                       |
          |  +- dev/                                        |
          |  +- etc/                                        |
          |  +- floppy/                                     |
          |  +- home/                                       |
          |  |   |                                          |
          |  |   +- rustler/                                |
          |  |   |   |                                      |
          |  |   |   +- draft-goebel-caif.txt               |
          |  |   |   +- ...                                 |
          |  |   +-...                                      |
          |  +-...                                          |
          |                                                 |
          +-------------------------------------------------+
  

9.3. Markup Elements for internal and external Referencing

9.3.1. Internal Cross-References - The "ilink" Element

The "ilink" element provides internal-to-document references, i.e. cross-refences. An "ilink" element contains non-markup text and points to an "itarget" within the same document. The REQUIRED attribute "target" references the attribute "name" of the "itarget" (Targets of Internal Cross-References - The "itarget" Element) element.

Synopsis:

        <ilink target="IDREF">...</ilink>

Example:

        See <ilink target="impact">Section "Impact"</ilink>

The "ilink" element also can be used to refer to a element defining a section (The Elements Defining the Main Sections) by providing the "target" attribute with the name of the element.

Software producing a rendering of an "ilink" reference MUST backtrack the scope of the ilink element and apply it to the referenced target if possible. In this case the scope is defined as its location within a "body" (The "body" element) or "rlist" (The Refencing List "rlist") element which has a a specific value in its "tg-ref" attribute. When producing a working link in a rendering the target MUST dynamically be located in the same scope of the referenced section.

For example: if the author places an "ilink" element pointing to a itarget (Targets of Internal Cross-References - The "itarget" Element) in or the context element (The "context" Element) itself in the "body" element of "description" (The "description" Element) that refers to the "target-group" (The "target-group" Element) of french-speaking developers, then the rendering software MUST produce a link, that points to the "body" element of the "context" element that refers to the same "target-group". If such a body element is missing, the software SHOULD omit the link generation and produce a warning.

Unfortunately, the process of valitation against a DTD (Document Type Definitions (DTD)) cannot find inconsistent links that do not accomplish the conditions described above. Hence, the use of the "ilink" element requires good discipline.

9.3.2. Targets of Internal Cross-References - The "itarget" Element

The empty element "itarget" provides the anchor an ilink (Internal Cross-References - The "ilink" Element) element points to. It has the REQUIRED attribute "name" that contains the value of the ID, the "target" attribute of "ilink" points to.

Synopsis:

        <itarget name="ID"/>

Example:

        <itarget name="impact"/>

9.3.3. The External Reference "elink"

The "elink" element provides references to targets outside the containing document trough a Unifom Ressource Identifier (URI). Like the "href" attribute of the "a" element in HTML the REQUIRED "target" attribute of "elink" contains an URI that points to the ressource. The element contains non-markup text.

Synopsis:

        <elink target="URI">...</elink>

Example:

        <elink target="http://www.caif.info/">
        The CAIF Homepage</elink>

9.3.4. The "const" Markup Element

The "const" element allows to include constituency (The "constituency" element ) specific information in the document wherever markup text is allowed. Due to its nature as being a markup element it can be used to enclose single words as well as whole text paragraphs. It has the REQUIRED attribute "ref" that is used to reference to one or multiple of the constituencies that are defined in the document.

The "const" element allows to distinguish between information that is specific to well-defined constituencies and such that is generally valid, thus applies not only to one or a subset of the constituencies.

If used carefully, an author can produce a document that can be rendered for the different constituencies without providing information that is not intended for the chosen constituency. If the issuer wants the specific information to be kept within his constituency the document can be "cleansed" at will from all the "const" elements and their content as well as the other elements that provide constituency-specific information (the "probability-of-occurrence" element, see Section 13.8.1.8 (The sub-element "probability-of-occurrence" of "problem"), and the "threat" element, see Section 13.8.1.9 (The sub-element "threat" of "problem")).

The "constituency" element (The "constituency" element ) can also be used to define abstract IT environments. Such could be a special configuration or a widlely used way to deploy affected systems (The "affected" Element) which is not the recommended way or implies new aspects to the threat the problem represents. Sometimes the problem itself is not as critical as it becomes when affecting systems deployed in a special way or if the affected systems interact in a special way. In such cases it can be useful to describe the problem itself and define the dangereous kind of deployment as an abstract constituency. An issuer then can describe the problem itself and provide additional information referring to the abstract constituency.

Synopsis:

        <const ref="IDREF {IDREF}">
         ...
        </const>

Example:

        <constituency id="StuttgartUniversity">
        ...
        </constituency>
        ...
        <const ref="StuttgartUniversity"> Since the perimeter packet
        filter (PPF) of Stuttgart University blocks ssh connection
        attempts, this problem affects only systems that have an
        exception rule defined in the PPF's ACL.  However, the PPF
        does not inhibit connection attempts from within the
        networks of Stuttgart University.</const>

9.3.5. The "aff" Markup Element

The markup element "aff" is intended to provide an internal ID to the descriptions that are contained in the "body" (The "body" element) or the "rlist items" (The "rli" Element - Sub-Element to "rlist" ) elements within the "affected" (The "affected" Element), the "not-affected" (The "not-affected" Element), or the "possibly-affected" (The "affected" Element) elements. The ID acts as a reference target from within the document. This is useful if the issuer wants to provide data for scanners that are capable to automatically determine whether systems in a given IT infrastructure are vulnerable to the problem(s) described. The data used by such a scanner can be put into the "determine-affectedness" (The "determine-affectedness" Element) element that has the OPTIONAL attribute "aff-ref". This attribute is intended to reference one or multiple of the IDs that are provided by the "aff" element. This mechanism then provides the link between the definitions of affected systems, versions, as well as patch levels and the data fed into the scanner.

The element also can be used to provide unique IDs to information provided in the "solution" (The "solution" Element) or "workaround" (The "workaround" Element) elements, thus enable CAIF-processing software to automatically provide information about a possible solution. For example, if there is code provided in "determine-affectedness" (The "determine-affectedness" Element) that can be used to mechanically determine wether a given system is affected (like OVAL code (The MITRE Cooperation, “Open Vulnerability Assessment Language,” .) [14]), the careful use of the "aff" element within the "solution" element can enable CAIF-processing software to combine the results of the OVAL-processing software with the appropriate URIs to retrieve the applicable patches. Thus, automatic announcement processing may help to facilitate the administration of a system.

Note, that the attribute "id" is of type ID, thus its value MUST be unique within a document. It is not possible, to use the same ID in two occurrences of the "aff" element, e.g. one used to markup text within the "affected" element and another in "solution". Nevertheless, the element is very useful if used accurately: the author can provide one ID to tag some text in the "affected" section and another ID to tag an URL pointing to the appropriate patch. The corresponding "detitem" element (The "detitem" Element) then can reference both IDs. If the names for these IDs are chosen carefully it is easily possible to read the XML code and understand that they belong together (see the example).

Synopsis:

        <aff id="ID">
         ...
        </aff>

Example:

        <affected>
          <rlist>
            <rli problem-ref="LSASS">
              <list style="symbols">
                <li>
                <aff id=WXP>Windows XP</aff>
                </li>
                <li>
                <aff id=WXPSP1>Windows XP Service Pack 1</aff>
                </li>
            </rli>
          </rlist>
        </affected>
        ...
        <determine-affectedness>
          <detitem method="OVAL"
                   aff-ref="WXP WXP-solution"
                   content-type="base64"
                   problem-ref="LSASS">
            <body>
            ...
            </body>
         </detitem>
        <determine-affectedness>
          <detitem method="OVAL"
                   aff-ref="WXPSP1 WXPSP1-solution"
                   content-type="base64"
                   problem-ref="LSASS">
            <body>
            ...
            </body>
         </detitem>
       </determine-affectedness>
       ...
       <solution>
          <rlist>
            <rli problem-ref="LSASS">
              <list style="symbols">
                <li>
                  <aff id=WXP-solution>
                    <eref target="http://download.microsoft.com/...">
                      LSASS-Patch for XP
                    </eref>
                  </aff>
                </li>
                <li>
                  <aff id=WXPSP1-solution>
                    <eref target="http://download.microsoft.com/...">
                      LSASS-Patch for XP Service Pack 1
                    </eref>
                  </aff>
                </li>
            </rli>
          </rlist>
       </solution>

9.3.6. The "update" Element

In some cases it may be necessary to change passages in an announcement sematically, e.g. if it has been issued containing an error that the issuer wishes to correct. In such cases it is useful, if the changes made in the document can be traced back. Of course all the changes made can be documented in the "revisions" (The "revision" Element) element but such documentation within the text itself provides more accuracy.

The markup element "update" allows authors to include new text, mark text as no longer valid and finally replace invalid text with new text. The element has the REQUIRED attribute "version" that MUST be provided with the version number (see Section 13.4 (The "revision" Element)) the update refers to, i.e. in which version it has been made.

Newly included text simply is enclosed in "update" tags whereas text that shall be marked as no longer valid is enclosed in update's sub-element "invalid". If the author wants to include new text in the document without marking some text as being invalid the "invalid" element is omitted. If there shall only be text marked invalid, the "update" element only contains the "invalid" element without any extra (new) text. If text shall be replaced, "update" contains the new text whereas its sub-element "invalid" contains the text to be replaced.

Synopsis:

        <update version="n.n">
          [new text]
          [<invalid>
             text to be replaced
           </invalid>]
        </update>

Examples

1. Replacement of text by a new text. The change is valid from version 1.1 on :

        <update version="1.1">
          <p>
          Microsoft Windows Server 2003
          </p>
          <invalid>
            <p>
            Microsoft Windows 3.11
            </p>
          </invalid>
        </update>

2. Text that has been newly added in version 1.2:

        <update version="1.2">
          Turning off the <service>ToolTalk</service> service
          is highly recommended.
        </update>

3. Text that has been marked "invalid" in version 1.3:

        <update version="1.3">
          <invalid>
          The process logs into <file path="/var/log/SYSLOG"/>
          by default.
          </invalid>
        </update>

10. Document Structuring Elements

CAIF provides several elements to enable authors to structure text. Besides increasing the readability with paragraphs (The Paragraph Element "p"), there are tables (The "table" Element and its Sub-Elements "tr" and "td") and lists (Lists: The "list" Element and its Sub-Element "li"). The tables are a simplified form of the tables known from HTML, the "list" element comprises numbered, un-numbered and bulleted lists.

On top of that, CAIF documents can contain "referencing lists" (see Section 10.5 (The Refencing List "rlist")) that attach the list items to references to vulnerability IDs like CVE numbers (The MITRE Cooperation, “The Common Vulnerabilities and Exposures Project (CVE), http://www.mitre.org/cve/,” .) [12] that can be defined by the "problems" element (The "problems" Element). This mechanism allows for the addressing of more than one problem or issue in a single announcement, thus enables distributors (Section 6.7 (Distributor)) to produce several renderings of a CAIF document each addressing one of the issues described in the source document. Of course it is also possible to produce a rendering addressing all the issues at the same time - this is what the referencing list is designed for.

In web presentations, using announcements as a knowledge base, CAIF documents could be stored in a database and produce renderings on demand, depending on a request by the reader. If CAIF is used as a datastructure for a vulnerability database the "rlist" element can be used to group depending vulnerabilities.

10.1. The Paragraph Element "p"

The "p" element is similar to the equally named element in HTML; it defines a paragraph containing arbitrary markup text.

Synopsis:

        <p>...</p>

Example:

        <p>
        This is a paragraph of text.
        </p>

10.2. The "table" Element and its Sub-Elements "tr" and "td"

The "table" element is a modified form of the equally named element in HTML. It comprises of an OPTIONAL "p" element (The Paragraph Element "p") providing a preamble for the table, any number of table rows "tr" and an OPTIONAL "p" element, allowing for postambling text. Each "tr" element can contain any numbers of table data "td" elements defining the table cells. The "td" element has the OPTIONAL attributes "align" defining the alignment of the content of the cell, and "colspan" defining the columns a cell shall span. It is up to a rendering system to apply more formatting, like borders etc., to a table.

Synopsis:

        <table>
         [<p>...</p>]
          <tr>
            <td [align=(right|left|top|bottom|center)]
                [colspan="..."]
            </td>
            {<td>...</td>}
          </tr>
          {<tr>...</tr>}
         [<p>...</p>]
        </table>

Example:

        <table>
         <p> A question and its possible answers:</p>
          <tr>
            <td align="center" colspan="3">
              Want a beer?
            </td>
          <tr>
            <td>yes</td>
            <td>no</td>
            <td>perhaps</td>
           <p> Ask your tummy before you check off. </p>
          </tr>
        </table>

A rendering could look like:

         A question and its possible answers:

        +--------------------+
        |    Want a beer?    |
        +-----+----+---------+
        | yes | no | perhaps |
        +-----+----+---------+

         Ask your tummy before you check off.

Of course, renderings can reflect extra design critera of an issuer.

10.3. Lists: The "list" Element and its Sub-Element "li"

The "list" defines a list of various styles. It contains one or more list items "li" that contain the rows of a list. "list" has the OPTIONAL attribute "style". It can have the values "symbols" indicating that the list items shall be preceeded by a bullet or similar symbol, "numbers" indicating that "list" contains a numbered list, and "empty" indicating that the list items do not have a symbol or number. The "list" element has an OPTIONAL "p" element (The Paragraph Element "p") preceeding the list elements providing a preamble as well as an OPTIONAL "p" after the last "li" element for postambling text.

Synopsis:

        <list [style="(symbols|numbers|empty)">
          [<p>...</p>]
          <li>... </li>
         {<li>...</li>}
          [<p>...</p>]
        </list>

Example:

        <list style="numbers">
          <p>The following list is a "numbered" list:</p>
          <li>This is a list item </li>
          <li>This is another list item</li>
          <p>This was the "numbered" list.</p>
        </list>

A rendering could look like:

        The following list is a "numbered" list:

         1. This is a list item

         2. This is another list item

        This was the "numbered" list.

10.4. The "body" element

The "body" element contains the markup text within a section element (The Main Sections of a CAIF Announcement). Its OPTIONAL "tg-ref" attribute references one or more target groups (see Section 13.2.1 (The "target-group" Element)) the text is written for.

The OPTIONAL "headline" attribute can be used to provide a target group-specific headline to the containing section element.

Synopsis:

        <body [tg-ref="ID{ ID}"]
              [headline="..."]>
             ...
        </body>

Whenever there is no "rlist" (The Refencing List "rlist") present within a sections element (The Main Sections of a CAIF Announcement) (which occurs, when the announcement describes only a single problem or the section's content does not idividually refer to one of the multiple problems described in the annoucement) the "body" element provides the link to a target group (The "target-group" Element) for the the text contained in the section. If there are more target groups to be addressed (including the language, which is one of the aspects of a target group) there MAY be more than one "body" element present, each addessing one or more target groups.

Example:

      <context>
        <body tg-ref="admin-en"
              headline="What is SNMP?">
              <protocol>SNMP</protocol> is a protocol to
              ....
        </body>
        <body tg-ref="admin-de"
              headline="Was ist SNMP?">
              <protocol>SNMP</protocol> ist ein Protokoll zur
              ....
        </body>
      </context>

10.5. The Refencing List "rlist"

The "rlist" element describes a "referencing list". It contains one or more "referencing list items" ("rlist" see Section 10.5.4 (The "rli" Element - Sub-Element to "rlist" )).

It has an OPTIONAL "headline" attribute that can be used to provide a headline string to the containing element (The Elements Defining the Main Sections) defining a section of an announcement (The Main Sections of a CAIF Announcement) according to the target group (The "target-groups" Element) (see the "tg-ref" attribute below) the content of the rlist is written for. An "rlist" MAY reference more than one target group.

"rlist" has the OPTIONAL attribute "style" (The "style" Attribute of "rlist") which defines the look of the list items. Like the equally named attribute of "list".

The "rlist" element contains an OPTIONAL "p" element (The Paragraph Element "p") preceeding the list elements providing a preamble to the rlist items as well as an OPTIONAL "p" after the last "rli" element for postambling text.

Synopsis:

        <rlist [tg-ref="ID{ ID}"]
               [headline="..."]
               [style="(numbers|symbols|ref-text|empty)"]>
            [<p>...</p>]
            <rli>...</rli>
            {<rli>...</rli>}
            [<p>...</p>]
        </rlist>

10.5.1. The "tg-ref" Attribute of "rlist"

Sometimes it is important to issue an announcement to more than one target group of readers. For this purpose, "rlist" provides the OPTIONAL attribute "tg-ref" that references to one or more "target-group" elements (see Section 13.2.1 (The "target-group" Element)) that define the language the text is written in, the technical background and the organizational overview the intended reader has, as well as the environment the described problem occurs in (see also Section 5.3 (Announcements for Multiple Target Groups of Readers)).

10.5.2. The "headline" Attribute of "rlist"

If a section element (The Elements Defining the Main Sections) contains more than one "rlist" to provide its content in several languages or target groups, an issuer might want to provide the section headline in several languages as well. For this purpose, the "rlist" element has an OPTIONAL attribute "headline".

10.5.3. The "style" Attribute of "rlist"

"rlist" has the OPTIONAL attribute "style" which defines the look of the list items. Like the equally named attribute of "list" "style" MAY have the values "numbers", "symbols", and "empty" with the same meanings (see Section 10.3 (Lists: The "list" Element and its Sub-Element "li")). The default value, that applies if the attribute is not present, is "numbers". There is an extra value "ref-text" that indicates that the value of the problem reference(s) (The "problems" Element) the attribute "problem-ref" of the sub-element "rli" (The "rli" Element - Sub-Element to "rlist" ) points to, shall be used as the bullet symbol of the list item in a rendering.

10.5.4. The "rli" Element - Sub-Element to "rlist"

The "rli" element defines a list item of a referencing list "rlist", similar to the list item "li" (Lists: The "list" Element and its Sub-Element "li"). By the value(s) of the OPTIONAL attribute "problem-ref" a rlist item can reference one or more problem elements (The "problem" Element), that identify the problems described by the announcement uniquely. This reference provides the tool to describe more than one issue within one announcement, e.g. a cumulative patch announcement. Each of the elements defining one of the main sections (The Main Sections of a CAIF Announcement) of a CAIF announcement contains one or multiple "rlist" elements in which the "rlist items" ("rli") contain information on the section's aspects referring to one or more "problem" elements. An announcement describing more than one problem, can be rendered into several announcement renderings each describing a single problem or a sub-set of the problems if the references are set properly.

A rlist item MAY contain arbitrary markup text including all structuring markup elements, except the "rlist" element, i.e. rlists cannot be used recursively.

Synopsis:

        <rli problem-ref="ID{,ID}">
          ...
        </rli>

Example:

        <affected>
           <rlist style="ref-text"
                  tg-ref="admin-en"
                  headline="Affected Systems">
              <rli problem-ref="CAN-2004-0847">
                <list style="symbols">
                  <li>Windows 2000 Service Pack 3 and Service
                                                  Pack 4</li>
                  <li>Windows XP Service Pack 1 and Service
                                                  Pack 2</li>
                  <li>Windows Server 2003</li>
                  <li>Windows XP Tablet PC Edition</li>
                  <li>Windows XP Media Center Edition</li>
                </list>
              </rli>
              <rli problem-ref="CAN-2005-0049">
                <list style="symbols">
                  <li>Windows Server 2003 for Itanium</li>
                  <li>SharePoint Portal Server 2003</li>
                  <li>SharePoint Portal Server 2001</li>
                </list>
              </rli>
           </rlist>
        </affected>

A rendering could look like:

        Affected Systems
        ================
         CAN-2004-0847:
          o Windows 2000 Service Pack 3 and Service Pack 4
          o Windows XP Service Pack 1 and Service Pack 2
          o Windows Server 2003
          o Windows XP Tablet PC Edition
          o Windows XP Media Center Edition

         CAN-2005-0049:
          o Windows Server 2003 for Itanium
          o SharePoint Portal Server 2003
          o SharePoint Portal Server 2001

10.5.5. An "rlist"-Example

To illustrate the sophisticated structure of the referencing list the following example demonstrates its use within the "exploit" element (The sub-element "exploit-status" of "problem").

      <context>
        <rlist tg-ref="admin-employee-en"
               headline="Technical Context"
               style="ref-text">
          <p>
          This section provides information about the systems that
          are affected by the problems described as well as their
          purpose.
          </p>
          <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
          The routines to process PNG image files are used by
          various applications that are displaying images.  Besides
          several image viewers the routines are used by the
          Internet Explorer too.
          </rli>
          <rli problem-ref="CAN-2005-0057">
          The <em>Hyperlink Object Library</em> is used by various
          applications to process hyperlinks.
          </rli>
        </rlist>
        <rlist tg-ref="admin-employee-de"
               headline="Technischer Kontext"
               style="ref-text">
          <p>
          Dieser Abschnitt ent&auml;lt Information zum technischen
          Kontext in denen die betroffenen Systeme eingesetzt
          werden.
          </p>
          <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
          Die Routinen zur Verarbeitng von PNG-Dateien werden von
          verschiedenen Applikationen benutzt, die Bilder
          verarbeiten oder darstellen.  Dies ist neben verschiedenen
          Bildbetrachtungsprogrammen auch der Internet Explorer.
          </rli>
          <rli problem-ref="CAN-2005-0057">
          Die Routinen zur Verarbeitung von Hyperlinks werden von
          verschiedenen Applikationen verwendet, die Hyperlinks
          verarbeiten m&uuml;ssen.  Dies ist u.a. der Internet
          Exporer.
          </rli>
        </rlist>
        <rlist tg-ref="user-employee-en"
               headline="Technical Kontext"
               style="numbers">
          <p>
          This section provides information about the programs that
          contain the problem.  It is intended to help you
          understand, in which technical context these programs can
          be found, and decide whether you use them or not.
          </p>
          <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
          The routines to process PNG image files are used by
          applications that are displaying and processing images.
          First of all this is the Internet Explorer, but also other
          programs like image viewers.  PNG is a special image file
          format, that is often used in web pages.
          </rli>
          <rli problem-ref="CAN-2005-0057">
          Hyperlinks are used to provide references in documents
          that interactively can be used to interlink documents.
          Several Programs in Microsoft Operating Systems provide
          the possibility to browse through documents using
          so-called <em>hyperlinks</em>.  The most popular
          application is the Internet Explorer processing html
          documents that interlink with hyperlinks.
          </rli>
        </rlist>
        <rlist tg-ref="user-employee-en"
               headline="Technisches Umfeld"
               style="numbers">
          <p>
          Dieser Abschnitt stellt Information &uuml;ber das
          technische Umfeld bereit, in dem die jeweiligen
          Schwachstellen auftreten.
          </p>
          <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
          Verschiedene Programme, die Bilder darstellen oder
          verarbeiten, verwenden Funktionen, die zentral bereit
          gestellt werden.  Eine dieser zentral bereitgestellten
          Funktionen ist die Funktionsbibliothek zur verarbeitung
          sog. PNG-Bilder.  PNG ist ein besonderes Format, das
          h&auml;ufig auf Webseiten verwendet wird.
          </rli>
          <rli problem-ref="CAN-2005-0057">
          <p>
          Hyperlinks sind Querverweise, die in Dokumenten
          verschiedener Formate verwendet werden k&ouml;nnen, um
          Referenzen innerhalb oder au&szlig;erhalb des Dokumentes
          zu setzen.  Diverse Programme sind in der Lage, diese
          Referenzen zu verarbeiten.  Bekanntester Vertreter ist der
          Internet Explorer.
          </p>
          <p>
          Die Routinen zur Verarbeitung von Hyperlinks werden
          zentral bereitgestelly um von den verschiedenen
          Applikationen verwendet werden zu k&ouml;nnen.
          </p>
          </rli>
        </rlist>

11. The Announcement: The Top-Level-Element "caif"

The "caif" element is the top-level element of an announcement, enclosing the complete CAIF document. Its start tag immediately follows the XML declarations and its end tag is the final string in a document. This element is REQUIRED in an announcement.

Synopsis:

   XML-Declarations
   <caif>
     <identification>...</identification>
     {<target-groups>...</target-groups>}
     {<constituencies>...</constituencies>}
     <revisions>...</revisions>
     <category>...</category>
     <subject>...</subject>
     <summary>...</summary>
     [<problems>...</problems>]
     [<affected>...</affected>]
     [<not-affected>...</not-affected>]
     [<possibly-affected>...</possibly-affected>]
     [<determine-affectedness>...</determine-affectedness>]
     [<mitigation>...</mitigation>]
     [<context>...</context>]
     [<description>...</description>]
     [<workaround>...</workaround>]
     [<solution>...</solution>]
     {<arbitrary>...</arbitrary>}
     [<bibliography>...</bibliography>]
     [<credits>...</credits>]
     [<disclaimer>...</disclaimer>]
     [<other-documents>...</other-documents>]
     [<rendered-copies>...</rendered-copies>]
   </caif>

Example:

     <?xml version="1.0" encoding="ISO-8859-1"?>
     <!DOCTYPE caif  SYSTEM "-//DTD Common Announcement
     Interchange Format//EN"
     "http://www.caif.info/dtd/caif.dtd">

     <caif>

       ...the document...

     </caif>

12. REQUIRED Elements in a CAIF Announcement

As one can see in the synopsis for the syntax of the "caif" element (The Announcement: The Top-Level-Element "caif"), the following elements (The Elements Defining the Main Sections) are REQUIRED in an announcements:

• "identification" (The "identification" Element and its Sub-Elements)
• "revisions" (The "revision" Element)
• "category" (The "category" Element)
• "subject" (The "subject" Element)
• "summary" (The "summary" Element)

including their sub-elements.

This very small set of mandatory elements provides a maximum of flexibility when using CAIF as the format of choice for arbitrary announcements or as a structure for databases.

13. The Elements Defining the Main Sections

This section describes all the elements the CAIF DTD provides; the syntax and the purpose are explained. It is a preamble to the DTD in Appendix C (The Document Type Definition (DTD) of CAIF).

13.1. The "identification" Element and its Sub-Elements

The "identification" element contains several other elements that provide information to uniquely identify the document. It does not enclose any text.

The REQUIRED "issuer" element (The "issuer" Element) contains information about the issuer of the announcement, the REQUIRED "announcement" element (The "announcement" Element) provides a unique id to identify the document, and the "type" element (The "type" Element) categorizes the various aspects of the type of the announcement.

The OPTIONAL "author" element (The "author" Element) contains name, initials, and e-mail address of the author. Since an announcement may have more than one author, this element MAY occur multiple times.

The empty element "distribution-allowed" defines to which constituences (The "constituency" element ) the annoucement may be distributed. Its "const-ref" attribute contains the IDs that identify these cosntituencies. The element "earliest-release" contains a string describing the date before an announcement should not be published. It can be used in different ways according a local policy.

Overall Synopsis:

        <identification>
          <issuer>...</issuer>
          <announcement>...</announcement>
          <type>...</type>
          <author>...</author>
          {<author>...</author>}
          [<distribution-allowed/>]
          [<earliest-release>...</earliest-release>]
        </identification>

The sub-elements to "identification"

The element "identification" is REQUIRED in a CAIF announcement.

13.1.1. The "issuer" Element

The "issuer" element contains the name of the issuer of the announcement (Section 6.4 (Issuer)). The element has a REQUIRED attribute "id" which MUST have the unique id of the issuer as its value. A good coice for such an id is the abbreviation of the issuing organization. It is not in the scope of this document to provide a system or repository for unique issuer ids. The Forum of Incident Response and Security Teams (FIRST (FIRST, “The Forum of Incident Response and Security Teams, http://www.first.org/,” 1995.) [10]) provides a database containig their member organisations, thus would make a good source of such ids. This element is REQUIRED in a CAIF announcement.

Synopsis:

        <issuer id="ID">
          Name of the issuer
        </issuer>

Example:

        <issuer id="RUS-CERT">
          Stuttgart University Computer Emergency Response Team
        </issuer>

The "issuer" element is a sub-element to "identification". It MUST NOT occur multiple times within its superior element.

13.1.2. The "announcement" Element

This is an empty element identifying the announcement by a number or string unique to the issuers own announcement identification system. Such could be a simple number or a complex id composed from varoious data important to the issuer. This element is REQUIRED to a CAIF announcement.

Synopsis:

        <announcement id="ID"/>

Example:

        <announcement id="1155"/>

Processing software MAY combine the "issuer" and the "announcement" to a string that identifies the announcement uniquely to the world, e.g. "RUS-CERT-Announcement#1155". The reason to provide two elements for this purpose is the fact that no uniform identification scheme for announcements has evolved yet. Providing the mechanism described above, CAIF allows to flexibly achieve this necessary requirement without forcing an issuer to adapt to a specific scheme.

The "announcement" element is a sub-element to "identification". It MUST NOT occur multiple times within its superior element.

13.1.3. The "type" Element

This element classifies the announcement. It has three pre-defined attributes to describe some main aspects of the document: "urgency", "level", and "flavor".

Depending on the problem the announcement addresses, its "urgency" attribute describes the urgency to take action to solve the problem or mitigate it.

"alert"

-- The announcement provides information about an issue that imposes an immediate and severe threat upon affected infrastructure and requires immediate action by operators of such. It also provides information about the - possibly temporary - solution of the causing problem, i.e. at least a workaround (The "workaround" Element) SHOULD be supplied.

"warning"

-- The announcement provides information about an issue that imposes a potentially severe threat on affected infrastructure and requires early action by operators of such. It also provides information about the - possibly temporary - solution of the causing problem.

"advisory"

-- The announcement provides information about an issue that imposes a potential threat upon affected infrastructure and advises action to operators of such. Such could be a theoretical problem which is hard to exploit and therefore does not impose an acute threat. Note that this state may change over time. The announcement also provides information about the - possibly temporary - solution of the causing problem.

"informational"

-- The announcement provides background or general information about a security issue. For example such could be a background article about a structural problem of a technical system or procedure or the effects of a specific policy.

The attribute "level" describes the quality of the information provided by the announcement in terms of its particularity. It has the following pre-defined values:

"brief"

-- The announcement provides brief information about a security issue. Usually such a document is no fully qualified announcement but rather a short description of an issue accompanied by references to documents describing the issue in greater detail. However, the required (REQUIRED Elements in a CAIF Announcement) elements have to be present in such an document. If an announcement is "brief" the "summary" (The "summary" Element) SHOULD be more exhaustive than in an annoucement of the other levels, and then MAY replace the "description" element (The "description" Element). This level also can be used, if CAIF is used as a datastructure in a "vulnerability database". An entry of such a database at least has the minimum set of the REQUIRED elements (The Elements Defining the Main Sections) and can be used as a basis for a fully featured announcement. Note, that a database containing CAIF announcements describing vulnerabilities is a vulnerability database as a side effect.

"full"

-- The announcement is a fully qualified CAIF document, providing all or a substantial sub-set of the informative sections (The Main Sections of a CAIF Announcement).

"digest"

-- The announcement provides information about more than one issue. Usually such documents are issued to announce cumulative patches or a patch cluster.

"other"

-- The announcement's quality does not fit into one of the above categories. This is the default value if the attribute is not present.

In a reissue (The "re-issued" Element) of a document, an announcement can change its urgency as well as its level if appropriate. e.g. an "advisory" that has addressed a problem in "brief" can be converted into a fully featured announcement and be made an "alert" if necessary.

The attribute "flavor" describes the quality of the announcement in terms of the solution available. It has the following pre-defined values:

"vulnerability-description"

-- The announcement mainly provides information about a problem but no patch from the vendor of the affected product. It rather provides information about one or more workarounds or temporary solutions. Such announcements eventually can be followed by a patch announcement (see next bullet) which provides a final solution to the problem.

"patch-notification"

-- The announcement provides information about the problem and its final solution. Such could be a patch or a new release of the affected product. A special configuration or the termination of an affected service does not qualify as a "patch-notification".

"heads-up"

-- The announcement is neither describing a known vulnerability nor a patch but rather a an issue that requires the reader to raise attention on some special activity or circumstances. Such an issue could be the suspicion that there is a yet unknown vulnerability raised for example by scans that cannot be attached to a known prablem that the scanner might want to exploit. Hence, readers should put their "heads up" to watch out for these scans and try to find out what it is all about.

"other"

-- All announcements that do not match one of the flavors described above. This is the default value if the attribute is not present.

Besides the attributes, the element MAY contain a textual description of the type within one or more "body" elements (The "body" element) that also provide a title string depending on the target group (The "target-group" Element) they refer to.

Synopsis:

        <type
        [urgency="(alert|warning|advisory|informational")]
        [level="(brief|digest|other)"]
        [flavor="(vulnerability-description|
                         patch-notification|
                         other)"]>
          <body
            ...
          </body>
          {<body
            ...
          </body>}
        </type>

Example:

        <type urgency="warning"
              level="digest"
              flavor="patch-notification">
          <body headline="Type of the Announcement"
                tg-ref="en-admin">
            Cumulative Patch Announcement
          </body>
          <body headline="Typ der Meldung" tg-ref="de-admin">
            Sammelpatchmeldung
          </body>
        </type>

The "type" element is a sub-element to "identification" and MAY contain markup text. The element is REQUIRED in a CAIF announcement and MUST occur a single time within its superior element. The attributes MAY be omitted in order to provide the pre-defined values "other" for "level" and "flavor". Note, that there is no pre-defined value for the "urgency" attribute. In case of this it is recommended to provide a textual description in the element. This makes a basic classification of the document possible.

13.1.4. The "author" Element

The "author" element identifies an author of the announcement. Since an announcement can have more than one author, the element MAY be present multiple times. It has three OPTIONAL attributes:

"initials"

- This attribute contains the grammalogue of the fullname of the author.

"name"

- This attribute contains the full name of the author including all titles.

"e-mail"

- This attribute contains an e-mail URI or e-mail address.

Synopsis:

        <author
          [initials="..."]
          [name="..."]
          [e-mail="..."]>
          ...
        </author>

Example:

        <author initials="og"
                name="Dipl.-Inform. Oliver Goebel"
                e-mail="mailto:goebel@caif.info">
          Oliver Goebel
        </author>

The "author" element is a sub-element to "identification". It can only occur within its superior element.

13.1.5. The "distribution-allowed" Element

The OPTIONAL empty element "distribution-allowed" is intended to define to whom an annoucement may be distributed. Some issuers may not want that renderings or the XML-source of an announcement is given to outsiders. Hence the intention of the issuer MUST be declared to processing software and people handling the document.

The REQUIRED attribute "const-ref" contains the IDs of the constituencies (The "constituency" element ) to which the distribution of the announcement is allowed.

If "distribution-allowed" is not present in an announcement, no restrictions apply to its distribution.

Synopsis:

        <distribution-allowed const-ref="IDREF {IDREF}"/>

Example:

        <distribution-allowed
                 const-ref="StuttgartUniversity example.com"/>

The "distribution-allowed" element is a sub-element to "identification". It can only occur within its superior element.

13.1.6. The "earliest-release" Element

The element "earliest-release" contains a string describing the date before an announcement should not be published. It can be used in different ways according a local policy. For example, if the issuer is member of a community that is producing announcement co-operatively, the element can be used to keep the document from being released into the public early when it is shared within the community. It SHOULD be interpreted by processing software.

The element has an attribute "date" that contains the date in ISO format. The element MAY contain non-markup text for additional explanation.

Synopsis:

        <earliest-release date="YYYY-MM-DD [hh:mm:ss(+|-)hh]">
        ...
        </earliest-release>

Example:

        <earliest-release date="2004-10-21">
        The vendor will release a patch on 2004-10-21.
        </earliest-release>

13.1.7. The Overall Syntax and an Overall Example for the "identification" Element

Containing all its sub-elements the element "identification" has the following syntax:

Overall Synopsis:

        <identification>
          <issuer>...</issuer>
          <announcement>...</announcement>
          <type>...</type>
          <author>...</author>
          {<author>...</author>}
          [<distribution-allowd const-ref="IDREF {IDREF}">]
          [<earliest-release>...</earliest-release>]
        </identification>

The following example illustrates the syntax of the "identification" element and its sub-elements.

Overall example:

        <identification>
          <issuer id="RUS-CERT">
            Stuttgart University Computer Emergency Response Team
          </issuer>
          <announcement id=1155/>
          <type level="digest" flavor="patch-notification">
            Cumulative Patch Announcement
          </type>
          <author initials="og"
                  name="Oliver Goebel"
                  e-mail="mailto:Goebel@CERT.Uni-Stuttgart.DE">
            Oliver Goebel, RUS-CERT, Stuttgart University
          </author>
          <distribution-allowed
                  const-ref="StuttgartUniversity example.com"/>
        </identification>

13.2. The "target-groups" Element

The "target-groups" element contains one or more "target-group" elements each providing the reference data for a specific target group of readers. The "target-groups" element does not contain any textual descriptions or attributes.

This element is OPTIONAL in an announcement

Synopsis:

        <target-groups>
          <target-group>
          ...
          </target-group>
         {<target-group>
          ...
          </target-group>}
        </target-groups>

13.2.1. The "target-group" Element

The "target-group" element contains information about the target group of readers the announcement addresses.

It contains markup text and is intended to provide an answer to the question "Who should read this document?". The answer SHOULD be verbose in order to give an explanation or extension to the value of the OPTIONAL "tech-background", "orga-overview", and "environment" attributes (see below).

The "target-group" element is a sub-element to "target-groups" and MUST NOT occur outside its superior element.

13.2.1.1. The Attributes of the element "target-group"

The element "target-group" features the following attributes:

"id"

-- Each "target-group" element has a REQUIRED "id" attribute that provides a unique identifier for the target group. It is recommended to use self-explanatory values for this attribute which reflect all the aspects (provided by the other attributes) like the language, the technical background, and the environment. Such a name could be a value like 'en-admin-mgmt-PMS' indicating that the referenced target group are members of the middle management having an system administrative technical background. It also indicates, that the textual descriptions given in the referencing "body" (The "body" element) and "rlist" (The Refencing List "rlist") elements within the sections (The Main Sections of a CAIF Announcement) of the announcement provide information on the problems within the context of the 'PMS' (Personnel Management System see example below) software suite.

"lang"

-- The REQUIRED attribute "lang" contains a two-letter language code to identify the language of the target group.

"tech-background"

-- The attribute "tech-background" categorizes the assumed technical abilities of the members of the target group. When writing contents in an announcement this is an important aspect. For example, if it comes to applying a workaround (Information about a Possible Solution) it is essential to provide enough information to the reader so that she is able to execute the necessary steps. Usually a system administrator who is familiar with the affected system needs less or differently detailed information than an ordinary user. The "tech-background" attribute may have the following values:

• "admin"
• "user"
• "developer"

The value "admin" indicates that the reader has an average technical knowledge of a system administrator. This is the default value if the attribute is omitted. The value "user" indicates that the reader only has technical knowledge and abilities of a user of the affected system(s). Finally the value "developer" indicates that the reader has the profund technical background knowledge of a system developer.

"orga-overview"

-- The "orga-overview" attribute provides information on the organizational overview a member of the intended target group has within the organization an affected system is used. An normal employee usually has less organizational overview than a member of the management, thus the information given within sections to the latter probably differs from the bare technical facts. For example: if a system is affected that is vital for web-based sales, a manager responsible for sales might want to know how the problem described in an announcement affects the web-services essential for his scope of responsibility. The "orga-overview" attribute may have the following values:

• "employee"
• "middle-management"
• "senior-management"

"environment"

-- The value of the "environment" attribute indicates the context in which the affected system is used. For example the context could be a software suite like a personnel management system (PMS) in which the affected ware is a component. Such could be an application like a web-server or the underlying operating system that is certified for a special version and patch-level by the manufacturer of the suite. In many cases it is a hard job for the administrator of the suite or the hosting computer system(s) to decide whether the countermeasures described in an announcement can be applied and which effects they may have on the suite. Defining a target group having this aspect allows issuers to provide such information. There are no pre-defined values for "environment".

"headline"

-- a headline string to the "target-group" can be defined in the OPTIONAL "headline" attribute.

The "target-groups" element and its "target-group" sub-elements have a similar architecture like the "problems" element (The "problems" Element) and its "problem" (The "problem" Element) sub-elements. Like "problem" the element "target-group" provides all necessary information about a target group as well as an ID that may be referenced from within the several sections (The Main Sections of a CAIF Announcement) of the announcement. The information is being provided in a normalized way.

Synopsis:

        <target-group id="ID"
                      lang="LANG_CODE"
                      [tech-background="(admin|user|developer)]"
                      [orga-overview="(employee|
                                      middle-management|
                                      senior-management)]
                      [environment="..."]
                      [headline="..."]>
        ...
        </target-group>

Example:

        <target-group id="en-admin-mgmt-PMS"
                      lang="en"
                      tech-background="admin"
                      orga-overview="middle-management"
                      environment="PMS"
                      headline="Who should Read this Document">
           Members of the middle-management with system administrator
           background responsible for running the PMS Personnel
           Management System should read this document.
        </target-group>

13.3. The "constituencies" Element

The OPTIONAL "constituencies" element implements the "constituency" section (Constituencies). It contains one or more "constituency" elements (see below: Section 13.3.1 (The "constituency" element )) that actually describe the different constituencies (Constituency) to which the several constituency-specific elements refer (Section 9.3.4 (The "const" Markup Element), Section 13.8.1.8 (The sub-element "probability-of-occurrence" of "problem"), Section 13.8.1.9 (The sub-element "threat" of "problem")). The "constituencies" element contains no text.

Synopsis:

        <constituencies>
          <constituency>
            ...
          </constituency>
          {<constituency>
            ...
          </constituency>}
        </constituencies>

13.3.1. The "constituency" element

The "constituency" element is the only sub-element of "constituencies" (The "constituencies" Element)

The element is intended to contain the description of a specific constituency. A constituency is a concrete IT infrastructure and its users. If issuers produce announcements for more than one constituency or if their overall constituency MUST be split up into several parts these entities can be described in seperate "constituency" elements. The element has the REQUIRED "id" attribute that uniquely identifies the constituency described to the document. This id can be used by the markup element "const" (The "const" Markup Element) as well as the elements "probability-of-occurrence" (The sub-element "probability-of-occurrence" of "problem") and "threat" (The sub-element "threat" of "problem") to refer to a specific constituency (Constituency), as their content is intentionally constituency-specific. Since the "const" element MAY occur in every place that allows markup text, it is possible to add constituency-specific information to almost all sections that provide some content for readers. The constituency specific contents may be removed before an announcement is interchanged if the issuer does not want them to be distributed.

In some cases it may be useful to define abstract constituencies that have several technical characteristics like enabled features of affected systems (Section 8.8 (Affected and Not Affected)). The "const" markup then can be used to enclose text passages that reference to the specific characteristics.

The description of the IT infrastructure and its users is provided by one or more "body" elements (The "body" element) specifically to the target group (The "target-group" Element) that is referenced by its "tg-ref" attribute. If the announcement is multi-lingual or addresses more than one target group, the "body" element MAY occur multiple times in "constituency" with different values for its "tg-ref" attribute.

Synopsis:

        <constituency id="ID">
          <body>
            ...
          </body>
          {<body>
            ...
          </body>}
        </constituency>

Example:

        <constituency id="StuttgartUniversity">
          <body tg-ref="en-admin en-user">
           The Constituency of Stuttgart University compriises all
           computer systems within the network segments
           129.69.0.0./24, 141.58.0.0./24, ...
          </body>
        </constituency>
        <constituency id="Windows Domain">
          <body tg-ref="en-admin en-user">
          This abstract constituency describes a standard
          installation of a Microsoft domain. The configuration
          has the following characteristics: ...
          </body>
        </constituency>

13.4. The "revision" Element

The "revisions" element too is a meta element that contains several sub-elements providing a history of the revisions and possible re-issues of the announcement. CAIF distiguishes between two forms of version changes of an announcement, the revision and the re-issue. While a revision is a change that does not alter the main aspects of an announcement in terms of risk or threat that would require a renewed emission of the document to the constituency (Constituency) including the information on the changed quality of the problem described in it, a re-issue of the document is exactly such a change thus requiring the re-emission (re-issuing) of the document.

This element has an OPTIONAL "body" element (The "body" element) that provides a title string to the section definded by "revisions". If the announcement is multi-lingual or addresses more than one target group, the "body" element MAY occur several times in "revisions" with different values for its "tg-ref" attribute. The different instances of "body" contain the target group-specific title strings and textual descriptions for the whole section.

Besides the OPTIONAL "body" elements "revisons" has three more sub-elements: the REQUIRED "issued" element providing the data of the initial issue of the document, one or more "re-issued" elements providing information on eventual re-issuings and "revision" providing the data of revisions of the announcement.

Synopsis:

        <revisions>
          {<body>...</body>}
          <issued>...</issued>
          {<re-issued>...</re-issued>}
          {<revision>...</revision>}
        </revisions>

The element "revisions" and its sub-elements

The "update" markup element (Section 9.3.6 (The "update" Element) can be used to markup changes within the document. Its "version" attribute references to the value of the "version" attribute of one of the element's "re-issued" or "revision" sub-elements.

13.4.1. The "issued" Element

The empty element "issued" identifies the date and version of the first issue of the announcement. The element has two attributes "date" and "version" to provide this data:

date

-- The date SHALL have ISO format: YYYY-MM-DD {hh:mm:ss[+|-]hh}.

version

-- The version SHALL be noted in a two-part number separated by a dot. Since the first part of the version number refers to the issue, this is usually a '1'. The second figure refers to the "revision" (The "revision" Element) of the announcement, usually a '0' in the initial issue. Consequently the attribute "version" usually has the value "1.0".

Synopsis:

        <issued version="1.0" date="YYYY-MM-DD [hh:mm:ss(+|-)hh]"/>

Example:

        <issued version="1.0" date="2003-10-20"/>

The "issued" element is a sub-element to "revisions". It MUST NOT occur multiple times within its superior element.

13.4.2. The "re-issued" Element

The element "re-issued" is introduced into an announcement, if the document has to be re-issued because some important aspects of the problem described have been subject to major changes. Such could be a re-estimation of the threat imposed by the problem or the publiation of exploit code.

The element is very similar to the element "issued" (The "issued" Element), it too has the attributes "version" and "date" as well as a third attribute "reason" with a set of pre-defined values:

"exploit"

-- This "reason" documents the publication of exploit code (The sub-element "exploit-status" of "problem"). If the problem described in the announcement has a more theoretical nature, the publication of working expoit code is a major change of the situation and indicates a re-issue of the announcement.

"risk"

-- This value is provided if the estimation of the risk potential of the problem described has changed.

"patch"

-- "reason" has the value "patch" if an announcement is re-issued because a patch for the - usually highly threatening - problem described has been published.

"other"

-- All other reasons. Details SHOULD be given in the text part of the element.

Each re-issuing of the announcement MUST result in an increment of the first figure of the version number of the attribute "version", e.g. the first re-issue has the version number "2.0" the second "3.0" and so on. The second figure indicates the revision (The "revision" Element) of the announcement.

The element is not empty, it SHOULD contain information about the changes that have been made since the last issue as well as details about the reason for the re-issuing. This content as well a title string to the sub-section defined by "re-issued" is provided target group-specificly by one or more "body" (The "body" element) elements.

Synopsis:

        <re-issued version="n.n"
                   date="YYYY-MM-DD [hh:mm:ss(+|-)hh]"
                   [reason="(exploit|risk|patch|other)"]>
          <body>
          ...
          </body>
        </re-issued>

Example:

        <re-issued version="2.0"
                   date="2003-10-25 13:17:23+02"
                   reason="exploit">
          <body tg-ref="en-admin-employee">
          Exploit code has been published.
          </body>
        </re-issued>

Note, that the "headline" attribute if the "body" element is OPTIONAL.

The "re-issued" element is a sub-element to "revisions". It can only occur within its superior element. Each re-issuing of the announcement is documented in an own instance of this element.

13.4.3. The "revision" Element

The element "revision" documents the date and changes made in an announcement done in a revision. A revision does not change the main qualities of the annoucement in a way that a reissue becomes necessary.

The element has two attributes "date" and "version" to provide this data:

date

-- The date SHALL have ISO format: YYYY-MM-DD {hh:mm:ss[+|-]hh}.

version

-- The version SHALL be noted in a two-part number separated by a dot. The first figure of the version number refers to the "issue" (The "issued" Element) of the announcement. A revision changes the second figure of the version number, subsequent to the first figure which is changed whenever the announcement is re-issued (The "re-issued" Element). In this event the second figure is reset to zero.

The changes that have been made since the last revision or issue as well as details about the reason for the revision as well as an OPTIONAL title string to the sub-section is given within one or more "body" elements (The "body" element). Each of these "body" elements refer to a specific target group and its aspects.

Synopsis:

        <revision version="n.n"
                  date="YYYY-MM-DD [hh:mm:ss(+|-)hh]">
          <body>
           ...
          </body>
        </revision>

Example:

        <revision version="1.1" date="2003-10-22">
          <body>
          Reference to background article added
          </body>
        </revision>

Note that the "tg-ref" attribute of the "body" element is OPTIONAL.

The "revision" element is a sub-element to "revisions". It can only occur within its superior element. Each revision of the announcement is documented in an own instance of this element.

13.5. The "category" Element

The empty element "category" provides data to categorize an announcement in coarse way. Of course all meta data can be used to categorize an announcement if processed by software. However according to our experience a general categorization done by the issuer that is constant to the document (i.e. the categorization is the same for each language and target group) and easy to read (few but prominent aspects) increases the usability of an announcement vastly.

The element "category" has three attributes "platform", "product", and "protocol" for three main aspects of the announcement. The attribute "platform" is REQUIRED and therefore MUST be present, whereas the other attributes are OPTIONAL.

Synopsis:

        <category platform="..." [product="..."] [protocol="..."]/>

The attributes have the following meanings:

platform

-- This attibute is used to describe the platform affected by the problem treated by the announcement. This could be an operating system or an operating system family (e.g. Microsoft Windows) or a more general issue like "cryptography" or "Software Patents". A special value is "Generic" that can be used as a bridge over more than one platforms in combination with one or both of the other attributes (see the following two sections), e.g.

Example:

        <category platform="Generic"
                  product="sendmail"
                  protocol="SMTP"/>

More than one value per attribute can be provided separated by space characters.

product

-- This attibute is used to describe the product affected by the problem addressed by the announcement. This could be a single program, a program family or a product that can be used on many platforms. In the latter case, it may be useful to combine it with a 'platform="Generic"'.

Example:

       <category platform="Generic" product="Mozilla">

protocol

-- This attribute describes a protocol that is either involved in the problem, e.g. provides the attack vector (The sub-element "attack-vector" of "problem"), is implemented incorrectly, or has a design flaw itself.

Example:

       <category platform="Generic" protocol="H.323">

There are several activities to produce categorization-trees for products, version numbers and other data to uniquely identify systems. Since a unique categorization-scheme is extremely dependent to the various vendors, CAIF does not provide a standardized product-tree, although such trees and categorizing taxonomies from other sources may be used.

13.6. The "subject" Element

The "subject" element implements the subject line (The Subject of the Announcement) (i.e. the overall title) of an announcement. It contains at least one "body" element (The "body" element) hat MAY provide a title string to the section definded by "subject". If the announcement is multi-lingual or addresses more than one target group, the "body" element MAY occur multiple times in "subject" with different values for its "tg-ref" attribute. The different instances of body contain the target group-specific title strings and subject strings. It is recommended, that this string does not contain any markup but a plain text string with a preferred length of no more than 72 characters (according to RFC2822, see [4] (, “Internet Message Format,” 04 2001.)) to avaoid information loss or reader inconvenience when used as a subject line of an e-mail message.

This element is REQUIRED in an announcement.

Synopsis:

        <subject>
          <body>
          ...
          </body>
        </subject>

Example:

        <subject>
          <body tg-ref="en-admin">
          Several Flaws in different H.323 Implementations
          </body>
        </subject>

13.7. The "summary" Element

This element contains an abstract of the announcement in markup text. A summary SHOULD address the issue described briefly but comprehensively. If an announcement has the level "brief" (The "type" Element) the summary SHOULD be more exhaustive since it then MAY replace the "description" element (The "description" Element).

The content of the "summary" element is provided target group-secificly by one or more "body" elements (The "body" element) that also MAY provide a title string to the section definded by "subject". If the announcement is multi-lingual or addresses more than one target group, the "body" element MAY occur multiple times in "subject" with different values for its "tg-ref" attribute.

This element is REQUIRED in an announcement.

Since the "summary" element does not contain an "rlist" element it has the OPTIONAL attribute "who", similar to "rlist" (The Refencing List "rlist") to allow for the provison of different subject lines to different target groups of readers.

Synopsis:

        <summary>
          <body>
           ...
          </body>
          {<body>
           ...
          </body>}
        </summary>

Example:

        <summary>
          <body tg-ref="en-admin-mgmt"
                headline="In Short">
          A buffer overflow bug in many implementations of the
          <protocol>H.323</protocol> protocol allows an attacker
          to execute arbitray code on affected systems. The
          <protocol>H.323</protocol> protocol is used by
          multimedia products like video-conferencing software
          or IP-telephony implementations.
          </body>
          <body tg-ref="de-admin-mgmt"
                headline="Zusammenfassung">
          Eine Pufferüberlaufschwachstelle in vielen
          Implementierungen des
          <protocol>H.323</protocol>-Protokolls erlaubt
          Angreifern beliebigen Programmcode auf gegen diese
          Schwachstelle verwundbare Systemen auszuführen. Das
          <protocol>H.323</protocol>-Protokoll wird von
          Multimediaanwendungen wie Videokonferenz- oder
          IP-Telefonie-Software verwendet.
          </body>
        </summary>

13.8. The "problems" Element

This element groups references to the described problems, like CVE and CAN Numbers (The MITRE Cooperation, “The Common Vulnerabilities and Exposures Project (CVE), http://www.mitre.org/cve/,” .) [12], or bug IDs of the various product vendors and vulnerability IDs. It has one or more "problem" sub-elements (The "problem" Element) each grouping the IDs referring to and the several aspects of a single problem. exposure, or vulnerability.

This element is OPTIONAL in an announcement.

Synopsis:

        <problems>
          {<body>...</body>}
          <problem>
            ...
          </problem>
          {<problem>
            ...
          </problem>}
        <problems>

13.8.1. The "problem" Element

The "problem" element is the only sub-element of "problems" (The "problems" Element).

This element MAY appear multiple times within its superior element "problems". Each instance contains one or more references identifying *one* vulnerability, exposure, or problem. The OPTIONAL attribute "id" contains an internal-to-document ID, that is referenced by the "problem-ref" attribute of the "rlist items" (The "rli" Element - Sub-Element to "rlist" ) in the section elements (The Elements Defining the Main Sections). This is especially useful if multiple problems are adressed by the announcement.

Rendering the XML announcement can produce one document addressing all problems described or several documents each addressing one problem, e.g. if information regarding a specific problem is requested via a web portal such could be rendered on the fly.

The "problem" element contains at least one "body" element (The "body" element). This element contains markup text describing the problem, vulnerability, or exposure as verbose as the issuer and the the specific target group require. If the announcement addresses more than one target group, the "body" element MAY occur several times in "problem" with different values for its "tg-ref" attribute each referring to a specific target group (The "target-group" Element). The different instances of body then contain the target group-specific textual descriptions, e.g. different language versions or several versions for readers with a different technical background or organizational overview.

Since all problem-specific elements within a CAIF-document may contain references to problems it is possible to produce renderings that provide a view that is triggered from a non problem-specific aspect. For example: it is possible to render a document that answers the question "Which problems apply to operating system XY". When parsing the document the parser would use all the "problem-ref" attributes of the "rli" elements (Section 10.5.4 (The "rli" Element - Sub-Element to "rlist" )) that describe operating system XY, to collect all the other "rli" elements that refer to the same "problem" elements.

The "problem" element has several sub elements containing information about aspects of the problem.

13.8.1.1. The sub-element "class" of "problem"

For characterization and statistical reasons this element contains information to classify the problem in terms of its cause. The knowledge of the principle of a problem usually is valuable information, when taking countermeasures.

It MAY contain one or more body elements (The "body" element) that contain a target group specific (The "target-group" Element) textual description.

The "class" element has the OPTIONAL attribute "key" that may contain a standard value to easen the classification and its use in statistics. CAIF provides the following standard classifications:

• "buffer-overflow-bug"
• "format-string-bug"
• "insecure-configuration"
• "insecure-defaults"
• "design-flaw"
• "implementation-flaw"
• "malware"
• "other"

The value "other" is the default, if the attribute is omitted. The meaning of the values are described in Detail in Appendix B.2.1 (The Keyset for the "key" Attribute of the "class" Element).

Synopsis:

        <class [key="(
                      buffer-overflow-bug   |
                      format-string-bug     |
                      insecure-configuration|
                      insecure-defaults     |
                      design-flaw           |
                      implementation-flaw   |
                      malware               |
                      other
                      )"]>
          {<body>
            ...
          </body>}
        </class>

Example:

        <class key="malware">
          <body tg-ref="en-admin">
          irc-bot
          </body>
        </class>

13.8.1.2. The sub-element "attack-vector" of "problem"

This element is intended to provide information about the path that can be used to exploit the problem and successfully attack an affected system (The "affected" Element). Such could be a specially crafted tcp packet to a port if the problem is in software that provides a network service or an email message containing the exploiting malware if it is a worm.

Such information is valuable for network administrators and security teams if they want to take emergency measures to protect their constituency (Constituency) from a severe threat, e.g. the blocking of port 22, if there was a severe flaw in ssh.

It contains one or more body elements (The "body" element) that each contain the information within a target group specific (The "target-group" Element) textual description.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

Synopsis:

        <attack-vector>
          <body>
            ...
          </body>
          {<body>
            ...
          </body>}
        </attack-vector>

Example:

        <attack-vector>
          <body tg-ref="en-admin">
          ssh-packet to port 22/tcp, or any other port on which sshd
          awaits connection attempts, depending on
          the configuration of sshd.
          </body>
        </attack-vector>

13.8.1.3. The sub-element "attack-requirements" of "problem"

This element provides information about the pre-requisites an attacker would need to successfully exploit the problem that is referenced by the containing problem element (The "problem" Element).

The "attack-requirements" element contains one or multiple body elements (The "body" element) that each contain the information within a target group specific (The "target-group" Element) textual description.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

The element's OPTIONAL attribute "key" provides some standard requirements an attacker needs to successfully attack an affected system (The "affected" Element) by exploiting the referenced problem, vulnerability, or exposure, and achieve the impact described within the "impact" element (The sub-element "impact" of "problem") which is also a sub-element of "problem". The "attack-requirements" element has the OPTIONAL attribute "key" that may contain a standard value describing attack requirements. CAIF provides the following standard types of attack requirements:

• "local"
• "network-group"
• "null-session"
• "broadcast-domain"
• "application-user"
• "remote"

If none of these values apply, the "key" attribute MAY be omitted or the value "other" can be provided. Both possibilities have the same effect since "other" is the default value. The set of values is described in Detail in Appendix B.2.2 (The Set of Pre-Defined Values for the "key" Attribute of the "attack-requirements" element).

Synopsis:

        <attack-requirements [key="(
                      local           |
                      network-group   |
                      null-session    |
                      broadcast-domain|
                      application-user|
                      remote          |
                      other
                      )"]>
          <body>
            ...
          </body>
          {<body>
            ...
          </body>}
        </attack-requirements>

Example:

        <attack-requirements key="remote" >
          <body tg-ref="en-admin">
          The attacker MUST have  access a network that is routing
          packets to the affected system.
          </body>
        </subject>

13.8.1.4. The sub-element "attack-signature" of "problem"

The "attack-signature" element is intended to provide information about the traces a try to exploit the problem or a successful attack leave. Such could be a log file entry, special network traffic or strange behavior. The element can also be used to provide fully featured attack signatures that can be fed into intrusion detection systems (IDS).

The OPTIONAL attribute "type" allows to provide some additional information to the parser. This is useful, if the issuer includes signatures for an IDS -- e.g. snort -- and wants the parser to extract and automatically feed them in the IDS. In this case, the attribute could have the value "snort" to indicate that the data included in the element is ready to be fed into the system.

It contains one or multiple body elements (The "body" element) that each contain the information within a target group specific (The "target-group" Element) textual description.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

The element "attack-signature" is OPTIONAL within its containing element problem (The "problem" Element).

13.8.1.5. The sub-element "impact" of "problem"

This element is intended to provide information about the effects a sucessful exploit of the problem has on the vulnerable system, commonly known as the "impact". Besides others, such could be a denial of service condition, a privilige escalation or the compromise of a system. The element implements the "impact" section ("Problem-IDs" - References to the Addressed Problems). The information given in this element SHALL express a constituency-independent worst-case view. It MUST NOT contain information about traces an attack - successful or not - leaves on an attacked system or its environment. Such information is to be included in the "attack-signature" element (The sub-element "attack-signature" of "problem").

The element contains one or more body elements (The "body" element) that contain the information within the several target group specific (The "target-group" Element) versions.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

The element's OPTIONAL attribute "key" provides some standard impacts a successful attack could have on an affected system (The "affected" Element) by exploiting the referenced problem, vulnerability, or exposure. They are:

• "denial-of-service"
• "information-leak"
• "data-manipulation"
• "user-compromise"
• "system-compromise"

If none of these values apply, the "key" attribute MAY be omitted or the value "other" can be provided. Both possibilities have the same effect since "other" is the default value. The set of values is described in Detail in Appendix B.2.3 (The Set of Pre-Defined Values for the the "key" Attribute of the "impact" element).

The element "impact" is OPTIONAL but MUST NOT occur multiple times within its containing element problem (The "problem" Element).

Synopsis:

        <impact [key="(
                        denial-of-service|
                        information-leak |
                        data-manipulation|
                        user-compromise  |
                        system-compromise|
                        other
                      )"]>
          <body>
            ...
          </body>
          {<body>
            ...
          </body>}
        </impact>

Example:

        <impact key="denial-of-service" >
          <body tg-ref="en-admin">
          A sucessful exploit results in the consumptopn of all
          system ressources, thus makes the hosting system
          unusable and any of its services unavailable.
          </body>
        </impact>

13.8.1.6. The sub-element "exploit-status" of "problem"

This element describes the status of knowledge about actual exploitations of the problem, vulnerability, or exposure and the availability of automated attack programs, so-called "exploit code". It is a valuable piece of information for operators of an affected system, to know if there are observed exploitations of a given problem or if there is code available that can be used to exploit the problem.

Exploit code is program code designed to exploit the problem in order to produce not only immediate effects like overflowing a buffer and thus crashing an affected system, but also mediate effects like inject and execute arbitrary program code. There are several types of exploit code: the so called "proof of concept" demonstrating that the problem can be exploited to sucessfully attack affected systems but not doing evil things, and its further development, the automated attack program that exploits the problem and does evil things on affected systems. The latter sometimes are called "malware" (malicious software).

Note, that not only so-called "root-kits" or scan programs having exploit functionality qualify as malware but worms, viruses, and bots too.

A change of the content of the "exploit-status" element may change the contents of the "threat" (The sub-element "threat" of "problem"), and "probability-of-occurrence" (The sub-element "probability-of-occurrence" of "problem") elements, if present, and may cause the re-issuing of the announcement according to the policies of an issuer.

The element contains one or more body elements (The "body" element) that contain the text describing the knowledge the author or the issuere respectively about the exploit status. Depending on the target groups (The "target-group" Element) defined in the overall document the several "body" elements contain a target group specific version of the text.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

Since it is obviously impossible to determine whether exploits do *not* occur it is unknown at best if they occur or not. Besides rumors about exploits it is a common practice, that exploits and exploit codes are advertised or announced. It can be regarded as a seperate quality of knowledge if the issuer herself has observed attempts to exploit the problem because she does not have to rely on third party information. Thus, this fact SHOULD be communicated in the announcement.

Sometimes a so-called "proof-of-concept" is published that demonstrates the principle of an exploit without providing the capability to successfully attack vulnerable systems. However, it is usually only a short way to use such a demonstration for producing working exploit code.

The final state of this development of the "exploit status" is the availability of automated attack programs that are capable to successfully exploit the problem. Such "malware" could be a worm for example.

The element's OPTIONAL attribute "key" provides some standard values that describe these states of knowledge. The attribute allows to categorize this piece of information.

CAIF provides the following standard classifications:

• "unknown"
• "rumored"
• "advertised"
• "observed"
• "proof-of-concept"
• "malware"

Note, that a virus, worm, or bot is "malware". The "key" attribute defaults to "unknown" if it is omitted. The meanings of the values are described in Detail in Appendix B.2.4 (The Set of Pre-Defined values for the "key" Attribute of the "exploit-status" Element).

Note, that the knowledge about the exploit status may be changing over time. While the knowledge may be poor when the annoucement is initially issued it may grow over time or the situation may change. In most cases a change of this knowledge would vindicate a re-issue of the announcement, especially if the situation changes and has an effect on the risk (The sub-element "risk" of "problem") the problem imposes on affected system (The "affected" Element) or threat (The sub-element "threat" of "problem") it imploses on a given constituency (The "constituency" element ). This is subject to the policy of the issuer.

The element "exploit-status" is OPTIONAL and MUST NOT occur multiple times within its containing element problem (The "problem" Element).

Synopsis:

        <exploit-status [key="(
                        unknown         |
                        rumored         |
                        advertised      |
                        observed        |
                        proof-of-concept|
                        malware
                      )"]>
          {<body>
            ...
          </body>}
        </exploit-status>

Example:

        <exploit-status key="advertised" >
          <body tg-ref="en-admin">
          RUS-CERT have announced to have verified the
          exploitability of the problem.
          </body>
        </exploit-status>

13.8.1.7. The sub-element "risk" of "problem"

This element describes the "technical" risk the problem, vulnerability, or exposure represents in a worst-case view. It MUST NOT reference to a specific constituency (The "constituency" element ). It rather references to an affected system (The "affected" Element) and the most severe impact (The sub-element "impact" of "problem") the successful exploitation of the problem could have on this system. This sort of "academic" view is the basis for further assessments and a constituency-specific evaluation of the problem (see Section 13.8.1.8 (The sub-element "probability-of-occurrence" of "problem") and Section 13.8.1.9 (The sub-element "threat" of "problem")).

The element contains one or more body elements (The "body" element) that MAY contain markup text to describe the risk in greater detail. Depending on the target groups (The "target-group" Element) defined in the overall document the several "body" elements contain a target group specific version of the text.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

The element's OPTIONAL attribute "key" provides some standard values that allow a standardized risk classification.

• "low"
• "medium"
• "high"
• "very high"

The meaning of the values are described in Detail in Appendix B.2.5 (The Pre-Defined Values for the "key" Attribute of the "risk" Element).

The OPTIONAL attribute "policy" identifies the procedure that has been applied to achieve the assessment that is described in the "body" element. If this assessment conflicts with the set of values of the optional "key" attribute then this attribute can be ommitted. The attribute may contain an abbreviation describing the name of the policy (like "CVSS" for the "Common Vulnerability Scoring System" [15] (The Forum of Incident Response and Security Teams (FIRST), “The Common Vulnerability Scoring System (CVSS),” .)) or an URL pointing to an external resource or ant other reference.

The element "risk" is OPTIONAL and MUST NOT occur multiple times within its containing element problem (The "problem" Element).

Synopsis:

        <risk [key="(
                       low      |
                       medium   |
                       high     |
                       very-high
                      )"]
              [policy="..."]>
          {<body>
            ...
          </body>}
        </risk>

Examples

        <risk key="very-high">
          <body tg-ref="en-admin" headline="Technical Risk">
            The potential technical risk is very high.
          </body>
          <body tg-ref="de-admin" headline="Gefahrenpotential">
            <em>sehr hoch</em>
          </body>
        </risk>

Synopsis:

        <risk key="very-high" policy="CVSS">
          <body tg-ref="en-admin" headline="Technical Risk">
            9.2
          </body>
          <body tg-ref="de-admin" headline="Technisches Risiko">
            9.2
          </body>
        </risk>

13.8.1.8. The sub-element "probability-of-occurrence" of "problem"

This element is intended to allow issuers to provide their constituency (The "constituency" element ) with an estimation on the probability the referenced problem, vulnerability, or exposure is exploited within the constituency's IT-infrastructure and the impacts described in the announcement (see Section 13.8.1.5 (The sub-element "impact" of "problem")) take effect.

If an abstract constituency has been defined, this element can be used to refer to this abstract constituency. The OPTIONAL "const-ref" attribute contains an unique id within the document that refers to the constituency the estimation is made for.

For example: if the problem described is a buffer overflow bug in a vital service of an operating system that is deployed in great numbers within constituency "A" the "probability-of-occurrence" would be much greater than in constituency "B" that is mostly relying on a different operating system.

However, "probability-of-occurrence" does not take into account the severety of the impact, the successful exploitation of the described problem would have on affected systems. This aspect is covered by the element "risk" (The sub-element "risk" of "problem"). A combined estimation taking into account the technical risk and the probability of occurrence is provided by the element "threat" (Section 13.8.1.9 (The sub-element "threat" of "problem"), see below).

The element contains one or more body elements (The "body" element) that MAY contain markup text to describe the estimation in greater detail and provide additional information. Depending on the target groups (The "target-group" Element) defined in the overall document the several "body" elements each contain a target group specific version of the text.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

The element's OPTIONAL attribute "key" provides some standard values that allow a standardized classification of the probability of occurrence of an exploit of the problem.

• "low"
• "medium"
• "high"
• "very high"

The set of values is described in Detail in Appendix B.2.6 (The Set of Pre-Defined Values for the "key" Attribute of the "probability-of-occurrence" Element).

The OPTIONAL attribute "policy" identifies the procedure that has been applied to achieve the assessment that is described in the "body" element. If this assessment conflicts with the set of values of the optional "key" attribute then this attribute can be ommitted. The attribute may contain an abbreviation describing the name of the policy (like "CVSS" for the "Common Vulnerability Scoring System" [15] (The Forum of Incident Response and Security Teams (FIRST), “The Common Vulnerability Scoring System (CVSS),” .)) or an URL pointing to an external resource or ant other reference.

Since there MAY be none or more than one constituencies defined, the element "probability-of-occurrence" MAY be omitted or MAY occur more that one time within its containing element problem (The "problem" Element).

Synopsis:

        <probability-of-occurrence
                [const-ref="ID{ ID}"]
                [key="(
                       low      |
                       medium   |
                       high     |
                       very-high
                      )"]
                [policy="..."]>
          {<body>
            ...
          </body>}
        </probability-of-occurrence>

Example:

        <probability-of-occurrence
            const-ref="StuttgartUniversity"
            key="medium" policy="RUS-CERT">
          <body tg-ref="en-admin"
                headline="Probability of Occurrence">
            The probability of exploits within Stuttgart
            University's IT infrastrucrure is rather
            <em>medium</em>, since there are only few
            affected systems deployed.
          </body>
          <body tg-ref="de-admin"
                headline="Eintrittswahrscheinlichkeit">
            Die Wahrscheinlichleit, dass die Schwachstelle
            innerhalb der Netze der Universtät Stuttgart
            ausgenutzt wird, ist eher als <em>mittel</em>
            einzuschätzen, da nur wenige verwundbare
            Systeme in Betrieb sind.
          </body>
        </probability-of-occurrence>
        <probability-of-occurrence
            const-ref="Example.com-Internal"
            key="high" policy="RUS-CERT">
          <body tg-ref="en-admin"
                headline="Probability of Occurrence">
            The probability of exploits within Example.com's
            internal IT infrastructure is to be
            considered <b>high</b> since there are many
            systems in service that are vulnerable to the
            problem described.
          </body>
          <body tg-ref="de-admin"
                headline="Eintrittswahrscheinlichkeit">
            Die Wahrscheinlichleit, dass die Schwachstelle
            innerhalb der internen IT-Infrastruktur von Example.com
            ausgenutzt wird, ist  als <b>hoch</b> einzuschätzen,
            da zahlreiche verwundbare Systeme in Betrieb sind.
          </body>
        </probability-of-occurrence>

This element is OPTIONAL in "problem".

13.8.1.9. The sub-element "threat" of "problem"

This element is intended to allow issuers to provide an estimation of the threat the referenced problem, vulnerability, or exposure imposes upon a given constituency (The "constituency" element ). The "threat" basically is a value that results from a calculus that takes the technical risk (The sub-element "risk" of "problem") and the probability the given problem is being exploited within a given constituency (The sub-element "probability-of-occurrence" of "problem"). Of course it is possible to make an estimation that refers to an abstract constituency. The OPTIONAL "const-ref" attribute contains an id unique within the document that refers to the constituency (The "constituency" element ) the estimation is made for.

The element contains one or more body elements (The "body" element) that MAY contain markup text to describe the estimation in greater detail and provide additional information. Depending on the target groups (The "target-group" Element) defined in the overall document the several "body" elements contain a target group specific version of the text.

The element MUST NOT contain any text nor any other elements outside its "body" subelements.

The element's OPTIONAL attribute "key" provides some standard values that allow a standardized classification of the threat the problem imposes on a given constituency.

• "low"
• "medium"
• "high"
• "very high"

The values and their meaning are described in Detail in Appendix B.2.7 (The Set of Pre-Defined Values for the "key" Attribute of the "threat" Element).

The OPTIONAL attribute "policy" identifies the procedure that has been applied to achieve the assessment that is described in the "body" element. If this assessment conflicts with the set of values of the optional "key" attribute then this attribute can be ommitted. The attribute may contain an abbreviation describing the name of the policy (like "CVSS" for the "Common Vulnerability Scoring System" [15] (The Forum of Incident Response and Security Teams (FIRST), “The Common Vulnerability Scoring System (CVSS),” .)) or an URL pointing to an external resource or ant other reference.

Since there MAY be none or more than one constituencies defined, the element "threat" MAY be omitted or MAY occur more that one time within its containing element problem (The "problem" Element).

Synopsis:

        <threat
                [const-ref="ID{ ID}"]
                [key="(
                       low      |
                       medium   |
                       high     |
                       very-high
                      )"]
                [policy="..."]>
          {<body>
            ...
          </body>}
        </threat>

Example:

        <threat const-ref="StuttgartUniversity"
            key="high">
          <body tg-ref="en-admin"
                headline="Potential Threat">
            The threat the problem described imposes on Stuttgart
            University's IT infrastrucrure is <b>high</b>, since
            the technical risk is <b>very high</b> and the impact on
            affected systems is a system compromise. Even few
            compromised systems can be used as bridge-head to attack
            other systems.
          </body>
          <body tg-ref="de-admin"
                headline="Bedrohungspotential">
            Die Bedrohung, die die beschriebene Schwachstelle
            für die IT-Infrastruktur der Universtät Stuttgart
            darstellt, ist als <em>hoch</em> einzuschätzen, da
            eine erfolgreiche Ausnutzung zur Kompromittierung
            des angegriffenen Systems führt. Diese Systeme
            können als Brückenkopf für weitere Angriffe verwendet
            werden.
          </body>
        </threat>
        <threat const-ref="Example.com-Internal"
            key="very-high">
          <body tg-ref="en-admin"
                headline="Potential Threat">
            The threat the problem described imposes on Example.com's
            internal IT-infrastructure is <vb>very high</vb>
            since there are are many systems in service that
            are vulnerable against the problem described and
            a successful exploitation results in a system compromise.
          </body>
          <body tg-ref="de-admin"
                headline="Bedrohungspotential">
            Die Bedrohung, die die beschriebene Schwachstelle
            für die internen IT-Infrastruktur von Example.com
            darstellt, ist als <vb>sehr hoch</vb> einzuschätzen,
            da zahlreiche verwundbare Systeme in Betrieb sind und
            eine Ausnutzung zur kopromittierung des angeriffenen
            Systems führt.
          </body>
        </threat>

This element is OPTIONAL within "problem".

13.8.1.10. The Overall Syntax of the "problem" Element

The "key" attributes of the sub-elements of "problem" that are described above allow to categorize the several aspects of the problems

One might think that these attributes better should be included in the "rli" elements (The "rli" Element - Sub-Element to "rlist" ) of the rlists (The Refencing List "rlist") that are contained by the corresponding elements. Indeed this was the case in an earlier version of CAIF but when multi-linguality and multiple target groups were introduced to the format, a normalization step was necessary. The information provided by these elements belong to a problem and therefore MUST be attached to the element that identifies the problem, independently from other aspects like information about the language or the target group (The "target-group" Element). If the attributes were attached to the "rlists" that may occur multiple times in a top-level element, their improper assignment of values could lead to inconsistencies that cannot be detected when validating an announcement against CAIF's DTD (The Document Type Definition (DTD) of CAIF). Hence, the attributes are attached to the "problem" element's sub-elements.

The rather complex element "problem" has the following syntax:

Overall Synopsis:

        <problem {id="ID"}>
          <body>
          ...
          </body>
          {<body>
          ...
          </body>}
          [<class>
          ...
          </class>]
          [<attack-vector>
          ...
          </attack-vector>]
          [<attack-requirements>
          ...
          </attack-requirements>]
          [<attack-signature>
          ...
          </attack-signature>]
          [<impact>
          ...
          </impact>]
          [<exploit-status>
          ...
          </exploit-status>]
          [<risk>
          ...
          </risk>]
          [<probability-of-occurrence>
          ...
          </probability-of-occurrence>]
          [<threat>
          ...
          </threat>]
        </problem>

13.9. The "mitigation" Element

The "mitigation" element contains information about factors that mitigate the risk potential or "technical risk" (The sub-element "risk" of "problem") of a problem. Such could be the fact, that the special configurations, that cause a system's affectedness, are not activated by default. Note, that a workaround (The "workaround" Element) or solution (The "solution" Element) does not mitigate a problem in the sense the term "mitigation" is used here.

The element SHOULD contain a basic description that is constituency-independent.

If the issuer wants to include constituency-specific information it MUST be enclosed in "const" (The "const" Markup Element) tags. Such information could be the fact that the default configuration of the systems of a given constituency is mitigating the threat because the systems configured like this are not affected. If such information is provided the assessments given in the "threat" (The sub-element "threat" of "problem") and "probability-of-occurrence" (The sub-element "probability-of-occurrence" of "problem") elements that refer to the same constituency SHOULD reflect this information.

Note, that the presence of mitigatig information MUST NOT have an effect on the risk assessment given in the "risk" element (The sub-element "risk" of "problem"), since that describes the risk potential in a worst-case view.

The element either comprises of one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the body's "tg-ref" attribute and an OPTIONAL title string to the section definded by "affected".

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <mitigation>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </mitigation>

Example:

        <mitigation>
          <body>
            <p>
            The affected feature is not activated by default.
            </p>
            <p>
            Please go to the <iref
            target="determine-affectedness">"Am I Affected?"</iref>
            section to determine, if the feature is activated on
            your system.
            </p>
          </body>
        </mitigation>

This element is OPTIONAL in an announcement.

13.10. The "affected" Element

This element contains information about the systems affected by the problems addressed by the announcement. It is recommended to structure the content in a list and be as verbose and exact as possible when describing versions etc.

It is strongly recommended, to use the system vendor's nomenclature when using product names, versions and patch-levels.

The markup element "aff" (The "aff" Markup Element) can be used to provide the descriptions of the affected systems with an internal id that acts as a reference target within the document. This is useful e.g. if the issuer wants to provide data for scanners that are capable automatically determine whether systems in a given it infrastructure are vulnerable to the problem(s) described (see also Section 13.13 (The "determine-affectedness" Element)).

The element either comprises of one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the body's "tg-ref" attribute and an OPTIONAL title string to the section definded by "affected".

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <affected>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </affected>

If provided consistently within announcements over time, the contents of this element as well as the contents of the elements "not-affected" (The "not-affected" Element), "possibly-affected" (The "possibly-affected" Element), and "category" (The "category" Element) can be used to produce a taxonomy-tree for the systems, platforms, and protocols addressed by announcements. If announcements are stored within a database, such could be used as keys for a query system.

13.11. The "not-affected" Element

This element contains information about the systems that are definitively not affected by the problem(s) addressed in the announcement. It is recommended to structure the content in a list and be as verbose and exact as possible when describing versions etc.

It is strongly recommended to use the system vendor's nomenclature for products and versions.

The markup element "aff" (The "aff" Markup Element) can be used to provide the descriptions of the affected systems with an internal id that acts as a reference target within the document. This is useful if the issuer wants to provide data for scanners that are capable automatically determine whether systems in a given it infrastructure are vulnerable to the problem(s) described (see also Section 13.13 (The "determine-affectedness" Element)).

The element either comprises of one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "not-affected" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <not-affected>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </not-affected>

13.12. The "possibly-affected" Element

This element contains information about the systems of which the issuer has no evidence on the affectedness by the problems addressed by the announcement. It is recommended to structure the content in a list and be as verbose and exact as possible when describing versions etc.

It is strongly recommended to use the system vendor's nomenclature for products and versions.

Note, that the content of this element usually requires maintenance, since it should be the intention of issuers and authors to determine whether a system is affected or not. Hence, this element SHOULD only be provided in an announcement, if it has to be issued urgently but time or ressources are insufficient to gain evidence about the affectedness of some systems. Thus, it is sensible for issuers to implement a policy on how to use this element.

The markup element "aff" (The "aff" Markup Element) can be used to provide the descriptions of the affected systems with an internal id that acts as a reference target within the document. This is useful if the issuer wants to provide data for scanners that are capable automatically determine whether systems in a given it infrastructure are vulnerable to the problem(s) described (see also Section 13.13 (The "determine-affectedness" Element)).

The element contains either one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "possibly-affected" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <possibly-affected>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </possibly-affected>

13.13. The "determine-affectedness" Element

The "determine-affectedness" element contains one or more "detitem" elements, each providing information on how the affectedness of a given system to the problem(s) described can be determined. Besides its sub-elements the "determine-affectedness" element does not contain any textual descriptions or attributes.

This element is OPTIONAL in an announcement

Synopsis:

        <determine-affectedness>
          <detitem>
          ...
          </detitem>
         {<detitem>
          ...
          </detitem>}
        </determine-affectedness>

13.13.1. The "detitem" Element

This element's purpose is to contain data, that helps to determine whether a given system or IT infrastructure is affected by the problem(s) described. Such data could be a description of steps that shall be performed manually by the reader, a script, some configuration data for an automated program (like a vulnerability scanner), or a combination of such.

The element contains either one or multiple "body" (The "body" element) elements that contain the information.

The OPTIONAL attribute "content-type" describes the type of data that is contained by the "body" elements. It has the following predefined values:

"base64"

-- the content is in a non-7-bit ascii format and has been base 64 encoded to be included within the document. The rendering policy defines how the content shall be treated.

"parsed"

-- the data is part of the CAIF document and SHALL be parsed by the CAIF parser. This is the default value and applies to all textual descriptions.

If the content is in another XML-based language like OVAL (The MITRE Cooperation, “Open Vulnerability Assessment Language,” .) [14] or AVDL (Organization for the Advancement of Structured Information Standards, AVDL Technical Committee, “OASIS Application Vulnerability Description Language (AVDL),” .) [16] the parser MUST be told, that it SHALL NOT process this part of the document but rather pass it to the respective parsers that will process the data. This is necessary because these languages do have their own document type definitions (DTD, see Section 7.2 (Document Type Definitions (DTD))) or schemata which are not part of CAIF's DTD (The Document Type Definition (DTD) of CAIF). If the CAIF parser tried to process these contents it would probably encounter errors. Thus, the contents MUST be marked as not to be parsed. This is done by providing the leading string "<![CDATA[" right at the beginning of the content that shall not be parsed. The string "]]>" marks the end of this data and tells the parser to continue processing the following content. Consequently, the string "]]" MUST NOT appear within the enclosed document.

The same applies to base64-encoded data.

The OPTIONAL attribute "method" indicates which method is to be used to determine the affectedness is described by the content. It has no pre-defined values but the following are considered to be useful:

"manual"

-- the information provided describes a manual method that is to be performed by the reader to determine whether a given system is affected by the problem(s) described, e.g. a list of steps or commands to be entered.

"shell"

-- the data is a shell code snippet or script that can be used to determine whether a system is affected or not.

a tool or format name

-- the data is to be fed into a software tool that is able to (semi-)automatically determine if a system or a the systems within a given IT-infrastructrure are affected. For example: if the data is provided in some other XML language like OVAL or AVDL, the names of the respective format SHOULD be provided. It is highly recommended that standardized names are used, so that CAIF-processing software knows which third-party software is to be fed with the data contained by the "detitem" element.

CAIF-interpreting software SHOULD assume "manual" as the default value if the attribute is omitted.

The REQUIRED attribute "aff-ref" provides a reference to the id that is defined by the "aff" markup element (The "aff" Markup Element). It is intended to allow an exact determination within the document for which affected system the information is provided in the "detitem" element.

The OPTIONAL attribute "problem-ref" allows to refer to one or more of the problems (The "problem" Element) that are described in the announcement. The mechanism is similar to the reference that is implemented by the "rli" element (The "rli" Element - Sub-Element to "rlist" ).

Synopsis:

        <detitem [method="manual|shell|tool|...]"
                 aff-ref="IDREF {IDREF}"
                 [problem-ref="IDREF {IDREF}]"
                 content-type="base64|parsed">
           <body>...</body>
           {<body>...</body>}
        </detitem>

Example:

        <affected>
          <rlist>
            <rli problem-ref="LSASS">
              <list style="symbols">
                <li>
                <aff id=W2000>Windows 2000</aff>
                </li>
                <li>
                <aff id=W2000SP1>Windows 2000 Service Pack 1</aff>
                </li>
            </rli>
          </rlist>
        </affected>
        ...
        <determine-affectedness>
          <detitem method="OVAL"
                   aff-ref="W2000"
                   problem-ref="LSASS">
                   content-type="base64"
            <body>
            OVAL-Data
            </body>
         </detitem>
         <detitem method="AVDL"
                  aff-ref="W2000SP1
                  problem-ref="LSASS">
                  content-type="base64"
            <body>
            AVDL-Data
            </body>
         </detitem>
       </determine-affectedness>

13.14. The "context" Element

This element implements the context section (Context Information) containing impartial information about the technical background of an/the system(s) affected (see Section 13.10 (The "affected" Element))by the problem addressed by the announcement that is independent to a special constituency.

The element contains either one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "context" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <context>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </context>

13.15. The "description" Element

This element contains a detailed description of the problem(s) addressed. It implements the "description" section (The Description in Detail). Authors SHOULD describe the problem(s) comprehensively, including the attack, its requirements, and vector, the impact, and possibly subsequent impacts, if applicable. The information provided SHOULD be sufficient for a reader to decide whether the issue is a threat to her IT infrastructure.

The element contains either one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "description" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is REQUIRED in an announcement.

Synopsis:

        <description>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </description>

13.16. The "workaround" Element

The "workaround" element contains information about one or more temporary solutions to the problem(s) addressed by the announcement. Such could be the termination or re-configuration of an affected service, or the restriction of access to an affected system. Authors SHOULD describe the necessary actions and steps comprehensively and detailed, in order to enable readers to easily apply the workaround.

The element contains either one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "workaround" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <workaround>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </workaround>

13.17. The "solution" Element

This element contains information about a more or less final solution, i.e. a patch or a new version of an affected system.

The element contains either one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions of the solution specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "solution" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <solution>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </solution>

13.18. The "arbitrary" Element

This element provides CAIF's mechanism to extend the format on a per-document basis. It has the attribute "name" that defines the name under which the element can be identified within the document. The OPTIONAL attribute "extends" contains the name of an existing CAIF element (The Elements Defining the Main Sections), or the "name" of another "arbitrary" element, thus indicating a relationship to this element.

So, if the set of elements in CAIF is not sufficient, issuers can use this mechanism to either extend existing elements with new (sub-)elements or create completely new element groups. Of course, processing software is limited in its capabilities of parsing such elements: it is not possible to tell the parser the sematics of the new elements. Therefore it is very important to choose self-explanatory names for "arbitrary" elements.

The element contains either one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section that is definded by the "arbitrary" element.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement and may occur multiple times in a CAIF document.

Synopsis:

        <arbitrary name="..."
                   [extends="..."]>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </arbitrary>

Example:

        <arbitrary name="vendor-status"
                   extends="workaround">
          <body tg-ref="en-admin en-user">
            The vendor has received a detailed description of the
            vulnerability as well as proof-of-concept code for its
            exploitation on 2004-01-15.
          </body>
        </arbitrary>

This "arbitrary" element is called "vendor-status" and belongs to the element "workaround".

Note, that the definition of this element allows to extend every pre-definded element (i.e. elements that are defined in CAIF's DTD Appendix C (The Document Type Definition (DTD) of CAIF)) within a document, since there is no restriction on the value of its "extends" attribute. Consequently it is also possible to extend structuring elements (Document Structuring Elements) like "body" (The "body" element) or "rlist" (The Refencing List "rlist") or other elements that may occur more than one time within a document. If such elements are extended by the "arbitrary" element, a problem may arise when rendering the announcement: if there is only one "arbitrary" element extending an element that has many instances within the document, does it apply to all these instances, or only to one? If the latter is assumed, to which instance does it apply?

The intention of the "arbitrary" element is to allow authors to add extra sections (The Main Sections of a CAIF Announcement) to a document if the set of predefined elements defining the sections (The Elements Defining the Main Sections) is not sufficient. Consequently only such elements SHOULD be extended to create a sort of sub- to super-element relationship. As mentionned above, it is also in focus to allow the creation of hierarchies with more than one level or completely detached hierarchies of new elements, i.e. it is possible to extend other "arbitrary" elements.

Therefore it is not possible to restrict the value space of the "extends" attribute to the existing section elements (The Elements Defining the Main Sections) without loosing the ability to extend other "arbitrary" elements that can have freely chosen names. Thus, the definition of "arbitrary" cannot inhibit the extension of a structuring or even a markup element.

To avoid this problem, authors MUST NOT extend elements that occur more than one time within a document, i.e. only section elements (The Elements Defining the Main Sections) and other "arbitrary" elements are allowed to be extended in order to restore interoperability of the documents.

The following elements MAY be extended by the "arbitrary" element:

• identification
• target-groups
• constituencies
• revisions
• category
• subject
• summary
• problems
• affected
• not-affected
• possibly-affected
• determine-affectedness
• mitigation
• context
• description
• workaround
• solution
• arbitrary
• bibliography
• credits
• disclaimer
• other-documents
• rendered-copy

13.19. The "bibliography" Element

This element contains a list of references to related documents within its "bibitem" sub-elements.

The element MAY contain multiple "body" (The "body" element) elements that contain some target group specific information (especially a headline string) about the section, followed by at least one "bibitem" (The "bibitem" Element) element that contains the references.

Synopsis:

        <bibliography>
          {<body>...</body>}
          <bibitem>...</bibitem>
          {<bibitem>...</bibitem>}
        </bibliography>

13.19.1. The "bibitem" Element

The "bibitem" elements contain the data that refer to a -- usually external -- source of information, like a document or any other resource that the author wants to mention or cite within the document.

The element MAY contain arbitrary markup text including the "elink" element (The External Reference "elink") that contains URIs as references to external resources, URIs are extremely useful for this purpose but since no restrictions apply to the format of the references, book titles and ISBN numbers MAY be used as well.

One might think that the "bibitem" element should have the option to provide multi-lingual and information for multiple target groups of readers, thus should have the respective attributes or contain "body" or "rlist" items. It does not in the same way like the other sections (The Main Sections of a CAIF Announcement) because the reference to an external resource does not have these aspects, the resource itself rather has a similar quality, the language it is written in as well as the target group of readers it is written for. Thus, the "bibitem" element has attibutes to let authors provide these aspects in an announcement an make it possible to produce target group specific renderings with selected bibliographic renderings.

Note, that besides others a target group (The "target-group" Element) may have a language aspect. It is not a contradiction if a "bibitem" references a document that is written in a different language than the language of the intended target group of readers. Since a lot of documentation in the IT-world is written in english it is a common practice to reference documents in english even if the announcement is written in another language (i.e. does not have english "target-groups"). It is up to the author to decide to which target group a given bibliographic reference shall be assigned. Nevertheless, the element MUST be provided with values carefully to avoid inconsistencies.

The element has the OPTIONAL attribute "name" that contains an ID that acts as a target for references from within the document, thus allows to make citations. The "ilink" element (Internal Cross-References - The "ilink" Element) is intended to internally cross-reference to the ID provided by the "name" attribute.

The REQUIRED attribute "type" defines whether the "bibitem" element contains a reference to an external resource that is considered a "primary" source of information contributing to the document or an "further-reading" reference providing a link to further reading.

If the announcement addresses more than one problem, the OPTIONAL "problem-ref" attribute allows to devote the reference given in the "bibitem" to one or more of the problems (The "problems" Element) that are described by the overall document.

The OPTIONAL "date" attribute contains a time-stamp according to ISO standards (YYYY-MM-DD {hh:mm:ss[+|-]hh}). If the reference is an internet resource the time-stamp documents the moment in which the contents of the referred resource have been looked at by the author. The version of the contents in this very moment is intended to be referenced. If the contents change over time, "date" tells the reader that a erlier version is referenced. If an author wants to circumvent the problem of changing references, she can use the "other-document" element (The "other-document" Element) to include a copy of the document that shall be referenced. Of course, copyright issues MUST be considered when doing so. If the "bibitem" references a resource not subject to fluctuation or constant change -- like a book -- the date MAY contain the date if the issuing of the resource.

The OPTIONAL attribute "tg-ref" provides one or more internal-to-document references to one or multiple target groups (The "target-group" Element). It allows the author to include bibliographic references appropriate to a specific readership defined by the target group.

The "const-ref" attribute allows to link the bibliographic reference to one or multiple specific constituencies, which is useful, when documents like an internal policy shall be referenced. Like all constituency specific information, a bibitem having a "const-ref" can be stripped off the document when it is distributed outside the referenced constituency.

The OPTIONAL "content-lang" attribute provides a language code that defines the language, the referenced resource is written in.

Synopsis:

         <bibitem [name="ID"]
                  type="[primary|further-reading]"
                  [problem-ref="IDREF {IDREF}"]
                  [date="YYYY-MM-DD [hh:mm:ss(+|-)hh]"]
                  [content-lang="LANG_CODE"]
                  [tg-ref="IDREF {IDREF}"]
                  [const-ref="IDREF {IDREF}"]>
             ...
         </bibitem>

Overall Example:

        <bibliography>
        <body headline="References"/>
         <bibitem name="MS03-041-en"
                  type="primary"
                  content-lang="en"
                  tg-ref="en-admin en-user">
             <elink
             target="http://www.microsoft.com/technet/treeview/
             ?url=/technet/security/bulletin/MS03-041.asp">
             Microsoft Security Bulletin MS03-041: Vulnerability in
             Authenticode Verification Could Allow Remote Code
             Execution (823182)
             </elink>
         </bibitem>
         <bibitem name="MS03-041-de"
                  type="primary"
                  content-lang="de">
                  tg-ref="de-admin de-user">
             <elink
             target="http://http://technet.microsoft.at/
             News_Showpage.asp?newsid=10701&secid=1502"> Microsoft
             Security Bulletin MS03-041: Sicherheitsanfälligkeit in
             Authenticode-Überprüfung kann Remotecodeausführung
             ermöglichen (823182)
             </elink>
         </bibitem>
        </bibliography>

13.20. The "credits" Element

The "credits" element contains information about and references to individuals or organizations who have contributed to the announcement, e.g. who have initially discovered the problem described.

The "credits" element either contains one or multiple "body" (The "body" element) or "rlist" (The Refencing List "rlist") elements. A mixed use of these elements is neither allowed nor sensible.

If the announcement describes a single problem, the element contains "body" elements each providing textual descriptions specific to the target group (The "target-group" Element) referred by the "tg-ref" attribute and an OPTIONAL title string to the section the "credits" element defines.

If the announcement addresses more than one problem (The "problems" Element), the element contains "rlist" elements each providing target group-specific textual descriptions within its "rli" (The "rli" Element - Sub-Element to "rlist" ) elements. Each "rlist" is specific to the target group referenced by its "tg-ref" attribute. The "rli" elements within a single rlist address the different problems, referenced by the "problem-ref" attribute of "rli".

This element is OPTIONAL in an announcement.

Synopsis:

        <credits>
          (<body>...</body>
           {<body>...</body>}|
           <rlist>...</rlist>
           {<rlist>...</rlist>})
        </credits>

Example:

        <credits>
         <rlist style="ref-text">
          <rli problem-ref="RUS-CERTAdvisory2000-04:01">
           This problem was discovered by <eref
           target="mailto:Weimer@CERT.Uni-Stuttgart.DE"> Florian
           Weimer</eref>, <eref
           target="http://CERT.Uni-Stuttgart.DE">RUS-CERT</eref>
           <rli>
           <rli problem-ref="VU#749342">
           This Problem was discovered by the University of Oulu
           Security Programming Group <elink
           target="http://www.ee.oulu.fi/research/ouspg/">
             OUSPG
           </elink>
           </rli>
         </rlist>
        </credits>

13.21. The "disclaimer" Element

This element is intended to contain a standard disclaimer of the issuer. Since this disclaimer usually covers a whole document, it does not contain an "rlist" element (The Refencing List "rlist"). Nevertheless, since the document may be multi-lingual, the "disclaimer" element contains one or multiple "body" elements (The "body" element) each referring to the set of target groups that are covering the same language. If there are target groups that use the same language but different law that requires different disclaimers, the issuer can provide different "target-group" elements (see Section 13.2.1 (The "target-group" Element)) which reflect this fact. Then different "body" elements each providing the proper wording for the different target groups can be included into "disclaimer".

This element is OPTIONAL in an announcement.

Synopsis:

        <disclaimer>
          <body>...</body>
          {<body>...</body>}
        </disclaimer>

Example:

        <disclaimer>
          <body tg-ref="en-admin-emp en-user-mgm"
                headline="Disclaimer">
            This document is provided "as is".
            No Warranty applies.
          </body>
          <body tg-ref="de-admin-emp de-user-mgm"
                headline="Haftungsausschluss">
            Die in diesem Text enthaltene Information wurde fuer
            die Mitglieder der Universitaet Stuttgart recherchiert
            und zusammengestellt.  Die Universitaet Stuttgart
            uebernimmt keinerlei Haftung für die Inhalte.
          </body>
        </disclaimer>

13.22. The "other-documents" Element

This element is a container for rendered copies of other documents within its "other-document" sub-elements.

The element MAY contain multiple "body" (The "body" element) elements that contain some target group specific information about the section, followed by at least one "other-document" (The "other-document" Element) element that contains the copies.

Synopsis:

        <other-documents>
          {<body>...</body>}
          <other-document>...</other-document>
          {<other-document>...</other-document>}
        </other-documents>

13.22.1. The "other-document" Element

This element provides a container to include rendered copies of other documents related to the issue of the announcement and/or CAIF announcements related to the topic. For authenticity as well as to circumvent the problems arising from the availability of network-based documents, a copy of such can be attached to an announcement within this element. The element MAY occur multiple times and the set of these elements implements the "Other Documents" section (Including Other Douments in the Announcement).

For maximum compatibility and due to the limitation of XML documents to contain character data only, renderings in other formats than 7-bit-ascii MUST be base64-encoded before they can be included into the "other-document" element. The OPTIONAL attribute "content-type" can be used to define and give the parser some information about the format of the document included. It SHOULD be provided in the MIME (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” 11 1996.) [5] format. Right after the element name in the start-tag the string "<![CDATA[" MUST follow. This string tells parsers to ignore the following content up to the string "]]>" which in turn tells the parser that it shall continue processing the data. Consequently, the string "]]" MUST NOT appear within the enclosed document.

The OPTIONAL attribute "description" can be used to provide the reader with some onformation about the content of the document included.

Synopsis:

        <other-document>
          <![CDATA[
            The base64-encoded rendering of an extra document
            In this document the string "]]" MUST NOT appear.
          ]]>
        </other-document>

This element is OPTIONAL in an announcement and MAY appear multiple times within its superior element each containing a rendered document.

13.23. The "rendered-copies" Element

This element pools target group specific rendered copies of the document. It MUST contain at least one "rendered-copy" (The "rendered-copy" Element) element that contains a rendering of the document.

Since XML itself is not a presentation format for a document, some implementations of processing- and rendering-software make minor changes like reformatting white-space that do not alter the meaning of the document but destroy a cryptographic signature. Therefore it is important to provide a mechanism that makes it possible to check the authenticity of the provided contents by (re-)distributors (Distributor), and, if applicable, to readers (Reader). By including one or multiple signed copies of renderings reflecting the different target group (The "target-groups" Element) specific aspects -- like the different languages -- in an element that contains data not to be parsed and processed by software, this goal can be achieved.

Of course, this form of authenticity cannot be tested mechanically since the reader has to compare the contents of the rendered and signed copy with the content of the redistributed XML document or the rendering of the redistributor, which possibly has a completely different look.

Synopsis:

        <rendered-copies>
          <rendered-copy>...</rendered-copy>
          {<rendered-copy>...</rendered-copy>}
        </rendered-copies>

The element is OPTIONAL in an announcement

13.23.1. The "rendered-copy" Element

This element is a container for a rendered and possibly signed copy of the original announcement, distributed by the issuer (Issuer).

The element "rendered-copy" has the OPTIONAL attribute "tg-ref" that contains one or multiple IDs referencing to one or multiple target groups (The "target-group" Element), thus allowing for the provision of target group specific renderings (e.g. different language versions). The OPTIONAL "headline" attribute can be used to provide the section with a headline string.

For maximum compatibility and due to the limitation of XML documents to contain character data only, renderings in other formats than 7-bit-ascii MUST be base64-encoded before they can be included into the "rendered-copy" element. The OPTIONAL attribute "content-type" can be used to define and give the parser some information about the format of the document included. It SHOULD be provided in the MIME (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” 11 1996.) [5] format. Right after the element name in the start-tag the string "<![CDATA[" MUST follow. This string tells parsers to ignore the following content up to the string "]]>" which in turn tells the parser that it shall continue processing the data. Consequently, the string "]]" MUST NOT appear within the enclosed document.

Synopsis:

        <rendered-copy [content-type="..."]
                          [tg-ref="IDREF {IDREF}"]
                          [headline="..."]>
          <![CDATA[
            The base64-encoded rendered and signed copy of the
            original announcement. In this document the string
            "]]" MUST NOT appear.
          ]]>
        </rendered-copy>

14. Security Considerations

An announcement might contain confidental material. The secure transmission and storage of CAIF documents is outside the scope of the CAIF format specification.

Readers want to know if announcements come from a known and trustworthy issuer or distributor and if they have not been altered by a third party. However, to meet distributor requirements, CAIF documents are distributed in a presentation-independent format, and if the document in this format is signed, the signature does not verify against a rendered copy of this document.

Therefore, the issuer MAY include a rendered and signed copy (The "rendered-copy" Element) of it, preferably both in text and MIME (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” 11 1996.) [5] format (conforming to [7] (Elkins, M., Del Torto, D., Levien, R., and T. Roessler, “MIME Security with OpenPGP,” August 2001.) or to S/MIME, to enable distribution by email).

When creating CAIF documents distributedly (more than one organization is taking part in the creation process) or when interchanging the XML source of documents between issuers and redistributors, mechanisms have to be implemented, that assure the integrity and authenticity of the documents. Such could be digitally signed canonical XML (Boyer, J., “Canonical XML Version 1.0,” March 2001.) [3]. These mechanisms are not in the scope of CAIF.

All parties exchanging CAIF documents who want their authenticity to be verifyable need to be part of the same PKI.

15. References

15.1. Normative References

15.2. Informal References

Appendix A. Glossary

A.1. Well-Formedness

An XML document is "well-formed" if it meets the basic rules (Basic Rules):

• Elements MUST be nested correctly
• Metacharacters MUST NOT be used in the document except in the appropriate places
• case-sensitivity is considered
• the document starts with the XML declaration
• the document contains at least the top-level element that contains all other elements
• within the top-level element appears at least one element
• all elements have a start tag and an end tag or are empty elements

A.2. Validity

An XML document is "valid" if it is well-formed (Well-Formedness) and matches against a Document Type Definition (Document Type Definitions (DTD)), i.e.:

• the document contains the DTD or a reference to the DTD used
• the documents contains *only* elements defined by the DTD
• all elements used match the syntax defined by the DTD
• all elements are nested as defined by the DTD, e.g. if element "b" is defined as a sub-element to "a", then "b" may only appear within "a"
• the top-level element has the same name like the document type

Appendix B. Keys and Standard Values

A number of the elements in CAIF that describe a section in an announcement (see Section 13 (The Elements Defining the Main Sections)) and some of their sub-elements contain an attribute that allows the author to provide a standardized, pre-defined value that can be processed mechanically. The information this attribute provides is additional to the textual description of the respective element.

The sets of pre-definde values are intended to be a basis for categorization without claiming completeness or enforcing authors to use them. The sets have evolved and express the experience gathered over time while writing announcements and classify them as well as looking at classifications of announcements from other issuers.

The predefined values are chosen as generic als possible. Vulnerabilities, problems, or exposures have several aspects that can be used to categorize the information. To minimize ambiguities and uncertainities it is important to be precise in describing as well as in dissociating the aspects. Consequently the various keysets have been chosen to represent the various aspects as generic and as dissociated as possible.

Common classifications like "remote code execution" that intermingle several aspects can be represented by the combination of the appropriate values of the various keysets representing the various aspects.

B.1. Pre-Defined Values for the "target-group" element

The element "target-group" (The "target-group" Element) that is intended to define the several aspects of a target group of readers (like the language and others) has the following attributes (The Attributes of the element "target-group") that may have a predefined value:

B.1.1. The Set of Pre-Defined Values for the "tech-background" Attribute of the "target-group" Element

The attribute "tech-background" categorizes the assumed technical abilities of the members of the target group. When writing contents in an announcement this is an important aspect to achieve a maximum understanding of the text privided. The "tech-background" attribute may have the following values:

"admin"

-- This value indicates that the reader has an average technical knowledge of a system administrator. "admin" is the default value if the attribute is omitted.

"user"

-- This value indicates that the reader only has technical knowledge and abilities of a user of the affected system(s).

"developer"

-- This value indicates that the reader has the profund technical background knowledge of a system developer. This value is useful, e.g. if the issuer wants to provide a workaround (The "workaround" Element) to solve a problem that requires profund knowledge in programming or reading, changing and successfully compile buggy source code into a patched executable.

B.1.2. The Set of Pre-Defined Values for the "orga-overview" Attribute of the "target-group" Element

The "orga-overview" attribute provides information on the organizational overview a member of the intended target group has. within the organization an affected system is used. The "orga-overview" attribute may have the following values:

"employee"

-- This value indicates that the reader has the sight of an average employee. This means that the information given SHOULD enable the reader to evaluate the impacts of the problem for their area of responsibility like the systems an administrator is running.

"middle-management"

-- This value indicates that the reader has the sight of a member of the middle management. This means that the information given SHOULD enable the reader to evaluate the impacts of the problem for their area of responsibility like a department or branch.

"senior-management"

-- This value indicates that the reader has the sight of a member of the senior management. This means that the information given SHOULD enable the reader to evaluate the strategic impacts of the problem for their area of responsibility and the company or institution in toto.

B.2. The Key Values for the "problem" element

The "problem" element (The "problem" Element) has the OPTIONAL sub-elements

• class (The sub-element "class" of "problem")
• attack-requirements (The sub-element "attack-requirements" of "problem")
• impact (The sub-element "impact" of "problem")
• exploit (The sub-element "exploit-status" of "problem")
• risk (The sub-element "risk" of "problem")
• probability-of-occurrence (The sub-element "probability-of-occurrence" of "problem")
• threat (The sub-element "threat" of "problem")

that all have an OPTIONAL "key" attribute. If present, each of these attributes contain a pre-defined value that provides a categorized meaning to the containing element.

They are described in detail in the following sections.

B.2.1. The Keyset for the "key" Attribute of the "class" Element

For statistical reasons this set provides standard classifications of the issues that are described by the announcement. The key provides pre-defined values to the "key" attribute of the "class" element (The sub-element "class" of "problem"):

"buffer-overflow-bug"

-- the problem is an unchecked buffer that can be overflowed, e.g. to inject false jump-addresses into the memory of an affected system (The "affected" Element). This class includes "heap overflow bugs" and "stack overflow bugs".

"format-string-bug"

-- The problem is a format string bug.

"insecure-configuration"

-- Affected systems (The "affected" Element) can be configured in a way that causes a security problem.

"insecure-defaults"

-- The default configuration of a system causes a security problem.

"design-flaw"

-- The design of a system causes a security problem.

"implementation-flaw"

-- The problem results of a simple implementation flaw.

"malware"

-- The problem is a piece of malware, like a bot, worm or virus that spreads autonomously or a root-kit that helps to compromise a system or any other tool to attack, compromise or disturb systems.

"other"

-- any other problem, that does not fit into one of the other categories. This value is the default, if the attribute is omitted.

B.2.2. The Set of Pre-Defined Values for the "key" Attribute of the "attack-requirements" element

This set provides some standard values for the "key" attribute of the "attack-requirements" (The sub-element "attack-requirements" of "problem") element that describes the requirements an attacker would need to successfully attack an affected system (The "affected" Element). The set contains the following standard types of attack requirements:

"local"

-- the attacker MUST have interactive ("local") access to an affected system to perform a successful attack

"network-group"

-- the attacker MUST have authenticated access to a network group like an CIFS/SMB or NIS/NFS domain to successfully attack an affected system

"null-session"

-- it MUST be possible for an attacker to establish a null-session to an affected system to perform a sucessful attack

"broadcast-domain"

-- an attacker MUST have access to the network broadcast domain an affected system is connected to, to perform a successful attack

"application-user"

-- the attacker MUST be an authenticated user of an application an affected system runs and that is accessible via a network, e.g. a web application. No other restrictions apply.

"remote"

-- the affected sytem MUST be connected to a network that is accessible by the attacker, no other restrictions apply, i.e. it is sufficient if the system is connected to the internet.

"other"

-- none of the key value applies. If this value is chosen, authors SHOULD provide some text within the "attack-requirements" element that describes the special requirements an attacker would need to successfully affected system. This value is assumed as default if the "key" attribute is omitted.

B.2.3. The Set of Pre-Defined Values for the the "key" Attribute of the "impact" element

This provides standard values for the "key" of the "impact" element (The sub-element "impact" of "problem"). The values describe some common impacts a successful attack has on an affected system. CAIF provides the following types of standard impacts:

"denial-of-service"

-- a successful exploit of the problem results in a state of un-availability of a special service or the hosting IT-infrastructure, a so-called "Denial of Service" ("DoS") condition.

"information-leak"

-- by exploiting the problem an attacker may be able to access information that is protected

"user-compromise"

-- an attcker may gain the privileges of an unprivileged user by exploiting the problem

"system-compromise"

-- exploiting the problem an attacker may gain administrative privileges

"other"

-- none of the above apply. If this value is chosen, issuers SHOULD provide some text within the "impact" element that describes the effect a successful attack has on an affected system. This value is assumed as default if the "key" attribute is omitted.

Note, that common terms like "remote root compromise" are not included within the set since such would mix up aspects that ought to be described by "impact" and "requirements".

B.2.4. The Set of Pre-Defined values for the "key" Attribute of the "exploit-status" Element

These standard values for the "key" attribute of the "exploit-status" element (The sub-element "exploit-status" of "problem") describe the knowledge about the status of exploitation of the problem(s) described by the announcement and the availability of automated attack programs. CAIF provides the following standard classifications:

"unknown"

-- It is not known, whether exploit code is available. This value is the default, if the attribute is omitted.

"rumored"

-- It is rumored that exploit code is available but the issuer has no evidence about its existence

"advertised"

-- the existence of exploit code has been advertised

"observed"

-- Exploits have been observed by the issuer or trusted parties

"proof-of-concept"

-- Code for a proof of concept has been published. A proof of concept is a demonstration of the successful exploitation of the vulnerability without providing a semi or fully automated attack program (i.e. malware). Usually there is only very few time left before malware appears in the wild.

"malware"

-- An attack program is available. Note, that worms, viruses and bots (e.g. actively exploiting vulnerabilities) fall into this category too.

B.2.5. The Pre-Defined Values for the "key" Attribute of the "risk" Element

These standard values for the "key" attribute of the "risk" element (The sub-element "risk" of "problem") describe the level of the "techical risk" the problem described in the announcement imposes on affected systems (The "affected" Element). Experience shows, that few values, that are clear in their meaning, make an announcement more easy to understand than a sophisticated set of many only slightly different values that document the quality of the potential risk in great detail. Therefore, CAIF provides a list of four values that are closely attached to the "impact" (The sub-element "impact" of "problem") and partly the "attack-requirements" (The sub-element "attack-requirements" of "problem") necessary for a successful exploitation of the problem described by the announcement. The following values are provided:

"low"

-- the risk imposed is low, an attack and the exploitation respectively of the problem causes an affected system to function improperly in a way that the regular operation is temporarily disturbed.

"medium"

-- an attack or the exploitation of the problem causes an affected system to function improperly in a way that the regular oparation is disturbed severely or terminated, e.g. the system changes to a denial of service status (The Set of Pre-Defined Values for the the "key" Attribute of the "impact" element).

"high"

-- an attack or the exploitation of the problem may result in the mediate compromise via a network connection or the immediate local compromise of an affected system

"very high"

-- an attack or the exploitation of the problem may result in the immediate compromise of an affected system via a network connection.

B.2.6. The Set of Pre-Defined Values for the "key" Attribute of the "probability-of-occurrence" Element

This set ptovides standard values for the "key" attribute of the "probability-of-occurrence" element (The sub-element "probability-of-occurrence" of "problem"). The determination of the probability of the occurrence of an impact (The sub-element "impact" of "problem") as the result of an attack within a specific constituency (The "constituency" element ) as well as the interpretation of the result are not trivial. Experience shows that it is useful to provide only a few values that give a good clue of such a probability to the reader and make the classification a job not too hard for an author. The following set of values - already known from the key set for the "technical risk" (The Pre-Defined Values for the "key" Attribute of the "risk" Element) thus not introducing a new system of value graduation, although the values have different meanings - is provided by CAIF.

"low"

-- The probability of the occurrence of a successful attack is low according the distributor's policy, e.g. around 0 to 0.1.

"medium"

-- The probability of the occurrence of a successful attack is medium according the distributor's policy, e.g. around 0.1 to 0.25.

"high"

-- The probability of the occurrence of a successful attack is high according the distributor's policy, e.g. around 0.25 to 0.5.

"very high"

-- The probability of the occurrence of a successful attack is very high according the distributor's policy, e.g. higher than 0.5.

Note, that the assessment provided by the "probability-of-occurrence" (The sub-element "probability-of-occurrence" of "problem") is specific to a constituency.

Issuers SHOULD provide a document that describes the policy of how classification is done and how the meaning of these values is to be interpretetd. The community of announcement issuers shoud adopt standards as they evolve.

B.2.7. The Set of Pre-Defined Values for the "key" Attribute of the "threat" Element

The set of four pre-defined values for the "key" attribute is intended to help estimate the "threat" (The sub-element "threat" of "problem") a problem imposes on a given constituency (The "constituency" element ). In CAIF's terminology the "threat" is a compilation of "risk" (The sub-element "risk" of "problem") and "probability-of-occurrence" (The sub-element "probability-of-occurrence" of "problem") to express the actual situation within the constituency to which it refers in terms of the urgency to act upon it. In order to keep the system of value graduation intoduced by the key set for the technical risk (The Pre-Defined Values for the "key" Attribute of the "risk" Element) the following pre-defined values are maintained:

"low"

-- The regular operation of the constituency's IT infrastructure is threatened slightly. The solution of the problem (Information about a Possible Solution) is recommended.

"medium"

-- The regular operation of the constituency's IT infrastructure is moderately thratened. The solution to the problem should be applied urgently.

"high"

-- The regular operation of the constituency's IT infrastructure is highly threatened. The solution to the problem MUST be applied urgently, intermediate countermeasures or workarounds like the temporary suspension of the operation of affected systems or the deployment of restricting firewall rules are recommended.

"very high"

-- The bare operation of the constituency's IT infrastructure is threatened. The solution to the problem MUST be applied immediately, intermediate countermeasures or workarounds like the temporary suspension of the operation of affected systems are required to provide protection until the problem is solved.

Appendix C. The Document Type Definition (DTD) of CAIF

<!--
   ================================================================

             Common Announcement Interchange Format (CAIF)
                      Document Type Definition

                            Version  1.2
			    (Revision 2)

                             2005-11-06

                           Oliver  Goebel

                              RUS-CERT
                        Stuttgart University

                        Breitscheidstrasse 2
                         D-70174 Stuttgart
                              Germany

                      Phone: +49-711-121-3678
                      Fax:   +49-711-121-3688
                      Email: goebel@caif.info

                   Copyright (C) Oliver Goebel,
                   The CAIF Project  2002-2005.
    All Rights Reserved. Distribution of this DTD is unlimited.

  This DTD specifies the Syntax of a standardized format for
  security announcements aka advisories. It shall enable
  announcement issuers to easily exchange and automatically process
  such in order to render and specially taylor such for a given
  constituency. It is designed to provide multi-lingual information
  for more than one target group of readers in a single document,
  e.g to allow for rendering several mono-lingual presentations
  containing the information for one target group.

  The format is extensible to flexibly reflect different
  announcement formats. It can be used to store different formats
  and normalize them to allow comparability and distill normalized
  information.

  =================================================================
 -->


<!-- ************* Data types used in this DTD *******************

     LANG-CODE  the lang_code definition according to RFC1766

     UTEXT      text without markup in elements (character data)

     ATEXT      attribute text (character data)

     MTEXT      markup text

     NUMBER     [0-9]+

     DATE       a timestamp, format: YYYY-MM-DD {hh:mm:ss[+|-]hh}

     URI        Uniform Ressource Identifier, e.g. an URL like
                "https://CERT.Uni-Stuttgart.DE/projects/caif/"

     VERSIONNUMBER      has the format nn.nn

     ALIGNTYPES         for tables

     TECH-BACKGROUND    the technical background of readers

     ORGA-OVERVIEW      the organizational overview of readers

     REQUIREMENT-KEYS   predefined values to express
                        attack requirements

     IMPACT-KEYS        predefined values for some standard
                        impacts

     CLASS-KEYS         predefined values for some standard
                        problem classes

     EXPLOIT-KEYS       predefined values for the exploit
                        status

     ASSESSMENT-KEYS    predefined standard values for the
                        various assessments

     LIST-STYLE-KEYS    styles for lists

     RLIST-STYLE-KEYS   styles for refefenced lists

     MENUSTYLE-KEYS     types for menus

     FILETYPE-KEYS      types of files

     URGENCY-KEYS       predefined urgency values for the 'type'
                        element

     LEVEL-KEYS         predefined level values for the 'type'
                        element

     FLAVOR-KEYS        predefined flavor levels for the 'type'
                        element

     RESTRICTION-KEYS   predefinded values describing the
                        restrictions for publishing the announcement

     CONTENT-KEYS       predefined values for the content of several
                        elements indicating wether it should be
                        parsed or not

     REASON-KEYS        predefined values indivcating the reason of
                        a re-issueing of an announcement

     BIBTYPE-KEYS       types of references to external documents for
                        further reading

    *************************************************************
 -->


<!ENTITY % LANG-CODE    "NMTOKEN">

<!ENTITY % UTEXT        "#PCDATA">

<!ENTITY % ATEXT        "CDATA">

<!ENTITY % DATE         "CDATA">

<!ENTITY % NUMBER       "CDATA">

<!ENTITY % PERCENT      "CDATA">

<!ENTITY % URI          "CDATA">

<!ENTITY % MTEXT        "(
                        %UTEXT;               |
                        p                     |
                        b                     |
                        vb                    |
                        em                    |
                        pre                   |
                        vendor                |
                        code                  |
                        program               |
                        service               |
                        protocol              |
                        sys-feat              |
                        file                  |
                        terminal              |
                        user                  |
                        output                |
                        menu                  |
                        list                  |
                        table                 |
                        ilink                 |
                        elink                 |
                        const                 |
                        aff                   |
                        update
                        )*"
>

<!-- Note that the entity MTEXT does not contain rlists (see below)
  -->

<!ENTITY % VERSIONNUMBER        "CDATA">

<!ENTITY % ALIGNTYPES   "(
                        right                 |
                        left                  |
                        top                   |
                        bottom                |
                        center
                        )"
>

<!ENTITY % TECH-BACKGROUND
                        "(
                        admin                 |
                        user                  |
                        developer
                        )"
>

<!ENTITY % ORGA-OVERVIEW
                        "(
                        employee              |
                        middle-management     |
                        senior-management
                        )"
>

<!ENTITY % REQUIREMENTS-KEYS
                       "(
                       local                  |
                       network-group          |
                       null-session           |
                       broadcast-domain       |
                       application-user       |
                       remote                 |
                       other
                       )"
>

<!ENTITY % IMPACT-KEYS "(
                       denial-of-service      |
                       information-leak       |
                       data-manipulation      |
                       user-compromise        |
                       system-compromise      |
                       other
                       )"
>

<!ENTITY % CLASS-KEYS  "(
                       buffer-overflow-bug    |
                       format-string-bug      |
                       insecure-configuration |
                       insecure-defaults      |
                       design-flaw            |
                       implementation-flaw    |
                       malware                |
                       other
                       )"
>

<!ENTITY % EXPLOIT-KEYS
                       "(
                       unknown                |
                       rumored                |
                       advertised             |
                       observed               |
                       proof-of-concept       |
                       malware
                       )"
>

<!ENTITY % ASSESSMENT-KEYS
                       "(
                       low                    |
                       medium                 |
                       high                   |
                       very-high
                       )"
>

<!ENTITY % LIST-STYLE-KEYS
                       "(
                       numbers                |
                       symbols                |
                       empty
                       )"
>

<!ENTITY % RLIST-STYLE-KEYS
                       "(
                       numbers                |
                       symbols                |
                       ref-text               |
                       empty
                       )"
>


<!ENTITY % MENUSTYLE-KEYS
                       "(
                       pull-down             |
                       pull-up               |
                       pop-up                |
                       window                |
                       tab                   |
                       tree                  |
                       input                 |
                       button
                       )"
>


<!ENTITY % FILETYPE-KEYS
                      "(
                      text                  |
                      log                   |
                      config                |
                      source                |
                      binary
                      )"
>


<!ENTITY % URGENCY-KEYS
                      "(
                      alert                 |
                      warning               |
                      advisory              |
                      informational
                      )"
>


<!ENTITY % LEVEL-KEYS
                     "(
                     brief                  |
                     full                   |
                     digest                 |
                     other
                     )"
>


<!ENTITY % FLAVOR-KEYS
                     "(
                     vulnerability-description |
                     patch-notification        |
                     heads-up                  |
                     other
                     )"
>



<!ENTITY % CONTENT-KEYS
                     "(
                     base64                   |
                     parsed
                     )"

>

<!ENTITY % REASON-KEYS
                     "(
                     exploit                  |
                     risk                     |
                     patch                    |
                     other
                     )"
>

<!ENTITY % BIBTYPE-KEYS
                     "(
                     primary                  |
                     further-reading
                     )"
>


<!-- *****************  Mark-up elements ********************** -->


<!ELEMENT em            %MTEXT;>

<!ELEMENT b             %MTEXT;>

<!ELEMENT vb            %MTEXT;>

<!ELEMENT pre           (%UTEXT;)>

<!ELEMENT vendor        %MTEXT;>

<!ELEMENT code          (%UTEXT;)>

<!ELEMENT program       (%UTEXT;)>

<!ELEMENT service       (%UTEXT;)>

<!ELEMENT protocol      (%UTEXT;)>

<!ELEMENT sys-feat      (%UTEXT;)>

<!ELEMENT file          (%UTEXT;)>
<!ATTLIST file
        path            %ATEXT;             #IMPLIED
        type            %FILETYPE-KEYS;     #IMPLIED
>

<!ELEMENT output        (%UTEXT;)>

<!ELEMENT user          (%UTEXT;)>
<!ATTLIST user
        prompt           %ATEXT;            #IMPLIED
        >

<!ELEMENT terminal      %MTEXT;>


<!ELEMENT menu          %MTEXT;>
<!ATTLIST menu
        style           %MENUSTYLE-KEYS;    #REQUIRED
        title           %ATEXT;             #IMPLIED
        >

<!ELEMENT const         %MTEXT;>
<!ATTLIST const
        ref             IDREFS              #REQUIRED
        >

<!ELEMENT aff           %MTEXT;>
<!ATTLIST aff
        id              ID                  #REQUIRED
        >

<!-- ....................... update .......................... -->

<!ELEMENT update        (
                        invalid?
                        )
>
<!ATTLIST update
          version       %VERSIONNUMBER;     #REQUIRED
>
<!ELEMENT invalid       %MTEXT;>

<!-- ....................  paragraph .......................... -->

<!ELEMENT p             %MTEXT;>


<!-- ..................... table .............................. -->

<!ELEMENT table         (
                        p?,
                        tr+,
                        p?
			)
>


        <!-- ..... sub-elements to table ..... -->

        <!ELEMENT tr    (
	        td+
                )
        >

        <!-- ..... sub-elements to tr ..... -->

                <!ELEMENT td
                                        %MTEXT;
                >
                <!ATTLIST td
                        align           %ALIGNTYPES;    #IMPLIED
                        colspan         %NUMBER;        #IMPLIED
                >


<!-- ........................ list ........................... -->

<!ELEMENT list          (
                        p?,
                        li+,
                        p?
                        )
>
<!ATTLIST list
        style           %LIST-STYLE-KEYS;      "symbols"
>

<!-- .................. list item ........................... -->

<!ELEMENT li            %MTEXT;>



<!-- *** Elements for structured and referenced formatting ***  -->

<!-- ...................... body .......................... -->

<!ELEMENT body  %MTEXT;>
<!ATTLIST body
          tg-ref        IDREFS                  #IMPLIED
          headline      %ATEXT;                 #IMPLIED
>


<!-- ...................... rlist ......................... -->

<!ELEMENT rlist         (
                        p?,
                        rli+,
                        p?
                        )
>
<!ATTLIST rlist
          tg-ref        IDREFS                  #IMPLIED
          headline      %ATEXT;                 #IMPLIED
          style         %RLIST-STYLE-KEYS;      "numbers"
>


<!-- .................. rlist item ........................ -->


<!ELEMENT rli           %MTEXT;
          >
<!ATTLIST rli
          problem-ref   IDREFS                  #IMPLIED
          >

<!-- ............ document internal reference ............ -->

<!ELEMENT ilink         (%UTEXT;)>
<!ATTLIST ilink
          target        IDREF                   #REQUIRED
          >


<!-- ........the target to which the ilink points ........ -->

<!ELEMENT itarget       EMPTY
          >
<!ATTLIST itarget
          name          ID                      #REQUIRED
          >

<!-- ............ External reference ..................... -->

<!ELEMENT elink         (%UTEXT;)>
<!ATTLIST elink
          target        %URI;                   #REQUIRED
          >

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!--               the over all format                         -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->


<!ELEMENT caif (

        identification,
        target-groups?,
        constituencies?,
        revisions,
        category,
        subject,
        summary,
        problems?,
        affected?,
        not-affected?,
        possibly-affected?,
        determine-affectedness?,
        mitigation?,
        context?,
        description?,
        workaround?,
        solution?,
        arbitrary*,
        bibliography?,
        credits?,
        disclaimer*,
        other-documents?,
        rendered-copies?
        )
>

<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!--                     the elements                          -->
<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

<!-- ................... identification ...................... -->


<!ELEMENT identification (
        issuer,
        announcement,
        type,
        author*,
        distribution-allowed?,
        earliest-release?
        )

>

    <!-- - - - - subelements to identification - - - - -->

        <!ELEMENT issuer        (%UTEXT;)>
        <!ATTLIST issuer
                       id       %ATEXT;         #REQUIRED
        >

        <!-- a unique format could be: number = $issuer_id#number,
	e.g.  RUS-CERT#1220 -->

        <!ELEMENT announcement                  EMPTY>
        <!ATTLIST announcement
                id     %NUMBER;                 #REQUIRED
        >

        <!ELEMENT type          (body+)>
        <!ATTLIST type
                urgency         %URGENCY-KEYS;  #IMPLIED
                level           %LEVEL-KEYS;    "other"
                flavor          %FLAVOR-KEYS;   "other"
        >

        <!ELEMENT author        (%UTEXT;)>
        <!ATTLIST author
                initials        %ATEXT;         #IMPLIED
                surname         %ATEXT;         #IMPLIED
                e-mail          %URI;           #IMPLIED
        >


        <!ELEMENT distribution-allowed  EMPTY>
        <!ATTLIST distribution-allowed
                const-ref       IDREFS          #REQUIRED
        >

        <!ELEMENT earliest-release   (%UTEXT;)>
        <!ATTLIST earliest-release
                date            %DATE;          #REQUIRED
        >

<!-- ................... target-groups ....................... -->

<!ELEMENT target-groups (target-group+)
>

<!-- ................... target-group ........................ -->
<!ELEMENT target-group          %MTEXT;>
<!ATTLIST target-group
        id                      ID                   #REQUIRED
        lang                    %LANG-CODE;          #REQUIRED
        tech-background         %TECH-BACKGROUND;    "admin"
        orga-overview           %ORGA-OVERVIEW;      #IMPLIED
        environment             %ATEXT;              #IMPLIED
        headline                %ATEXT;              #IMPLIED
>

<!-- .................. constituencies ....................... -->

<!ELEMENT constituencies (constituency+)
>

        <!ELEMENT constituency  (
                body+
                )
        >
        <!ATTLIST constituency
                id              ID              #REQUIRED
        >

<!-- ..................... revisions ......................... -->

<!ELEMENT revisions     (

        body*,
        issued,
        re-issued*,
        revision*
        )
>

    <!-- - - - -  Subelements to revisions  - - - -  -->

        <!ELEMENT issued        EMPTY>
        <!ATTLIST issued
                version         %VERSIONNUMBER; #REQUIRED
                date            %DATE;          #REQUIRED
        >
        <!ELEMENT re-issued     (body+)>
        <!ATTLIST re-issued
                version         %VERSIONNUMBER; #REQUIRED
                date            %DATE;          #REQUIRED
                reason          %REASON-KEYS;   "other"
        >

        <!ELEMENT revision      (body+)>
        <!ATTLIST revision
                version         %VERSIONNUMBER; #REQUIRED
                date            %DATE;          #REQUIRED
        >


<!-- ..................  category ........................... -->

<!ELEMENT category       EMPTY>
<!ATTLIST category
        platform         %ATEXT;                #REQUIRED
        product          %ATEXT;                #IMPLIED
        protocol         %ATEXT;                #IMPLIED
>



<!-- ................... subject ............................ -->


<!ELEMENT subject        (body+)>


<!-- .................... summary ........................... -->


<!ELEMENT summary        (body+)>


<!-- ................... problems ........................... -->


<!ELEMENT problems      (
                        body*,
                        problem+
                        )
>

        <!-- - - - - Subelements to problems - - - - -->

        <!ELEMENT problem   (
                            body+,
                            class?,
                            attack-vector?,
                            attack-requirements?,
                            attack-signature?,
                            impact?,
                            exploit-status?,
                            risk?,
                            probability-of-occurrence*,
                            threat*
                            )
	>
        <!ATTLIST problem
                id          ID                  #IMPLIED
	>

        <!-- sub-elements to problem -->

	<!ELEMENT class (
                        body*
                        )
        >

	<!ATTLIST class
	 	key	%CLASS-KEYS;         "other"
        >



        <!ELEMENT attack-vector
                        (
                        body+
                        )
        >

        <!ELEMENT attack-requirements
                        (
                        body*
                        )
        >
        <!ATTLIST attack-requirements
                key     %REQUIREMENTS-KEYS;  "other"
        >

        <!ELEMENT attack-signature
                        (
                        body+
                        )
        >
        <!ATTLIST attack-signature
                type     %ATEXT;            #IMPLIED
        >


	<!ELEMENT impact
	                (
			body*
			)
        >
	<!ATTLIST impact
	 	key	%IMPACT-KEYS;       "other"
        >



	<!ELEMENT exploit-status
	                (
			body*
			)
        >
	<!ATTLIST exploit-status
	 	key	%EXPLOIT-KEYS;      "unknown"
        >



	<!ELEMENT risk
	                (
			body*
			)
        >
	<!ATTLIST risk
	 	key	%ASSESSMENT-KEYS;       #IMPLIED
		policy  %ATEXT;                 #IMPLIED
        >




	<!ELEMENT probability-of-occurrence
	                (
			body*
			)
        >
	<!ATTLIST probability-of-occurrence
                const-ref
                        IDREFS                  #IMPLIED
	 	key	%ASSESSMENT-KEYS;       #IMPLIED
		policy  %ATEXT;                 #IMPLIED
        >



	<!ELEMENT threat
	                (
			body*
			)
        >
	<!ATTLIST threat
                const-ref
                        IDREFS                  #IMPLIED
	 	key	%ASSESSMENT-KEYS;       #IMPLIED
		policy  %ATEXT;                 #IMPLIED
        >


<!-- .....................mitigation......................... -->


<!ELEMENT mitigation    (
                        body+   |
                        rlist+
                        )
>

<!-- ...................  affected  ......................... -->


<!ELEMENT affected      (
                        body+   |
                        rlist+
                        )
>

<!-- ...................  not-affected  ..................... -->



<!ELEMENT not-affected  (
                        body+   |
                        rlist+
                        )
>

<!-- .................  possibly-affected ................... -->



<!ELEMENT possibly-affected (
                        body+   |
                        rlist+
                        )
>


<!-- ................determine-affectedness.................. -->

<!ELEMENT determine-affectedness (
                        detitem+
                        )
>


<!ELEMENT detitem       (
                        body+
                        )
>

<!ATTLIST detitem
        method          %ATEXT;                #IMPLIED
        aff-ref         IDREFS                 #REQUIRED
	problem-ref     IDREFS                 #IMPLIED
        content-type    %CONTENT-KEYS;         #IMPLIED
>

<!-- ..................... context .......................... -->

<!ELEMENT context       (
                        body+   |
                        rlist+
                        )
>

<!-- .................. description ......................... -->

<!ELEMENT description   (
                        body+   |
                        rlist+
                        )
>

<!-- .................. workaround .......................... -->

<!ELEMENT workaround    (
                        body+   |
                        rlist+
                        )
>

<!-- ................... solution ........................... -->

<!ELEMENT solution      (
                        body+   |
                        rlist+
                        )
>

<!-- .................. arbitrary ........................... -->

<!ELEMENT arbitrary     (
                        body+   |
                        rlist+
                        )
>
<!ATTLIST arbitrary
        name            ID                      #REQUIRED
        extends         %ATEXT;                 #IMPLIED
>

<!-- ................... bibliography ....................... -->

<!ELEMENT bibliography  (
                        body*,
                        bibitem+
                        )
>


<!ELEMENT bibitem       %MTEXT;>
<!ATTLIST bibitem
        name            ID                      #IMPLIED
        type            %BIBTYPE-KEYS;          #REQUIRED
        problem-ref     IDREFS                  #IMPLIED
        date            %DATE;                  #IMPLIED
        content-lang    %LANG-CODE;             #IMPLIED
        tg-ref          IDREFS                  #IMPLIED
        const-ref       IDREFS                  #IMPLIED
>
<!--
  bibtem's attribute "content-lang" describes the language of the
  referenced resource
  -->

<!-- .................... credits ........................... -->

<!ELEMENT credits     (
                      body+     |
                      rlist+
                      )
>

<!-- .................. disclaimer .......................... -->

<!ELEMENT disclaimer (
                     body+
                     )
>

<!-- .................. other-documents ....................  -->

<!ELEMENT other-documents (
                     body*,
                     other-document+
                     )
>

<!ELEMENT other-document (%UTEXT;)>
<!ATTLIST other-document
        content-type    %ATEXT;                 #IMPLIED
        description     %ATEXT;                 #IMPLIED
>

<!-- .................. rendered copy ....................  -->

<!ELEMENT rendered-copies (
		     rendered-copy+
                     )
>

<!ELEMENT rendered-copy (%UTEXT;)>
<!ATTLIST rendered-copy
        content-type    %ATEXT;                 #IMPLIED
        tg-ref          IDREFS                  #IMPLIED
        headline        %ATEXT;                 #IMPLIED
>

<!-- ......................... END ....................... -->

Appendix D. Acknowledgements

The author gratefully acknowledges the contributions of:

• Friedemann Bauer (RUS-CERT),
• Andrew Cormack (UKERNA),
• Hans de Vries (TU Delft),
• Tom Fischer (RUS-CERT),
• Anselm Garbe (RUS-CERT),
• Igor Gilitschenski (RUS-CERT),
• Detlef Guenther (CERT-VW),
• Michael Hartmann (SAP),
• Tim Heinken (CERT-VW),
• Damir Rajnovic (CISCO-PSIRT),
• Joachim Ring (ComCERT),
• Rolf Schulz (GNSec),
• Kurt Seifried,
• Helmut Springer,
• Florian Weimer (RUS-CERT),
• and Hans Ulmer (SAP-CERT)

Author's Address