ISO/IEC TR 20004:2012
(Main)Information technology — Security techniques — Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045
Information technology — Security techniques — Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045
ISO/IEC TR 20004:2012 refines the AVA_VAN assurance family activities defined in ISO/IEC 18045:2008 and provides more specific guidance on the identification, selection and assessment of relevant potential vulnerabilities in order to conduct an ISO/IEC 15408 evaluation of a software target of evaluation. ISO/IEC TR 20004:2012 leverages the Common Weakness Enumeration (CWE) and the Common Attack Pattern Enumeration and Classification (CAPEC) to support the method of scoping and implementing ISO/IEC 18045:2008(E) vulnerability analysis activities. ISO/IEC TR 20004:2012 does not define evaluator actions for certain high assurance ISO/IEC 15408 components, where there is as yet no generally agreed guidance.
Technologies de l'information — Techniques de sécurité — Redéfinition de l'analyse de vulnérabilité de logiciel selon l'ISO/CEI 15408 et l'ISO/CEI 18045
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
20004
First edition
2012-08-15
Information technology — Security
techniques — Refining software
vulnerability analysis under
ISO/IEC 15408 and ISO/IEC 18045
Technologies de l'information — Techniques de sécurité — Redéfinition
de l'analyse de vulnérabilité de logiciel selon l'ISO/CEI 15408 et
l'ISO/CEI 18045
Reference number
ISO/IEC TR 20004:2012(E)
©
ISO/IEC 2012
---------------------- Page: 1 ----------------------
ISO/IEC TR 20004:2012(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2012 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 20004:2012(E)
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Terms and definitions . 1
3 Abbreviated terms . 3
4 Background Context . 4
5 Overview . 9
5.1 Purpose . 9
6 Vulnerability Assessment Activities . 10
6.1 Determine relevant potential vulnerabilities . 10
6.1.1 Identify relevant weaknesses and attack patterns from existing structured assurance
case . 12
6.1.2 Identify relevant weaknesses and attack patterns from public sources . 12
6.2 Assess TOE susceptibility to attack . 15
6.2.1 Design and specify security/penetration testing . 15
6.2.2 Execute and document security/penetration testing . 15
6.3 Report on exploitable vulnerabilities . 16
Bibliography . 17
© ISO/IEC 2012 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 20004:2012(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when the joint technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may decide to
publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review
every five years in the same manner as an International Standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Attention is
drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO
and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 20004:2012 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
iv © ISO/IEC 2012 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 20004:2012(E)
Introduction
This Technical Report provides added refinement, detail and guidance to the vulnerability analysis activities
outlined in ISO/IEC 18045:2008(E). It is intended to be used in conjunction with and as an addendum to
ISO/IEC 18045:2008(E). The refinement, detail and guidance provided by this document are not intended to
satisfy the full range of requirements under the AVA_VAN family as defined in ISO/IEC 18045:2008(E) or to
artificially restrict the activities performed by evaluators but rather to facilitate consistency through a minimal
baseline of AVA_VAN evaluation.
The target audience for this Technical Report is primarily evaluators applying ISO/IEC 15408 and certifiers
confirming evaluator actions; evaluation sponsors, developers, PP/ST authors and other parties interested in
IT security are a secondary audience.
This Technical Report recognizes that not all questions concerning IT security evaluation will be answered
herein and that further interpretations will be needed. Individual schemes will determine how to handle such
interpretations and other guidance, although these can be subject to mutual recognition agreements.
© ISO/IEC 2012 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 20004:2012(E)
Information technology — Security techniques — Refining
software vulnerability analysis under ISO/IEC 15408 and
ISO/IEC 18045
1 Scope
This Technical Report refines the AVA_VAN assurance family activities defined in ISO/IEC 18045:2008 and
provides more specific guidance on the identification, selection and assessment of relevant potential
vulnerabilities in order to conduct an ISO/IEC 15408 evaluation of a software target of evaluation. This
Technical Report leverages the Common Weakness Enumeration (CWE) and the Common Attack Pattern
Enumeration and Classification (CAPEC) to support the method of scoping and implementing
ISO/IEC 18045:2008 vulnerability analysis activities.
This Technical Report does not define evaluator actions for certain high assurance ISO/IEC 15408
components, where there is as yet no generally agreed guidance.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
assurance case
structured set of claims, arguments and a corresponding body of evidence to demonstrate that a system
satisfies specific claims with respect to its security properties
2.2
attack pattern
abstracted approach utilized to attack software
2.3
attack potential
measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise,
resources and motivation
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.5]
2.4
confirm
declare that something has been reviewed in detail with an independent determination of sufficiency
NOTE The level of rigour required depends on the nature of the subject matter. This term is only applied to evaluator
actions.
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.14]
2.5
CVE vulnerability
vulnerability listed in CVE
© ISO/IEC 2012 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC TR 20004:2012(E)
2.6
determine
affirm a particular conclusion based on independent analysis with the objective of reaching a particular
conclusion
NOTE The usage of this term implies a truly independent analysis, usually in the absence of any previous analysis
having been performed. Compare with the terms “confirm” or “verify” which imply that an analysis has already been
performed which needs to be reviewed
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.22]
2.7
encountered potential vulnerabilities
potential weakness in the TOE identified by the evaluator while performing evaluation activities that could be
used to violate the SFRs
[SOURCE: ISO/IEC 15408-1:2009, definition 3.5.2]
2.8
evaluation
assessment of a PP, an ST or a TOE, against defined criteria
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.26]
2.9
exploitable vulnerability
weakness in the TOE that can be used to violate the SFRs in the operational environment for the TOE
[SOURCE: ISO/IEC 15408-1:2009, definition 3.5.3]
2.10
potential vulnerability
suspected, but not confirmed, weakness
NOTE Suspicion is by virtue of a postulated attack path to violate the SFRs.
[SOURCE: ISO/IEC 15408-1:2009, definition 3.5.5]
2.11
Protection Profile
implementation-independent statement of security needs for a TOE type
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.52]
2.12
residual vulnerability
weakness that cannot be exploited in the operational environment for the TOE, but that could be used to
violate the SFRs by an attacker with greater attack potential than is anticipated in the operational environment
for the TOE
[SOURCE: ISO/IEC 15408-1:2009, definition 3.5.6]
2.13
Security Target
implementation-dependent statement of security needs for a specific identified TOE
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.63]
2 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 20004:2012(E)
2.14
selection
specification of one or more items from a list
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.64]
2.15
target of evaluation
set of software, firmware and/or hardware possibly accompanied by guidance
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.70]
2.16
threat agent
entity that can adversely act on assets
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.71]
2.17
TOE evaluation
assessment of a TOE against defined criteria
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.72]
2.18
TOE-relevant CVE vulnerabilities
CVE vulnerabilities from all versions of the TOE product family or CVE vulnerabilities associated with products
of the same technology type,
2.19
verify
rigorously review in detail with an independent determination of sufficiency
NOTE Also see “confirm” (3.1.14). The term “verify” has more rigorous connotations. It is used in the context
of evaluator actions where an independent effort is required of the evaluator.
[SOURCE: ISO/IEC 15408-1:2009, definition 3.1.84]
2.20
vulnerability
weakness in the TOE that can be used to violate the SFRs in some environment
[SOURCE: ISO/IEC 15408-1:2009, definition 3.5.7]
2.21
weakness
characteristic or property of a TOE that, in proper conditions, could contribute to the introduction of
vulnerabilities within that TOE
3 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
CAPEC™ Common Attack Pattern Enumeration and Classification
CVE® Common Vulnerabilities & Exposures
© ISO/IEC 2012 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC TR 20004:2012(E)
CWE™ Common Weakness Enumeration
ETR Evaluation Technical Report
PP Protection Profile
SAR Security Assurance Requirement
SFR Security Functional Requirement
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF Interface
4 Background Context
ISO/IEC 15408-3 sub-clause 15.1 defines “development vulnerabilities” as vulnerabilities which take
advantage of some properties of the TOE which were introduced during its development. In the same sub-
clause, ISO/IEC 15408-3 states that an assessment of development vulnerabilities is covered by the
assurance family called “vulnerability analysis” (AVA_VAN). ISO/IEC 15408-3 expects this assessment to
determine whether potential vulnerabilities identified could allow attackers to violate the SFRs and to deal with
the threat that an attacker will be able to discover flaws [as the identified potential vulnerabilities]
(ISO/IEC 15408-3:2008 sub-clause 15.2.1).
The levels in the AVA_VAN assurance family are ordered as follows:
AVA_VAN.1 “vulnerability survey” (ISO/IEC 15408-3:2008 sub-clause 15.2.3);
AVA_VAN.2 “vulnerability analysis” (ISO/IEC 15408-3:2008 sub-clause 15.2.4);
AVA_VAN.3 “focused vulnerability analysis” (ISO/IEC 15408-3:2008 sub-clause 15.2.5);
AVA_VAN.4 “methodical vulnerability analysis” (ISO/IEC 15408-3:2008 sub-clause 15.2.6);
AVA_VAN.5 “advanced methodical vulnerability analysis” (ISO/IEC 15408-3:2008 sub-clause
15.2.7).
AVA_VAN.1 is the lowest level and AVA_VAN.5 is the highest level in the AVA_VAN assurance family.
ISO/IEC 15408-3 states the following two evaluator actions for each of the AVA_VAN levels.
“Potential vulnerability identification from public sources” action
“The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE”,
in AVA_VAN.1.2E (ISO/IEC 15408-3:2008 sub-clause 15.2.3.4.2);
in AVA_VAN.2.2E (ISO/IEC 15408-3:2008 sub-clause 15.2.4.4.2);
in AVA_VAN.3.2E(ISO/IEC 15408-3:2008 sub-clause 15.2.5.4.2);
in AVA_VAN.4.2E(ISO/IEC 15408-3:2008 sub-clause 15.2.6.4.2);
in AVA_VAN.5.2E(ISO/IEC 15408-3:2008 sub-clause 15.2.7.4.2).
4 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 20004:2012(E)
“Penetration testing” action
“The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine
that the TOE is resistant to attacks performed by an attacker possessing
Basic attack potential” in AVA_VAN.1.3E (ISO/IEC 15408-3:2008 sub-clause 15.2.3.4.3);
Basic attack potential” in AVA_VAN.2.4E(ISO/IEC 15408-3:2008 sub-clause 15.2.4.4.4);
Enhanced-Basic attack potential” in AVA_VAN.3.4E (ISO/IEC 15408-3:2008 sub-clause 15.2.5.4.4);
Moderate attack potential” in AVA_VAN.4.4E (ISO/IEC 15408-3:2008 sub-clause 15.2.6.4.4); or
High attack potential” in AVA_VAN.5.4E (ISO/IEC 15408-3:2008 sub-clause 15.2.7.4.4).
ISO/IEC 18045:2008 further specifies certain work units associated with the “Potential vulnerability
identification from public sources” action (in its sub-clauses 14.2.1.5, 14.2.2.5, 14.2.3.5, 14.2.4.5) as follows.
AVA_VAN.1-3, AVA_VAN.2-3, AVA_VAN.3-3, AVA_VAN.4-3
The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the
TOE.
The availability of information, that may be readily available to an attacker that helps to identify and facilitate
attacks, effectively operates to substantially enhance the attack potential of a given attacker. The accessibility
of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this
information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern
search tools make such information easily available to the evaluator, and the determination of resistance to
published potential vulnerabilities and well known generic attacks can be achieved in a cost-effective manner.
The search of the information publicly available should be focused on those sources that refer specifically to
the product from which the TOE is derived. The extensiveness of this search should consider the following
factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of ADV
evidence available.
AVA_VAN.1-4, AVA_VAN.2-5, AVA_VAN.3-5, AVA_VAN.4-5
The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and
applicable to the TOE in its operational environment.
It may be identified that no further consideration of the potential vulnerability is required if for example the
evaluator identifies that measures in the operational environment, either IT or non-IT, prevent exploitation of
the potential vulnerability in that operational environment.
The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the
evaluator determines that the potential vulnerability is not applicable in the operational environment.
Otherwise the evaluator records the potential vulnerability for further consideration.
A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an
input into penetration testing activities, shall be reported in the ETR by the evaluators.
NOTE As stated in ISO/IEC 18045:2008 sub-clauses 14.2.5, ISO/IEC 18045 does not specify any work units at the
AVA_VAN.5 level.
© ISO/IEC 2012 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC TR 20004:2012(E)
The content of the “Potential vulnerability identification from public sources” evaluator action is summarized in
the following diagram.
Figure 1 — “Potential vulnerability identification from public sources” evaluator action summary
ISO/IEC 18045:2008 further specifies certain work units associated with the “Penetration testing” action (in its
sub-clauses 14.2.1.6, 14.2.2.7, 14.2.3.7, 14.2.4.7) as follows.
AVA_VAN.1-5, AVA_VAN.2-6, AVA_VAN.3-6, AVA_VAN.4-6
The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities.
The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its
operational environment, to the potential vulnerabilities identified during the search of the sources of
information publicly available. Any current information provided to the evaluator by a third party (e.g.
evaluation authority) regarding known potential vulnerabilities will be considered by the evaluator.
The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond
those which required
a Basic attack potential (in the case of AVA_VAN.1-5);
a Basic attack potential (in the case of AVA_VAN.2-6);
a Enhanced-Basic attack potential (in the case of AVA_VAN.3-6); or
a Moderate attack potential (in the case of AVA_VAN.4-6).
AVA_VAN.1-6, AVA_VAN.2-7, AVA_VAN.3-7, AVA_VAN.4-7
The evaluator shall produce penetration test documentation for the tests based on the list of potential
vulnerabilities in sufficient detail to enable the tests to be repeatable.
6 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 20004:2012(E)
With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for
the TOE's susceptibility. Specifically the evaluator considers:
a) the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses;
b) initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will
need to exist and security attributes they will need to have);
c) special test equipment that will be required to either stimulate a TSFI or make observations of a
TSFI;
d) whether theoretical analysis should replace physical testing, particularly relevant where the results of
an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to
succeed after a given number of attempts.
AVA_VAN.1-7, AVA_VAN.2-8, AVA_VAN.3-8, AVA_VAN.4-8
The evaluator shall conduct penetration testing.
The evaluator uses the penetration test documentation resulting from work unit
AVA_VAN.1-5 (in the case of AVA_VAN.1-7);
AVA_VAN.2-6 (in the case of AVA_VAN.2-8);
AVA_VAN.3-6 (in the case of AVA_VAN.3-8); or
AVA_VAN.4-6 (in the case of AVA_VAN.4-8)
as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from
performing additional ad hoc penetration tests.
AVA_VAN.1-8, AVA_VAN.2-9, AVA_VAN.3-9, AVA_VAN.4-9
The evaluator shall record the actual results of the penetration tests.
AVA_VAN.1-9, AVA_VAN.2-10, AVA_VAN.3-10, AVA_VAN.4-10
The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach,
configuration, depth and results.
AVA_VAN.1-10 and AVA_VAN.2-11
The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational
environment, is resistant to an attacker possessing a Basic attack potential.
If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker
possessing less than Enhanced-Basic attack potential, then this evaluator action (namely AVA_VAN.1.3E or
AVA_VAN.2.4E) fails.
The guidance in (ISO/IEC 18045 Annex B.4) should be used to determine the attack potential required to
exploit a particular vulnerability and whether it can therefore be exploited in the intended environment.
AVA_VA.3-11
The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational
environment, is resistant to an attacker possessing an Enhanced-Basic attack potential.
© ISO/IEC 2012 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC TR 20004:2012(E)
If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker
possessing less than Moderate attack potential, then this evaluator action (namely AVA_VAN.3.4E) fails.
The guidance in B.4 should be used to determine the attack potential required to exploit a particular
vulnerability and whether it can therefore be exploited in the intended environment.
AVA_VAN.4-11
The evaluator shall examine the results of all penetration testing to determine that the TOE, in its
operational environment, is resistant to an attacker possessing a Moderate attack potential.
If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an
attacker possessing less than a High attack potential, then this evaluator action (namely
AVA_VAN.4.4E) fails.
The guidance in B.4 should be used to determine the attack potential required to exploit a particular
vulnerability and whether it can therefore be exploited in the intended environment.
AVA_VAN.1-11, AVA_VAN.2-12, AVA_VAN.3-12, AVA_VAN.4-12
The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing
for each:
a) its source (e.g. ISO/IEC 18045 evaluation methodology activity being undertaken when it was
conceived, known to the evaluator, read in a publication);
b) the SFR(s) not met;
c) a description;
d) whether it is exploitable in its operational environment or not (i.e. exploitable or residual).
e) the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and
the equipment required to perform the identified vulnerabilities, and the corresponding values
using the tables B.2 and B.3 of (ISO/IEC 18045) Annex B.4.
NOTE As stated in ISO/IEC 18045:2008 sub-clauses 14.2.5, ISO/IEC 18045 does not specify any work units at the
AVA_VAN.5 level.
The content of the “Penetration testing” evaluator action is summarized in the following diagram.
8 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC TR 20004:2012(E)
Figure 2 — “Penetration testing” evaluator action summary
5 Overview
5.1 Purpose
This document is intended to provide added refinement, detail and guidance to the vulnerability analysis
activities outlined in ISO/IEC 18045:2008(E) for the software elements of a TOE. Specifically, it is intended to
add refinement and clarification of the “Potential vulnerability identification from public sources”
(AVA_VAN.1.2E/2.2E/3.2E/4.2E) and “Penetration testing” (AVA_VAN.1.3E/2.4E/3.4E/4.4E) evaluator
actions, which are currently imprecise in regards to searching for, identifying and testing relevant potential
vulnerabilities. This document provides guidance on an approach to objectively search for, identify, filter and
test potential vulnerabilities utilizing international ad hoc standard resources for software weaknesses and
attack patterns. The set of relevant software weaknesses and attack patterns identified through this guidance
represent a minimal set for analysis under the AVA_VAN assurance family in an ISO/IEC 15408 evaluation.
Additional weaknesses and attack patterns may be determined relevant by specific national schemes,
technical communities, associated protection profiles or other sources. In utilizing these standard structured
resources, the approach defined here has the added benefit of being equally applicable to the TOE
development process as it does to the TOE security evaluation process. This means that relevant
weaknesses and attack patterns identified and tested for during development, whether defined ad hoc or as
part of a structured assurance case, can provide an head start template for a TOE-specific set of relevant
weaknesses and attack patterns for use in the security evaluation.
This document is intended to be used in conjunction with and as an addendum to ISO/IEC 18045.
© ISO/IEC 2012 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/IEC TR 20004:2012(E)
6 Vulnerability Assessment Activities
6.1 Determine relevant potential vulnerabilities
ISO/IEC 18045:2008(E) defines the work units for determining relevant potential vulnerabilities in Sub-
clauses:
14.2.1.5.1 Work unit AVA_VAN.1-3;
14.2.2.5.1 Work unit AVA_VAN.2-3;
14.2.3.5.1 Work unit AVA_VAN.3-3;
14.2.4.5.1 Work unit AVA_VAN.4-3
Common Vulnerabilities and Exposures (CVE®) is a dictionary of common names (i.e., CVE Identifiers) for
publicly known information security vulnerabilities, while its Common Configuration Enumeration (CCE™)
provides identifiers for security configuration issues and exposures. CVE’s common identifiers make it easier
to share data across separate network security databases and tools, and provide a baseline for evaluating the
coverage of an organization’s security tools.
CVE is:
One name for one vulnerability or exposure
One standardized description for each vulnerability or exposure
A dictionary rather than a database
How disparate databases and tools can "speak" the same language
A way to interoperability and better security coverage
A basis for evaluation among tools and databases
Free for public download and use
Industry-endorsed via the CVE Editorial Board and CVE-Compatible Products
CVE was launched in 1999 when most information security tools used their own databases with their own
names for security vulnerabilities. At that time there was no significant variation among products and no easy
way to determine when the different databases were referring to the same problem. The consequences were
potential gaps in security coverage and no effective interoperability among the disparate databases and tools.
In addition, each tool vendor used different metrics to state the number of vulnerabilities or exposures they
detected, which meant there was no standardized basis for evaluation among the tools.
CVE’s common, standardized identifiers provided a systematic approach to these problems.
CVE is now a widely adopted industry standard for vulnerability and exposure names. CVE Identifiers provide
reference points for data exchange so that information security products and services can speak with each
other. CVE Identifiers also provides a baseline for evaluating the coverage of tools and services to help users
determine which tools are most effective and appropriate for their organization’s needs. In short, products and
services compatible with CVE provide better coverage, easier interoperability, and enhanced security.
There now exists a publicly available, substantive standardized enumeration of potential software
1
vulnerabilities (weaknesses) in the form of the Common Weakness Enumeration (CWE™). The Common
Weakness Enumeration is an international commun
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.