: 1~ 1 0~ Bulletin
`
`October 2002
`October 2002
`
`0 11101
`
`ADVISING USERS ON INFORMATION TECHNOLOGY
`
`SECURITY PATCHES AND
`SECURITY PATCHES AND
`THE CVE VULNERABILITY
`THE CVE VULNERABILITY
`NAMING SCHEME: TOOLS
`NAMING SCHEME: TOOLS
`TO ADDRESS COMPUTER
`TO ADDRESS COMPUTER
`SYSTEM VULNERABILITIES
`SYSTEM VULNERABILITIES
`Elizabeth B. Lennon, Editor, Information
`Elizabeth B. Lennon, Editor, Information
`Technology Laboratory, National Institute of
`Technology Laboratory, National Institute of
`Standards and Technology
`Standards and Technology
`Today more than ever, timely response
`Today more than ever, timely response
`to vulnerabilities is critical to maintain
`to vulnerabilities is critical to maintain
`the operational availability, confiden-
`the operational availability, confiden-
`tiality, and integrity of information
`tiality, and integrity of information
`technology (IT) systems. To assist fed-
`technology (IT) systems. To assist fed-
`eral agencies and industry respond to
`eral agencies and industry respond to
`vulnerabilities in a timely manner,
`vulnerabilities in a timely manner,
`ITL recently released two new publi-
`ITL recently released two new publi-
`cations dealing with vulnerabilities in
`cations dealing with vulnerabilities in
`computer systems: NIST Special Pub-
`computer systems: NIST Special Pub-
`lication (SP) 800-40, Procedures for
`lication (SP) 800-40, Procedures for
`Handling Security Patches, by Peter
`Handling Security Patches, by Peter
`Mell and Miles C. Tracy, and NIST
`Mell and Miles C. Tracy, and NIST
`SP 800-51, Use of the Common Vulner-
`SP 800-51, Use of the Common Vulner-
`abilities and Exposures (CVE) Vulnera-
`abilities and Exposures (CVE) Vulnera-
`bility Naming Scheme, by Peter Mell
`bility Naming Scheme, by Peter Mell
`and Tim Grance. This ITL Bulletin
`and Tim Grance. This ITL Bulletin
`summarizes these two documents on
`summarizes these two documents on
`system vulnerabilities, available at
`system vulnerabilities, available at
`http: //csrc.nist.gov/publications/
`http://csrc.nist.gov/publications/
`nistpubs/index.html.
`nistpubs/index.html.
`
`Security Patches
`Security Patches
`Failure to keep operating system and
`Failure to keep operating system and
`application software up to date is a
`application software up to date is a
`common mistake made by IT profes-
`common mistake made by IT profes-
`sionals. Despite extensive testing, all
`sionals. Despite extensive testing, all
`operating systems and applications are
`operating systems and applications are
`released with bugs (errors in the soft-
`released with bugs (errors in the soft-
`ware) that affect security, perfor-
`ware) that affect security, perfor-
`mance, and stability. As software
`mance, and stability. As software
`programs expand, the potential num-
`programs expand, the potential num-
`ber of bugs grows. Many security-
`ber of bugs grows. Many security-
`related bugs are generally discovered
`related bugs are generally discovered
`only after a large number of users start
`only after a large number of users start
`using the software, and hackers and
`using the software, and hackers and
`independent testers start attempting
`independent testers start attempting
`to compromise it. Once a bug is dis-
`to compromise it. Once a bug is dis-
`covered, the software manufacturer
`covered, the software manufacturer
`often releases a piece of software to
`often releases a piece of software to
`correct the bug. This software is often
`correct the bug. This software is often
`called a patch, hotfix, or service pack.
`called a patch, hotfix, or service pack.
`
`Patches are released for three reasons:
`Patches are released for three reasons:
`■ To fix faults in an application or
`■ To fix faults in an application or
`operating system. Many hacker
`operating system. Many hacker
`attacks are based on exploiting faults
`attacks are based on exploiting faults
`in the computer code of applications
`in the computer code of applications
`and operating systems. Patches are
`and operating systems. Patches are
`also released to correct performance
`also released to correct performance
`or functionality problems.
`or functionality problems.
`■ To alter functionality or to address a
`■ To alter functionality or to address a
`new security threat. An example of
`new security threat. An example of
`this is new virus definitions for an
`this is new virus definitions for an
`antivirus application. There was
`antivirus application. There was
`nothing "wrong" with the code of
`nothing “wrong” with the code of
`the antivirus program, but it had to
`the antivirus program, but it had to
`be updated to detect new viruses
`be updated to detect new viruses
`that did not exist when the applica-
`that did not exist when the applica-
`tion was first released.
`tion was first released.
`■ To change or modify the software
`■ To change or modify the software
`configuration to make it less suscep-
`configuration to make it less suscep-
`tible to attacks and more secure.
`tible to attacks and more secure.
`Applying patches in a timely and con-
`Applying patches in a timely and con-
`sistent manner is critical to maintain-
`sistent manner is critical to maintain-
`ing the operational availability,
`ing the operational availability,
`confidentiality, and integrity of IT sys-
`confidentiality, and integrity of IT sys-
`tems. However, failure to keep operat-
`tems. However, failure to keep operat-
`ing system and application software
`ing system and application software
`patched is an all too common mistake
`patched is an all too common mistake
`made by IT professionals. New
`made by IT professionals. New
`patches are released daily, and it is
`patches are released daily, and it is
`often difficult for even experienced
`often difficult for even experienced
`system administrators to keep abreast
`system administrators to keep abreast
`of all the new patches.
`of all the new patches.
`The CERT/Coordination Center
`The CERT/Coordination Center
`(CC) (http://www.cert.org) estimates
`(CC) (http://www.cert.org) estimates
`that 95 percent of all network intru-
`that 95 percent of all network intru-
`sions could be avoided by keeping sys-
`sions could be avoided by keeping sys-
`tems up to date with appropriate
`tems up to date with appropriate
`patches. In an increasingly intercon-
`patches. In an increasingly intercon-
`nected world, it is critical that system
`nected world, it is critical that system
`administrators keep their systems
`administrators keep their systems
`patched to the most secure level. A
`patched to the most secure level. A
`common misperception among some
`common misperception among some
`system administrators is that a firewall
`system administrators is that a firewall
`reduces the need for timely patching.
`reduces the need for timely patching.
`Unfortunately, this is incorrect
`Unfortunately, this is incorrect
`because a firewall generally permits
`because a firewall generally permits
`some level of traffic between most
`some level of traffic between most
`
`Continued on page 2
`Continued on page 2
`
`ITL Bulletins are published by the
`ITL Bulletins are published by the
`Information Technology Laboratory
`Information Technology Laboratory
`(ITL) of the National Institute of
`(ITL) of the National Institute of
`Standards and Technology (NIST).
`Standards and Technology (NIST).
`Each bulletin presents an in-depth
`Each bulletin presents an in-depth
`discussion of a single topic of significant
`discussion of a single topic of significant
`interest to the information systems
`interest to the information systems
`community. Bulletins are issued on
`community. Bulletins are issued on
`an as-needed basis and are available
`an as-needed basis and are available
`from ITL Publications, National
`from ITL Publications, National
`Institute of Standards and Technology,
`Institute of Standards and Technology,
`100 Bureau Drive, Stop 8901,
`100 Bureau Drive, Stop 8901,
`Gaithersburg, MD 20899-8901,
`Gaithersburg, MD 20899-8901,
`telephone (301) 975-2832. To be
`telephone (301) 975-2832. To be
`placed on a mailing list to receive
`placed on a mailing list to receive
`future bulletins, send your name,
`future bulletins, send your name,
`organization, and business address to
`organization, and business address to
`this office. You will be placed on this
`this office. You will be placed on this
`mailing list only.
`mailing list only.
`
`Bulletins issued since March 2001
`Bulletins issued since March 2001
`
`❐ An Introduction to IPsec (Internet Protocol
`O An Introduction to IPsec (Internet Protocol
`Security), March 2001
`Security), March 2001
`❐ Biometrics – Technologies For Highly
`O Biometrics — Technologies For Highly
`Secure Personal Authentication, May 2001
`Secure Personal Authentication, May 2001
`O Engineering Principles for Information
`❐ Engineering Principles for Information
`Technology Security, June 2001
`Technology Security, June 2001
`O A Comparison of The Security
`❐ A Comparison of The Security
`Requirements for Cryptographic Modules
`Requirements for Cryptographic Modules
`In FIPS 140-1 and FIPS 140-2, July
`In FIPS 140-1 and FIPS 140-2, July
`2001
`2001
`O Security Self-assessment Guide For
`❐ Security Self-assessment Guide For
`Information Technology Systems,
`Information Technology Systems,
`September 2001
`September 2001
`O Computer Forensics Guidance, November
`❐ Computer Forensics Guidance, November
`2001
`2001
`O Guidelines on Firewalls and Firewall
`❐ Guidelines on Firewalls and Firewall
`Policy, January 2002
`Policy, January 2002
`O Risk Management Guidance for
`❐ Risk Management Guidance for
`Information Technology Systems, February
`Information Technology Systems, February
`2002
`2002
`O Techniques for System and Data Recovery,
`❐ Techniques for System and Data Recovery,
`April 2002
`April 2002
`O Contingency Planning Guide for
`❐ Contingency Planning Guide for
`Information Technology Systems, June
`Information Technology Systems, June
`2002
`2002
`O Overview: The Government Smart Card
`❐ Overview: The Government Smart Card
`Interoperability Specification, July 2002
`Interoperability Specification, July 2002
`O Cryptographic Standards and Guidelines:
`❐ Cryptographic Standards and Guidelines:
`A Status Report, September 2002
`A Status Report, September 2002
`
`NISI'
`
` National Institute of Standards and Technology • Technology Administration • U.S. Department of Commerce
`WIZ, Inc. EXHIBIT - 1023
`WIZ, Inc. v. Orca Security LTD.
`
`WIZ, Inc. EXHIBIT - 1023
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`2
`2
`
`internal and external hosts. As long as
`internal and external hosts. As long as
`a communication channel is allowed
`a communication channel is allowed
`between the internal network and the
`between the internal network and the
`Internet or other external network,
`Internet or other external network,
`there is a risk of compromise; thus
`there is a risk of compromise; thus
`patching becomes critical.
`patching becomes critical.
`
`Identifying Vulnerabilities and
`Identifying Vulnerabilities and
`Applicable Patches
`Applicable Patches
`Vulnerabilities are weaknesses in soft-
`Vulnerabilities are weaknesses in soft-
`ware that can be exploited by a mali-
`ware that can be exploited by a mali-
`cious entity to gain greater access and/
`cious entity to gain greater access and/
`or permission than it is authorized to
`or permission than it is authorized to
`have on a computer. Not all vulnera-
`have on a computer. Not all vulnera-
`bilities have related patches; thus, sys-
`bilities have related patches; thus, sys-
`tem administrators must not only be
`tem administrators must not only be
`aware of vulnerabilities and patches,
`aware of vulnerabilities and patches,
`but also of the need to mitigate
`but also of the need to mitigate
`unpatchedvulnerabilities through other
`unpatched vulnerabilities through other
`methods (e.g., workarounds, firewalls,
`methods (e.g., workarounds, firewalls,
`and router access control lists).
`and router access control lists).
`To help address this growing problem,
`To help address this growing problem,
`we recommend that organizations have
`we recommend that organizations have
`an explicit and documented patching
`an explicit and documented patching
`and vulnerability policy and a system-
`and vulnerability policy and a system-
`atic, accountable, and documented
`atic, accountable, and documented
`process for handling patches. NIST SP
`process for handling patches. NIST SP
`800-40, Procedures for Handling Secu-
`800-40, Procedures for Handling Secu-
`rity Patches, provides principles and
`rity Patches, provides principles and
`methodologies for accomplishing this.
`methodologies for accomplishing this.
`One of several possible techniques is
`One of several possible techniques is
`through the creation of a patch and
`through the creation of a patch and
`vulnerability group (PVG). This group
`vulnerability group (PVG). This group
`facilitates the identification and distri-
`facilitates the identification and distri-
`bution of patches within the organiza-
`bution of patches within the organiza-
`tion. Its duties include:
`tion. Its duties include:
`
`ITL Bulletins Via E-Mail
`ITL Bulletins Via E-Mail
`We now offer the option of delivering
`We now offer the option of delivering
`your ITL Bulletins in ASCII format
`your ITL Bulletins in ASCII format
`directly to your e-mail address. To
`directly to your e-mail address. To
`subscribe to this service, send an e-mail
`subscribe to this service, send an e-mail
`message from your business e-mail
`message from your business e-mail
`account to listproc@nist.gov with the
`account to listproc@nist.gov with the
`message subscribe id-bulletin, and your
`message subscribe itl-bulletin, and your
`name, e.g., John Doe. For instructions
`name, e.g., John Doe. For instructions
`on using listproc, send a message to
`on using listproc, send a message to
`listproc@nist.gov with the message
`listproc@nist.gov with the message
`HELP. To have the bulletin sent to an
`HELP. To have the bulletin sent to an
`e-mail address other than the From
`e-mail address other than the From
`address, contact the ITL editor at
`address, contact the ITL editor at
`301-975-2832 or
`301-975-2832 or
`elizabeth.lennon@nist.gov.
`elizabeth.lennon@nist.gov.
`
`■ Creating a reasonably representa-
`■ Creating a reasonably representa-
`tive organizational hardware and
`tive organizational hardware and
`software inventory,
`software inventory,
`■ Identifying newly discovered vul-
`Identifying newly discovered vul-
`nerabilities and security patches,
`nerabilities and security patches,
`■ Prioritizing patch application,
`■ Prioritizing patch application,
`■ Creating an organization-specific
`■ Creating an organization-specific
`patch database,
`patch database,
`■ Testing patches for functionality
`■ Testing patches for functionality
`and security (to the degree that
`and security (to the degree that
`resources allow),
`resources allow),
`■ Distributing patch and vulnerability
`■ Distributing patch and vulnerability
`information to local administrators,
`information to local administrators,
`■ Verifying patch installation through
`■ Verifying patch installation through
`network and host vulnerability
`network and host vulnerability
`scanning,
`scanning,
`■ Training system administrators in
`■ Training system administrators in
`the use of vulnerability databases,
`the use of vulnerability databases,
`■ Deploying patches automatically
`■ Deploying patches automatically
`(when applicable), and
`(when applicable), and
`■ Configuring Automatic Update of
`■ Configuring Automatic Update of
`Applications (when applicable).
`Applications (when applicable).
`If organizations use the PVG
`If organizations use the PVG
`approach, this does not diminish the
`approach, this does not diminish the
`responsibility of all systems adminis-
`responsibility of all systems adminis-
`trators to patch the systems under
`trators to patch the systems under
`their control. Each systems adminis-
`their control. Each systems adminis-
`trator should:
`trator should:
`■ Apply patches identified by the
`■ Apply patches identified by the
`PVG,
`PVG,
`■ Test patches on the specific target
`■ Test patches on the specific target
`systems, and
`systems, and
`■ Identify patches and vulnerabilities
`Identify patches and vulnerabilities
`associated with software not moni-
`associated with software not moni-
`tored by the PVG.
`tored by the PVG.
`Besides creating a PVG, organizations
`Besides creating a PVG, organizations
`should be aware that applying patches
`should be aware that applying patches
`and mitigating vulnerabilities is sel-
`and mitigating vulnerabilities is sel-
`dom, especially in large organizations,
`dom, especially in large organizations,
`a straightforward process. To help
`a straightforward process. To help
`with this, NIST SP 800-40 covers
`with this, NIST SP 800-40 covers
`areas such as obtaining patches, priori-
`areas such as obtaining patches, priori-
`tizing patches, testing patches, and
`tizing patches, testing patches, and
`applying patches. An overview of spe-
`applying patches. An overview of spe-
`cific government patch and vulnera-
`cific government patch and vulnera-
`bility resources is included.
`bility resources is included.
`Appendices present a glossary of
`Appendices present a glossary of
`terms, patching resources for a variety
`terms, patching resources for a variety
`of platforms and applications, guid-
`of platforms and applications, guid-
`ance on using the NIST ICAT Meta-
`ance on using the NIST ICAT Meta-
`base, commonly used vulnerability
`base, commonly used vulnerability
`
`October 2002
`October 2OO2
`
`resources, and guidance on using
`resources, and guidance on using
`other available tools and resources.
`other available tools and resources.
`
`Recommendations for Handling
`Recommendations for Handling
`Security Patches
`Security Patches
`Organizations should have an explicit
`Organizations should have an explicit
`and documented patching and vulner-
`and documented patching and vulner-
`ability policy as well as a systematic,
`ability policy as well as a systematic,
`accountable, and documented set of
`accountable, and documented set of
`processes and procedures for handling
`processes and procedures for handling
`patches. The patching and vulnerabil-
`patches. The patching and vulnerabil-
`ity policy should specify what tech-
`ity policy should specify what tech-
`niques an organization will use to
`niques an organization will use to
`monitor for new patches and vulnera-
`monitor for new patches and vulnera-
`bilities and which personnel will be
`bilities and which personnel will be
`responsible for such monitoring. An
`responsible for such monitoring. An
`organization's patching process should
`organization’s patching process should
`define a method for deciding which
`define a method for deciding which
`systems get patched and which
`systems get patched and which
`patches get installed first. It should
`patches get installed first. It should
`also include a methodology for testing
`also include a methodology for testing
`and safely installing patches.
`and safely installing patches.
`When designing a process for han-
`When designing a process for han-
`dling patches, consider the principles
`dling patches, consider the principles
`that make up the PVG patching con-
`that make up the PVG patching con-
`cept. Other patching variations may
`cept. Other patching variations may
`be acceptable, but the core concepts
`be acceptable, but the core concepts
`should be found within the chosen
`should be found within the chosen
`patching methodology. These ideas
`patching methodology. These ideas
`include using organizational invento-
`include using organizational invento-
`ries, vulnerability and patch monitor-
`ries, vulnerability and patch monitor-
`ing, patch prioritization techniques,
`ing, patch prioritization techniques,
`organizational patch databases, patch
`organizational patch databases, patch
`testing, patch distribution, patch
`testing, patch distribution, patch
`application verification, patch training,
`application verification, patch training,
`automated patch deployment, and
`automated patch deployment, and
`automatic updating of applications.
`automatic updating of applications.
`The patch process can be automated
`The patch process can be automated
`or manual; however, organizations
`or manual; however, organizations
`should expect to transition to more
`should expect to transition to more
`automated methods in the future. The
`automated methods in the future. The
`movement towards automated patch
`movement towards automated patch
`methods will parallel organizational
`methods will parallel organizational
`plans to centralize services and stan-
`plans to centralize services and stan-
`dardize desktop configurations.
`dardize desktop configurations.
`While patching and vulnerability
`While patching and vulnerability
`monitoring can often appear an over-
`monitoring can often appear an over-
`whelming task, consistent mitigation
`whelming task, consistent mitigation
`of organizational vulnerabilities can be
`of organizational vulnerabilities can be
`achieved through a tested, prioritized,
`achieved through a tested, prioritized,
`and integrated patching and remedia-
`and integrated patching and remedia-
`tion process. It is our hope that NIST
`tion process. It is our hope that NIST
`SP 800-40 will aid those whose job is
`SP 800-40 will aid those whose job is
`to undertake this important and
`to undertake this important and
`difficult task.
`difficult task.
`
`■
`■
`

`

`October 2002
`October 2OO2
`
`Common Vulnerabilities and
`Common Vulnerabilities and
`Exposures (CVE) Vulnerability
`Exposures (CVE) Vulnerability
`Naming Scheme
`Naming Scheme
`
`Closely related to the handling of
`Closely related to the handling of
`security patches is a means to identify
`security patches is a means to identify
`and organize known IT system vulner-
`and organize known IT system vulner-
`abilities. As described in NIST SP
`abilities. As described in NIST SP
`800-51, the Common Vulnerabilities
`800-51, the Common Vulnerabilities
`and Exposures (CVE) vulnerability
`and Exposures (CVE) vulnerability
`naming scheme is a dictionary of com-
`naming scheme is a dictionary of com-
`mon names for publicly known IT
`mon names for publicly known IT
`system vulnerabilities. It is an emerg-
`system vulnerabilities. It is an emerg-
`ing industry standard that has
`ing industry standard that has
`achieved wide acceptance by the secu-
`achieved wide acceptance by the secu-
`rity industry and a number of govern-
`rity industry and a number of govern-
`ment organizations. Technical
`ment organizations. Technical
`vulnerability experts from 31 industry,
`vulnerability experts from 31 industry,
`academia, and government organiza-
`academia, and government organiza-
`tions vote on the common names.
`tions vote on the common names.
`CVE provides the computer security
`CVE provides the computer security
`community with:
`community with:
`■ a comprehensive list of publicly
`a comprehensive list of publicly
`known vulnerabilities,
`known vulnerabilities,
`■ an analysis of the authenticity of
`an analysis of the authenticity of
`newly published vulnerabilities, and
`newly published vulnerabilities, and
`■ a unique name to be used for each
`a unique name to be used for each
`vulnerability.
`vulnerability.
`General CVE information is available
`General CVE information is available
`at http://cve.mitre.org. The vulnera-
`at http://cve.mitre.org. The vulnera-
`bilities listed in CVE can be viewed
`bilities listed in CVE can be viewed
`using the NIST ICAT vulnerability
`using the NIST ICAT vulnerability
`index at http://icat.nist.gov.
`index at http://icat.nist.gov.
`
`Who we are
`Who we are
`The Information Technology Laboratory
`The Information Technology Laboratory
`(ITL) is a major research component of
`(ITL) is a major research component of
`the National Institute of Standards and
`the National Institute of Standards and
`Technology (NIST) of the Technology
`Technology (NIST) of the Technology
`Administration, U.S. Department of
`Administration, U.S. Department of
`Commerce. We develop tests and
`Commerce. We develop tests and
`measurement methods, reference data,
`measurement methods, reference data,
`proof-of-concept implementations, and
`proof-of-concept implementations, and
`technical analyses that help to advance the
`technical analyses that help to advance the
`development and use of new information
`development and use of new information
`technology. We seek to overcome barriers
`technology. We seek to overcome barriers
`to the efficient use of information
`to the efficient use of information
`technology, and to make systems more
`technology, and to make systems more
`interoperable, easily usable, scalable, and
`interoperable, easily usable, scalable, and
`secure than they are today. Our web site is
`secure than they are today. Our web site is
`http://www.itl.nist.gov/.
`http://www.itl.nist.gov/.
`
`Guidelines for Use of the CVE
`Guidelines for Use of the CVE
`Vulnerability Naming Scheme
`Vulnerability Naming Scheme
`
`1. Federal departments and agencies
`1. Federal departments and agencies
`should give substantial consider-
`should give substantial consider-
`ation to the acquisition and use of
`ation to the acquisition and use of
`security-related IT products and
`security-related IT products and
`services that are compatible with the
`services that are compatible with the
`CVE vulnerability naming scheme.
`CVE vulnerability naming scheme.
`Most federal departments and agen-
`Most federal departments and agen-
`cies use commercial off-the-shelf
`cies use commercial off-the-shelf
`(COTS) security products and ser-
`(COTS) security products and ser-
`vices to track, detect, or counter
`vices to track, detect, or counter
`known vulnerabilities. A problem
`known vulnerabilities. A problem
`with many of these products is that
`with many of these products is that
`different products use different
`different products use different
`names for the same vulnerabilities.
`names for the same vulnerabilities.
`Without a consistent vulnerability
`Without a consistent vulnerability
`terminology, it is difficult to com-
`terminology, it is difficult to com-
`pare the vulnerability coverage of
`pare the vulnerability coverage of
`such security products. Also, it may
`such security products. Also, it may
`be complex to correlate alerts
`be complex to correlate alerts
`among databases and tools of differ-
`among databases and tools of differ-
`ent vendors or services.
`ent vendors or services.
`CVE-compatible products and ser-
`CVE-compatible products and ser-
`vices, however, use the same name
`vices, however, use the same name
`for each vulnerability, thus address-
`for each vulnerability, thus address-
`ing many of these coverage and cor-
`ing many of these coverage and cor-
`relation concerns. Therefore, it is
`relation concerns. Therefore, it is
`important to consider acquiring
`important to consider acquiring
`CVE-compatible security products
`CVE-compatible security products
`and services. Agencies should be
`and services. Agencies should be
`careful, however, to consider CVE
`careful, however, to consider CVE
`compatibility only for products and
`compatibility only for products and
`services that inherently make use of
`services that inherently make use of
`vulnerability names. Such products
`vulnerability names. Such products
`and services include vulnerability
`and services include vulnerability
`scanners, vulnerability databases,
`scanners, vulnerability databases,
`vulnerability advisory services, vul-
`vulnerability advisory services, vul-
`nerability patch services, most
`nerability patch services, most
`intrusion detection systems (IDSs),
`intrusion detection systems (IDSs),
`and some firewalls.
`and some firewalls.
`Your organization's use of CVE-
`Your organization’s use of CVE-
`compatible products can assist you by
`compatible products can assist you by
`■ determining which product cov-
`■ determining which product cov-
`ers the vulnerabilities most appli-
`ers the vulnerabilities most appli-
`cable to an agency's network
`cable to an agency’s network
`infrastructure; and
`infrastructure; and
`■ increasing the assurance that the
`increasing the assurance that the
`alerts produced by the product(s)
`alerts produced by the product(s)
`you choose will be able to be cor-
`you choose will be able to be cor-
`related with alerts from your
`related with alerts from your
`other products and from your
`other products and from your
`incident response center.
`incident response center.
`
`3
`3
`
`The requirements for CVE compat-
`The requirements for CVE compat-
`ibility are described at http://cve.
`ibility are described at http://cve.
`mitre.org/compatible/requirements.
`mitre.org/compatible/requirements.
`html. Currently identified compati-
`html. Currently identified compati-
`ble products and services are listed
`ble products and services are listed
`on the Compatible Products pages,
`on the Compatible Products pages,
`http://cve.mitre.org/compatible.
`http://cve.mitre.org/compatible.
`While CVE compatibility should be
`While CVE compatibility should be
`an important consideration in IT
`an important consideration in IT
`security product and service acquisi-
`security product and service acquisi-
`tion, federal departments and agen-
`tion, federal departments and agen-
`cies should foremost consider their
`cies should foremost consider their
`overall requirements (functionality,
`overall requirements (functionality,
`cost, performance, architecture, etc.)
`cost, performance, architecture, etc.)
`when acquiring products and services.
`when acquiring products and services.
`2. Federal departments and agencies
`2. Federal departments and agencies
`should periodically monitor their
`should periodically monitor their
`systems for applicable vulnerabili-
`systems for applicable vulnerabili-
`ties listed in the CVE vulnerability
`ties listed in the CVE vulnerability
`naming scheme.
`naming scheme.
`NIST recommends monitoring sys-
`NIST recommends monitoring sys-
`tems for vulnerabilities included in
`tems for vulnerabilities included in
`the CVE list since it is a standard-
`the CVE list since it is a standard-
`ized, reviewed, and comprehensive
`ized, reviewed, and comprehensive
`vulnerability repository. CVE con-
`vulnerability repository. CVE con-
`sists of both standardized and can-
`sists of both standardized and can-
`didate vulnerabilities, and systems
`didate vulnerabilities, and systems
`should be monitored for both types.
`should be monitored for both types.
`Agencies should identify the CVE
`Agencies should identify the CVE
`entries that apply to the software
`entries that apply to the software
`used in their systems and correct
`used in their systems and correct
`those vulnerabilities. Greater
`those vulnerabilities. Greater
`emphasis should be placed upon
`emphasis should be placed upon
`systems that are accessible from the
`systems that are accessible from the
`Internet (e.g., web and e-mail serv-
`Internet (e.g., web and e-mail serv-
`ers), systems that house important
`ers), systems that house important
`or sensitive applications or data
`or sensitive applications or data
`(e.g., databases), or network infra-
`(e.g., databases), or network infra-
`structure components (e.g., routers,
`structure components (e.g., routers,
`switches, and firewalls). Since it is
`switches, and firewalls). Since it is
`infeasible for an organization to
`infeasible for an organization to
`find and fix all vulnerabilities in
`find and fix all vulnerabilities in
`every system simultaneously, orga-
`every system simultaneously, orga-
`nizations should carefully prioritize
`nizations should carefully prioritize
`their monitoring and patching
`their monitoring and patching
`efforts (see NIST SP 800-40, Proce-
`efforts (see NIST SP 800-40, Proce-
`dures for Handling Security Patches,
`dures for Handling Security Patches,
`http://csrc.nist.gov) to correct the
`http://csrc.nist.gov) to correct the
`most severe vulnerabilities on the
`most severe vulnerabilities on the
`most high-risk systems.
`most high-risk systems.
`Automated software tools can scan
`Automated software tools can scan
`hosts and networks for CVE vulner-
`hosts and networks for CVE vulner-
`abilities, and we recommend regular
`abilities, and we recommend regular
`use of such products. However, such
`use of such products. However, such
`products may not check for every CVE
`products may not check for every CVE
`
`■
`■
`■
`■
`

`

`4
`4
`
`vulnerability entry. For additional
`vulnerability entry. For additional
`thoroughness, systems administra-
`thoroughness, systems administra-
`tors and security officers can period-
`tors and security officers can p