Identify security vulnerabilities to the system.

UCF ID: 00700

Control Type: Process or Activity

Status: Live

Supporting and supported controls

This control directly supports:

Identify the risks to organizational information and technology. [UCF Control ID 00698]

There are no supporting controls.

Authority documents complied with:

FFIEC IT Examination Handbook – Information Security, Pg 12, Exam Tier I Obj 1.4, Exam Tier I Obj 6.9, Exam Tier II Obj M.22; FFIEC IT Examination Handbook – Management, Exam Obj 5.2; Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 1.2.1, § 6.2.b; Army Regulation 380-19: Information Systems Security, February 27, 1998, § 1-5.a(1), § 5-3.c; Chemical Facility Anti-Terrorism Standards (CFATS), Department of Homeland Security, 6 CFR Part 27, § 27.230(a)(14); FIPS 191, Guideline for the Analysis of Local Area Network (LAN) Security, § 3.3; Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996, § 3.3.1; Business Continuity Institute (BCI) Good Practice Guidelines, 2005, Stage 1.3 Process; The Standard of Good Practice for Information Security, SM2.2.4(d), SM3.4.4(d), SM3.4.4(e), CB5.3.3(c), CB5.3.3(d), CI5.4.4(c), CI5.4.4(d), NW4.4.4(c), NW4.4.4(d), SD3.5.4(c), SD3.5.4(d); ISO/IEC 17799 Code of Practice for Information Security Management, 2005, § 6.2.1; ISO/IEC 27001 Information Security Management Systems - Requirements, 2005, § 4.2.1(d); ISO/IEC 27002 Code of practice for information security management, 2005, § 6.2.1; Australian Government ICT Security Manual (ACSI 33), § 3.5.14, § 3.7.29; Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 1.2, § 6.2(b); Payment Card Industry (PCI) Payment Application Data Security Standard, Version 1.1, § 7.1; BS 25999-1, Business continuity management. Code of practice, 2006, § 6.5.1, § 6.5.5; PAS 77 IT Service Continuity Management. Code of Practice, 2006, § 6.2 ¶ 2; Leahy Personal Data Privacy and Security Act of 2009, Senate Bill 1490, 111th Congress, § 302(a)(3)(A), § 302(a)(3)(D); ISO/IEC 13335-1, Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management, 2004, § 3.4; ISO/IEC 13335-3 Information technology — Guidelines for the management of IT Security — Part 3: Techniques for the management of IT Security, 1998, ¶ 9.3.5; ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000, ¶ 10.3.4, ¶ 10.3.5

Banking and Finance Guidance

The organization should assess the potential vulnerabilities to the systems. The risk assessment should consider the risk to the organization for the time the vulnerability exists, even if it is just a short time. [Pg 12, Exam Tier I Obj 1.4, Exam Tier I Obj 6.9, Exam Tier II Obj M.22, FFIEC IT Examination Handbook – Information Security]

[Exam Obj 5.2, FFIEC IT Examination Handbook – Management]

Payment Card Guidance

The organization must develop procedures for identifying newly discovered vulnerabilities, such as subscribing to alert services.
Verify a process has been implemented to continuously identify new vulnerabilities to the system, including from resources outside the organization.
Interview security personnel to ensure new vulnerabilities are identified. [§ 6.2.b, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 1.2.1]

The organization must develop procedures for identifying newly discovered vulnerabilities, such as subscribing to alert services. [§ 6.2(b), Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 1.2]

Procedures should be in place to identify new security vulnerabilities via security information sources, such as security alert services, that can be subscribed to free over the Internet. These procedures should be applied to all software that comes with the payment application. [§ 7.1, Payment Card Industry (PCI) Payment Application Data Security Standard, Version 1.1]

US Federal Security Guidance

The measures implemented to meet the system objectives should be commensurate with the relative vulnerabilities to the system. Vulnerabilities should be identified for each specific threat. Factors to consider when identifying the vulnerabilities include geographic location, data classification, operational criticality, and the sensitivity of the data. Vulnerabilities identified and not corrected should be identified in future risk assessments. [§ 1-5.a(1), § 5-3.c, Army Regulation 380-19: Information Systems Security, February 27, 1998]

The facility must address all the specific risks for its location that are identified by the Assistant Secretary. [§ 27.230(a)(14), Chemical Facility Anti-Terrorism Standards (CFATS), Department of Homeland Security, 6 CFR Part 27]

[§ 3.3, FIPS 191, Guideline for the Analysis of Local Area Network (LAN) Security]

US Federal Privacy Guidance

A risk assessment must be performed by a business entity to identify internal and external vulnerabilities that could lead to unauthorized disclosure, alteration, or use of or access to sensitive personally identifiable information or systems that contain sensitive personally identifiable information and to determine, with regard to the destruction and disposal of sensitive personally identifiable information, the vulnerability of this information during the destruction and disposal process or during the process of disposing or retiring hardware. [§ 302(a)(3)(A), § 302(a)(3)(D), Leahy Personal Data Privacy and Security Act of 2009, Senate Bill 1490, 111th Congress]

NIST Guidance

A vulnerability analysis, a safeguard analysis, a likelihood assessment, threat identification, and a consequence assessment are all called for. [§ 3.3.1, Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996]

ISO Guidance

Before granting access to a third party, risks should be identified and controls should be implemented. The identification of vulnerabilities should take into account the following: The type of access and what information the third party is accessing; the value of the information; the controls used by the third party; procedures to deal with security incidents; measures being used to identify third party personnel who have access; and legal requirements. [§ 6.2.1, ISO/IEC 17799 Code of Practice for Information Security Management, 2005]

All vulnerabilities to the system that could be exploited by a threat should be identified. [§ 4.2.1(d), ISO/IEC 27001 Information Security Management Systems - Requirements, 2005]

Before granting access to a third party, risks should be identified and controls should be implemented. The identification of vulnerabilities should take into account the following: The type of access and what information the third party is accessing; the value of the information; the controls used by the third party; procedures to deal with security incidents; measures being used to identify third party personnel who have access; and legal requirements. [§ 6.2.1, ISO/IEC 27002 Code of practice for information security management, 2005]

Vulnerabilities. An organization should evaluate vulnerabilities as part of its ICT security program. A weakness of an asset, or group of assets, that can be exploited by one or more threats is known as a vulnerability. Vulnerabilities associated with assets include weaknesses in physical layout, organization, procedures, personnel, management, administration, hardware, software or information. Threats may exploit vulnerabilities to cause harm to the ICT system or business objectives. A vulnerability can exist in the absence of corresponding threats. A vulnerability in itself does not cause harm; a vulnerability is merely a condition or set of conditions that may allow a threat to affect an asset. Vulnerabilities arising from different sources need to be considered, for example, those intrinsic or extrinsic to the asset. Vulnerabilities may remain unless the asset itself changes such that the vulnerability no longer applies. Vulnerabilities should be assessed both individually and in aggregate to consider the full operational context.
Vulnerability assessment is the examination of weaknesses that may be exploited by identified threats. This assessment must take into account the environment and existing safeguards. The measure of a vulnerability of a particular system or asset to a threat is a statement of the ease with which the system or asset may be harmed.
Vulnerabilities may be qualified in terms such as High, Medium, and Low, depending on the outcome of the vulnerability assessment. [§ 3.4, ISO/IEC 13335-1, Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management, 2004]

Vulnerability Assessment. This assessment includes identifying weaknesses in the physical environment, organization, procedures, personnel, management, administration, hardware, software or communications equipment, that may be exploited by a threat source to cause harm to the assets, and the business they support. The presence of a vulnerability does not cause harm in itself as there must be a threat present to exploit it. A vulnerability which has no corresponding threat does not require the implementation of a safeguard, but should be recognized and monitored for changes. It should be noted that an incorrectly implemented or malfunctioning safeguards, or safeguards being used incorrectly, could in themselves be a vulnerability.
Vulnerabilities can be related to properties or attributes of the asset that can be used in a way, or for a purpose, other than that intended when the asset was purchased or made. For example, one of the properties of an EEPROM (Electronically Erasable Programmable Read Only Memory) is that the information stored on it can be erased and replaced. This is one of the design criteria of an EEPROM. However, this property also means that the unauthorized destruction of information stored on the EEPROM is possible. This can be a vulnerability.
This assessment identifies vulnerabilities that may be exploited by threats and assesses their likely level of weakness, i.e. ease of exploitation. For example, some assets are easily disposed of, easily concealed or transported - all of these properties can relate to vulnerabilities. Input for the vulnerability assessment should be obtained from the asset owners or users, from facility specialists, and IT systems experts on hardware and software. Examples of vulnerabilities are:
· unprotected connections (for example to the Internet),
· untrained users,
· wrong selection and use of passwords,
· no proper access control (logical and/or physical),
· no back-up copies of information or software, and
· location in an area susceptible to flooding.
It is important to assess how severe the vulnerabilities are, in other words how easily they may be exploited. A vulnerability should be assessed in relation to each threat that might exploit it in a particular situation. For instance, a system may have a vulnerability to the threats of masquerading of user identity and misuse of resources. The vulnerability to masquerading of user identity may be high because of lack of user authentication. On the other hand, the vulnerability to misuse resources may be low because even with lack of user authentication the means by which resources might be misused are limited.
The result of this step should be a list of vulnerabilities and assessments of the ease of exploitation, e.g. on a scale high, medium, and low. [¶ 9.3.5, ISO/IEC 13335-3 Information technology — Guidelines for the management of IT Security — Part 3: Techniques for the management of IT Security, 1998]

¶ 10.3.4 Masquerading of user identity. An organization should implement safeguards to prevent masquerading of user identity, which can be used to circumvent authentication and all services and security functions related to that. In conclusion it can lead to integrity problems whenever this masquerade allows access and modification to information. Safeguards in this area are listed below.
• I&A (Identification & Authentication): Masquerade becomes more difficult if I&A (Identification & Authentication) safeguards based on combinations of something known, something possessed, as well as intrinsic characteristics of users are applied.
• Logical access control and audit: Logical access control cannot distinguish between an authorized user and somebody masquerading as this authorized user, but the use of access control mechanisms in place can reduce the area of impact. Review and analysis of audit logs can detect unauthorized activities.
• Protection against malicious code: A way to acquire passwords is to introduce malicious code to capture passwords, protection against such software should be in place.
• Network management: Implement network management to prevent unauthorized access by masquerading as a user in traffic, e.g. e-mail.
• Data integrity protection: Additional protection can be provided using cryptographic means like digital signatures.
¶ 10.3.5 Misrouting/rerouting of messages. An organization should implement safeguards to prevent misrouting, which is the deliberate or accidental wrong directing of messages, whereas rerouting can take place for both, good and bad purposes. Rerouting can for example be done to maintain integrity of availability. Misrouting and rerouting of messages can lead to a loss of integrity, for example if messages are altered and then sent to the original addressee. Safeguards against that are listed below.
• Network management: Safeguards to protect against misrouting and rerouting should be implemented for network security.
• Data integrity protection: Hash functions and digital signatures may be used to avoid unauthorized alteration in case of misrouting or rerouting. [¶ 10.3.4, ¶ 10.3.5, ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000]

General Guidance

It is recommended that, as part of a risk assessment, all threats to critical business processes be identified. This can be done by reviewing the BIA. [Stage 1.3 Process, Business Continuity Institute (BCI) Good Practice Guidelines, 2005]

Risk analyses should determine the vulnerabilities to confidentiality, integrity, and availability of systems, networks, and information as well as for systems under development. The information security function should monitor all new and emerging vulnerabilities that could affect the organization. [SM2.2.4(d), SM3.4.4(d), SM3.4.4(e), CB5.3.3(c), CB5.3.3(d), CI5.4.4(c), CI5.4.4(d), NW4.4.4(c), NW4.4.4(d), SD3.5.4(c), SD3.5.4(d), The Standard of Good Practice for Information Security]

UK and Canadian Guidance

The organization should understand the vulnerabilities of each critical activity. Vulnerabilities are weaknesses that could be exploited by a threat. [§ 6.5.1, § 6.5.5, BS 25999-1, Business continuity management. Code of practice, 2006]

The risk assessment outcome should provide the organization with enough information on its vulnerabilities to be able evaluate them in a rational manner and deal with them by eliminating the risk. [§ 6.2 ¶ 2, PAS 77 IT Service Continuity Management. Code of Practice, 2006]

Asia and Pacific Rim Guidance

Relevant sources should be continuously monitored for security alerts about new vulnerabilities that could affect the organization's systems. [§ 3.5.14, § 3.7.29, Australian Government ICT Security Manual (ACSI 33)]

Metrics

The metrics associated with this control are as follows:

Report on the percentage of systems with critical information assets or functions that have been assessed for vulnerabilities in accordance with policy. [UCF Control ID 02128]