Abstract

This memo describes requirements for an advisory interchange format. Comments and criticism are welcome. Distribution of this memo is unlimited.

Table of Contents

1.  Motivation
2.  Scope of this Document
3.  Basic Terminology
4.  General Requirements
    4.1  Reader Requirements
    4.2  Distributor Requirements
    4.3  Issuer Requirements
5.  Advisory Structure
    5.1  General Information
    5.2  Information About The Problem
    5.3  Restrictions and Information Related to Distribution
    5.4  Including Other Text Documents
    5.5  Free-Text Sections
    5.6  Disclaimer
    5.7  Contact Information
6.  Text Markup
7.  Presentation
8.  Categorization
9.  Coordination
10.  Security Considerations
11  References
    11.1  Normative References
    11.2  Informal References
Authors' Addresses
A.  Related work on standardization of advisories
    A.1  rain forest puppy's Full Disclosure Policy
    A.2  The Withdrawn Draft on Responsible Disclosure
    A.3  Tristan Debaupuis' Internet Draft
    A.4  JANET Guideance Notes: Writing Advisories
    A.5  The CVE Dictionary
    A.6  The NIST ICAT Database
B.  Acknowledgements

1. Motivation

Due to the way information technology is being deployed, security defects are and will be a threat operators of IT infrastructure have to deal with, especially if it is connected to the world-wide Internet. Therefore, information on security issues is vital for operating such infrastructure.

Such information is available from many sources, in very different formats. Over the years, a specific notification method for security issues has evolved: the security advisory. However, while there is consensus among authors that such a class of documents exists, current security advisories differ substantially in almost any aspect. This diversity leads to three major problems:

• Infrastructure operators who read original security advisories need considerable amount of time, experience, and expertise, to decide if action is necessary and what countermeasures have to be taken.
• Providers of security-related information have to prepare their own advisory, in a format familiar to their audience, resulting in a massive duplication of work.
• It is not immediately obvious if two security advisories 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.

We believe that a uniform structure for security advisories can help to reduce these problems. Structured advisories also have the potential to facilitate augmented redistribution, e.g. the preparation of derived documents tailored to meet reader-specific requirements.

However, distributors of security advisories need to present these advisories according to local typesetting conventions. This is the reason why a presentation-independent interchange forma} is needed to avoid that many different advisories are issued regarding the same topic.

A standardized structure for security advisories helps authors to include information readers need to quickly decide the relevance of an advisory. Combined with the familiarity a standard format will create among readers, this potentially results in easier access to security-relevant information.

As a conclusion, a standardized structure for security advisories can help to disseminate essential information on security issues both more quickly and more widely. A canonical way of reading security advisories shall help to increase security awareness among readers who currently lack the time and experience needed to cope with the current flood of vastly different advisories.

2. Scope of this Document

This document describes requirements that the Common Advisory Interchange Format (CAIF) shall meet.

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

• this requirements document,
• the format specification (based on the requirements described in this document)
• the description of a category system,
• 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 advisories 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 advisories.

3. Basic Terminology

advisory

A document which describes a computer security problem or a solution of such a problem.

distribution

The act of an issuer giving others access to his or her own advisories. The issuer is said to "distribute" an advisory.

redistribution

The act of letting others access an advisory after it has been received (either from the issuer, or from another distributor). The distributor is also said to "redistribute" an advisory.

distributor

A party who distributes or redistributes advisories.

issuer

The author of an advisory, or, if the author works for an institution which chooses to attribute advisories to itself, that institution.

reader

A person who reads an advisory.

section

A part of an advisory containing specific information. "Standard sections" have well-defined content, which sometimes can be processed automatically.

field

A subdivision of a section, containing one information unit.

container

A mechanism for transport and storage which combines several CAIF documents (maybe from different issuers) related to a specific problem and which can be treated as a single unit.

NOTE: Should there be a distinction between "advisory" and "alert"?

4. General Requirements

In this section, we will briefly examine the needs of different parties dealing with advisories.

4.1 Reader Requirements

Readers need answers to the following questions:

• Who sent the advisory? Is this document authentic?
• Is it relevant to me?
• Do I have to react? If yes, how fast?
• What are my options?

In the presentation form, the advisory should provide the necessary information to answer the second question unambiguously at the beginning of the document.

In addition, some readers will have to prepare documents regarding the problem for non-technical people, e.g. if an important service has to be suspended because of a weakness in a key component. We doubt that it is possible to distribute prefabricated documents for this purpose in most cases because issuers cannot know how technology is deployed by readers. CAIF should provide means to add further, site-specific data to advisories, using acontainer which contains related documents.

4.2 Distributor Requirements

A CAIF advisory is intended to be reformatted according to the local needs of a distributor. Therefore, it should not contain any visual markup, but only structural markup.

It should be easy to write parsers and generators for CAIF advisories. Conversion of advisories to other formats should be straightforward.

In most cases, it should be possible to decide mechanically whether and how redistribution of a document is permitted.

Augmented distribution which leaves signatures intact (see Section 10) should be possible as well: Distributors may want to add information which is specifically targeted at their audience: translations, clarifications, additions reflecting local deployment and usage patterns, and so on.

It has to be possible to document that an advisory is a translation of another advisory.

4.3 Issuer Requirements

NOTE: Issue requirements are still subject to debate.

RUS-CERT has identified the following requirements: The CAIF specification should not result in sophisticated technical requirements for issuers. A simple text editor shall suffice to prepare CAIF documents, except for the creation of digital signatures. This requirement conflicts with the distributor requirement of easy parsing and the implementation as in XML, as all structural information has to be explicit in XML documents.} However, these requirements cannot serve as general ones because they lack sufficient justification to be globally applicable.%

5. Advisory Structure

Advisories typically consist of several sections. Many of them are considered essential by the security community, but there seems to be no general agreement on the exact content of each section. CAIF shall specify several standard sections, some of them mandatory for each advisory.

The description below only lists the required data at interchange format level. For presentation purposes, the sections and fields are rearranged in an order which has yet to be determined (see Section 7). This happens during conversion to other formats performed by distributors or readers.

An issuer might want to incorporate information from various sources, offering different reliability and trust, and tag which field contents have been confirmed by the issuer. At least the following tags appear to be necessary:

• unconfirmed
• unable to reproduce
• confirmed (by issuer)
• confirmed by different entity (referenced by a unique ID, see Section 9

Distributors could use these tags as well.

5.1 General Information

Some data is required to properly identify an advisory and its issuer:

• the subject of the advisory, i.e. the heading (preferably less than 70 characters, for compatibility with mail messages)
• an unambiguous identification of the issuer, that is a name and an email address, and the name of the issuing organization or person (see Section 5.6 for a way to give full contact information) [NOTE: KPK wonders why this redundancy is necessary.]
• an advisory number, which references the issuer (by containing a unique identifier)
• a version number (in a standard format to permit mechanical processing)
• the issuing date of the advisory
• the date of the last revision
• references to information on which the advisory was based (a vendor announcement, for example)
• references to advisories for the same vulnerability (for instance, translations, or non-CAIF advisories)
• references to related advisories on different topics
• a revision history which lists major changes
• the language the advisory is written in
• a list of CVE names (Appendix A.5) addressed by this advisory
• credits related to the described vulnerability [NOTE: Such information is necessary by certain processes (see Appendix A.1} for an example). Such information could also be included in one of the free-text sections. Shall we remove this field?]

5.2 Information About The Problem

For a given problem, the reader needs the following information in order to decide if his or her systems are vulnerable, and what reaction (if any) is necessary, in what time frame:

• a list of systems which are known to be affected (mandatory)
• a list of systems which are potentially or probably affected but not confirmed at the time the advisory is published (optional)
• a list of systems which are known to be not affected (optional)
• an indication of systems which are vulnerable only in certain configurations
• attack requirements (e.g. access at the Ethernet link layer, TCP/IP network, interactive login, console access; mandatory, but can be unknown, e.g. if the vendor doesn't supply this information)
• the attack vector (e.g. a specially crafted HTTP request; mandatory)
• probability of attack
• the impact (e.g. root compromise, denial of service; mandatory)
• the cause (e.g. a missing bounds check, insufficient privilege checking; optional)
• the vulnerability class (e.g. remotely exploitable root buffer overflow)
• a short statement describing the severity of the vulnerability (optional)
• vendor status (contact date, availability of a patch, for example; mandatory, but might be unknown)
• attack signatures (logfile excerpts, IDS signatures)

[NOTE: How are the last fields related to each other?]

Readers who know which technology they are using need a rating which is independent of the probability that the affected product or service is installed or activated at all. For less informed readers, a rating which reflects how widespread the affected product or configuration is (and thus, the attack probability) should be supplied.

The "vulnerability class" summarizes multiple aspects of common vulnerabilities, for example, attack vector ("remotely exploitable"), cause ("buffer overflow"), and impact ("root compromise"), e.g. a "remotely exploitable bufer overflow, leading to root compromise".

CAIF shall provide the items listed above in a specific section with suitable subsections. The information in these section shall be human readable.

5.3 Restrictions and Information Related to Distribution

An advisory might contain critical information which should not be made public at the moment, or might still be subject to review. CAIF shall provide a standard section which describes this state.

Some issuers may wish to restrict the redistribution for certain well-defined commercial purposes. CAIF shall define commercial use of an advisory, and provide means to express and honor such wishes, but it should still be possible to redistribute advisories automatically.

Issuers might want to restrict the distribution of their advisories to a verbatim, unmodified form (perhaps except for changes resulting from CAIF-conforming presentation forms).

CAIF should support the implementation of different disclosure procedures. Such procedures might lead to the following distribution restrictions:

• no public distribution at all
• public distribution without any restrictions
• restricted distribution before a given date, and public distribution after it

For more complicate cases, CAIF shall enable issuers to state that redistribution must only happen after manual inspection.

Some sections (for example, the context section described in Section 5.5) can be reused by different issuers in different advisories. CAIF could provide a mechanism for issuers to indicate that they encourage reuse of such sections. (It is not clear if such reuse is covered by fair use, so explicit permission is required.)

5.4 Including Other Text Documents

It shall be possible to include other text documents, for example vendor advisories, in the CAIF container. [NOTE: This is also helpful for implementing the mechanisms mentioned in Section 10.]

5.5 Free-Text Sections

In addition to the structured information described so far, an advisory provides unstructured information as well:

• Audience (mandatory). Not all documents are intended for all reader audiences. This section should state who should read the document.
• Information for end users (mandatory). Although most problems cannot be resolved by end users, we want to encourage them to stay informed about security issues. This means that we have to tell them if they are affected by a problem, and what they can do. Such information has to be presented near the top of the advisory. Sometimes, end users are unaffected by vulnerabilities or cannot do anything to counter them. This has to be stated, too.
• Context (optional). We have to recognize the fact that people run services without knowing many technical details about them, sometimes even not knowing that they are running them, or why they need this service. The context section shall provide background information explaining the affected service (for example, so that readers can decide if they can disabled it without impact on legitimate use).
• Description (mandatory). In this section, the issuer describes the vulnerability, providing information which did not fit into the structure presented so far.
• Checking for affectedness (optional). In some cases, a vulnerability is only relevant if a system is configured in a certain way. This section describes how readers can check if their configuration is affected.
• Countermeasures (optional). Temporary countermeasures might reduce the impact of attacks, make attacks impossible (by disabling the service in question), or add substantial attack requirements.
• Resolution (optional). This section lists the steps to be taken to resolve the problem permanently (e.g. applying a vendor patch).
• Attack detection (optional). This section describes observable effects of exploits of the vulnerability (logfile entries, network activity).

Being a format standard, CAIF~shall not prescribe the level of detail in the description, although we believe that enough details for independent verification are required for properly dealing with security issues.

5.6 Disclaimer

A standard section is required which includes a warranty disclaimer and other legal information. It has to be the responsibility of the issuer to ensure that distribution restrictions mentioned in the disclaimer and in the information in the distribution restrictions section match. The disclaimer section shall contain only one field, and it is optional.

5.7 Contact Information

An optional standard section with contact information shall be provided by CAIF. The contact information shall be represented in unstructured text. (Structured contact information is already provided, see Section 5.1.) Therefore, only a single field in this section is required, which can list multiple contacts if necessary.

6. Text Markup

In order to facilitate the presentation of the description in various formats, a high-level markup language has to be used for unstructured text, which shall provide the following features:

• Several types of emphasis:
  • minor, can be omitted in Spartan formats (e.g. plain text)
  • normal, has to have a visible effect in all formats
  • major, clearly visible in all formats (should be used with care by issuers)
• Markup for special text strings:
  • product names
  • program and command names
  • file names
  • environment variables
  • short code portions
  • pulldown/popup menu entries
• Markup for text sections:
  • short quotes and quotations (the latter consisting of several paragraphs)
  • shell interaction and other screen contents
  • file contents (suitable for cut and paste in the text version)
  • unnumbered and numbered enumerations
  • simple tables
• Special constructs for hyperlinks etc.:
  • URLs (including email addresses), both with and without substitute text for formats without hyperlinks
  • references to glossary entries
  • references to well-known ressources (e.g. RFCs)
  • references to inline or external images (screen shots and so on, should be used with care by issuers)

[NOTE: It should be examined if a DocBook subset can be used for this kind of markup. Otherwise, Texinfo markup constructs could be used, but in a different syntactic environment.]

7. Presentation

CAIF should specify certain sets of minimum requirements for presentation formatting, and issuers have to be able to choose which requirement sets are allowed for rendering a specific advisory. Some issuers may want to permit verbatim redistribution only, where "verbatim" means that a specific presentation form contains all information in the advisory. Other issuers might permit some sections or fields (e.g. the context section mentioned above) to be included in other advisories. CAIF should define requirements for citation (including ascription).

CAIF shall provide recommendations for additional presentation forms besides the required ones. For example, the order of the sections and their contents should reflect the reader expectations outlined in Section 4.1.

8. Categorization

Some readers will want to receive advisories only for certain platforms or software by specific vendors. In order to mechanically sort advisories, they have to be categorized.

The category model will be described in a separate document. The category model must meet the aforementioned reader's requirements Issuers must be able to categorize advisories easily (that is, without browsing endless category lists). There must be a backbone of globally understood categories, so that readers can and distributors can select advisories based on certain well-known categories.

A single set of categories can be used to categorize the items below. (Otherwise, an extension mechanism for additional classes of categories had to be defined.) Categories are associated with whole CAIF documents, not with single fields.

At least the following information shall be mapped to categories:

• reader audiences,
• vendor, product, and platform,
• vulnerability impact, attack vector, and class.

Obviously, there is some redundancy if information is both present in the association of a CAIF document with a category and in a section or field, but the information in the corresponding sections is textual and more verbose, and the categorization omits some data, but can be processed mechanically. In addition, it is wishful thinking to assume that a category model can express any attack vector, vulnerability impact, or type, so a free-text section is still required.

The categories have to be updated from time to time, for example, when new products or vulnerability types become common. However, there does not seem to be a reliable way to distribute category updates along with advisories, so a centrally administered category database (including the relationships among categories) is required.

9. Coordination

CAIF as proposed in this document encompasses several shared namespaces:

• IDs for issuers (contained in advisory numbers), together with PKI-related information,
• IDs for vendors,
• categories and their relationships.

Central coordination is necessary to avoid collisions between issuer IDs, and to maintain a backbone of globally understood categories and their relations.

CAIF advisories have to refer unambiguously to vendors, products and product lines, and product versions. However, certain events (such as marketing, or sale of product lines to a different vendor, or mergers) can infleit changes on product names. In order to enable comparison of advisories over longer time periods, constant and unambiguous identifiers for

• products and product lines, and
• product versions

are highly desirable. [NOTE: It is not clear if this in the scope of CAIF. Is such a database of identifiers deemed necessary?]

10. Security Considerations

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

Readers want to know if advisories 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 has to include a rendered and signed copy of it, preferably both in text and MIME format (conforming to [4]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).

All parties exchanging CAIF documents whose authenticity they want to verify need to be part of the same PKI.

11. References

11.1 Normative References

11.2 Informal References

Authors' Addresses

Appendix A. Related work on standardization of advisories

This section lists work related to the standardization of advisories of which the issuers were aware. Its impact on CAIF is briefly discussed.

A.1 rain forest puppy's Full Disclosure Policy

Rain forest puppy's Full Disclosure Policy describes the once canonic way of interaction between researchers and software maintainers and deals with problem areas such a minimum time for software maintainers before public disclosure, but also (non-monetary) compensation for the discoverers of vulnerabilities. (Recent developments, however, show that Full Disclosure is no longer supported by the majority of researchers, if it ever was.)

As a result, CAIF and the Full Disclosure Policy cover disjoint scopes, but the latter should be referenced in the CAIF specification nevertheless, to underline that there are social aspects of advisories as well, not just syntactic or technical ones.

A.2 The Withdrawn Draft on Responsible Disclosure

In early 2002, an attempt was made to describe a standard process for the disclosure of security vulnerabilities in [5]Christey, S. and C. Wysopal, Responsible Vulnerability Disclosure Process, February 2002.. Public discussion showed that there is currently no consensus in the IETF regarding the process described. In addition, it was decided that such process descriptions are not in the scope of the IETF at all.

CAIF is primarily a format specification. As a side effect of the format, issuers will be encouraged to include certain pieces of information, but the process how and when advisories are distributed is outside the scope of CAIF. However, CAIF is intended to provide a technical framework to implement such processes.

A.3 Tristan Debaupuis' Internet Draft

Tristand Debaupuis' "Security Advisory Format" Internet Draft ([6]Debeaupuis, T., Security Advisory Format, May 1999. shares many goals with CAIF.

Debaupuis is convinced as well that many parties can benefit from advisories in a standard format. However, Debaupuis seems to hope that two incarnations of the same advisory providing essentially the same information can coexist: an XML version (difficult to read for humans, easy to read for machines) and a plain text version (easy for humans, difficult, but still parsable for machines). We doubt that it is reasonable to assume that it is possible to parse vendor advisories to convert them to a more structured XML version, due to the current, changing nature of vendor advisory formats. With the parsing approach, the definite copy of an advisory can be in non-standard format, and as a result, conversion from the standard format to formats with additional markup (e.g. HTML with rich markup) does not make sense, and the DTD does not provide any means for text markup (besides structuring the whole advisory).

The document type definition given in this draft is not an XML DTD, but one for SGML, contrary to the claim in the draft. (Perhaps this is related to the fact that reliable XML technology was not availabe when the draft was written for the first time.) Furthermore, the encoding requirements are incompatible with XML and might hamper its deployment.

A.4 JANET Guideance Notes: Writing Advisories

[NOTE: This document [7]Cormack, A., Writing Advisories, March 2002. was published when the work on this revision of the CAIF requirements document was finished. Therefore, it has not influenced CAIF yet.]

A.5 The CVE Dictionary

The Common Vulnerabilities and Exposures dictionary is an attempt to assign identifiers to vulnerabilities in a way such that the same vulnerability gets the same identifier (whatever `same vulnerability' means). New vulnerabilities are assigned candidate numbers, the canditates are subject to a review process, and may end up in the general CVE dictionary.

The CVE dictionary does not contain detailed information on vulnerabilities, but references advisories describing them. As a result, CVE is not directly relevant for CAIF, but it should still be possible to attach CVE identifiers to CAIF advisories.

[NOTE: CVE distinguishes between vulnerabilities (which are critical for all applications) and exposures (which are not relevant in some environments, for example, certain kinds of information leaks). It is open to debate whether CAIF should made this distinction as well.]

A.6 The NIST ICAT Database

The National Institute of Standards and Technology, an institution of the US government, maintains a structured vulnerability database (which happens to use CVE in turn). The database does not store complete advisories, but considerably more information than the CVE dictionary:

• severity
• short CVE description
• the component name which is affected (called "exposed component")
• the name of the software in a specific format
• up to five hyperlinks for external references, associated with data on the type of information referenced
• several boolean fields specifying:
  • attack requirements
  • vulnerability types
  • loss types (impact types)
  • domain type (affected class of operating systems)
  • exposed components
• vendor name
• product name
• version number (of the vulnerable product)

Note that, like CVE, ICAT does not store detailed descriptions usually found in advisories. In addition, the database format is nit a transport and interchange format.

[NOTE: A comparison with Section 5 of this document reveals that CAIF should be able to express all this information, possibly resorting to categories (see target="categories"/>) This means that CAIF advisories could be integrated easily into the ICAT database.]

Appendix B. Acknowledgements

The authors whish to thank Klaus-Peter Kossakowski and Damir Rajnovic comments on drafts of this memo. 2005-11-07
Copyright © 2005 RUS-CERT, Universität Stuttgart
Die Universität Stuttgart übernimmt keinerlei Haftung für den Inhalt dieser Seite.