Internet DRAFT - draft-debeaupuis-saf
draft-debeaupuis-saf
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:33:27 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 19 May 1999 11:05:00 GMT
ETag: "2e97ff-4b11-37429adc"
Accept-Ranges: bytes
Content-Length: 19217
Connection: close
Content-Type: text/plain
draft-debeaupuis-saf-00.txt T. Debeaupuis
INTERNET DRAFT HSC
Expires: 19 November 1999 19 May 1999
Security Advisory Format
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This is first drafty Internet-draft of the Security Advisory Format.
A lot of work still to be done in clarifying, removing mistakes and
work on the specification of unique names for components impacted by
vulnerabilities. Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents
as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
3id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast).
Distribution of this document is unlimited.
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 [RFC2119].
Abstract
This memo describes a format for security advisories. An advisory is
a document describing a vulnerability of a program, an operating
system or, more generally, a software or hardware component of the
information system.
This specification tries to minimize changes in issuer and readers
current practices (messages style), and by trying to help a program
re-read the advisory tries also to keep advisories easily and
Debeaupuis [Page 1]
INTERNET-DRAFT Security Advisory Format 18 May 1999
friendly readable by humans. It focuses on structure of documents.
This specification is primarily useful for advisories issuers such as
CSIRTs [RFC2350] and users and is linked with intrusion detection.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Table of Contents
1. Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changes since last version . . . . . . . . . . . . . . . . . . . 2
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Design goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Advisory Format . . . . . . . . . . . . . . . . . . . . 3
5.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.2. Advisory encoding . . . . . . . . . . . . . . . . . . . . . . . 4
5.3. Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.4. SAF grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. APPENDIX 1 - Current advisories semantics . . . . . . . . . . . . 7
2. Changes since last version
Not applicable at this time.
3. Introduction
We face different information issuers :
- CSIRTs
- Vendors
- Groups of people studying vulnerabilities
Different needs :
- Advisory submitters will find in this format a more efficient way
to inform the or their community. Internally to the Advisory submit¡
ter organisation, this format can also be used to ease the handling
of advisories.
- IT security officers : within organizations, IT security officers
need to know know what are the vulnerabilities of a specific
Debeaupuis [Page 2]
INTERNET-DRAFT Security Advisory Format 18 May 1999
operating system or software, and in a more general way, a software
or hardware component.
- Numerous categories of people (intrusion detection people,
researchers, vendors, security consulting firms) are commonly work¡
ing on advisories as a building block of their work : investiga¡
tions, auditing softwares (on system or network). A common format
will help them entering datas in the databases without spending time
to re-organized and formalized advisories. This format aim will
also be useful for management tools (IDS frameworks, network secu¡
rity management) to correlate alarms and advisories.
The problem that we are facing today is a lake of standardization
between the different formats used to report vulnerabilities.
4. Design goals
The design goals of SAF are as follows :
(1) SAF must suit to security advisory issuers as of users of
those advisories,
(2) SAF must be parsable by a program,
(3) SAF should not modify too much current practices and ways of
working. SAF should not modify too much advisories looks-and-feel.
(4) SAF must not impose content or order of informations in advi¡
sories.
5. Security Advisory Format
5.1. Definitions
Advisory :
A text document announcing to a community a vulnerability in a
component of an information system. For example, a software appli¡
cation, a packaging of an application, an operating system, a
router hardware.
Vulnerability :
An intrinsic or external provocted fail of a component of the
information system leading to decrease the security protection
level of a resource.
Debeaupuis [Page 3]
INTERNET-DRAFT Security Advisory Format 18 May 1999
Impact :
the damage provoked if the vulnerability is exploited.
Patch :
a peace of software replacing the misfunctioning parts of the com¡
ponent to eradicate the vulnerability.
Workaround :
a procedure describing a change in the configuration that can pro¡
tect the component from being corrupted by a the exploit of a vul¡
nerability without applying patches.
5.2. Advisory encoding
SAF is a token based labeling language. A SAF advisory is a 7 bit US-
ASCII document or 8 bit ISO 8859-1 text document. Implementations
MUST support both encodings.
5.3. Sections
Advisories are composed of sections. Sections order is NOT enforced.
5.4. SAF grammar
A SAF document can be encoded intro two formats : an XML document
conforming the DTD provided in this document, or a readable and
parsable text format (to be defined).
<!-- ================================================= -->
<!-- This is the XML Security Advisory Format DTD -->
<!-- -->
<!-- Author: Tristan Debeaupuis -->
<!-- ================================================= -->
<!-- $Id:$
-->
<!-- ================================================= -->
<!-- Entities
<!entity % isoent system>
%isoent;
<!-- ================================================= -->
<!-- Elements -->
<!element advisory - -
Debeaupuis [Page 4]
INTERNET-DRAFT Security Advisory Format 18 May 1999
(advisory ( head, body? ) >
<!attlist advisory
opts cdata "null">
<!element head - o (title, ref?, author, abstract?)
<!element title - o
#pcdata>
<!element author - o (name, thanks?,
(and, name, thanks?)*)>
<!element name - o (#pcdata) +(newline)>
<!element and - o empty>
<!element thanks - o (#pcdata)>
<!element date - o (#pcdata) >
<!element ref - - (#pcdata) >
<!element abstract - o (#pcdata)>
<!element body - o (#pcdata)>
<!-- The original source of this advisory (my organization name) -->
<!element source - - (#pcdata) >
<!-- Title of the advisory, usually the subject of the mail -->
<!element title - - (#pcdata) >
<!-- Date of issue of this advisory. If it is an update, the current date -->
<!element date - - (#pcdata) >
<!-- A free text describing the problem -->
<!element description - - (#pcdata) >
<!-- Language used in this advisory -->
<!element lang - - (#pcdata) >
<!-- Level of impact -->
<!element impact - - (#pcdata) >
<!attlist impact
level cdata "dos|admin"> <! Dos : Deny of Service -->
<! This list (dos, admin) must be expanded in future versions of -->
<! this document -->
<!-- List of impacted components -->
<!element objects - - (object)+>
<!-- Free text describing the vulnerability on this component -->
Debeaupuis [Page 5]
INTERNET-DRAFT Security Advisory Format 18 May 1999
<!element object - - (#pcdata) >
<! Objects name must be defined uniquely among all the -->
<! advisories. So, a central repository with fast update -->
<! will probably be necessary. -->
<! This name will be the same used in the IDEF (Intrusion -->
<! Detection Exchange Format)
<!attlist object
name cdata #required
impacted cdata "yes|no|unknown|maybe"
patchref cdata "null">
<!-- Reference to the exploit script or URL to an exploit -->
<!-- May be used with caution - URL can change -->
<!element exploit - - (#pcdata) >
<!-- A free text describing a way to stop the problem -->
<!element workaround - - (#pcdata) >
<!-- List of patches -->
<!element patchs - - (#pcdata) >
<!-- The filename of this advisory -->
<!element filename - - (#pcdata) >
<!-- ================================================= -->
<!-- end of ADVISORY DTD
<!--
Local Variables:
mode: sgml
End: -->
<!-- ================================================= -->
6. Security Considerations
This document describes a format which aim is not to improve security
of advisories (transmission, trust, archiving). It can help security
officers having a better view of the vulnerabilities impacts on their
systems by facilitating advisories re-treatment by automatic or semi-
automatic programs.
7. References
[RFC2234] "Augmented BNF for Syntax Specifications: ABNF", D.
Crocker, P. Overall, RFC 2234, November 1997.
Debeaupuis [Page 6]
INTERNET-DRAFT Security Advisory Format 18 May 1999
[RFC2350] "Expectations for Computer Security Incident Response" N.
Brownlee, E. Guttman, RFC 2234, June 1998.
[RFC2119] Key works for use in RFCs to Indicate Requirement Levels,
S. Bradner, RFC 2119, March 1997.
[US-ASCII] United States of America Standards Institute (now American
National Standards Institute), X3.4, 1968, "USA Code for Information
Interchange". ANSI X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains definitive for the
Internet.
8. APPENDIX 1 - Current advisories semantics
Note : the annexes are only for information. They are helpful and
will be deleted in the future because we are not trying to standard¡
ize CSIRTs current formats, but to propose an evolution and a merge
of those formats.
This section uses ABNF but is not a lexical definition of advisories
but rather a semantical grammar description of advisories.
CERT
Types of advisories :
- Vendor initiated bulletins
<CERT-VB> = <HEADING> <INTRODUCTION>
<FORWARDED-TEXT>
<HOW-TO-CONTACT>
<CERTCC-INFORMATIONS>
- CERT advisories
<CERT-BULLETIN> = <HEADING> <INTRODUCTION>
<DESCRIPTION>
<IMPACT>
<SOLUTION>
<APPENDIX>*
<NO-WARRANTY>
<HOW-TO-CONTACT>
<CERTCC-INFORMATIONS>
<COPYRIGHT>
Debeaupuis [Page 7]
INTERNET-DRAFT Security Advisory Format 18 May 1999
<APPENDIX> = 1*<VENDOR-INFORMATION>
<VENDOR-INFORMATION> = <VENDOR-NAME>
<CURRENT-STATE>
- Advisories released by other CSIRTs and forwarded by CERT with or
without
added-value.
- CERT Summaries
CIAC
- CIAC Bulletin
<CIAC-BULLETIN> = <HEADING> <SUMUP> <DESCRIPTION>
<VENDOR-SPECIFIC-INFORMATION>*
<HEADING> = <LOGO> crlf <TYPEOFBULLETIN> crlf crlf <TITLE> crlf
crlf <DATE><ADVISORY-NUMBER>
<SUMUP> = <HRULE> crlf <PROBLEM> crlf <PLATFORM> crlf <DAMAGE>
crlf <SOLUTION> crlf <HRULE> <VULNERABILITY> crlf
<ASSESSMENT>
<DESCRIPTION> =
<VENDOR-SPECIFIC-INFORMATION> =
AUSCERT
<AUSCERT-ADVISORY> = <TITLE-BANNER> crlf
<SUMMARY> crlf
<CONTENT>
<TITLE-BANNER> = <PARTNUM>
<TITLE>
<DATE>
<LAST-REVISED>
<INTRODUCTION>
<LAST-REVISED> = <DATE> " " <ACTION>
<CONTENT> = <DESCRIPTION>
<IMPACT>
Debeaupuis [Page 8]
INTERNET-DRAFT Security Advisory Format 18 May 1999
<WORKAROUND>
<MOREINFO>
<THANKS>
<WARRANTY>
<ADDRESS>
<REVISION-HISTORY>
MICROSOFT
- Paragraphs are left aligned, close to the border
- Lists are indented at 1 and 3 spaces
- Sections are introduced by a section name without number, under¡
lined with "=".
A blank line is used before a section title and the section text is
directly
added on the line following the section underlines.
- Tokens are :
Originally Posted : date of first release of the advisory,
Summary : sum-up. What is affected, on which systems, what's the
impact, is there are patches, workarounds ?
Issue : What's the technical problem of the vulnerability ?
Affected Software Versions : list of affected components
What Microsoft is Doing : tell if patches (fixes), knowledge base
article are available, tell the fix references for each impacted
components.
What customers should do : explanation of fixes (supported but not
regression tested). No specific information.
More Information : references (URLs) for this advisory, and the
Knowledge Base article.
Obtaining Support on this Issue : Reference to subscribe to sup¡
port.
Acknowledgements : thanks to people who has reported the problem.
Revisions : list of revision of this document. For each revision,
date of revision and comment are given.
Debeaupuis [Page 9]
INTERNET-DRAFT Security Advisory Format 18 May 1999
<MICROSOFT-BULLETIN> = <TITLE>
<POSTED-DATE>
<REVISED-DATE>
<SUMMARY>
<ISSUE>
<AFFECTED-SOFTWARE>
<WHAT-MICROSOFT-DOING>
<WHAT-TO-DO>
<WORKAROUND>
<MORE-INFORMATION>
<REVISIONS>
<WARRANTY>
<COPYRIGHT>
<MAILING-LIST-INFO>
CISCO
<CISCO-SECURITY-NOTICE> = <FIELD-NOTICE> <HRULE>
<REVISION>
<RELEASE-DATE>
<CONFIDENTIALITY>
<SUMMARY>
<AFFECTED-TEXT>
<IMPACT>
<BUGREF>
<LIST-OF-AFFECTED-AND-PATCHES>
<WORKAROUND>
<EXPLOITATION>
<NOTICE-STATUS>
<DISTRIBUTION-REFERENCES>
<REVISION-HISTORY>
<CISCO-SECURITY-PROCEDURES>
<HRULE>
<COPYRIGHT>
<SGI-ADVISORY> = <HEADINGS>
<WARNING>
<DESCRIPTION>
<IMPACT>
<WORKAROUND>?
<SOLUTION>
<ACKNOWLEDGMENTS>
<SGI-CONTACTS>
Debeaupuis [Page 10]
INTERNET-DRAFT Security Advisory Format 18 May 1999
<HEADINGS> = <TITLE>
<NUMBER>
<DATE>
<SOLUTION> = <PATCH-URL>
1*(<OS-NAME> <VULNERABLE> <PATCH-NUMBER>
<ACTION>)
L0pht
<L0PHT-ADVISORY> = <HEADINGS>
<DESCRIPTION>
<IMPACT>
<SOLUTION>
<HEADINGS> = <URL-REF>
<RELEASE-DATE>
<COMPONENT-IMPACTED>
<OPERATING-SYSTEM>
<IMPACT>
<PATCH-AVAILABILITY>
- Repent Security Incorporated, RSI
<RSI-ADVISORY> = <TITLE>
<TITLE> = <PART-NUM>
<BANNER>
- Herv‰ Schauer Consultants, HSC
<HSC-ADVISORY> = "(" <SOURCE> ") " <TITLE> "(" <DATE> ")" crlf
<OBJETS-TOUCHES>
<IMPACT>
<DESCRIPTION>
<PARADE>
<CORRECTIFS>
<OBJETS-TOUCHES> = *<OBJET-TOUCHE>
<CORRECTIFS> =
Debeaupuis [Page 11]
INTERNET-DRAFT Security Advisory Format 18 May 1999
Acknowledgements
Many thanks to Barbara Fraser and Jean-Michel Cornu for there support.
Author's Address
Tristan Debeaupuis
Herv‰ Schauer Consultants
142, rue de Rivoli
75001 Paris
France
Phone: +33 141 409 700
Email: Tristan.Debeaupuis@hsc.fr
Comments should be sent directly to the author.
Debeaupuis [Page 12]
