GAIT For Business and IT Risk to Scope PCI Compliance Business and IT Risk.pdf · GAIT FOR BUSINESS...

CASE STUDIES OF USING GAIT FOR BUSINESS AND IT RISK TO SCOPE PCI COMPLIANCE

AADDVVAANNCCEEDD TTEECCHHNNOOLLOOGGYY CCOOMMMMIITTTTEEEE

CCaassee SSttuuddiieess ooff UUssiinngg GGAAIITT‐‐RR TToo SSccooppee PPCCII CCoommpplliiaannccee

Case Studies of Using GAIT for Business and IT Risk (GAIT-R)

to Scope PCI Compliance

Authors: Christine Bellino, Jefferson Wells

Christine Chaney, Continental Airlines Gary Eymer, Marathon Oil Corporation

Eric Hannagan, Jefferson Wells Gene Kim, Tripwire, Inc.

Norman Marks, SAP Dave Myerson, Nike, Inc.

James Reinhard, Simon Property Group, Inc. David Williams, JCPenney

External Contributors:

Dorian Cougias, Unified Compliance Framework

The Institute of Internal Auditors, Advanced Technology Committee Draft 1.2

September 16, 2008

CCaassee SSttuuddiieess ooff UUssiinngg GGAAIITT‐‐RR TToo SSccooppee PPCCII CCoommpplliiaannccee

Table of contents I. PCI Compliance Problem Statement........................................................................................1 II. The GAIT-R Methodology.......................................................................................................2

Document Structure ............................................................................................................................................ 3 III. Scenario 1: Level 3 E-Commerce Merchant .........................................................................4

Background narrative for PCI compliance.......................................................................................................... 4 Step 1. Identify the business objectives for which the controls are to be assessed ............................................ 5 Step 2. Identify the key business controls required to provide reasonable assurance that the business objectives will be achieved ...................................................... 5 Step 3. Identify the critical IT functionality relied upon, from among the key business controls ..................... 6 Step 4. Identify the computing environment where cardholder data is transmitted, stored or processed where ITGCs need to be tested ....................................................... 6 Step 5. Identify ITGC process risks and related control objectives ................................................................... 6 Functionality 1. SSL libraries and HTTPS server provide encryption of data from the customer online form........................................................ 7 Functionality 2. SSL libraries encrypt cardholder data transmitted to the processor.............................. 8 Functionality 3. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is never stored....................................... 8 Functionality 4. Needed cardholder data is stored securely and securely deleted .................................. 9 Step 6. Identify the key ITGCs to test that address identified risk and related control objectives .................. 10 Functionality 1. SSL libraries and HTTPS server provide encryption of data from the customer online form...................................................... 11 Step 7. Perform a reasonable person holistic review of all key controls ......................................................... 11 Step 8. Determine the scope of the review and build an appropriate design and effectiveness testing program ........................................................................ 11

IV. Scenario 2: Level 1 Large Retailer.......................................................................................12 Background narrative for PCI compliance........................................................................................................ 12 Step 1. Identify the business objectives for which the controls are to be assessed .......................................... 14 Step 2. Identify the key business controls required to provide reasonable assurance that the business objectives will be achieved ................................................... 14 Step 3. Identify the critical IT functionality relied upon, from among the key business controls ................... 14 Step 4. Identify the computing environment where cardholder data is transmitted, stored or processed where ITGCs need to be tested........................................................ 14 Step 5. Identify ITGC process risks and related control objectives ................................................................. 15 Functionality 1. SSL libraries encrypt cardholder data transmitted to the processor............................ 15 Functionality 2. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is never stored.................................... 17 Functionality 3. Needed cardholder data is stored securely and securely deleted ............................... 18 Functionality 4. SSL libraries encrypt cardholder data prior to transmission...................................... 19 Step 6. Identify the key ITGCs to test that address identified risk and related control objectives .................. 21 Functionality 1. SSL libraries encrypt cardholder data transmitted to the processor............................ 21 Step 7. Perform a reasonable person holistic review of all key controls ......................................................... 21 Step 8. Determine the scope of the review and build an appropriate design and effectiveness testing program ........................................................................ 21

V. Conclusion................................................................................................................................22

CCaassee SSttuuddiieess ooff UUssiinngg GGAAIITT‐‐RR TToo SSccooppee PPCCII CCoommpplliiaannccee 1

I. PCI Compliance Problem Statement All organizations that accept or process payment cards of any type are subject to the Payment Card Industry Data Security Standard (PCI DSS) and other relevant contractual obligations. The stated goal of the PCI DSS is to “improve the security of global payment systems by protecting consumers, merchants and banks from credit information theft and loss and subsequent fraudulent activity.” Fundamental to correctly defining the PCI environment is the ability to properly document the information flow of where payment card data enters, transits, is processed, stored, and output while it is under the organization’s control. Analysis of security breaches and forensics data supplied by Verizon Business Systems1 showed that at least 65% of all known cardholder data breach incidents occurred on systems that were not known to have contained cardholder data. Furthermore, in those organizations, 75% did not employ proper monitoring processes that would have enabled the organization to detect and respond to the security breach. This clearly indicates that organizations are not correctly scoping the PCI environment, nor are they properly monitoring these systems according to PCI guidelines. Until these issues are corrected, data breaches will keep occurring, even though organizations have PCI compliance programs. We have identified two courses of action that are required to remedy this:

1. Organizations must have tools to more accurately scope what IT systems are in the PCI environment; and

2. For those IT systems in scope, organizations must systematically and consistently identify the control objectives that enable the effective prevention of, detection of, and recovery from cardholder data security breaches.

The guidance for these courses of action can be found in GAIT for Business and IT Risk (GAIT-R).

1 “2008 Data Breach Investigations Report: Four Years Of Forensics Research. More Than 500 Cases. One Comprehensive Report”, Verizon Business Systems.


II. The GAIT-R Methodology These two PCI compliance challenges of correct scoping and substantiation are very similar to those faced by organizations having to comply with Section 404 of the Sarbanes-Oxley Act of 2002 (SOX-404). These challenges led The Institute of Internal Auditors (IIA) to develop and publish the GAIT2 Methodology in January 20073, which was designed to help organizations identify the IT general control process risks and related key controls that need to be included in the assessment of internal controls over financial reporting in their SOX-404 compliance efforts. GAIT has been widely adopted by organizations, and has provided prescriptive guidance for management that is consistent with the guidance provided by the U.S. Securities and Exchange Commission (SEC) and the Public Company Accounting Oversight Board (PCAOB). In 2008, The IIA published GAIT-R, which extends the application of GAIT beyond financial reporting to business and IT risk, including compliance with laws and regulations and operations. GAIT-R provides a set of principles and a formal, top-down, structured reasoning approach for identifying and assessing all the controls, both IT and in the business, required to address business objectives, including those specific to the “IT compliance” requirements. We believe that the GAIT-R methodology can be applied to correctly scope PCI environments where credit card processing occurs. GAIT-R is a framework that helps organizations move from a “compliance checklist” mentality to a holistic, top-down, and risk-based approach to all activities in the IT control environment. Similarly, GAIT-R could be applied for any other compliance objective: e.g., HIPPA, FISMA, GLBA, etc. Ideally, GAIT-R will be used to integrate PCI compliance efforts with other regulatory requirements, such as SOX-404, HIPPA, etc., and specify when we can rely on testing done for other compliance efforts. Among the outcomes would be reduced risk, an enhanced control environment, as well as the reduction of unnecessary testing and compliance costs. GAIT-R is based on four principles: • Principle 1: The failure of technology is only a risk that needs to be assessed, managed, and audited if

it represents a risk to the business. • Principle 2: Key controls should be identified as the result of a top-down assessment of business risk,

risk tolerance, and the controls (including automated controls and IT general controls) required to manage or mitigate business risk.

• Principle 3: Business risks are mitigated by a combination of manual and automated key controls. In order to assess the system of internal control to manage/mitigate business risks, key automated controls need to be assessed.

• Principle 4: IT general controls may be relied upon to provide assurance of the continued and proper operation of automated key controls. • Principle 4a: The IT general control (ITGC) process risks that need to be identified are those that

affect critical IT functionality in significant applications and related data. • Principle 4b: The ITGC process risks that need to be identified exist in processes and at various

IT layers: application program code, databases, operating systems, and network. • Principle 4c: Risks in ITGC processes are mitigated by the achievement of IT control objectives,

not individual controls.

2 GAIT stands for Guide to the Assessment of IT General Controls Scope Based on Risk (GAIT). 3 “The GAIT Methodology,” The Institute of Internal Auditors, January 2007 (http://www.theiia.org/guidance/technology/gait/).

IIII.. TThhee GGAAIITT‐‐RR MMeetthhooddoollooggyy


The GAIT-R methodology comprises eight steps: 1 Identify the business process and objectives for which the controls are to be assessed. 2 Identify the key business controls required to provide reasonable assurance that the business

objectives will be achieved. 3 Identify the critical IT functionality relied upon, from among the key business controls. 4 Identify the significant applications where ITGCs need to be tested4. 5 Identify ITGC process risks and related control objectives. 6 Identify the key ITGCs to test that address identified risk and related control objectives. 7 Perform a reasonable person holistic review of all key controls. 8 Determine the scope of the review and build an appropriate design and effectiveness testing program.

Document Structure In the remainder of this document, we provide two case studies of applying GAIT-R to PCI compliance. The first is a simple e-commerce environment supporting a $100M revenue organization, and the second is a more complex retail environment, supporting a 1000 store, $10B revenue organization. In each scenario, we walk through the GAIT-R Methodology, documenting the thought process for scoping and substantiation of IT controls.

4 For purposes of PCI compliance, this GAIT-R step is best defined as the identification of the PCI computing environment where cardholder data is transmitted, stored or processed where ITGCs need to be tested (e.g., this includes applications, databases, operating systems, network devices, and so forth).


III. Scenario 1: Level 3 E-Commerce Merchant

Background narrative for PCI compliance “Level 3 Merchant Inc.” is a $50M privately held company that sells consulting services and intellectual property over an e-commerce site, in addition to its traditional off-line channels. The site is managed in-house by a three-person IT staff handling order entry and processing (e.g., the accepting and processing of credit card payments). The e-commerce site has been steadily growing for the past few years and was responsible for over $5M in revenue last year. The site accepts approximately 100 transactions per day that are processed by one acquiring bank. The front-end order entry application is the DolphinCart shopping cart, which is part of the e-commerce site. It is run by a Drupal Web server and the blog engine, which handles all customer encryption sessions, which depends on Secure Sockets Layer (SSL) libraries in the operating system (OS). The front end application is located in a secure network zone (“demilitarized zone” or DMZ), which receives customer cardholder data, including the primary account number (PAN), expiration date, and the customer validation code (CVC or three-digit code on the back of the card). The cardholder data is then encrypted and transmitted over an SSL session to the processor (payment gateway) for authorization. An approval code is received by the application from the payment gateway. The application performs authorization transactions in real-time (i.e., no batch jobs store cardholder data), that sends the data to the Processor to complete the transactions for that business day.

Scenario 1 – Example Diagram

IIIIII.. SScceennaarriioo 11:: LLeevveell 33 EE‐‐CCoommmmeerrccee MMeerrcchhaanntt


A portion of the encrypted cardholder data is stored locally in a mySQL database (located on a secure network zone on the internal network). All but the last 4 digits of the PAN are truncated by the application, which transforms the data so that it is no longer considered “cardholder data.” The last 4 digits, approval code, expiration date, customer name, and transaction amount are stored in the database. The OS is Red Hat Linux. Company IT staff manages the application and the OS. The hosting company manages the networks and firewalls. In summary, the cardholder data is stored, processed, or transmitted as follows:

• Data is stored in the mySQL database. • Data is transmitted:

o Local network within the data center o Wide area network (Internet) to the credit card processor, transiting through two firewalls o Encryption functionality provided by the SSL libraries in the OS

• Data is processed by a processor (payment gateway). o Authorization is performed by the payment gateway. o Approval is received by the application from the payment gateway. o Settlement transactions are performed online.

• Back office o The accounting staff has access to the acquiring bank/processor e-commerce Web site in

order to perform account reconciliation. Accounting staff can access full credit card transaction information, but no prohibited cardholder data is stored

o Customer service has access to the database in order to perform charge backs or refunds. The customer must provide a credit card number to receive a refund.

The cardholder data environments are segmented into secure network zones, and do not transit the corporate network.5 All transmissions carrying cardholder data are encrypted using SSL.

Step 1. Identify the business objectives for which the controls are to be assessed For the purpose of this case study, we are only considering the business objectives specific to PCI DSS compliance. We recognize that there are other business objectives for this process (e.g., completeness and accuracy of the approval process), but these are omitted for clarity. The PCI DSS compliance objective is: • Process credit card transactions securely, according to PCI DSS requirements.

Step 2. Identify the key business controls required to provide reasonable assurance that the business objectives will be achieved Control 1. All transmitted cardholder data from the customer is encrypted consistent with PCI standards

(i.e., front-end order entry, online form). Control 2. All cardholder data is encrypted prior to transmission to the credit card processor consistent

with PCI standards (i.e., authorization and settlement process).

5 For scoping a PCI engagement, any device or network that is involved with the transmission, storage, or processing is in-scope for the PCI environment and assessment. The first step in defining the cardholder data environment (CDE) is to define how the transaction is performed to include transmission, storage, and processing of cardholder data. If a network is flat, then every device, server, workstation, etc. on the network is included in scope for the CDE.



Control 3. No prohibited cardholder data is stored (i.e., storage of CVV6, AV2 in paper, system logs, data warehouse, etc.)

Control 4. All stored cardholder data remains secure (i.e., storage of CVV, AV2 in paper, system logs, data warehouse, etc.)

Because of the automated nature of how orders are processed, there are no manual key controls. GAIT-R requires the identification of all controls, including entity-level controls7. However, PCI DSS compliance does not require the review of entity-level controls.

Step 3. Identify the critical IT functionality relied upon, from among the key business controls Functionality 1. SSL libraries and HTTPS server provide encryption of data from the customer online

form. Functionality 2. SSL libraries encrypt cardholder data transmitted to the processor. Functionality 3. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is

never stored. Functionality 4. Needed cardholder data is stored securely and securely deleted.

Step 4. Identify the computing environment where cardholder data is transmitted, stored or processed where ITGCs need to be tested8

Functionality The IT systems that deliver the IT functionality Functionality 1. SSL libraries and HTTPS server provide encryption of data from the customer online form.

DolphinCart application Red Hat OS

Functionality 2. SSL libraries encrypt cardholder data transmitted to the processor.

DolphinCart application Red Hat OS

Functionality 3. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is never stored.

DolphinCart application

Functionality 4. Needed cardholder data is stored securely and securely deleted.

DolphinCart application mySQL database Red Hat OS Network

Step 5. Identify ITGC process risks and related control objectives In this step, for each critical IT functionality being relied upon, we identify the risks and related control objectives for the following three areas: change/configuration, access, and operations. Questions to ask for each area are:

6 “Prohibited cardholder data” is defined by PCI to be any personally identifiable information (PII) associated with a cardholder: Primary Account Number (PAN) that includes expiration date, cardholder name and address, CVV (Card Verification Values) or CVC Card track data (magnetic stripe) 7 Examples of entity-level controls include code of conduct being actively communicated, a whistleblower line that enables employees to report violations of cardholder privacy, adequacy of staffing to ensure that personnel performing PCI-related activities are trained and experienced, an understanding of current PCI compliance requirements and a mechanism that is triggered on changes, and so forth. 8 As described in the paper introduction, this is an adaptation of GAIT-R Step 4, which originally read “identify the significant applications where ITGCs need to be tested.”



Q1: What must be configured? (includes code, settings, and security settings) Q2: What access restrictions must be set? (e.g., physical, logical, separation of duty) Q3: What must be operationally put into place? PCI specifically refers to the following:

• Planned activities such as secure backups, vulnerability management and patching, review of logs, and security awareness training

• Unplanned activities such as exception handling, incident/problem management, security incident handling

Functionality 1. SSL libraries and HTTPS server provide encryption of data from the customer online form The table below lists only the ITGC risks that have been identified that jeopardize the functionality.

Change/configuration risks ITGC control objectives Untested or unauthorized change results in cardholder data exposure (e.g., encryption, access controls, configurable settings). • Application: Untested or unauthorized SSL

functionality via the .htaccess file could be disabled in the application, resulting in cardholder data exposure.

• Database: n/a. There is no database for the front-end order entry systems.

• OS: SSL functionality could be disabled in the OS libraries, resulting in cardholder data exposure (patch creates vulnerability).

• Network: n/a. No encryption functionality resides in the network, as all encryption is done end-to-end.

Changes are implemented following a change management process that identifies unauthorized or untested changes that are deployed into production: • Application: yes • Database: no • OS: yes • Network: no

Access risks Unauthorized access to front-end order entry systems results in cardholder data exposure. For example, unauthorized access to accounts is gained that access cardholder data or decryption keys (e.g., administrative accounts, order entry accounts, etc.). • Application: Unauthorized use of

administrative, order entry, and service accounts results in cardholder data exposure.

• Database: n/a. There is no database for the front-end order entry systems

• OS: Unauthorized use of administrative accounts results in cardholder data exposure.

• Network: n/a. Unauthorized access to firewalls/networks is unlikely to cause exposure to cardholder data (i.e., all data is encrypted).

All created accounts are authorized, existing accounts are owned by authorized personnel, and revoked appropriately. • Application: yes • Database: no • OS: yes • Network: no • Physical data center access: no

(“Level 3 Merchant Inc.” is not responsible, but their hosting provider will have to show that they restrict access to authorized personnel.)



• Physical data center access: Servers are in a third-party data center (which must ensure that unauthorized physical access to servers/networks that could result in exposure of cardholder data is controlled).

Operational risks Application and OS vulnerabilities could be exploited, resulting in cardholder data exposure. • Application: New vulnerabilities could result in

cardholder data exposure. • Database: n/a. There is no database. • OS: New vulnerabilities could result in

cardholder data exposure. • Network: Network vulnerabilities are unlikely to

result in cardholder data exposure. Exposure to cardholder data is unlikely to occur due to failures in logging, unless someone makes a change that disables encryption.

Vulnerability assessments are conducted periodically to prevent exposure of cardholder data. • Application: yes • Database: no • OS: yes • Network: no

Functionality 2. SSL libraries encrypt cardholder data transmitted to the processor This functionality resides in the authorization and settlement process. The processor transmission risks are similar to the customer transmission risks, shown in Functionality 1.

Functionality 3. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is never stored This functionality resides in the back-end processes, such as customer support and accounting, but we have already verified that no prohibited cardholder information resides in the front-end systems.

Change/configuration risks ITGC control objectives Code or configuration changes (e.g., configuration change, turning on debug logging) could result in prohibited cardholder information being stored. Change/configuration risks: • Application: Code or configuration settings are

changed causing storage of prohibited information.

• Database: Code or configuration settings are

Changes are implemented following a change management process that identifies unauthorized or untested changes that are deployed into production: • Application: yes • Database: yes • OS: no • Network: no



changed causing storage of prohibited information.

• OS: n/a. No change at the OS layer is likely to cause storage of prohibited data.

• Network: n/a. No change at the network layer is likely to cause storage of prohibited data.

Access risks Because we’ve already established and verified that no prohibited data is being stored in the front-end or back-end systems, unauthorized access to these systems is unlikely to result in storage of prohibited cardholder data (i.e., there must first be a change)9. • Application: n/a • Database: n/a • OS: n/a • Network: n/a

All created accounts are authorized, existing accounts are owned by authorized personnel, and revoked appropriately. • Application: no • Database: no • OS: no • Network: no

Operational risks

There is no offline mode that could cause storage of prohibited data. Failures in operational procedures, such as vulnerability management and secure logging, are also unlikely to cause storage of prohibited data. Operational risks: • Application: n/a • Database: n/a • OS: n/a • Network: n/a

n/a • Application: no • Database: no • OS: no • Network: no

Functionality 4. Needed cardholder data is stored securely and securely deleted This functionality resides in the back-end processes, such as customer support and accounting (i.e., we have already verified that no prohibited cardholder information resides in the front-end systems).

Change/configuration risks ITGC control objectives In this scenario, there is no stored prohibited cardholder data (i.e., all but last 4 digits of PAN have been truncated).

Changes are implemented following a change management process that identifies unauthorized or untested changes that are deployed into production:

9 Access risks will be the same for Functionality 3 and Functionality 4.



Change/configuration risks: • Application: Code or configuration settings are

changed, causing storage of prohibited data. • Database: n/a. Functionality to truncate PAN

resides in the application, not the database. • OS: n/a. Changes to the OS are unlikely to result

in storage of cardholder data. • Network: n/a. Changes to the OS are unlikely to

result in storage of cardholder data.

• Application: yes • Database: no • OS: no • Network: no

Access risks Because we’ve truncating the PAN, there is no cardholder data being stored. Therefore, unauthorized access to these systems will not expose cardholder data. (There must first be an unauthorized change.)10 Restricted access risks (provisioning, ongoing monitoring, secure the backdoor): • Application: n/a • Database: n/a • OS: n/a • Network: n/a


Operational risks There is no offline mode that could cause storage of cardholder data. Failures in operational procedures, such as vulnerability management and secure logging, are also unlikely to cause storage of prohibited cardholder data. Operational risks: • Application: n/a • Database: n/a • OS: n/a • Network: n/a

None • Application: no • Database: no • OS: no • Network: no

Step 6. Identify the key ITGCs to test that address identified risk and related control objectives Step 6 is left as an exercise for the adopter of this methodology. As an example, we show the ITGCs in support of Functionality 1 for change management.

10 Access risks will be the same for Functionality 3 and Functionality 4.



Functionality 1. SSL libraries and HTTPS server provide encryption of data from the customer online form

ITGC objectives ITGC controls Changes are implemented following a change management process that identifies unauthorized or untested changes that are deployed into production: • Application: yes • Database: no • OS: yes • Network: no

• All changes to the application and OS are

recorded on a change form and approved by management.

• All authorized changes are tested prior to implementation.

• A separate IT environment for production and non-production is maintained.

• A periodic review is performed to ensure that undocumented changes are investigated.

• …and so forth…

Step 7. Perform a reasonable person holistic review of all key controls Step seven is intended for the adopter to perform a reasonable person review of the risks, control objectives, and the controls identified as a result of applying this methodology. It is intended that the review includes a look at the overall PCI DSS compliance risk of the company to evaluate for the possibility that a key risk was overlooked. Evaluating any prior risk and control review reports may be included as a part of this assessment. At this point, we have identified 1) the critical IT functionality and 2) where we have reliance on ITGCs. They are as follows:

Summary GAIT Matrix for combined Functionalities 1-4:

Layer Change / Configuration

Operations Security/Logical Access

Application Yes Yes Yes Database Yes Operating system Yes Yes Yes Network/infrastructure

Step 8. Determine the scope of the review and build an appropriate design and effectiveness testing program This is left as an exercise for the GAIT-R adopter following the organization’s testing methodologies and format.


IV. Scenario 2: Level 1 Large Retailer

Background narrative for PCI compliance “Large Level 1 Inc.” is a publicly traded, medium-sized grocery chain that reported $10B in revenue last year. The company processes over 6,000,000 transactions per year and as a result is a Level 1 merchant. As such, it has to comply with the following PCI requirements as of September 30, 2004: • An annual on-site security audit validated by an independent security assessor or internal audit if

signed by officer of the company. • Quarterly network scans completed by a qualified independent scan vendor. The company has 1000 stores, with approximately 20 point of sale (POS) systems/devices at each location. The retail stores are the only channel to the consumer (i.e., no e-commerce operations). The store’s POS setup consists of a combination of scanned check-out and self-service counters. The POS systems and devices are connected to an on-site “back-end” server which collects credit card data. Each store has about five servers, which are all connected to the corporate authorization servers via leased lines and satellite, where card authorization and settlement are performed. All data transferred from the stores to corporate servers are encrypted. The corporate authorization server transmits the encrypted credit card information to the bank for authorization. Authorization from the bank is returned encrypted to the corporate authorization server and then forwarded on to the specific store server for execution. Once authorization has been confirmed, the POS system and store server delete all prohibited data. Credit card numbers and consumer names are encrypted and retained for seven days on the store server for processing refunds. In the event of system or network failures, transactions can be processed offline, including manually, where signed physical imprints are manually inputted into the system. Once entered into the system, the signed receipt is retained, and the physical imprint is securely shredded. There is a small wireless network in each store which connects handheld inventory counting tools to the POS system. The in-store systems are supported by one technical person on site. All system changes, enhancements, or fixes are managed by the corporate IT staff at HQ. The POS systems are commercially supported and have been validated as “PCI-compliant.” This is a card-present environment. At each POS station, consumers will either swipe their credit card and the signature is scanned electronically, or the consumer will sign a carbon paper imprint. In online authorization mode: All cardholder data is sent from the POS station to the store servers, where non-prohibited cardholder data is stored (to support refunds). Cardholder data is sent to the corporate back-end systems where authorization and settlement are performed, and cardholder data is stored for seven days (to support refunds and sales reconciliation). In offline authorization mode (e.g., store or company loses connectivity to processor): All cardholder data is sent from the POS station to the store servers. They then get an approval code from the back-office system, and store servers will store cardholder data (including the full PAN, which is encrypted by the in-store servers) until either authorization is obtained or 24 hours elapses, at which point the cardholder data is securely purged.

IIVV.. SScceennaarriioo 22:: LLeevveell 11 LLaarrggee RReettaaiilleerr


In manual mode (e.g., store systems are down): All consumer transactions are done manually, generating physical imprints. Then store personnel will manually enter the transactions when the store systems are back up again.

Leas

ed L

ine

Con

nect

ion

to C

orpo

rate

Scenario 2 Example Diagram

POS systems:

• Vendor supported application • Windows CE systems • No local storage, except for configuration settings and memory

Store servers:

• Active Directory domain controller (primary and secondary) • POS Application • Microsoft SQL Server database • Microsoft Windows 2003 • Routers and VPN connected to leased line to corporate systems • Wireless LAN support wireless scanners for inventory

Wireless LAN resides on the same network as the store systems, to support connectivity to the inventory management systems. Store servers are physically secure, to prevent someone from physically stealing the systems and data.



Step 1. Identify the business objectives for which the controls are to be assessed For the purpose of this case study, we are only considering the business objectives specific to PCI DSS compliance. We recognize that there are other business objectives for this process (e.g., completeness and accuracy of the approval process), but these are omitted for clarity. The PCI DSS compliance objective is: • Process credit card transactions securely, according to PCI DSS requirements.

Step 2. Identify the key business controls required to provide reasonable assurance that the business objectives will be achieved Control 1. All cardholder data is encrypted prior to transmission to the credit card processor consistent

with PCI standards (i.e., authorization and settlement process). Control 2. No prohibited cardholder data is stored (i.e., storage of CVV, AV2 in paper, system logs, data

warehouse, etc.) Control 3. All stored cardholder data remains secure (i.e., storage of CVV, AV2 in paper, system logs,

data warehouse, etc.) Control 4. All cardholder data transmitted between company systems are encrypted consistent with PCI

standards (i.e., between store systems and to the corporate servers). The presence of an offline transaction mode and physical imprints requires manual controls (e.g., required offline mode procedures, batch controls such as closeout, secure physical storage, training to protect physical imprints, etc.). GAIT-R requires the identification of all controls, including entity-level controls, such as regional store manager doing daily inspections that physical imprints are protected. However, PCI DSS compliance does not require the review of entity-level controls.

Step 3. Identify the critical IT functionality relied upon, from among the key business controls Functionality 1. SSL libraries encrypt cardholder data transmitted to the processor. Functionality 2. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is

never stored. Functionality 3. Needed cardholder data is stored securely and securely deleted Functionality 4. SSL libraries encrypt cardholder data prior to transmission.

Step 4. Identify the computing environment where cardholder data is transmitted, stored or processed where ITGCs need to be tested11

Functionality The IT systems that deliver the IT functionality Functionality 1. SSL libraries encrypt cardholder data transmitted to the processor.

Store servers: Front-end POS application Windows 2003 OS Corporate servers: Back-end POS application Windows 2003 OS

11 As described in the paper introduction, this is an adaptation of GAIT-R Step 4, which originally read “identify the significant applications where ITGCs need to be tested.”



Functionality 2. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is never stored.

Store servers: POS application Windows 2003 OS

Functionality 3. Needed cardholder data is stored securely and securely deleted.

Store servers: POS application SQL Server database Windows 2003 OS Corporate servers: Back-end POS application Windows 2003 OS Network

Functionality 4. SSL libraries encrypt cardholder data prior to transmission.

Store servers: Front-end POS application Windows 2003 OS Corporate servers: Back-end POS application Windows 2003 OS

Step 5. Identify ITGC process risks and related control objectives In this step, for each critical IT functionality being relied upon, we identify the risks and related control objectives for the following three areas: change/configuration, access, and operations. Questions to ask for each are: Q1: What must be configured? (includes code, settings, and security settings) Q2: What access restrictions must be set? (e.g., physical, logical, separation of duty) Q3: What must be operationally put into place? PCI specifically refers to the following:

• Planned activities such as secure backups, vulnerability management and patching, review of logs, and security awareness training

• Unplanned activities such as exception handling, incident/problem management, security incident handling

Functionality 1. SSL libraries encrypt cardholder data transmitted to the processor. For this step, we are only considering the front-end order entry system and the corporate back-end servers. This will bring into scope the within-store traffic (where encryption is provided by the application or OS) and traffic to the corporate servers (where encryption is provided by the VPN network).

Change/configuration risks ITGC control objectives Untested or unauthorized change results in cardholder data exposure (e.g., encryption, access controls, configurable settings).




• Application: Code or configuration changes to the POS application could disable encryption, resulting in cardholder data exposure.


• OS: SSL functionality could be disabled in the OS libraries, resulting in cardholder data exposure.

• Network: VPN provides end-to-end encryption, and could be disabled to disable encryption.

• Application: yes • Database: no • OS: yes • Network: yes

Access risks Unauthorized access to systems is unlikely to result in unencrypted cardholder data being exposed (unless there is a change). • Application: n/a • Database: n/a • OS: n/a • Network: n/a. Unauthorized access to

firewalls/networks is unlikely to cause exposure to cardholder data

• Physical data center access: n/a


Operational risks Application and OS vulnerabilities could result in cardholder data exposure. • Application: New vulnerabilities could result in

cardholder data exposure. • Database: n/a. There is no database. • OS: New vulnerabilities could result in cardholder

data exposure. • Network: Because data is encrypted before

transmission, even new vulnerabilities to the corporate VPN is unlikely to result in cardholder data exposure.

Exposure to cardholder data is unlikely to occur due to failures in logging, unless someone makes a change that disables encryption.




Functionality 2. All but the last four digits of the PAN are truncated prior to storage and the CVV/CVC is never stored This functionality primarily resides in the store servers, which ensure that cardholder data is purged after credit card authorization. Corporate servers receive information with no prohibited cardholder information.

Change/configuration risks ITGC control objectives Encrypted PAN data can be stored for up to 24 hours in offline settlement mode, all encrypted by the application. The risk is that a change in the application disables encryption or enables logging of prohibited information. Change/configuration risks: • Application: code or configuration settings are

changed that disable encryption. • Database: n/a. Functionality to truncate PAN

resides in the application, not the database. • OS: n/a. Changes to the OS are unlikely to result

in storage of cardholder data. • Network: n/a. Changes to the OS are unlikely to

result in storage of cardholder data.


• Application: yes • Database: no • OS: no • Network: no

Access risks Unauthorized access risks in the following areas could expose cardholder data: • Application: Application access could expose

encrypted information. • Database: n/a • OS: n/a • Network: n/a

All created accounts are authorized, existing accounts are owned by authorized personnel, and revoked appropriately. • Application: yes • Database: no • OS: no • Network: no

Operational risks Backups of the store servers that contain encrypted cardholder data could be stolen or copied, but is unlikely to result in exposure of cardholder data.12 Cardholder data is backed up. There are no other operational procedures where failures are likely to cause storage of cardholder data

• Application: no • Database: no • OS: no • Network: no • Physical: Data center is locked

(storage closet is locked) to protect encryption key.

12 If backup tapes are stolen, card issuers may define this as a breach and require an investigation. However, this is different than a data compromise or data loss, which is the risk that was evaluated in this example.



(e.g., vulnerability management, secure logging). Operational risks: • Application: n/a • Database: n/a • OS: n/a • Network: n/a • Physical: n/a (Physical tapes may be stolen, but

encryption makes it unlikely to result in cardholder data exposure.)

Functionality 3. Needed cardholder data is stored securely and securely deleted This functionality resides in the back-end processes, such as data warehouse (i.e., we have already verified that no prohibited cardholder information resides in the front-end systems). There are two areas that we want to inspect: the in-store servers (which purge prohibited information) and the corporate servers (which receive information from the store servers). In other words, corporate server receives information with no prohibited cardholder information. The high risk area we identify is: • Store server is not correctly purging prohibited data after credit card authorization (due to a code

change, or debugging being turned on). Store servers purge prohibited data, but still contain cardholder names and primary account number (PAN) for seven days. If this information is compromised, then this constitutes a PCI breach.

Change/configuration risks ITGC control objectives Code or configuration changes (e.g., configuration change, turning on debug logging) to the store servers could result in prohibited cardholder information being stored. Change/configuration risks: • Application: Code or configuration settings are

changed, causing storage of prohibited information. • Database: Code or configuration settings are

changed, causing storage of prohibited information. • OS: n/a. No change at the OS layer is likely to

cause storage of prohibited data. • Network: n/a. No change at the network layer is

likely to cause storage of prohibited data.


• Application: yes • Database: yes • OS: no • Network: no (Changes to the application and database will reside in the HQ change control and SDLC processes which authorize and schedule changes to store servers.)



Access risks Because we’ve already established and verified that no prohibited cardholder data is being stored in the store servers for 24 hours, unauthorized access to these systems is unlikely to expose prohibited cardholder data. (There must first be an unauthorized change.) Because we are using a PCI-validated application, the cardholder names and PAN are encrypted by the application. The risk of disclosure of data is low, even if there is physical theft of the store server, or the data is copied, because the physical decryption key is required. • Application: Because the application can decrypt

prohibited cardholder data (with the appropriate account and presence of the physical key), unauthorized access to the application can result in exposed cardholder data (e.g., running report, executing code, etc.).

• Database: n/a • OS: n/a • Network: n/a

All created accounts are authorized, existing accounts are owned by authorized personnel, and revoked appropriately. • Application: yes • Database: no • OS: no • Network: no

Operational risks

There is an offline mode that requires storage of encrypted PAN for 24 hours. Failure in operational procedures, such as vulnerability management and secure logging, are also unlikely to cause storage of prohibited data. Operational risks: • Application: n/a • Database: n/a • OS: n/a • Network: n/a

None • Application: n/a • Database: n/a • OS: n/a • Network: n/a

Functionality 4. SSL libraries encrypt cardholder data prior to transmission For this step, we consider all transmission of cardholder data, not just to the payment processor.

Change/configuration risks ITGC controls Untested or unauthorized change results in cardholder data exposure (e.g., encryption, access controls, configurable settings).




• Application: SSL functionality could be disabled in the application, resulting in cardholder data exposure.


• OS: SSL functionality could be disabled in the OS libraries, resulting in cardholder data exposure.

• Network: n/a. No encryption functionality resides in the network, as all encryption is done end-to-end.

• Application: yes • Database: no • OS: yes • Network: no

Access risks Unauthorized access to front-end order entry systems results in cardholder data exposure. For example, unauthorized access to accounts is gained that access cardholder data or decryption keys (e.g., administrative accounts, order entry accounts, etc.). • Application: Unauthorized use of administrative

accounts results in cardholder data exposure. • Database: n/a. There is no database for the front-end

order entry systems. • OS: Unauthorized use of administrative accounts

results in cardholder data exposure. • Network: n/a. Unauthorized access to firewalls/

networks is unlikely to cause exposure to cardholder data.

• Physical data center access: Unauthorized physical access to servers/networks could result in exposure of cardholder data.

All created accounts are authorized, existing accounts are owned by authorized personnel, and revoked appropriately. • Application: yes • Database: no • OS: yes • Network: no • Physical: yes

Operational risks Application and OS vulnerabilities could result in cardholder data exposure. • Application: New vulnerabilities could result in

cardholder data exposure. • Database: n/a. There is no database. • OS: New vulnerabilities could result in cardholder

data exposure. • Network: no Exposure to cardholder data is unlikely to occur due to logging, unless someone makes a change that disables encryption.




Step 6. Identify the key ITGCs to test that address identified risk and related control objectives Step 6 is left as an exercise for the adopter of this methodology. As an example, we show the ITGCs in support of Functionality 1 for change management.

Functionality 1. SSL libraries encrypt cardholder data transmitted to the processor.

ITGC control objectives ITGC controls Changes are implemented following a change management process that identifies unauthorized or untested changes that are deployed into production: • Application: yes • Database: no • OS: yes • Network: no

• All changes to the application and OS are

recorded on a change form and approved by management.

• All authorized changes are tested prior to implementation.

• A separate IT environment for production and non-production is maintained.

• A periodic review is performed to ensure that undocumented changes are investigated.

• …and so forth…

Step 7. Perform a reasonable person holistic review of all key controls Step seven is intended for the adopter to perform a reasonable person review of the risks, control objectives, and the controls identified as a result of applying this methodology. It is intended that the review includes a look at the overall PCI DSS compliance risk of the company to evaluate for the possibility that a key risk was overlooked. Evaluating any prior risk and control review reports may be included as a part of this assessment. At this point, we have identified 1) the critical IT functionality and 2) where we have reliance on ITGCs. They are as follows:

Summary GAIT Matrix for combined Functionalities 1-4:

Layer Change / Configuration

Operations Security/Logical Access

Application Yes Yes Yes Database Yes Operating system Yes Yes Yes Network/infrastructure Yes

Step 8. Determine the scope of the review and build an appropriate design and effectiveness testing program This is left as an exercise for the GAIT-R adopter following the organization’s testing methodologies and format.


V. Conclusion As evidenced in the results of applying GAIT-R to the two scenarios in this case study, the methodology works well for identifying the appropriate compliance requirements regardless of an organization’s size or complexity. Applying a standard methodology to scoping PCI compliance will assist the auditor and those responsible for PCI compliance to focus on what is truly important to meeting the compliance objectives and minimizing risk to the organization.

GAIT For Business and IT Risk to Scope PCI Compliance Business and IT Risk.pdf · GAIT FOR BUSINESS...

Documents

Transcript of GAIT For Business and IT Risk to Scope PCI Compliance Business and IT Risk.pdf · GAIT FOR BUSINESS...