| TOC |
|
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.
(c) Copyright Oliver Goebel, The CAIF Project 2004-2005
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.
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
| TOC |
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.
| TOC |
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:
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.
| TOC |
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:
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.
| TOC |
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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).
| TOC |
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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)).
| TOC |
To provide a uniform usage of terms this section defines the basic terminology used in this document.
| TOC |
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)).
| TOC |
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.
| TOC |
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.
| TOC |
- "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.
| TOC |
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.
| TOC |
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)).
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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
| TOC |
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".
| TOC |
A person who reads an announcement, usually a member of the constituency (Constituency).
| TOC |
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).
| TOC |
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.
| TOC |
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).
| TOC |
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.
| TOC |
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:
[token1] token2
matches
token2
as well as
token1 token2
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.
token1|token2
or
(token1|token2)
match
token1
or
token2
<element id="ID"/>
matches the following code:
<element id="This_is_an_id"/>
but not
<element id="This is an id"/>
<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".
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.
| TOC |
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.
| TOC |
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.
| TOC |
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").
| TOC |
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.
| TOC |
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>
| TOC |
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/>
| TOC |
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"/>
| TOC |
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.
-->
| TOC |
The following rules apply to produce "well-formed" (Well-Formedness) documents:
<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.
<element> blah </Element>
This is not allowed in XML because the end tag "</Element>" does not match the start tag "&element>".
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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).
| TOC |
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.
| TOC |
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).
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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).
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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!
| TOC |
CAIF provides markup elements for special text strings to increase the readability of renderings.
| TOC |
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>
| TOC |
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.
| TOC |
The "code" element marks up source-code snippets within the t