Effectiveness of the PCI DSS 2.0 on Preventing Security Breaches:
A Holistic perspective
MBA, MIS, CEH, PhD
Asst. Professor, College of Information Technology
University of Dubai
January 25th, 2011
Abstract
With more and more transactions based on credit cards, merchants dealing with these are not only forced to comply with these standards or face huge penalties but also finding it costly and increasingly difficult to implement and interpret the Payment Card Industry Data Security Standard (PCI DSS). One of the top reasons cited for merchants to fail PCI audit, and a leading factor in data theft, is the failure to adequately protect stored cardholder data. Hence while implementation of the PCI DSS is not a guarantee for 100 percent protection, effective implementation of the PCI standards goes a long way in ensuring adequate protection against security breaches. While PCI DSS focus only on cardholder data this is not enough to ensure complete protection of information systems assets of an organisation as a comprehensive overview of information security based on security and audit compliance frameworks are required to offer a comprehensive security layer to the organisation data. Hence there is growing need to incorporate and integrate relevant security and internal control standards and frameworks along with PCI DSS to ensure holistic security to cardholder data. This paper looks at the issues faced in PCI DSS implementation, explore and evaluate the applicability of the related IS security and audit frameworks that can be integrated for ensuring an effective and efficient comprehensive organizational IS security and thus finally propose an integrated comprehensive security framework for data protection.
IS security from a holistic perspective considers “the process of administering people, policies, and programs with the objective of assuring continuity of operations while maintaining strategic alignment with the organisational mission” (Cazemer et al. 2000, cited in Choobineh, Dhillon, Grimaila and Rees, 2007, p.959). This strategic alignment requires the PCI DSS not only to diverge from its focused domain and expand to its outer concentric rings of the greater IS domain, but also forces it to link to the organizational strategic goals which is a major concern for IS managers. The strategic alignment of IS with business is the main focus of IT governance. In a survey done by PWC and IT Governance Institute in 2005 and 2008 the importance of strategic alignment of organisational goals with the IT goals was cited by 90% of the surveyed as vital to organisation. Hence strategic alignment can result if the PCI DSS goal of securing cardholder data is aligned with the IS goals and finally to the higher level organisational goals. Hence an isolated siloed approach of PCI DSS standards implementation may not be effective in creating a secure IS environment for holding cardholder information.
Merchants dealing with credit cards are faced with two extremes. On one side is the risk of credit card transaction breaches and fraud along with penalties for not complying with the PCI standards; and on the other hand merchants face huge cost in complying with the PCI standards. For example in 2008 level-1 merchants (those dealing with more than 6 million transactions per year spend an average of US $ 3.38 million to become PCI compliant including the cost of PCI assessment services (Amanto-McCoy, 2009). Since 2006, merchants have collectively spent in excess of $1 billion on compliance with the PCI DSS as part of their security programs (First data 2009). Based on VeriSign Global Security Consulting Services’ PCI assessments of merchant companies it was found out that 79 percent of the implementations were cited for failure to protect stored data and thus fail their assessments (First Data, 2009).
It has been stated that in order for information security measures to become effective, security should not only be built like a staircase of combined measures (Hagen, Albrechtsen and Howden, 2008) but should be mutually dependent on each other (Sundt, 2006;Berghel, 2005 cited in Hagen, Albrechtsen and Howden, 2008). Considering the fact that the current biggest challenge for IT executives is aligning activities with the business; (Gartner cited in Silva and Abreu, 2009) it is worthwhile to look at security from a wider perspective looking at external issues that can impact on IS security. Information security should not be regarded as a technical issue, but a business and governance challenge that involves adequate risk management, reporting, and accountability. Therefore, information security must be addressed at the highest levels of the organization and not regarded as a technical specialty relegated to the information technology (IT) department (Musa, 2010). Although compliance standards such as Sarbanes Oxley, Basel II and PCI DSS have been around for the last 15 years, now that organisations run the risk of the Information Commissioners' Office (ICO) fining them £500,000 for a data breach, there has never been a more pressing time to implement a holistic approach to compliance (Coburn, 2010).
PCI DSS
The PCI DSS is the very first industry-wide standard focusing on the credit card industry that aims at achieving a strong protection of sensitive consumer and cardholder data, and prevents major security issues (Liu, Xiao, Chen, Ozdemir, Dodle, and Singh, 2010). The Payment Card Industry Data Security Standards is an open global forum launched in 2006 by the five global payment brands namely American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. It was created for developing, managing, educating, and communicating the PCI Security Standards, including the Data Security Standard (PCI DSS), Payment Application Data Security Standard (PA-DSS), and PIN Transaction Security (PTS) Requirements to merchants, vendors and financial institutions involved in credit card transactions. The objective was to enhance the security of the cardholder through protection of cardholder data and thus help facilitate global adoption of consistent data security measures created to mitigate data breaches and prevent payment cardholder data fraud. Compliance is enforced on those dealing with credit cards and there are penalties for non conformance of the PCI DSS standard by PCI Security Standards Council. PCI DSS 2.0 version (released on October 2010) comprises of 6 principles, 12 major requirements, 45 sub requirements, 75 detailed requirements with corresponding testing procedures for the requirements and sub requirements. An example of the Requirement 5: Use and regularly update anti-virus software or programs is given below:
|
Principle 3. Maintain a Vulnerability Management Program Requirement 5: Use and regularly update anti-virus software or programs Sub requirement 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). [Testing procedure: 5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists] 5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. [Testing procedure:5.1.1 For a sample of system components, verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits). |
Box 1 A PCI DSS requirement randomly selected from PCI DSS 2.0
2 DATA BREACHES
One of the most serious data breach in recent history occurred in 2006 at TJX Company Inc which was classified as the largest off-price apparel and home fashions retailer in both the United States and the world. Prior to the breach it ranked 133rd on the Fortune 500 list with an annual revenues of $17 billion, 125,000 employees with over 2400 stores worldwide. But in one of the largest security breach ever reported, in late 2006, hackers broke into the systems of TJX and stole vital customer information and it is estimated that the full financial impact of this incident might amount up to one billion dollars (Xu, Grant, Nguyen and Dai, 2008). The hackers gained entry by exploiting the poor network security on a wireless network at a store. This allowed them to sit outside the store and intercept customers' credit card numbers as they made transactions. Then they used their open access point to track back to the company's central database. Since the company was storing customers' personal data and complete credit card numbers in an unencrypted format it allowed the thieves to simply download them. It was estimated that at least 94 million Visa and MasterCard accounts may have been exposed to the potential fraud (Jewell, 2007). Another sensational case of breach of a company that is PCI complaint occurred in Hannaford in the year 2008. It is a supermarket chain that is PCI complaint and reported thefts of 4.2 million customer credit and debit card numbers with 1,800 cases of fraud. The data breach began on Dec. 7, unusual credit card activity came to light on Feb. 27 and the breach wasn't contained until March 10 and reported only on March 17th. The company stated that unauthorized software that was secretly installed on servers in nearly all of Hannaford Bros. Co.'s supermarkets enabled the massive data breach that compromised up to 4.2 million credit and debit cards (Harkavy, 2008). It has been argued by experts that this is the work of an insider.
According to Verizon 2010 study ((Baker, Goudie, Hutton, Hylender, Niemantsverdriet, Novak, et al. 2010) PCI complaint organizations were 50% less likely to be attacked than the non complaint ones. While compliance to PCI DSS is a mandatory requirement and an appropriate way to protect cardholder data, even full compliance with the PCI DSS may not ensure protection as there are other factors beyond the control of PCI DSS that can affect a breach like insider threat, failing to follow non PCI DSS process and outsourcing. In a breach involving the US Department of defence in 2007, the US Department of Veteran's Affairs caught a former employee who has stolen 1.8 million Social Security Numbers from the office. He quit when he discovered that they were about to do a background check on him (ITRC, 2008). A simple overlook from the side of employees can also result in breach. In 2009, 76 million records of US military veterans, including millions of Social Security numbers dating to 1972 were stolen when a defective hard drive was sent back to its vendor for repair and recycling without first destroying the data (ITRC, 2010). According to Washington Post at least 8.3 million personal and financial records of consumers were compromised by data spills or breaches at businesses, universities and government agencies in the first quarter of 2008. According to the ITRC in 2008, 641 breaches were reported resulting in 35,597,210 records being exposed where one such breach was in the University of Miami where 2.1 million records were exposed when the confidential information of tens of thousands of University of Miami patients was stolen when thieves took a case out of a vehicle used by a private off-site storage company. The data included names, addresses, Social Security numbers or health information (ITRC, 2009).
If the latest statistics is taken, then as of June 30th 2010 the ITRC recorded 341 individual breaches for the first 6 months of 2010 and this does not include the breaches not reported, veiled from public and unknown. The 2010 Verizon data breach investigation report conducted by the Verizon Risk team and the US Secret service revealed the source of these breaches as is given in figure 1 (Baker, W., M. Dahn, et al. (2010). In most of these cases non technical and human factors were seen as reasons for these breaches which PCI DSS standards might not have been able to prevent.
Figure 1 Sources of data breaches in 2009 and 2010 (Compiled from Verizon 2010 data breach investigation report)
While compliance to PCI DSS is not a guarantee for full protection against data breaches, it considerably reduces the risk and the liability to the company. From figure 1 it is evident that having a strong defense in depth is no guarantee as the insider source of threat has grown substantially (26%) but has reduced the threat from hackers to a great extend. This fact is emphasised in figure 2 where the insider threat (privilege misuse risen by 26%) is repeated and is growing at an alarming rate.
Figure 2 Types of data breaches (Compiled from Verizon 2010 data breach investigation report)
The major focus of the PCI DSS is to protect cardholder data. This has been emphasised in all the 12 high level requirements under six categories and the corresponding testing procedure to fulfill these requirements. The failure to adequately protect stored data by companies is the leading factor in data theft and is also a main reason for merchants to fail a PCI audit. VeriSign Global Security Consulting Services, a division of security services vendor VeriSign, has conducted hundreds of PCI assessments in recent years. Of the merchant companies assessed by VeriSign Global Security Consulting Services, (a division of security services vendor VeriSign) it was found that 79 percent of those assessed were cited for the failure in their PCI audit due to their failure to protect stored data (First Data, 2009).
The high incidence of security breaches in organizations could be attributed to their inability to adequately focus on non-technical issues (Dhillon and Backhouse 2001; Straub and Welke 1998; and Siponen, 2005 cited in Ifendo, 2009). Such non-technical concerns and issues may include the basic IT policies, procedures, practices, and strategies that organizations put in place to minimize IT threats and control any loss that may arise from breaches (Siponen, 2005; McPhee, 2008; Schatz, 2008 cited in Ifendo, 2009). Research on standard setting has found that proper governance is a key to success. Success is more likely if the governance structure includes all of the various interests in the network. Moreover the standards themselves need to be effective yet flexible enough to satisfy competitive interests (Sullivan, 2010).
It should not be denied that the provisions of the PCI standard when implemented for online transaction would undoubtedly provide security protection for some aspects of the retailer’s interests that fall outside the narrow definition of credit card transaction management (protection of cardholder data), but the retailer may need to take a broader view of security requirements by adopting the hybrid approach of PCI baseline implementation supplemented by risk assessment to address those matters outside PCI scope (Rowlingson and Winsborrow, 2006).
3 IT CONTROL COMPLAINCE FRAMEWORKS
Organisations worldwide have been busy coping with compliance, regulations and standards, but due to time deadlines, lack of expertise in this area, multitude of regulations, lack of experienced staff, and cost factor they generally adopt a highly fragmented and siloed approach to governance, compliance and security. Taking into account the financial sector, the compliance costs as a percentage of net income grew from 2.83% of net income to 3.69% of net income and is stated to rise further (Cox and Sampath, 2007) while the total cost of Governance Risk and Compliance is expected to grow to $29.8 billion in 2010 billion in US (AMR Research, cited in Tucci, 2009). In fact a study on 500 US and multinational organisations found out that on an average it was necessary to dedicate 35% of the security budget to any compliance effort (Everett, 2009). The UK Corporate IT Forum (CIF) in a 2009 survey estimated that only 1% of the surveyed companies are fully PCI compliant while 9% has failed their audit while the rest were trying to achieve conformance.
An internal control provides reasonable assurance regarding the achievement of objectives in the area of effectiveness and efficiency of operations, reliability of financial reporting and compliance with regulations (Pathak, 2003). In selecting controls businesses have wide choices namely BS 7799, Criteria of Control Board (CoCo), Committee of Sponsoring Organizations (COSO), Federal Information System Controls Audit Manual (FISCAM), Control Objectives for Information and related Technology (COBIT), generally accepted accounting principles (GAPP), Generally Accepted System Security Principles (GASSP), Information Technology Control Guidelines (ITCG), systems auditability and control (SAC), Capability Maturity Model (SSE-CMM), and SysTrust; and out of these BS 7799, CoCo, COSO, COBIT, FISCAM, ITCG, SAC and SysTrust are process oriented (Campbell, 2003) with process/requirements for each IS entity (process or object of IS for compliance) similar to PCI DSS. A few of the commonly used ones are ISO 27000 series for information security, Sarbanes Oxley Act for technology governance, COBIT and Information Technology Infrastructure Library ( ITIL) for IT governance and services, and the CMMI for assessing the maturity level of the information systems. As far as implementing the PCI DSS standard is concerned, the requirements set by PCI DSS are in line with the IT security best practices required by widely recognised standards such as ISO 27002, ‘Code of Best Practices for Information Security Management’ or COBIT, ‘Control Objectives for Information and related Technologies’ (Laredo, 2008). Moreover IT control implementers have been encouraged to use ITIL to define strategies, plans and processes, use COBIT for metrics, benchmarks and audits and use ISO/IEC 27002 to address security issues to mitigate the risks (Sahibudin, Sharifi & Ayat, 2008).
In a survey of security professionals the Enterprise Strategy Group (ESG) discovered that 72 percent of North American organizations with 1,000 or more employees, have implemented one or more formal IT best-practice control and process models and the most widely used commercial IT control frameworks are ITIL, ISO 27002 and COBIT to provide optimal security management (Turner et al., 2009). Moreover in a comparison of ISO 27000 with the PCI DSS, 70 out of 80 technical features were similar to both (Gikas, 2010). Hence it was decided to review the following frameworks namely COBIT, ITIL, ISO 27002 and PCI DSS for the purpose of the study.
COBIT
COBIT provides IT controls and IT metrics (Wallhoff, 2004) and is used as a high level governance and control framework (Gaynor, 2002; Hardy, 2006b) with growing acceptance worldwide (Guildentops & Haes, 2002). It is exhaustive (Edelstein, 2004) and encompasses the complete lifecycle of IT investment (Debreceny, 2006). COBIT is a breakthrough (Lainhart, 2001) multi-purpose business tool that is used worldwide (Gerke & Ridley, 2006; Yan & Makal, 1998) is the most effective and helpful tool for IT audit (Singleton, 2006). It is a trusted and internationally recognised standard that is being used increasingly by a diverse range of organisations throughout the world (Guildentops & Haes, 2002; Hussain & Siddiqui, 2005; Lainhart, 2000; Oliver, 2003; Ridley, Young, & Carroll, 2004; Singleton, 2006).
While PCI DSS comes with 6 major ‘principles’, 12 major requirements that follows the principles, 45 sub requirements, 75 detailed requirements, and testing procedures for the corresponding sub requirements and detailed sub requirements, COBIT comes up with 34 high level processes (corresponding to the 6 major principles of PCI DSS), and 318 detailed processes (corresponding to the 12 major requirements of PCI DSS). But on a detailed analysis of the 318 detailed processes it can be seen that these can be segmented further to correspond to the 45 sub requirements/75 detailed requirements of the PCI DSS. COBIT further elaborates the detailed processes with ‘activities’ that can be equated with the ‘testing procedures’ of the PCI DSS. Here the missing links in PCI DSS from a COBIT perspective are the ‘information criteria’, the ‘RACI chart’, ‘IT goals’, and ‘measures’ (see table 4). For example the control DS5.9 Malicious Software Prevention, Detection and Correction is given as (see box 2):
|
III. DS Delivery and Support DS 5 Ensure Systems Security DS5.9 Malicious Software Prevention, Detection and Correction [Put preventive, detective and corrective measures in place (especially up-to-date security patches and virus control) across the organisation to protect information systems and technology from malware (e.g., viruses, worms, spyware, spam).] |
Box 2 A sample control taken from COBIT
ITIL
ITIL is a set of best practices developed by CCTA (Central Communication and Telecom Agency, now subsumed under the Office of Government Commerce, UK (OGC) in 1980s through research into successful organizations and interviews with experts. ITIL which has grown to become the most widely accepted approach to IT Service Management in the world provides international best practice guidance in IT Service Management (OGC, 2007). It offers more than just guidance and is aligned with ISO/IEC 20000 (Service Management Standard, previously BS15000). ITIL show the goals, general activities, inputs and outputs of the various processes, which can be incorporated within IT organisations. The Information Technology Infrastructure Library (ITIL) is a set of books that contain proper procedures to handle situations that any IT organization would come into contact with in IT service. Organisations that implement ITIL can use a series of templates (check lists, tasks) and procedures, to implement it to their enterprise. ITIL is broken up into a series of processes. Each of the processes defined in ITIL is designed to drive a specific IT business function or discipline (Latif, Din and Ismael, 2010). The ITIL service management practices are comprised of three main sets of products and services namely ITIL service management practices – core guidance, ITIL service management practices (complementary guidance) and ITIL web support services. The core set consists of six publications:
· Introduction to ITIL Service Management Practices
· Service Strategy (SS)
· Service Design (SD)
· Service Transition (ST)
· Service Operation (SO)
· Continual Service Improvement (CSI)
Each of these core set comes with support processes (see table 1)
ISO 27002
The ISO 27002 standard establish guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organization. The actual controls listed in the standard are intended to address the specific requirements identified via a formal risk assessment. The standard is also intended to provide a guide for the development of "organizational security standards and effective security management practices and to help build confidence in inter-organizational activities" (ISO, 2008). It focuses on operational security, application security, computing platform security, network security and physical security. From a ISO 27002 perspective the term ‘information’ includes all forms of data, documents, communications, conversations, messages, recordings, photographs, digital data, email, and fax communications (Praxiom Research, 2010). Since cardholder information can be transmitted in any of these forms, implementation of ISO 27002 along with PCI DSS enhances the security of cardholder data. Quite similar to COBIT and PCI DSS, ISO 27002 has identified 11 control areas, 39 control objectives, and 133 controls. For example the ISO 27002 is demonstrated by taking a control that closely correlate with COBIT, and PCI DSS (see Box 3):
|
10. Communication and operations management 10.4 Protect against malicious and mobile code 10.4.1 Establish controls to handle malicious code |
Box 3 An ISO 2007 standard that closely relate to PCI DSS
3 COMPARING COBIT, ITIL, ISO 27002 AND PCI DSS
COBIT has been considered as high level IT governance framework combining in itself IT security, IT audit and IT assurance. Being very comprehensive covering the entire life cycle of information systems the processes of ITIL, ISO 27002 and PCI DSS are stated as broad controls in COBIT. According to Conradie & Hoekstra (2002) of PWC, ITIL is strong in IT processes, but limited in security and system development while COBIT is strong in IT controls and IT metrics but does not say how and does not have a security focus, and ISO 17799 is strong in security controls (Since ISO 17799 which is a code of practice of practice for information security has been renamed as ISO 27002 the statement can be true of ISO 27002 also) but does not say how the process flows. COBIT, ITIL and ISO 27002 can be aligned for business benefit and this has been demonstrated by the IT Governance Institute (ITGI) and the Office of Government Commerce (OGC) in 2008 when they mapped each of the processes of the three frameworks in a single document as guidance for practitioners to combine the two frameworks with the ISO standard. For example table 3 illustrates the mapping of the three (ITGI, 2008).
Table 1 COBIT mapped with ITIL and ISO 27002
|
COBIT 4.1 Domain: Plan and Organise (PO) |
|||
|
PO4 Define the IT Processes, Organisation and Relationships |
|||
|
CobiT 4.1 Control Objective |
Key Areas |
ITIL V3 Supporting Information |
ISO/IEC 27002:2005 Supporting Information |
|
PO4.6 Establishment of roles and responsibilities |
• Explicit roles and responsibilities • Clear accountabilities and end-user authorities |
• SS 2.6 Functions and processes across the life cycle • SD 6.2 Activity analysis • SD 6.4 Roles and responsibilities • ST 6.3 Organisation models to support service transition • SO 6.6 Service operation roles and responsibilities • CSI 6 Organising for continual service improvement |
• 6.1.2 Information security co-ordination • 6.1.3 Allocation of information security responsibilities • 6.1.5 Confidentiality agreements • 8.1.1 Roles and responsibilities • 8.1.2 Screening • 8.1.3 Terms and conditions of employment • 8.2.2 Information security awareness, education and training • 15.1.4 Data protection and privacy of personal information |
|
PO4.7 Responsibility for IT quality assurance (QA)
|
• Responsibility, expertise and placement of QA according to organisational requirements |
• CSI 6 Organising for continual service improvement |
N/A |
|
PO4.8 Responsibility for risk, security and compliance |
• Ownership of IT risks in the business • Roles for managing critical risks • Enterprise wide risk and security management • System-specific security • Direction on risk appetite and acceptance of residual risks |
• SD 6.4 Roles and responsibilities |
• 6.1.1 Management commitment to information security • 6.1.2 Information security co-ordination • 6.1.3 Allocation of information security responsibilities • 8.1.1 Roles and responsibilities • 8.2.1 Management responsibilities • 8.2.3 Disciplinary process • 15.1.1 Identification of applicable legislation • 15.1.2 Intellectual property rights (IPR) • 15.1.3 Protection of organisational records • 15.1.4 Data protection and privacy of personal information • 15.1.6 Regulation of cryptographic controls • 15.2.1 Compliance with security policies and standards |
When ITIL is benchmarked with COBIT, it has been found that they correspond with each other to a high degree, especially, when the processes of COBIT are ITIL based as in its latest version (Sahibuddin et al., 2008). Since COBIT encompasses the controls, and processes of ITIL, ISO 27992 and PCI DSS, integration of these into COBIT provides a 360 degree view of security. Moreover a comparison is made between COBIT and PCI DSS that provide rationale for integrating PCI DSS into COBIT for comprehensive IS security.
Table 2 Comparative evaluation of COBIT 4.1 and PCI DSS 2.0
|
Evaluative Criteria |
COBIT 4.1 |
PCI DSS 2.0 |
|
Major goal/objective |
Align business goals with IT goals |
To encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally |
|
Technical focus |
Less technically reliant on compliance |
Very much reliant on technology for compliance |
|
Process orientation |
Subdivides IT into four domains and 34 processes in line with the responsibility areas of plan, build, run and monitor, providing an end-to-end view of IT |
Provides a baseline of technical and operational requirements designed to protect cardholder data based on 6 principles, 12 requirements, numerous sub requirements that are further sub divided and corresponding testing procedures. |
|
Implementation guidance |
Generic and need to be customized |
Specific, focused, in depth and detailed |
|
Focus on |
Organisational wide information security and control assurance |
Protection of Cardholder data only |
|
Domain of application |
Includes all IS domain |
Includes only those networks, locations and flows of cardholder data |
|
Target audience |
Organisations who need to comply with global and country wise regulations/ requirements like SOX and who need to implement best practices in ITG |
All merchants who accept credit and debit cards; credit card processors, issuers and acquirers, third party processors and gateways; developers and software providers |
|
Implementation |
Voluntary in most countries and organisations |
Mandatory |
|
Personnel allocation |
RACI |
No evidence |
|
Information criteria |
Effectiveness, efficiency, confidentiality, integrity, availability, compliance, reliability and integrated into the control processes . |
Not evident and not integrated into the requirements but can be based on the extended CIA triangle – confidentiality, integrity, availability, possession, utility, accuracy, authenticity. |
|
Identified IT resources/ scope/ Target domain |
Applications, information, infrastructure, people |
System components (linked to cardholder data environment), people, process, technology |
|
Role/ responsibility charting |
RACI chart for all activities |
Not defined |
|
Measurement done by: |
Benchmarking; goals and metrics; compliance – ‘complaint’ and ‘not complaint’ |
Compliance – ‘in place’ and ‘not in place’ |
|
Measures |
Various measures used like ‘degree of .., ‘percent of..’, level of.’, delay between..’. ‘no. of …’, ‘frequency..’, ‘elapsed time..’, ‘unit cost per service…’, ‘average of…’ ‘standard deviation..’. |
Not defined |
|
Goals and metrics |
Defined |
Not defined |
|
Maturity model |
Defined |
Not defined |
4 INTEGRATED AUDIT SECURITY MANAGEMENT MODEL
From the above table it is evident that while process wise COBIT and PCI DSS are similar, PCI DSS is lacking in information criteria, RACI chart, maturity model, metrics and measurement tools. Thus the advantage of incorporating COBIT comes from its detailed guidance on various aspects of control, audit, measurement and assessment of maturity. For each control of COBIT there are the RACI (Responsible, accountable, consulted and informed) chart which specifies who is responsible for each control, the person who is accountable, to be consulted and informed which is linked to each control activity derived from the COBIT control. The RACI chart can either be applied at the higher level of COBIT control or at the level of PCI DSS principles or requirement. This is again linked to the goals and metrics along with aligned to the maturity model. COBIT also specified and defined the COBIT maturity model for each high level control. Regarding the balance score card, even though it is not defined in the COBIT controls, guidance have been given by COBIT on how to attach the BSC. The integrated audit security management model is given in figure 3.
Considering all of these functionalities in COBIT there are two options for integrating PCI DSS with COBIT. The PCI DSS requirements can be linked to a related control of COBIT (like DS 5) to generate a list of sub controls corresponding to the requirements/sub requirements. In this way those relevant controls of COBIT that are representative of PCI DSS can be decomposed further down using the requirements, sub requirements and testing procedures of PCI DSS and then measured using an optimal mix of measurement, performance indicators and assessments. Secondly a separate set of PCI DSS controls can be attached to COBIT and thus follow the COBIT method of audit and measurement. This can provide the PCI DSS not only with added functionality but also the presence of other frameworks and standards like ITIL and ISO 27002 can provide a comprehensive IS security layer to the company’s information system. The first step in this direction is to go through and evaluate each of the 34 high level controls of COBIT to decide on the PCI DSS requirements that can be incorporated in it followed by mapping PCI DSS to COBIT (as was done in table 1 where COBIT was mapped with ITIL). But since this requires involving IT security and audit experts (through empirical research and can be done to test the model given in figure 3) and is a separate project this will not be discussed in this paper.
Figure 3 Integrated Audit Security Management Model
CONCLUSION
As is evident from section 2 the insider threat is growing at an alarming rate which PCI DSS may not be able to prevent. By integrating PCI DSS into COBIT, ITIL and ISO 27002 a multilayer security is ensured that takes into account insider as well as outside threat. Becoming PCI complaint doesn’t mean that the company is insulated from all sorts of cyber fraud but effective implementation by integrating with relevant security and governance frameworks/standards can mitigate the risk to a greater extent. While the latest version of PCI DSS 2.0 promises better protection, than the former version, still there is room for improvement. But generalization of this model requires validation through empirical research in different sectors of the industry and in different geographical locations. It is hoped that further research in this domain would substantiate the model.
REFERENCES
1. Amato-McCoy, D. M. (2009). The Next Phase of PCI Security. Chain Store Age. July: 48-49.
2. Baker, W., M. Dahn, et al. (2010). VERIZON 2010 PAYMENT CARD INDUSTRY COMPLIANCE REPORT.
3. Baker, W., M. Dahn, et al. (2010). VERIZON 2010 PAYMENT CARD INDUSTRY COMPLIANCE REPORT.
4. Campbell, P. L. (2003). An Introduction to Information Control Models. Albuquerque, Networked Systems Survivability & Assurance Department, Sandia National Laboratories: 1-88.
5. Choobineh, J., G. Dhillon, et al. (2007). "Management of Information Security: Challenges and Research Directions1." Communications of the Association for Information Systems 20(57).
6. Coburn, A. (2010). "Fitting PCI DSS Within a Wider Governance Framework." Computer Fraud & Security(September): 11-13.
7. Conradie:, N., & Hoekstra, A. (2002). CobiT, ITIL and ISO17799: How to use them in conjunction. Retrieved 5 January, from www.cccure.org/Documents/COBIT/COBIT_ITIL_and_BS7799.pdf
8. Cox, D. and R. Sampath (2007). Navigating the Compliance Labyrinth. New York, Deloitte Center for Banking Solutions.
9. Debreceny, R. S. (2006). Re-engineering IT Internal Controls: Applying Capability Maturity Models to the Evaluation of IT Controls. 39th Hawaii International Conference on Systems Sciences, Hawaii, IEEE Computer Society.
10. Edelstein, S. M. (2004). "Sarbanes-Oxley Compliance for Nonaccelerated Filers: Solving the Internal Control Puzzle." The CPA Journal 74(12): 52-58.
11. Everett, C. (2009). "PCI DSS: Lack of direction or lack of commitment?" Computer Fraud & Security December(12): 18-20.
12. First Data. (2009). "PCI DSS and Handling Sensitive Cardholder Data." Retrieved 10 January, from www.firstdata.com.
13. Gaynor, D. (2002). "IT Governance." Accountancy Ireland 34(4): 28.
14. Gerke, L. and G. Ridley (2006). Towards an abbreviated COBIT framework for use in an Australian State Public Sector. 17th Australasian Conference on Information Systems, Adelade.
15. Gikas, C. (2010). "A General Comparison of FISMA, HIPAA, ISO 27000 and PCI-DSS Standards." Information Security Journal: A Global Perspective 19: 132-141.
16. Guildentops, E. and S. D. Haes (2002). "COBIT 3rd Edition Usage Survey: Growing Acceptance of COBIT." Information Systems Control Journal 6: 25-27.
17. Hagen, J. M., Albrechtsen, E., & Hovden, J. (2008). Implementation and Effectiveness of Organizational Information Security Measures. Information Management & Computer Security, 16(4), 377 - 397.
18. Hardy, G. (2006b). "Guidance on Aligning COBIT, ITIL and ISO 17799." Information Systems Control Journal 1.
19. Harkavy, J. (2008). "Secret software blamed for Hannaford breach " Retrieved 10 January, 2011, from http://www.msnbc.msn.com/id/23846014/ns/technology_and_science-security/.
20. Hussain, S. J. and M. S. Siddiqui (2005). Quantified Model of COBIT for Corporate IT Governance. First International Conference on Information and Communication Technologies, ICICT 2005. , Malaysia, IEEE.
21. Ifinedo, P. (2009). "Information technology security management concerns in global financial services institutions Is national culture a differentiator?" Information Management & Computer Security 17(5): 372-387.
22. ITGI. (2008). Aligning CobiT® 4.1, ITIL® V3 and ISO/IEC 27002 for Business Benefit. Illinois: IT Governance Institute.
23. ISO. (2008). Introduction To ISO 27002 (ISO27002). from http://www.27000.org/iso-27002.htm
24. ITRC Breach Report (2008). 2009 Data Breach Statistics. San Diego, Identity Theft Resource Centre.
25. ITRC Breach Report (2009). 2009 Data Breach Statistics. San Diego, Identity Theft Resource Centre
26. ITRC Breach Report (2010). 2010 Data Breach Statistics. San Diego, Identity Theft Resource Centre
27. Jewell, M. (2007). "TJX breach could top 94 million accounts " Retrieved 10 January 2011, from http://www.msnbc.msn.com/id/21454847/ns/technology_and_science-security/
28. Lainhart, J. W. (2000). "COBIT: A Methodology for Managing and Controlling Information and Information Technology Risks and Vulnerabilities." Journal of Information Systems 14(2000 Supplement): 21-25.
29. Latif, A. A., Din, M. M., & Ismail, R. (2010). Challenges in Adopting and Integrating ITIL and CMMi in ICT Division of a Public Utility Company. Paper presented at the 2010 Second International Conference on Computer Engineering and Applications (ICCEA) Bali Island
30. Laredo, V. G. (2009). PCI DSS compliance: a matter of strategy. Card Technology Today.
31. Liu, J., Y. Xiao, et al. (2010). "A Survey of Payment Card Industry Data Security Standard." IEEE Communications Surveys & Tutorials 12(3 THIRD QUARTER): 287-303.
32. Musa, A. (2010). "Information Security Governance in Saudi Organizations: An Empirical Study " Information Management and Computer Security 18(4): 226-276.
33. Oliver, D. J. (2003). "A Selective Approach to COBIT." Information Systems Control Journal 3.
34. Pathak, J. (2003). "Internal Audit and E-Commerce Controls." Internal Auditing 18(2): 30-34.
35. Praxiom Research Group Ltd. (2010). ISO IEC 27002 2005. Retrieved 5 January, from www.praxiom.com/iso-17799-2005
36. Ridley, G., J. Young, et al. (2004). COBIT and its Utitlization: A Framework from the Literature. 37th Hawaii International Conference on System Sciences, Hawaii, IEEE Computer Society.
37. Rowlingson, R. and R. Winsborrow (2006). "A comparison of the Payment Card Industry data security standard with ISO17799." Computer Fraud & Security(March): 16-19.
38. Sahibudin, S., M. Sharifi, et al. (2008). Combining ITIL, COBIT and ISO/IEC 27002 in Order to Design a Comprehensive IT Framework in Organizations. Second Asia International Conference on Modelling & Simulation, Malaysia, IEEE Computer Society.
39. Silva., L. A. F. d. and B. e. Abreu (2009). Exploring and Overcoming Major Challenges in IT Infrastructures Faced by IT Executives Fourth International Conference on Software Engineering Advances ICSEA '09, Porto, IEEE XPlore Digital Library.
40. Singleton, T. W. (2006). "COBIT- A Key to Success as an IT Auditor." Information Systems Control Journal 1.
41. Sullivan, R. J. (2010). The Changing Nature Of U.S. Card Payment Fraud: Issues For Industry And Public Policy. . Workshop on the Economics of Information Security Harvard University, Federal Reserve Bank of Kansas City.
42. Tucci, L. (2009, 10 January). "Governance, Risk and Compliance Spending not Focused on Technology." from http://searchcompliance.techtarget.com/news/1375707/Governance-risk-and-compliance-spending-not-focused-on-technology.
43. Turner, M. J., J. Oltsik, et al. (2009 ). "ISO, ITIL, & CobiT Together Foster Optimal Security Investment." from http://www.thecomplianceauthority.com/iso-itil-a-cobit.php
44. Wallhoff, J. (2004). "Combining ITIL with COBIT and 17799." from http://www.scillani.se/assets/pdf/Scillani%20Article%20Combining%20ITIL%20with%20Cobit%20and%2017799.pdf.
45. Xu, W., G. Grant, et al. (2008). "Security Breach: The Case of TJX Companies, Inc." Communications of the Association for Information Systems 23(1).
46. Yan, R. and M. Makal (1998). "Two Views of Internal Controls: COBIT and the ITCG." IT Audit 1(December 1).