EMERGING TRENDS IN MEASURING ITSG PERFORMANCE

In this section we provide insights about the emerging trends in measuring ITSG performance from the perspective of e-banking. Therefore, the significance of an ITSG program relies on con­stant monitoring, reporting and on the ability to articulate the results in clear and consistent met­rics.

SCAP consists of six inter-related components (Table 3) that shape the security requirements of the method namely

1. Automated vulnerability management,

2. Standardized reporting and

3. Conformity with the NIST Validation program.

SCAP components integrate information into an automated flow making security more mea­surable and comply with NIST federal security requirements (NIST, 2011). SCAP is usually being used to enable enterprise reporting within the U.S. Federal Government but for the purpose of this chapter we briefly describe the role of SCAP as an ITSG tool for generating stronger data control within an e-banking environment.

CVE (Common Vulnerabilities and Exposures)

CVE is a dictionary list of information security vulnerabilities and exposures. This standard de­fines “vulnerability” as a condition in a system that allows an attacker to

1. Execute commands as another user

2. Access restricted data

3. Pose as a different entity

4.

Every publicly known information security vul­nerability or exposure has a unique identification code which includes the following characteristics:

• CVE Identifier numerical figure (e.g., “CVE-1333-1234”).

• Status description (e.g. default password).

• Short analysis (e.g. remote command execution).

• Relevant references (e.g. OVAL-ID).

CCE (Common Configuration Enumeration)

Similar to the CVE purpose, CCE (2011) is a complementary standard with an aim to auto­mate the management of vulnerabilities and also provide conformity with policies such as federal information technology security requirements (e.g. NIST). CCE can correlate configuration data across multiple information sources. Each entry contains the following five attributes:

• CCE Identifier numerical figure (e.g.”CCE-5678-122”).

• Short status description of the configura­tion issue (e.g. operating system).

• Theoretical Parameters of the tested sys­tem (e.g. time, space, specification and settings).

• Viable technical solutions to a given con­figuration issue (e.g. download a security update).

• Relevant references (e.g. OVAL-ID).

CPE (Common Platform Enumeration)

A method of naming software (e.g. vendor, title, version). Purpose is to foster automation towards identification of the IT platforms to which a vulnerability or element of guidance applies. CPE uniform naming specification encourages community members generate names for new IT platforms in a consistent and formal manner. A CPE Name is a unique collection of components (URI scheme name) given to a specific platform type that is made up of hardware, applications, an operating system, and other possible parts e.g. cpe://microsoft:windows:2000

CVSS (Common Vulnerability Scoring System)

CVSS is a universal open and standardized method for vulnerability scoring. CVSS uses multiple fields for evaluating the overall risk of an indi­vidual vulnerability. Two common uses of CVSS are: a) prioritization of vulnerability remediation activities and b) calculation the severity of vulner­abilities discovered on a system.

1. Base Score Metrics (inherent characteristics of the vulnerability)

2. Exploitability Metrics (related exploit range, attack complexity, and level of authentication needed)

3. Impact Metrics (confidentiality, integrity, availability and impact value weighting)

4. Environmental Metrics (effect of a vulner­ability on the system environment)

5. Temporal Metrics (elements about the vul­nerability that change over time e.g. avail­ability of exploit, type of fix available and level of vulnerability verification).

XCCDF (extensible Configuration Checklist Description Format)

XCCDF is a selection of documents or check­lists for automated policy compliance. XCCDF uses an XML specification language to provide compliance with recommendations for mini­mum security controls under NIST guidelines. This method describes a process for measuring system configuration to a specified document or checklist. Audience of the XCCDF specification is primary government and secondary industry secu­rity analysts and product developers. Specifically, XCCDF goals are to a) generate documentation b) express policy-aware configuration rules c) sup­port complex systems that may require complex rules d) support compliance scoring e) support customization.

OVAL (Open Vulnerability and Assessment Language)

A method for performing structured tests for re­porting purposes. The purpose of OVAL is to create and update a database of system characteristics against OVAL definitions so as to evaluate a system for a specified machine state. OVAL supports, homogenizes and transfers the communication of security content across the whole system. OVAL actual use is similar to a common Risk Assessment process namely: identify and collect configuration data (OVAL System Characteristics); analyze a “specified machine state” such as a vulnerability (OVAL Definition schema) and document and report the final results about the state of a system (OVAL Results schema).

In summary, the purpose of SCAP in measuring ITSG performance in e-banking is to

1. Identify the context of e-banking, existing and new risk elements (vulnerabilities and exposures) in automated fashion and con­stantly update the candidate list.

2. Analyze and configurate the data from the IT platforms used based on existing controls (policies and settings) and user-system interaction.

3. Score and prioritize ITSG performance.

4. Facilitate community involvement via an enhanced role as a cognitive resource and

5. Insure compliance with NIST 800-53 con­trols. This integration of efforts can help standardize a highly complex environment and provide real-time risk management.

Other metrics, such as the number of persons trained in security awareness, reduction in fraud losses, in audit findings, or in security incidents (e.g., computer viruses, reported unauthorized data), may also portray the effectiveness of an ITSG program (Solms and von Solms, 2009). Important factor is the experience and security behavior of different stakeholders and the use of the method to acquire the results (qualitative, semi, quantitative, combination).

In addition, attempts to measure ITSG per­formance using statistics tools, such as the Stan­dard deviation, are not new however there are arguments against their effectiveness (Frankland, 2008). In addition, experts opinion may well be a more sufficient indicator of the effectiveness of an ITSG program however, opinion may be tampered with corrupted practitioners who rely on the FUD (Fear, Uncertainly and Doubt) principle. In this respect, best practices and international standards have already progressed in clearly de­fining a series of core metrics that characterize an ITSG program. For example ISO 27004 (ISO/ IEC 27004:2009), part of ISO/IEC 27000 series, provides guidance on the development and use of measures and measurement for the assessment of an implemented information security manage­ment system, in alignment with ISO 27001 and ISO 27002.

At this moment, there is no formal approach used across financial institutions about the effec­tiveness of an ITSG program in e-banking. Any reasonable approach should be satisfactory as long as the methods used are consistent (Brotby, 2009). To be successful, the widespread e-banking sector would have to agree on the metrics to be used and the collection of statistics. In this respect, the effectiveness of an ITSG program should be measured by whether or not defined objectives are achieved. As with any other process, increased productivity and compliance, greater resource utilization, customer satisfaction and successful risk mitigation can be indicators of an effective ITSG program. Another indicator might be trends in strategic, proactive security activities as op­posed to purely tactical, reactive ones. For this reason effective policies and procedures must be the foundation for reliable security metrics and measurements.