• Save
Payment Card Industry Data Security Standard (Pci Dss)
Upcoming SlideShare
Loading in...5
×
 

Payment Card Industry Data Security Standard (Pci Dss)

on

  • 2,009 views

Payment Card Industry Data Security Standard (PCI DSS)

Payment Card Industry Data Security Standard (PCI DSS)

Statistics

Views

Total Views
2,009
Views on SlideShare
2,001
Embed Views
8

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 8

http://www.slideshare.net 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Payment Card Industry Data Security Standard (Pci Dss) Payment Card Industry Data Security Standard (Pci Dss) Presentation Transcript

  • PCI DSS Payment Card Industry Data Security Standard Configuration Control for Virtual and Physical Infrastructures Orlando Moreno omoreno@hotmail.com 408.656.2498
  • Introduction According to the New York Times, on January 19, 2009, Heartland Payment Systems disclosed that they may have exposed the credit information of tens of millions of credit and debit card holders in what may be one of the largest data compromises to date. Heartland had been compliant with the Payment Card Industry Data Security Standard (PCI DSS), the standard designed by the major credit card companies to “protect consumers, merchants and banks from the theft or loss of credit information and any subsequent fraudulent activity.” The Heartland security breach illustrates a concerning trend toward organizations achieving PCI compliance, but still suffering a major breach. 408.656.2498 omoreno@hotmail.com 2
  • Being PCI Compliant Does Not Ensure Security The PCI DSS applies to any organization that accepts, stores or processes payment cards of any type and is a comprehensive checklist of actions these organizations must take to improve the security of global payment systems. Although the adoption of PCI DSS by an organization will most likely improve its security posture, being compliant with the PCI DSS does not ensure the organization is secure. As security practitioners, if we mechanically follow the PCI DSS checklist and our organization suffers a data security breach, we are still held responsible, and our organization still gets fined, suffers brand damage and may lose its ability to process credit card transactions. While checklists are useful tools, following them can lull us into a false sense of security. 408.656.2498 omoreno@hotmail.com 3
  • Being PCI Compliant Does Not Ensure Security To rely solely on the PCI DSS checklists to secure cardholder data is similar to a pilot relying only on the pre-flight checklist before takeoff, then colliding with another plane during takeoff. A checklist is not enough. In reality, the goal of effective security controls is to prevent security breaches from occurring, and when they do, to allow quick detection and recovery. This requires not just following a checklist, but understanding the organization’s compliance and security objectives, understanding what the top risks to achieving those objectives are, having adequate situational awareness to identify where we need controls to mitigate those risk, and then having implementing and monitoring the correct production controls. 408.656.2498 omoreno@hotmail.com 4
  • Two Areas Of Risks: Configuration And Change In this paper, we will first review the high-level goals of the PCI DSS. Then, we will examine two areas of technical controls required by the PCI DSS relevant to configurations and change, and present the primary risks that they are designed to mitigate. These controls span most of the PCI DSS requirements, either implicitly or explicitly. In Part I we discuss the first area, configuration controls, which require that specific configuration settings are correct. Returning to the airplane analogy, in a pre-flight checklist, configuration controls equate to checking that fuel levels are correct, the baggage door indicator light indicates the door is closed, the flaps are in the correct setting for takeoff, and so forth. In Part II we discuss the second area, change process controls, which ensure required activities have been completed properly. 408.656.2498 omoreno@hotmail.com 5
  • Two Areas Of Risks: Configuration And Change In a pre-flight checklist, these equate to ensuring that the pilot checks that the flap controls have the appropriate range of motion, that all maintenance issues were appropriately addressed, the pilot has signed all the required forms, the flight attendants correctly performed the safety presentation, and the pilot and copilot visually check the runway for other plans before takeoff, and so forth. These activities must be validated not just at one point in time, but regularly over an entire period of time (i.e. the entire year between PCI audits). 408.656.2498 omoreno@hotmail.com 6
  • The Intent of Configuration and Change Process Controls For the PCI DSS, configuration controls ensure that all computing systems in the cardholder data environment are configured correctly. For example, PCI DSS Requirement deals with firewalls, and includes requirements that all firewall settings are set to “deny all,” that audit logging is enabled, that required password aging is enabled, and so forth. On the other hand, change process controls ensure all changes to those computing systems in the cardholder data environment were adequately tested, authorized and verified. For example, PCI DSS Requirement also requires evidence that all changes to firewall rules are detected and authorized by management. 408.656.2498 omoreno@hotmail.com 7
  • The Intent of Configuration and Change Process Controls Other PCI Requirements require that all application software and operating system patches are tested by management for correct functionality before deployment into production. Configuration controls tend to more explicit, and can be verified merely by examining production configuration settings to the PCI DSS standard. This often makes configuration controls easier to test. Without automation, verifying change process controls can be more difficult to test than configuration controls. Instead of checking for correctness at a single point in time, change process controls ensure that management and supervisory controls have been reliable and consistent over a period of time. 408.656.2498 omoreno@hotmail.com 8
  • The Intent of Configuration and Change Process Controls For instance, to ensure that all application changes were tested, we must first assemble the population of all application changes in the specified period, and then substantiate that management signed off on all of them as being adequately tested. These tests can be automated to a significant degree. For instance, if an organization has a change audit/reconciliation monitoring technology that can reconcile detected production changes with authorized and tested changes, management can rely on these reports to show that no unauthorized or untested changes were made. 408.656.2498 omoreno@hotmail.com 9
  • The PCI DSS Configuration Controls In this section, we examine the broad requirements where the PCI DSS requires configuration controls. For each requirement, we will explain the requirement intent and provide specific examples of how to fulfill them. To ensure compliance with configuration controls, we can either inspect these settings manually or use automated tools. 408.656.2498 omoreno@hotmail.com 10
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 1 of the PCI DSS states: “Firewalls are computer devices that control computer traffic allowed between a company’s network (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within a company’s internal trusted network. The cardholder data environment is an example of a more sensitive area within the trusted network of a company. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employees’ Internet access through desktop browsers, employees’ e-mail access, dedicated connection such as business to business connections, via wireless networks, or via other sources. 408.656.2498 omoreno@hotmail.com 11
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 1 of the PCI DSS states: Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.” PCI DSS requires that we configure firewalls securely. PCI DSS Requirement 1 has four sub-requirements; for example, Requirement 1.1, which states that we must “establish firewall and router configuration standards.” And Requirement 1.2, states that we must “build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment.” 408.656.2498 omoreno@hotmail.com 12
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 1 of the PCI DSS states: In order to fulfill these requirements, for each firewall or router in the cardholder data environment, we must be able to block unauthorized services (e.g., FTP, IP finger, IP source routing, etc.), ensure that role-based administration is enabled, ensure that access settings only allow authorized resources to change or access security settings, etc. Specifications of what firewall settings must be set to achieve compliance with the PCI DSS can be found in many checklists and other technical guidance. This includes: • The Center For Internet Security (CIS) (www.cisecurity.org) • The Defense Information Systems Agency (DISA) (www.disa.mil) • The SANS Institute (www.sans.org) • Firewall vendors 408.656.2498 omoreno@hotmail.com 13
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 1 of the PCI DSS states: Verifying correctness of these settings can be done manually. However, automated tools are preferable, as they increase reliability, reduce the risk of human error, and reduce the time and effort required. 408.656.2498 omoreno@hotmail.com 14
  • Requirement 2: Do not use vendor-supplied defaults for system pass words and other security parameters Requirement 2 of the PCI DSS states: “Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.” The application stack consists of applications, databases, operating systems and network devices. Each computing system in each of these layers has configuration settings and user accounts that may use vendor-supplied defaults. For each of the computing systems in the cardholder data environment, PCI DSS requires evidence that configuration settings are set securely, and that default user accounts have been either disabled or do not use the vendor- supplied default passwords. 408.656.2498 omoreno@hotmail.com 15
  • Requirement 2: Do not use vendor-supplied defaults for system pass words and other security parameters Requirement 2 of the PCI DSS states: PCI DSS Requirement 2 has a number of sub-requirements. For example, PCI DSS Requirement 2.2 states that we must “develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards as defined.” In order to comply with this requirement, for Microsoft Windows servers, we must ensure that the security configurations are set correctly, such as: • Minimum Password Age Is Greater than or Equal to 1 Day • Allow Anonymous SID/Name Translation: Disabled • Do Not Allow Anonymous Enumeration of SAM Accounts: Enabled • Do Not Allow Anonymous Enumeration of SAM Accounts and Share: Enabled 408.656.2498 omoreno@hotmail.com 16
  • Requirement 7: Restrict access to cardholder data by business need to know Requirement 7 of the PCI DSS states: “To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. ‘Need to know’ is when access rights are granted to only the least amount of data and privileges needed to perform a job.” Each computing system in the application stack may have user accounts that management has not explicitly assigned to an authorized user (e.g., guest and service accounts). For each of these computing systems, we must identify and disable all accounts not explicitly authorized by management. 408.656.2498 omoreno@hotmail.com 17
  • Requirement 7: Restrict access to cardholder data by business need to know Requirement 7 of the PCI DSS states: PCI DSS Requirement 7 has a number of sub-requirements. For example, Requirement 7.2.3 specifies that system components with multiple users must restrict access on a user’s need to know, and must default to “deny all.” In order to comply with this requirement, we must ensure that the configurations are properly set. On Microsoft Windows servers, this would include: • Disabling the Microsoft Windows AppMgr permissions • Ensuring that the ability to access system files is properly restricted, including • %SystemRoot%system32cacls.exe • %SystemRoot%system32debug.exe • %SystemRoot%system32drwatson.exe • %SystemRoot%system32drwtsn32.exe • %SystemRoot%system32edlin.exe • %SystemRoot%system32eventcreate.exe 408.656.2498 omoreno@hotmail.com 18
  • Requirement 8: Assign a unique ID to each person with computer access Requirement 8 of the PCI DSS states: “Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.” PCI DSS Requirement 8 requires that all user activity on computing systems can be traced to an authorized user, prohibiting use of shared accounts, and so forth. For instance, Requirement 8.4 states that we must “render all passwords unreadable during transmission and storage on all system components using strong cryptography,” while Requirement 8.5 states that we must “ensure proper user authentication and password management for non-consumer users and administrators on all system components.” 408.656.2498 omoreno@hotmail.com 19
  • Requirement 8: Assign a unique ID to each person with computer access Requirement 8 of the PCI DSS states: In order to comply with this requirement, all authorized accounts must have strong password controls such as password strength, aging and expiration policies. In addition, we must ensure that for each asset in the application stack, we set password policies according to the PCI DSS requirements. To achieve this, we must ensure that the relevant configurations settings are set properly. This includes: • All system components must enable audit logging • Maximum password age is less than 90 days • Minimum password length is greater than or equal to 7 • Password complexity: enabled • Password history memory is greater than or equal to 4 408.656.2498 omoreno@hotmail.com 20
  • Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 10 of the PCI DSS states: “Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.” For each IT asset in the application stack, we must ensure that logging mechanisms are enabled to track user activities. System activity logs in all environments enable post-mortem forensics analysis if something does go wrong (e.g., security breach, lost cardholder information, service outage or impairment, etc.). This also enables root cause analysis and impact analysis. 408.656.2498 omoreno@hotmail.com 21
  • Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 10 of the PCI DSS states: PCI DSS Requirement 10 has a number of sub-requirements. For instance, Requirement 10.2.1 states that we must log “all individual user accesses to cardholder data,” and Requirement 10.2.3 states that we must have “access to all audit trails.” In order to comply with Requirement 10, we must ensure that the configurations are properly set. On Microsoft Windows servers, this includes ensuring that the following settings are enabled: • Audit Logon of Domain Accounts • Audit Logon Events • Audit Account Management 408.656.2498 omoreno@hotmail.com 22
  • Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 10 of the PCI DSS states: In order to comply with Requirement 10, we must also ensure that the configurations for event logging are properly configured and sized, to ensure that relevant data is not discarded due to small log spool sizes. For example: • Application Event Log Size Is Greater than or Equal to 16 MB • System Event Log Size Is Greater than or Equal to 16 MB • Security Event Log Size Is Greater than or Equal to 80 MB 408.656.2498 omoreno@hotmail.com 23
  • Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 10 of the PCI DSS states: Conclusion In Part I: Configuration Controls, the examples of settings that we must configure by no means represent the entire list of settings that must be configured to achieve PCI compliance. These examples are intended to show the type of “checklist” items we must verify to be compliant with the PCI DSS. 408.656.2498 omoreno@hotmail.com 24
  • The PCI DSS Change Process Controls In this section, we examine each requirement for the change process controls the PCI DSS requires. Just as we did for the earlier configuration controls, we’ll explain the intent behind each requirement. We’ll also provide steps we can take to fulfill them. To ensure compliance with change process controls, we can either inspect these settings manually or use automated tools. Requirement 1: Install and maintain a firewall configuration to protect cardholder data In Part I, we noted that Requirement 1 requires that certain firewall settings be set correctly. However, it’s not enough to verify that the configurations are secure at a single point in time; we need to demonstrate that all changes to firewall settings are detected and authorized by management and that none of those changes take us out of compliance with the PCI DSS configuration requirements. 408.656.2498 omoreno@hotmail.com 25
  • The PCI DSS Change Process Controls In fact, Requirement 1.1.1 states that we must establish firewall configuration standards that include “a formal process for approving and testing all external network connections and changes to the firewall configuration.” To fulfill this part of the PCI DSS Requirement 1, we must: • Detect all changes made to the firewalls in the cardholder data environment. • Have in place a workflow that management uses to approve proposed changes. • Have a manual or automated means of reconciling detecting changes with authorized changes, validating that all changes made were indeed authorized. By doing this, we can generate a change process control report that substantiates that all changes in the cardholder data environment were approved and tested by management. 408.656.2498 omoreno@hotmail.com 26
  • Requirement 3: Protect stored cardholder data Requirement 3 of the PCI DSS states: “Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.” 408.656.2498 omoreno@hotmail.com 27
  • Requirement 3: Protect stored cardholder data Requirement 3 of the PCI DSS states: To fulfill PCI DSS Requirement 3, we must protect stored cardholder data by: • Ensuring that applications prevent prohibited cardholder data such as CVV and AV23 from being stored in system logs, a data warehouse or database. • Storing cardholder data securely. To prevent the storage of prohibited cardholder data, we must verify that the computing systems that support the frontend processes (order entry, POS, etc.) and back-end processes (authorization and settlement, customer support, accounting, etc.) involved in credit card processing do not store such data. We usually verify this by inspecting the code or asking the relevant system vendors to verify PCI compliance. However, just as with the configuration controls, testing that prohibited cardholder data is not stored is only reliable for that single point in time. 408.656.2498 omoreno@hotmail.com 28
  • Requirement 3: Protect stored cardholder data Requirement 3 of the PCI DSS states: Instead, we need to ensure that no code or configuration changes occur over time that could cause prohibited cardholder data to be stored. For instance, any of the following changes could result in prohibited data being stored: • Enabling application debug logging • Changing a configuration setting at the application level • Changing a database configuration setting • Adding or changing a database stored procedure 408.656.2498 omoreno@hotmail.com 29
  • Requirement 3: Protect stored cardholder data Requirement 3 of the PCI DSS states: Furthermore, the PCI DSS requires that we store cardholder data securely. To do this, we must ensure that all computing systems that store cardholder data are configured securely and in accordance with PCI DSS requirements. Because cardholder data is primarily processed and stored in the application and database, we can often meet this objective by verifying that those systems are properly configured. But again, it is not enough to verify that configuration settings are correct at a single point in time; we must ensure that all changes to configuration settings are authorized and do not take us out of compliance with PCI DSS requirements. 408.656.2498 omoreno@hotmail.com 30
  • Requirement 3: Protect stored cardholder data Requirement 3 of the PCI DSS states: To fulfill PCI DSS Requirement 3, we must: • Detect all changes made to any computing systems that support the front- and back-end processes involved in credit card processing as well as any computing systems that store cardholder data. • Have a workflow that ensures management signs off on approved changes. • Have a manual or automated means of reconciling detected changes with authorized changes to validate that all changes that were made were indeed authorized. 408.656.2498 omoreno@hotmail.com 31
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks Requirement 4 of the PCI DSS states: “Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.” PCI DSS requires that all cardholder data be encrypted during transmission. Encryption typically is done by end-to-end encryption at the operating system level, or in rare cases, at the network level. Although we test and verify that cardholder data has been encrypted, once again, this is only for a single point in time. 408.656.2498 omoreno@hotmail.com 32
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks Requirement 4 of the PCI DSS states: An untested or unauthorized change to an operating system file, library, or network setting could result in disabling encryption; for this reason, we must detect all changes made to the operating system and network to ensure they don’t jeopardize functionality and that they were authorized before release into production. To fulfill this requirement, we must complete the same three activities seen for Requirements 1 and 3: detect all changes, have a workflow in place that ensures changes are approved, and have a means of ensuring detected changes were authorized. 408.656.2498 omoreno@hotmail.com 33
  • Requirement 6: Develop and maintain secure systems and applications “Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.” To comply with PCI DSS Requirement 6, we must apply security patches to the applications, database, operating system, and network on a regular basis. A major risk is that scheduled updates and patches are not completed as planned; for instance, the patch management system only successfully completes on 490 of the 500 production systems, leaving 10 systems in a vulnerable and insecure state. 408.656.2498 omoreno@hotmail.com 34
  • Requirement 6: Develop and maintain secure systems and applications To mitigate this risk, we must ensure that planned and scheduled changes are deployed completely, accurately and within the specified timeframe. To do this we must: • Have a change calendar (or “forward schedule of change” in ITIL language) of authorized and scheduled changes • Detect all changes on production computing systems • Be able to detect when scheduled changes were not implemented properly (i.e., a scheduled patch was not deployed completely, accurately, or within in the required timeframe) 408.656.2498 omoreno@hotmail.com 35
  • Requirement 11: Regularly test security systems and processes “Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.” PCI DSS requires that all computing systems, computing system components, processes, and system software are adequately secured. Achieving this requires that we first test components for correct functionality and vulnerabilities, and then ensure tested components have not changed in a way that would invalidate previous testing results. 408.656.2498 omoreno@hotmail.com 36
  • Requirement 11: Regularly test security systems and processes The second element, ensuring that change doesn’t invalidate these certification and test results, is what is specified by PCI DSS Requirement 11.5, which requires organizations to “deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.” In order to fulfill this requirement, we must: • Detect all changes made to any computing systems that support the front- end and back-end processes involved in credit card processing and to any computing systems that store cardholder data. • Have a workflow that ensures management signs off on approved changes. • Have a manual or automated means of reconciling detected changes with authorized changes to validate that all changes made were indeed authorized. 408.656.2498 omoreno@hotmail.com 37
  • Questions Orlando Moreno omoreno@hotmail.com 408.656.2498 408.656.2498 omoreno@hotmail.com 38