This memo describes requirements for an advisory interchange format. Comments and criticism are welcome. Distribution of this memo is unlimited.
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.7 Contact Information
6. Text Markup
10. Security Considerations
11.1 Normative References
11.2 Informal References
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
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:
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.
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:
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.
- A document which describes a computer security problem or a solution of such a problem.
- The act of an issuer giving others access to his or her own advisories. The issuer is said to "distribute" an advisory.
- 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.
- A party who distributes or redistributes advisories.
- The author of an advisory, or, if the author works for an institution which chooses to attribute advisories to itself, that institution.
- A person who reads an advisory.
- A part of an advisory containing specific information. "Standard sections" have well-defined content, which sometimes can be processed automatically.
- A subdivision of a section, containing one information unit.
- 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"?
In this section, we will briefly examine the needs of different parties dealing with advisories.
Readers need answers to the following questions:
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.
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.
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.%
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:
Distributors could use these tags as well.
Some data is required to properly identify an advisory and its issuer:
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:
[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.
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:
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.)
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.]
In addition to the structured information described so far, an advisory provides unstructured information as well:
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.
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.
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.
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:
[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.]
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.
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:
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.
CAIF as proposed in this document encompasses several shared namespaces:
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
are highly desirable. [NOTE: It is not clear if this in the scope of CAIF. Is such a database of identifiers deemed necessary?]
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 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.
|||Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000.|
|||Fallside, D., "XML Schema Part 0: Primer", W3C REC REC-xmlschema-0-20010502, May 2001.|
|||Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.|
|||Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.|
|||Christey, S. and C. Wysopal, "Responsible Vulnerability Disclosure Process", draft-christey-wysopal-vuln-disclosure-00 (work in progress), February 2002.|
|||Debeaupuis, T., "Security Advisory Format", draft-debeaupuis-saf-00.txt (work in progress), May 1999.|
|||Cormack, A., "Writing Advisories", JANET Guidance Note JANET/GD/NOTE/0007, March 2002.|
This section lists work related to the standardization of advisories of which the issuers were aware. Its impact on CAIF is briefly discussed.
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.
In early 2002, an attempt was made to describe a standard process for the disclosure of security vulnerabilities in 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.
Tristand Debaupuis' "Security Advisory Format" Internet Draft (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.
[NOTE: This document 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.]
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.]
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:
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.]
The authors whish to thank Klaus-Peter Kossakowski and Damir Rajnovic comments on drafts of this memo.