From e8ba3f70caa9feb351d2b7ea3acf9a2dd62c99fd Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 4 Apr 2016 09:53:25 -0400 Subject: [PATCH] add license and readme --- LICENSE.md | 49 +++++ README.md | 514 ++++++++++++++++++++++++++++++++++++++++++++ README.txt | 612 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1175 insertions(+) create mode 100644 LICENSE.md create mode 100644 README.txt diff --git a/LICENSE.md b/LICENSE.md new file mode 100644 index 0000000000..b1fa17d72e --- /dev/null +++ b/LICENSE.md @@ -0,0 +1,49 @@ +Copyright 2012 Carnegie Mellon University. + +This archive is funded and supported by Department of Homeland Security +under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for +the operation of the Software Engineering Institute, a federally funded +research and development center sponsored by the United States +Department of Defense. + +Any opinions, findings and conclusions or recommendations expressed in +this material are those of the author(s) and do not necessarily reflect +the views of Department of Homeland Security or the United States +Department of Defense. + +NO WARRANTY + +THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE +MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY +MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY +MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR +MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE +MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY +KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT +INFRINGEMENT. + +This material has been approved for public release and unlimited +distribution except as restricted below. + +The Government of the United States has a royalty-free +government-purpose license to use, duplicate, or disclose the work, in +whole or in part and in any manner, and to have or permit others to do +so, for government purposes pursuant to the copyright license under the +clause at 252.227-7013 and 252.227-7013 Alternate I. + +Internal use:* Permission to reproduce this material and to prepare +derivative works from this material for internal use is granted, +provided the copyright and "No Warranty" statements are included with +all reproductions and derivative works. + +External use:* This material may be reproduced in its entirety, without +modification, and freely distributed in written or electronic form +without requesting formal permission. Permission is required for any +other external and/or commercial use. Requests for permission should be +directed to the Software Engineering Institute at +permission@sei.cmu.edu. + +* These restrictions do not apply to U.S. government entities. + +CERT(R), CERT Coordination Center(R) are registered marks of Carnegie +Mellon University. diff --git a/README.md b/README.md index e69de29bb2..f42ef288e2 100644 --- a/README.md +++ b/README.md @@ -0,0 +1,514 @@ +CERT Coordination Center Vulnerability Data Archive +==== + +Release 2014-12-08 + + +Contents +======== + +1. Change Log +2. Manifest +3. Support/Feedback +4. Description +5. Data Format +6. Metadata +7. Field Definitions for Vulnerability Reports +8. Field Definitions for Vendor Records + + +1. Change Log +============= + +2014-12-08 Updated data, note significant number of nearly identical + reports associated with automated Android SSL testing + +2014-05-22 Updated data + +2013-11-20 Updated data + +2013-04-03 Updated data, added field definition for [DateCreated], + fixed 8-bit characters in section 8 + +2012-07-10 Initial release + + +2. Manifest +=========== + +README.asc +CERT_vul_reports.xml.zip +CERT_vendor_records.xml.zip +CERT_vul_reports.json.zip +CERT_vendor_records.json.zip +support.zip + + +3. Support/Feedback +=================== + +We offer no formal support, however we may respond to questions and +feedback sent to with the tag INFO#365908 in the +subject. + + +4. Description +=============== + +This data archive contains nearly all of the non-sensitive vulnerability +data collected by the CERT/CC, from the inception of the vulnerability +notes database (approximately May 1998) to the date the archive was +prepared, as noted above in the Change Log. + +- - From roughly 2004 onwards, the United States Department of Homeland +Security (DHS) United States Computer Emergency Readiness Team (US-CERT) +has funded the vulnerability analysis and coordination work that +includes this vulnerability data and the publication of Vulnerability +Notes: + + + +This data is incomplete. All records (reports) should have an ID, +title, and creation date. Only some (~6%) of the reports have been +analyzed, coordinated, written up, and published as Vulnerability Notes. + +Most of the reports are in a preliminary state, with blank or default +field values. Few fields are consistently entered across the entire +data set. It is generally inappropriate from an analysis perspective to +draw conclusions from incomplete and inconsistent data. You have been +warned. + +There are two sets of data, vulnerability reports and vendor records. A +published Vulnerability Note is made up of one vulnerability report and +one or more vendor records. + +In this document, field names are enclosed in square brackets, like +this: [FieldName]. + +Vulnerability reports describe information about a reported +vulnerability. A report may contain 0 or more vulnerabilities. CERT +typically attempts to have one vulnerability report per vulnerability, +but this isn't always a practical level of abstraction. +[VulnerabilityCount] is the number of vulnerabilities (per CERT's +definition) in a vulnerability report. + +Vulnerability reports have 0 or more associated vendor records. Vendor +records describe vendor information related to a vulnerability report. A +record is typically created when CERT notifies a vendor about a +vulnerability, reasonably believes the vendor may be affected, becomes +aware of information about the vendor related to the vulnerability, or +otherwise feels that there is relevant information about the vendor +related to the vulnerability. + + +5. Data Format +============== + +Archives of both data sets are available in both JSON and XML formats. +The archives each contain one ZIP archive file of the entire data set +and smaller files with 1000 records each. Data is sorted +(alphabetically) by the [ID] field. + +The vulnerability notes database is a Lotus Notes application. The +domino_8_5_M2.xsd and domino_8_5_M2.dtd files included with this +distribution (in support.zip) may be of help processing the XML +formatted data. + +Some fields are intially created as text and the field type is updated +only once data has been entered. For example, a datetime field that is +blank may appear as a text field. + + +6. Metadata +=========== + +At the root level, [toplevelentries] is the number of records in the +data set. + +Per record, [position] is the position of the record in the data set. +Data is sorted (alphabetically) by the [ID] field. + +[unid] is a Lotus Notes ID that is unique across all databases on a +server. + +[noteid] is another ID used by Lotus Notes, unique within a database. + +At least in these data sets, [siblings] is the number of records in the +data set. + +Within a record, [columnumber] is just a 0-based sequential number for +fields. + + +7. Field Definitions for Vulnerability Reports +============================================== + +Descriptions for fields included in published Vulnerability Notes are +also available here: + + + +Some of the fields in this archive are not included in published +Vulnerability Notes. + +[ID] +text +Vulnerability report ID, the format is VU#nnnnnn (six digits), with some +older records having fewer than six digits. This is the associated +vulnerability report for the vendor record. + +[IDNumber] +text +The numerical portion of the ID (nnnnnn, six or sometimes fewer digits). + +[Title] +text +Title of the vulnerability report. May be HTML-escaped. + +[Keywords] +textlist +List of keywords. These become HTML meta keywords in a published +Vulnerability Note. + +[Overview] +text +Overview/summary of the vulnerability report. + +[Description] +text +A detailed description of the vulnerability report. + +[Impact] +The impact of the vulnerability. + +[Resolution] +text +A solution to the vulnerability, typically a complete solution, such as +a patch or update. + +[Workarounds] +text +Workarounds or mitigations for the vulnerability, typically something +less than a complete solution, but still effective at mitigating the +vulnerability. + +[SystemsAffectedPreamble] +text +A preamble to the list of vendors. + +[ThanksAndCredit] +text +Acknowledgement, credit, and possibly thanks to the person(s) or +organization(s) who discovered or reported the vulnerability or who +contributed to the coordination or analysis effort or information used +in the Vulnerability Note. + +[Author] +text +This field is set to the name of the analyst who is first assigned the +vulnerability report. When a report is published as a Vulnerability +Note, this field is the author. + +[References] +text or textlist +URLs to reference information about the vulnerability report. + +[CVEIDs] +text or textlist +List of one or more related CVE IDs. + +[CERTAdvisory] +text or textlist +References to one or more CERT Advisories. + +[US-CERTTechnicalAlert] +text or textlist +References to one or more US-CERT Technical Alerts. + +[VulnerabilityCount] +number +The number of unique vulnerabilities in a vulnerability report. + +[DateCreated] +datetime +Date the vulnerability report was created. This closely corresponds to +the date CERT was first aware of the vulnerability. + +[DatePublic] +datetime +Date the vulnerability is known to be public. This may be the date a +Vulnerability Note is published. This field may only contain date +information, not time. + +[DateFirstPublished] +text or datetime +Date the Vulnerability Note was first published. This field is a text +type if it is blank, datetime when it is populated. + +[DateLastUpdated] +datetime +Date the vulnerabilty report was last updated. + +[Revision] +number +Number of times the vulnerability report was revised, with "1" being the +initial creation of the report. + +"VRDA_D1_" in the field name indicates that the field is used in the +first round of decision support (triage, surface analysis, or D1) to +determine how to handle the vulnerability report. Although the +"VRDA_D1" component fields are text type, they can be safely treated as +numbers (integers). "VRDA_D1" fields were added to the database in +2007. + +More information about VRDA (Vulnerability Response Decision Assistance) +is available here: + + + +[VRDA_D1_DirectReport] +text +If this field is set to "1" then the vulnerability was directly reported +to or found by CERT. If this field is "0" then the vulnerability was +not a direct report or internal discovery. If this field is blank then +the report may or may not have been a direct report or internal +discovery. + +[VRDA_D1_Population] +text +This field answers the question "What is the population of affected +systems?" [VRDA_D1_Population] maps to [CVSS_TargetDistribution]. +"1" - Low +"2" - Low-Medium +"3" - Medium-High +"4" - High (e.g., Microsoft Windows, Adobe Flash, TCP, DNS, core +UNIX/Linux) + +[VRDA_D1_Impact] +text +This field answers the question "What is the impact of the vulnerabiliy?" +"1" - Low (e.g., nuisance DoS/resource consumption, limited information +disclosure) +"2" - Low-Medium +"3" - Medium-High +"4" - High (e.g., execute arbitrary code with elevated privileges, take +control of target) + +"CAM_" in the field name stands for "CERT Advisory Metric." More +information is available here: + + + +If all of the "CAM_" fields in a vulnerability report are "0" then it is +most likely that the vulnerability report has not been analyzed beyond +initial creation and surface analysis. Although the "CAM" component +fields are text type, they can be safely treated as numbers (integers +from 0-20). The calculated "CAM" fields are number type. + +[CAM_WidelyKnown] +text +This field answers the question "Is information about the vulnerability +widely available or known?" + +[CAM_Exploitation] +text +This field answers the question "Is the vulnerability being exploited?" + +[CAM_InternetInfrastructure] +text +This field answers the question "Is internet infrastructure at risk +because of this vulnerability?" + +[CAM_Population] +text +This field answers the question "How many systems on the internet are at +risk from this vulnerability?" + +[CAM_Impact] +text +This field answers the question "What is the impact of exploiting the +vulnerability?" + +[CAM_EaseOfExploitation] +text +This field answers the question "How easy is it to exploit the +vulnerability?" + +[CAM_AttackerAccessRequired] +text +This field answers the question "What are the preconditions does an +attacker require to exploit the vulnerability?" + +[CAM_ScoreCurrent] +number +Calculated CERT Advisory Metric score, decimal number from 0-180. + +[CAM_ScoreCurrentWidelyKnown] +number +Calculated CERT Advisory Metric score with [CAM_WidelyKnown] set to 20. + +[CAM_ScoreCurrentWidelyKnownExploited] +number +Calculated CERT Advisory Metric score with [CAM_WidelyKnown] and +[CAM_Exploitation] both set to 20. + +[IPProtocol] +text +IP protocol information related to the vulnerability, e.g., 80/tcp, +161/udp. + +"CVSS_" in the field name stands for "Common Vulnerability Scoring +System." More information is available here: + + + + + +Vulnerability Reports started including CVSS v2 metrics in March 2012. +Older reports will have empty CVSS_ values. Reports that have not been +scored will have default CVSS_ values, including "--" for some fields. + +[CVSS_AccessVector] +text +See . + +[CVSS_AccessComplexity] +text +See . + +[CVSS_Authenication] +text +See . + +[CVSS_ConfidentialityImpact] +text +See . + +[CVSS_IntegrityImpact] +text +See . + +[CVSS_AvailabilityImpact] +text +See . + +[CVSS_Exploitability] +text +See . + +[CVSS_RemediationLevel] +text +See . + +[CVSS_ReportConfidence] +text +See . + +[CVSS_CollateralDamagePotential] +text +See . + +[CVSS_TargetDistribution] +text +See . +[CVSS_TargetDistribution] maps to [VRDA_D1_Population]. + +[CVSS_SecurityRequirementsCR] +text +See . + +[CVSS_SecurityRequirementsIR] +text +See . + +[CVSS_SecurityRequirementsAR] +text +See . + +[CVSS_BaseScore] +text +See . + +[CVSS_BaseVector] +text +See . + +[CVSS_TemporalScore] +text +See . + +[CVSS_TemporalVector] +text +See . + +[CVSS_EnvironmentalScore] +text +See . + +[CVSS_EnvironmentalVector] +text +See . + + +8. Field Definitions for Vendor Records +======================================= + +[ID] +text +Vulnerability report ID, the format is VU#nnnnnn (six digits), with some +older records having fewer than six digits. This is the associated +vulnerability report for the vendor record. + +[VendorRecordID] +text +Lotus Notes unique ID for a vendor record + +[Vendor] +text +Name of the vendor. + +[Status] +text +Status of the vendor with regard to the vulnerability. By default, the +status is "Unknown." If we believe a vendor is affected, the status is +"Affected" or "Vulnerable". If we believe a vendor is not affected, the +status is "Not Affected" or "Not Vulnerable". + +[VendorStatement] +text +A statement about the vunerability by the vendor. The statement in this +field is authenticated -- usually the text has been cryptographically +signed by the vendor or verified by CERT out-of-band. + +[VendorInformation] +text +Information about the vendor about the vulnerability. This is more +loosely vetted information, for example something available on the +vendor's web site. + +[VendorReferences] +text or textlist +URLs to vendor reference information about the vulnerability. + +[Addendum] +text +Additional comments or rebuttal from CERT to [VendorStatement]. + +[DateNotified] +datetime +Date the vendor was notified by CERT. Notification implies at least +that CERT sent email to a last-known good contact at the vendor. + +[DateResponded] +datetime +Date the vendor responded. + +[DateLastUpdated] +datetime +Date the vendor record was last updated. + +[Revision] +number +Number of times the vendor record was revised, with "1" being the +initial creation of the record. diff --git a/README.txt b/README.txt new file mode 100644 index 0000000000..9d32d012ff --- /dev/null +++ b/README.txt @@ -0,0 +1,612 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + + +CERT Coordination Center Vulnerability Data Archive + +Release 2014-12-08 + + +Contents +======== + +1. Change Log +2. Manifest +3. Support/Feedback +4. Description +5. Data Format +6. Metadata +7. Field Definitions for Vulnerability Reports +8. Field Definitions for Vendor Records +9. Copyright and Usage + + +1. Change Log +============= + +2014-12-08 Updated data, note significant number of nearly identical + reports associated with automated Android SSL testing + +2014-05-22 Updated data + +2013-11-20 Updated data + +2013-04-03 Updated data, added field definition for [DateCreated], + fixed 8-bit characters in section 8 + +2012-07-10 Initial release + + +2. Manifest +=========== + +README.asc +CERT_vul_reports.xml.zip +CERT_vendor_records.xml.zip +CERT_vul_reports.json.zip +CERT_vendor_records.json.zip +support.zip + + +3. Support/Feedback +=================== + +We offer no formal support, however we may respond to questions and +feedback sent to with the tag INFO#365908 in the +subject. + + +4. Description +=============== + +This data archive contains nearly all of the non-sensitive vulnerability +data collected by the CERT/CC, from the inception of the vulnerability +notes database (approximately May 1998) to the date the archive was +prepared, as noted above in the Change Log. + +- - From roughly 2004 onwards, the United States Department of Homeland +Security (DHS) United States Computer Emergency Readiness Team (US-CERT) +has funded the vulnerability analysis and coordination work that +includes this vulnerability data and the publication of Vulnerability +Notes: + + + +This data is incomplete. All records (reports) should have an ID, +title, and creation date. Only some (~6%) of the reports have been +analyzed, coordinated, written up, and published as Vulnerability Notes. + +Most of the reports are in a preliminary state, with blank or default +field values. Few fields are consistently entered across the entire +data set. It is generally inappropriate from an analysis perspective to +draw conclusions from incomplete and inconsistent data. You have been +warned. + +There are two sets of data, vulnerability reports and vendor records. A +published Vulnerability Note is made up of one vulnerability report and +one or more vendor records. + +In this document, field names are enclosed in square brackets, like +this: [FieldName]. + +Vulnerability reports describe information about a reported +vulnerability. A report may contain 0 or more vulnerabilities. CERT +typically attempts to have one vulnerability report per vulnerability, +but this isn't always a practical level of abstraction. +[VulnerabilityCount] is the number of vulnerabilities (per CERT's +definition) in a vulnerability report. + +Vulnerability reports have 0 or more associated vendor records. Vendor +records describe vendor information related to a vulnerability report. A +record is typically created when CERT notifies a vendor about a +vulnerability, reasonably believes the vendor may be affected, becomes +aware of information about the vendor related to the vulnerability, or +otherwise feels that there is relevant information about the vendor +related to the vulnerability. + + +5. Data Format +============== + +Archives of both data sets are available in both JSON and XML formats. +The archives each contain one ZIP archive file of the entire data set +and smaller files with 1000 records each. Data is sorted +(alphabetically) by the [ID] field. + +The vulnerability notes database is a Lotus Notes application. The +domino_8_5_M2.xsd and domino_8_5_M2.dtd files included with this +distribution (in support.zip) may be of help processing the XML +formatted data. + +Some fields are intially created as text and the field type is updated +only once data has been entered. For example, a datetime field that is +blank may appear as a text field. + + +6. Metadata +=========== + +At the root level, [toplevelentries] is the number of records in the +data set. + +Per record, [position] is the position of the record in the data set. +Data is sorted (alphabetically) by the [ID] field. + +[unid] is a Lotus Notes ID that is unique across all databases on a +server. + +[noteid] is another ID used by Lotus Notes, unique within a database. + +At least in these data sets, [siblings] is the number of records in the +data set. + +Within a record, [columnumber] is just a 0-based sequential number for +fields. + + +7. Field Definitions for Vulnerability Reports +============================================== + +Descriptions for fields included in published Vulnerability Notes are +also available here: + + + +Some of the fields in this archive are not included in published +Vulnerability Notes. + +[ID] +text +Vulnerability report ID, the format is VU#nnnnnn (six digits), with some +older records having fewer than six digits. This is the associated +vulnerability report for the vendor record. + +[IDNumber] +text +The numerical portion of the ID (nnnnnn, six or sometimes fewer digits). + +[Title] +text +Title of the vulnerability report. May be HTML-escaped. + +[Keywords] +textlist +List of keywords. These become HTML meta keywords in a published +Vulnerability Note. + +[Overview] +text +Overview/summary of the vulnerability report. + +[Description] +text +A detailed description of the vulnerability report. + +[Impact] +The impact of the vulnerability. + +[Resolution] +text +A solution to the vulnerability, typically a complete solution, such as +a patch or update. + +[Workarounds] +text +Workarounds or mitigations for the vulnerability, typically something +less than a complete solution, but still effective at mitigating the +vulnerability. + +[SystemsAffectedPreamble] +text +A preamble to the list of vendors. + +[ThanksAndCredit] +text +Acknowledgement, credit, and possibly thanks to the person(s) or +organization(s) who discovered or reported the vulnerability or who +contributed to the coordination or analysis effort or information used +in the Vulnerability Note. + +[Author] +text +This field is set to the name of the analyst who is first assigned the +vulnerability report. When a report is published as a Vulnerability +Note, this field is the author. + +[References] +text or textlist +URLs to reference information about the vulnerability report. + +[CVEIDs] +text or textlist +List of one or more related CVE IDs. + +[CERTAdvisory] +text or textlist +References to one or more CERT Advisories. + +[US-CERTTechnicalAlert] +text or textlist +References to one or more US-CERT Technical Alerts. + +[VulnerabilityCount] +number +The number of unique vulnerabilities in a vulnerability report. + +[DateCreated] +datetime +Date the vulnerability report was created. This closely corresponds to +the date CERT was first aware of the vulnerability. + +[DatePublic] +datetime +Date the vulnerability is known to be public. This may be the date a +Vulnerability Note is published. This field may only contain date +information, not time. + +[DateFirstPublished] +text or datetime +Date the Vulnerability Note was first published. This field is a text +type if it is blank, datetime when it is populated. + +[DateLastUpdated] +datetime +Date the vulnerabilty report was last updated. + +[Revision] +number +Number of times the vulnerability report was revised, with "1" being the +initial creation of the report. + +"VRDA_D1_" in the field name indicates that the field is used in the +first round of decision support (triage, surface analysis, or D1) to +determine how to handle the vulnerability report. Although the +"VRDA_D1" component fields are text type, they can be safely treated as +numbers (integers). "VRDA_D1" fields were added to the database in +2007. + +More information about VRDA (Vulnerability Response Decision Assistance) +is available here: + + + +[VRDA_D1_DirectReport] +text +If this field is set to "1" then the vulnerability was directly reported +to or found by CERT. If this field is "0" then the vulnerability was +not a direct report or internal discovery. If this field is blank then +the report may or may not have been a direct report or internal +discovery. + +[VRDA_D1_Population] +text +This field answers the question "What is the population of affected +systems?" [VRDA_D1_Population] maps to [CVSS_TargetDistribution]. +"1" - Low +"2" - Low-Medium +"3" - Medium-High +"4" - High (e.g., Microsoft Windows, Adobe Flash, TCP, DNS, core +UNIX/Linux) + +[VRDA_D1_Impact] +text +This field answers the question "What is the impact of the vulnerabiliy?" +"1" - Low (e.g., nuisance DoS/resource consumption, limited information +disclosure) +"2" - Low-Medium +"3" - Medium-High +"4" - High (e.g., execute arbitrary code with elevated privileges, take +control of target) + +"CAM_" in the field name stands for "CERT Advisory Metric." More +information is available here: + + + +If all of the "CAM_" fields in a vulnerability report are "0" then it is +most likely that the vulnerability report has not been analyzed beyond +initial creation and surface analysis. Although the "CAM" component +fields are text type, they can be safely treated as numbers (integers +from 0-20). The calculated "CAM" fields are number type. + +[CAM_WidelyKnown] +text +This field answers the question "Is information about the vulnerability +widely available or known?" + +[CAM_Exploitation] +text +This field answers the question "Is the vulnerability being exploited?" + +[CAM_InternetInfrastructure] +text +This field answers the question "Is internet infrastructure at risk +because of this vulnerability?" + +[CAM_Population] +text +This field answers the question "How many systems on the internet are at +risk from this vulnerability?" + +[CAM_Impact] +text +This field answers the question "What is the impact of exploiting the +vulnerability?" + +[CAM_EaseOfExploitation] +text +This field answers the question "How easy is it to exploit the +vulnerability?" + +[CAM_AttackerAccessRequired] +text +This field answers the question "What are the preconditions does an +attacker require to exploit the vulnerability?" + +[CAM_ScoreCurrent] +number +Calculated CERT Advisory Metric score, decimal number from 0-180. + +[CAM_ScoreCurrentWidelyKnown] +number +Calculated CERT Advisory Metric score with [CAM_WidelyKnown] set to 20. + +[CAM_ScoreCurrentWidelyKnownExploited] +number +Calculated CERT Advisory Metric score with [CAM_WidelyKnown] and +[CAM_Exploitation] both set to 20. + +[IPProtocol] +text +IP protocol information related to the vulnerability, e.g., 80/tcp, +161/udp. + +"CVSS_" in the field name stands for "Common Vulnerability Scoring +System." More information is available here: + + + + + +Vulnerability Reports started including CVSS v2 metrics in March 2012. +Older reports will have empty CVSS_ values. Reports that have not been +scored will have default CVSS_ values, including "--" for some fields. + +[CVSS_AccessVector] +text +See . + +[CVSS_AccessComplexity] +text +See . + +[CVSS_Authenication] +text +See . + +[CVSS_ConfidentialityImpact] +text +See . + +[CVSS_IntegrityImpact] +text +See . + +[CVSS_AvailabilityImpact] +text +See . + +[CVSS_Exploitability] +text +See . + +[CVSS_RemediationLevel] +text +See . + +[CVSS_ReportConfidence] +text +See . + +[CVSS_CollateralDamagePotential] +text +See . + +[CVSS_TargetDistribution] +text +See . +[CVSS_TargetDistribution] maps to [VRDA_D1_Population]. + +[CVSS_SecurityRequirementsCR] +text +See . + +[CVSS_SecurityRequirementsIR] +text +See . + +[CVSS_SecurityRequirementsAR] +text +See . + +[CVSS_BaseScore] +text +See . + +[CVSS_BaseVector] +text +See . + +[CVSS_TemporalScore] +text +See . + +[CVSS_TemporalVector] +text +See . + +[CVSS_EnvironmentalScore] +text +See . + +[CVSS_EnvironmentalVector] +text +See . + + +8. Field Definitions for Vendor Records +======================================= + +[ID] +text +Vulnerability report ID, the format is VU#nnnnnn (six digits), with some +older records having fewer than six digits. This is the associated +vulnerability report for the vendor record. + +[VendorRecordID] +text +Lotus Notes unique ID for a vendor record + +[Vendor] +text +Name of the vendor. + +[Status] +text +Status of the vendor with regard to the vulnerability. By default, the +status is "Unknown." If we believe a vendor is affected, the status is +"Affected" or "Vulnerable". If we believe a vendor is not affected, the +status is "Not Affected" or "Not Vulnerable". + +[VendorStatement] +text +A statement about the vunerability by the vendor. The statement in this +field is authenticated -- usually the text has been cryptographically +signed by the vendor or verified by CERT out-of-band. + +[VendorInformation] +text +Information about the vendor about the vulnerability. This is more +loosely vetted information, for example something available on the +vendor's web site. + +[VendorReferences] +text or textlist +URLs to vendor reference information about the vulnerability. + +[Addendum] +text +Additional comments or rebuttal from CERT to [VendorStatement]. + +[DateNotified] +datetime +Date the vendor was notified by CERT. Notification implies at least +that CERT sent email to a last-known good contact at the vendor. + +[DateResponded] +datetime +Date the vendor responded. + +[DateLastUpdated] +datetime +Date the vendor record was last updated. + +[Revision] +number +Number of times the vendor record was revised, with "1" being the +initial creation of the record. + + +9. Copyright and Usage +====================== + +Copyright 2012 Carnegie Mellon University. + +This archive is funded and supported by Department of Homeland Security +under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for +the operation of the Software Engineering Institute, a federally funded +research and development center sponsored by the United States +Department of Defense. + +Any opinions, findings and conclusions or recommendations expressed in +this material are those of the author(s) and do not necessarily reflect +the views of Department of Homeland Security or the United States +Department of Defense. + +NO WARRANTY + +THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE +MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY +MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY +MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR +MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE +MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY +KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT +INFRINGEMENT. + +This material has been approved for public release and unlimited +distribution except as restricted below. + +The Government of the United States has a royalty-free +government-purpose license to use, duplicate, or disclose the work, in +whole or in part and in any manner, and to have or permit others to do +so, for government purposes pursuant to the copyright license under the +clause at 252.227-7013 and 252.227-7013 Alternate I. + +Internal use:* Permission to reproduce this material and to prepare +derivative works from this material for internal use is granted, +provided the copyright and "No Warranty" statements are included with +all reproductions and derivative works. + +External use:* This material may be reproduced in its entirety, without +modification, and freely distributed in written or electronic form +without requesting formal permission. Permission is required for any +other external and/or commercial use. Requests for permission should be +directed to the Software Engineering Institute at +permission@sei.cmu.edu. + +* These restrictions do not apply to U.S. government entities. + +CERT(R), CERT Coordination Center(R) are registered marks of Carnegie +Mellon University. + +The domino_8_5_2.xsd and domino_8_5_2.dtd files included with this +distribution are copyright IBM Corp. and are redistributed under the +following terms: + + + +11) Licensee's license agreement with the end user of Licensee's +Application must notify the end user that the Redistributables or their +modifications may not be i) used for any purpose other than to enable +Licensee's Application, ii) copied (except for backup purposes), iii) +further distributed or transferred without Licensee's Application or iv) +reverse assembled, reverse compiled, or otherwise translated except as +specifically permitted by law and without the possibility of a +contractual waiver. Furthermore, Licensee's license agreement must be at +least as protective of IBM as the terms of this Agreement. + +IBM Lotus Notes Redistributables + +The following list includes files that are provided to You pursuant to +the Redistributables section of the IBM International Program License +Agreements License Information that applies to this Program: + +All source files in the following directory may be redistributed in the +form in which the files were provided: + - \xmlschemas + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.5 (GNU/Linux) + +iQEVAwUBVIaUob4NbsoIhRIZAQI7Hwf/UGfhxjT8oFjdZKC9W0TwA6o+1l2mrN0F +GKXfFhUBZ1wzoIVggrMkpyBHET6dxC4Liy/X/FyqjLSIBynyICees/KVGdqN+L8E +0DAB2JnA6mggZtXH3gUlSuSsbT/rc0xUt8P22OOZNnFc/b1SxcbHa1IIfCw4lqsv +tbuqcGQqevZHnF4Y/JdVYNu1jJtN0U7Z3IELXRW58mhAZ/Oeu9ImLzurQtIPXB58 +P4ZHASE6GycMcX9Jlmhr1xsKYKYX3WjvPdw7j0Z1dZ/Bn5ESmBjbeeF0pUR6wpFV +EOHK3Gh1MhL/sY5yxBnbzYtfsx7/RH8n+Z40Y+6kihR+eucPkHYeOA== +=KeVb +-----END PGP SIGNATURE-----