These materials are © 201 - WhiteHat Security · These materials are John Wiley & Sons, Inc. Any dissemination, distribution, or unauthoried use is strictly prohibited. PCI DSS Compliance

These materials are © 2016 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.


PCI DSS Compliance

by Susan Cook

WhiteHat Security Special Edition


PCI DSS Compliance For Dummies®, WhiteHat Security Special Edition

Published by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030‐5774 www.wiley.com

Copyright © 2016 by John Wiley & Sons, Inc., Hoboken, New Jersey

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permissions.

Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trade-marks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other coun-tries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

ISBN 978‐1‐119‐18600‐7 (pbk); ISBN 978‐1‐119‐18602‐1 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

For general information on our other products and services, or how to create a custom For Dummies book for your business or organization, please contact our Business Development Department in the U.S. at 877‐409‐4177, contact [email protected], or visit www.wiley.com/go/custompub. For information about licensing the For Dummies brand for products or services, contact BrandedRights&[email protected].

Publisher’s Acknowledgments

Some of the people who helped bring this book to market include the following:

Development Editor: Elizabeth Kuball

Copy Editor: Elizabeth Kuball

Acquisitions Editor: Amy Fandrei

Editorial Manager: Rev Mengle

Business Development Representative: Karen Hattan

Production Editor: Antony Sami

http://www.wiley.com

http://www.wiley.com/go/permissions

mailto:[email protected]

http://www.wiley.com/go/custompub

mailto:BrandedRights&[email protected]


Introduction

If your business has anything at all to do with credit card processing, you need to be aware of the secu-

rity requirements identified in the PCI Data Security Standards. A successful data breach that results in an exposure of customer payment card information can lead to significant financial damage, both from the breach itself and from future consequences. Compliance with the data security standards reduces this risk.

About This BookThis book provides an overview of the PCI Data Security Standards, and gets more in depth on the requirements for web application security.

Foolish AssumptionsI’m assuming that you’re affiliated in some way with an organization that has a part in processing credit card transactions. I’m also assuming that you’re familiar with basic information technology and information security principles. As such, this book is written primarily for people who fit that profile and who are interested in potential new solutions for improving their compliance with PCI Data Security Standards. But don’t worry — even if you don’t completely fit that profile, this book will still be understandable.


Icons Used in This BookThroughout this book, from time to time you will see icons that call attention to important information. Here’s what you can expect:

This icon points out information you should try your hardest to remember. In other words, it’s important!

Even though this is a For Dummies book, sometimes there’s no choice but to get techni-cal. If you see this icon, it means an explana-tion for anything overly technical or jargon‐y.

Pay attention! Not only will this book educate you, but it will also provide helpful suggestions.

These alerts offer you a heads‐up to help you avoid situations that may result in potentially costly errors.

2


Understanding PCI DSS

In This Chapter▶▶ Looking at the origins of PCI DSS▶▶ Reading the standards▶▶ Understanding how applicability is determined▶▶ Assessing risk to businesses and customers

In this chapter, I provide background on the data security standards, discuss applicability, and touch

on risk.

Exploring the Data Security StandardsAt 115 pages, PCI DSS v3.1 is hardly light reading. Fortunately, the document itself is a searchable PDF with embedded links in the table of contents. In this section, I review important terminology, discuss the origin of these terms, and provide insight into navigat‑ing the document.

Chapter 1

4


Understanding the terminologyAlthough you won’t usually see industry jargon in a For Dummies book, this book covers technical standards that use a specific vocabulary. Familiarizing yourself with some of the more important terms will help you understand the information in this book as well as in the PCI Data Security Standards.

You will see these terms often:

✓ Payment card brand: Simply put, this is the type of payment card, such as MasterCard or Visa. You may have also heard it referred to as a credit card network.

✓ Issuer: This is the entity that issues the payment card. Generally, it’s a bank. Some payment card brands, such as American Express and Discover, issue their own cards.

✓ Merchant: Any entity that accepts payment cards for goods and/or services.

Exploring the originsIt was not long after payment transactions began being conducted over the Internet that online credit card fraud became a big problem. By the early 2000s, each of the major payment card brands had developed its own set of security guidelines. As you might expect, it was very difficult for anyone to become compliant with five different sets of guidelines.

In response to the lack of compliance and the increase in data breaches, five major payment card brands col‑laborated on a single, unified set of security standards.

5


This collaboration led to the release of PCI DSS 1.0 in December 2004. In September 2006, the PCI Security Standards Council was created. The PCI Security Standards Council consists of the five major payment brands listed earlier in this section, as well as industry stakeholders. The council is a regulatory body in that it sets and manages the standards; however, enforce‑ment is left up to the individual payment card brands.

You can find more information about the PCI Security Standards Council on their website at www.pcisecuritystandards.org.

Navigating the standardsPCI DSS has 12 high‐level requirements covering the following categories of security controls:

✓ Network and system security

✓ Cardholder data protection

✓ Vulnerability management

✓ Access controls

✓ Monitoring and testing

✓ Information security policies

Each requirement is further broken down into discrete sub‐requirements. The document itself is designed to aid in assessing compliance by providing guidelines and testing procedures for each sub‐requirement. Clarification and definitions are also provided in some areas. Figure 1‑1 shows the basic layout for each requirement.

http://www.pcisecuritystandards.org

6


In addition to the requirements, PCI DSS contains addi‑tional information to assist you with the following activities:

✓ Determining applicability

✓ Determining the scope of an assessment

✓ Incorporating compliance into normal business activities

✓ Using compensating controls when specific compliance objectives cannot be met

You can view the current version of PCI DSS at www.pcisecuritystandards.org/security_standards.

Determining Applicability to Your BusinessFirst and foremost, you must realize that PCI‐DSS applies to every aspect of credit card processing. So, if

Figure 1-1: PCI DSS Requirement Layout

https://www.pcisecuritystandards.org/security_standards

https://www.pcisecuritystandards.org/security_standards

7


your business has anything to do with credit card processing, the question you should be asking is not, “Does PCI‐DSS apply?” but rather “What parts of PCI‐DSS apply?”

This question can be answered by looking at how credit card transactions are processed.

Processing transactionsThe way a business processes payment cards is gener‑ally determined by the way it interacts with customers, such as in person, online, via phone, or through the mail. A business that interacts with customers in multiple ways may use multiple methods of processing payment cards. Several of the most common methods are described in the following sections.

Credit card terminalsTerminals read the card’s magnetic stripe or chip. With terminals, each transaction may be processed individu‑ally, or transaction information may be saved and pro‑cessed in bulk. Terminals may transmit data over telephone lines, wired network connections, or wire‑less network connections.

Credit card imprintersProcessing through an imprinter requires the physical card be placed in a device that uses pressure to imprint the information on the front of the card onto a slip for processing by the merchant’s bank.

Mobile payment devicesThese card readers attach to a mobile device such as a smartphone or tablet. A mobile app collects and trans‑mits the information for processing over a cellular or wireless network.

8


Online paymentsWhen buying goods or services online, the credit card information is generally entered into a form and trans‑mitted to the merchant or a service provider for pro‑cessing. Shopping cart software and third‐party marketplaces such as auction sites are common types of online payment options.

Paper formsMerchants may receive credit card data via paper forms. This is often the case when a customer wants to pay for services with a credit card and has received a statement in the mail. The customer provides the pay‑ment card information and returns it to the merchant.

Payment enabled softwareSome software applications have payment processing capabilities built in. This is often seen with fundraising and membership software where payments are taken by telephone.

Point of sale (POS) solutionsPOS solutions combine a cash register and credit card terminal into a single device for faster processing. They may also connect to a company’s inventory control system or other software.

Applicability in high‐profile industriesApplicability may also be determined by industry, but not because there are industry‐specific requirements. Rather, certain industries are prone to activities that determine applicability. You will see in the following sections that it can be very complicated for certain types of industries.

9


RetailThese are entities that sell goods and services to con‑sumers. Sales may take place in a variety of venues, including the following:

✓ In stores

✓ Over the phone

✓ Online through e‐commerce sites

✓ Online through mobile applications

✓ In temporary locations

HealthcareInformation security in the healthcare industry is regu‑lated by the Health Insurance Portability and Accountability Act (HIPAA). HIPAA security and pri‑vacy requirements were developed to protect patient health information, not financial information. Although some of the requirements are similar, they aren’t inter‑changeable, and being HIPAA compliant does not auto‑matically make an entity PCI DSS compliant.

If you’ve ever been to a hospital or large medical facil‑ity you may have noticed that there are many opportu‑nities for payment. These typically include the following:

✓ Patient payments: Payments may be taken at check‐in desks, billing offices, online, over the phone, or even bedside.

✓ Other goods and services: This includes, but is not limited to, gift shops, cafeterias, pharmacies, and parking garages.

✓ Fundraising: Donations may be solicited in person, online, over the phone, and at fundraising events.

10


Financial institutionsPCI DSS compliance for financial institutions is not as straightforward as for the retail industry. They perform many tasks related to payment card processing, which means an individual financial institution could assume one or more of the following roles:

✓ Merchant: If the institution accepts payment cards for goods or services such as safe deposit boxes, it is a merchant.

✓ Issuer: If the institution issues payment cards that are branded with MasterCard or Visa logos, it is an issuer. This includes branded debit cards.

✓ Acquirer: If the financial institution processes payment card transactions on behalf of mer‑chants, it is an acquirer.

Service providersWith regard to PCI DSS, a service provider is an entity that stores, processes, or transmits cardholder data for merchants. Service providers include, but are certainly not limited to, entities that perform the following services:

✓ Third‐party payment card processing

✓ Web hosting

✓ Loyalty programs

✓ Credit bureaus

✓ Shopping carts

✓ Fraud and chargeback investigation

✓ Records management

11


Recognizing the Risk to Your Business and Your CustomersYour customers are entrusting you with their payment card information and this should not be taken lightly. Failure to protect this information could result in iden‑tity theft, theft of funds, and a good deal of inconve‑nience for the customer.

Data breach notification laws require that individuals be notified when their information has been stolen. Although that notification may not always happen in a timely manner, when it does happen the customer is going to associate the negative impacts with your business.

This leads to lost revenue from impacted customers as well as from potential customers that are now wary of trusting your business with their payment card information.

Other direct financial impacts to a business include the cost of

✓ Customer notification

✓ Credit monitoring for affected customers

✓ Investigation into the cause of the breach

✓ Remediating the vulnerabilities

12



Reviewing Compliance Requirements

In This Chapter▶▶ Defining and locating cardholder data▶▶ Protecting cardholder data in storage and transmission

▶▶ Protecting systems against malware▶▶ Applying security patches▶▶ Separating application environments

I n this chapter, I discuss requirements that address protection of cardholder data and maintaining a

secure environment.

Protecting Cardholder DataPCI DSS requirements 3 and 4 focus on protecting card-holder data in storage and transmission. Before I go into the specifics of the requirements, you need to under-stand exactly what constitutes cardholder data and how it’s different from sensitive authentication data.

Chapter 2

14


Identifying cardholder dataAccording to PCI DSS, cardholder data includes the following information:

✓ The primary account number (PAN)

✓ The cardholder’s name

✓ The card’s expiration date

✓ A three‐digit service code

This information is stored on the physical card itself, on the magnetic stripe, and in some cards in an embed-ded chip. In the following sections, I fill you in on the data that can be found in each of the three interfaces.

PhysicalThe card itself contains the cardholder name, PAN, expiration date, and card verification value (CVV). The CVV is the three‐digit code found on the back of the card to the right of the signature line. This is consid-ered sensitive authentication information and cannot be stored, although it can be collected and used in processing.

Magnetic stripeThe magnetic stripe has three tracks, referred to simply as Track 1, Track 2, and Track 3. Track 2 is in American Banking Association (ABA) format and is used most often. Track 1 uses International Air Transport Association (IATA) format and contains additional data. Track 3 is not commonly used and is outside the scope of this book.

Both Track 1 and Track 2 contain the following information:

15


✓ PAN: The primary account number is a maximum of 19 digits.

✓ Country code: On some cards, a three‐digit coun-try code is stored.

✓ Expiration date: The card’s expiration date is stored in the format YYMM.

✓ Service code: A three‐digit service code that indi-cates where the card can be used

✓ Discretionary data: This data is for use by the card issuer.

Track 1 also contains the cardholder’s name, a country code, and a format code. The full contents of the mag-netic stripe is considered sensitive authentication infor-mation and cannot be stored as part of processing.

Standards for magnetic stripesThe structure and contents of a payment card’s magnetic stripe are governed by international standard ISO/IEC 7813, which is maintained by International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). The current version of this standard is ISO/IEC 7813:2006. It was last reviewed in 2013 and is subject to a five‐year review schedule. The third track of a card’s magnetic stripe is also governed by ISO/IEC 4909:2006, also reviewed in 2013.

Organizations developing applications to process payment cards should be familiar with this standard.

16


EMV chipNewer payment cards may store data on an EMV chip. EMV is an acronym of Europay, MasterCard, and Visa, the three companies that created the standard used by the chips. Instead of swiping the card through a reader, the card is inserted into the reader or read from a short distance away.

Generally, the cardholder name is not stored on the chip and the CVV is dynamic for additional security. This CVV is sensitive authentication data, as is the full dataset stored in the chip.

Protecting data in storageThe importance of protecting stored cardholder data cannot be stressed enough. In fact, it’s important enough that PCI DSS Requirement 3 contains 22 sub‐requirements for data storage. These requirements are summarized as follows:

✓ Data retention and disposal: Data retention and disposal policies, procedures, and processes should ensure that only the appropriate data is stored for a minimal amount of time and deleted securely when no longer needed. There must also be a process for identifying and deleting data past its retention period.

✓ Sensitive authentication data: The full contents of a track on the magnetic stripe or of the chip, the CVV, and a customer’s personal identification number (PIN) cannot be stored after the card has been authorized. Card issuers and certain types of service providers may store this information only if there is a legitimate business need.

17


✓ PAN display: When displayed, the PAN must be masked so that no more than the first six and the last four digits are visible. This applies to receipts, computer screens, and other records for which the entire PAN is not necessary.

✓ PAN storage: The PAN must be unreadable in storage, regardless of storage media. Simply put, you cannot store it in plain text. It can be ren-dered unreadable using various methods of strong cryptography or by storing only a truncated por-tion of the PAN. I discuss encryption further in the next section.

Encrypting the PANThere are various methods of strong cryptography that can be used to render the PAN unreadable.

HashesHashing is a form of one‐way encryption, so it should only be used when the original number does not need to be retrieved. Adding a random value increases the security of a hash and is referred to as salting.

Even with salting and strong cryptography, hashes are still vulnerable because PANs are predictable.

Index tokens and padsThis method uses a randomly generated single‐use pri-vate key (the pad) to encrypt the PAN. Each character of the PAN is combined with the corresponding charac-ter in the key. The pads must be stored securely.

18


Disk encryptionIt is often easier to encrypt an entire disk, particularly removable media, than to encrypt individual files or database columns, which is generally preferred. Although disk encryption is allowed, it cannot be based on operating system or general network credentials. A separate management solution is required.

Key managementThe purpose of key management is to manage a key through its lifecycle, from generation to expiration. Keys must be generated using strong cryptographic methods and expire after a certain period of time.

Keys must be stored in a compliant form at all times and in as few places as possible. Access to keys should be highly restricted. Only individuals charged with managing keys really need access.

There are three compliant forms of key storage:

✓ Encrypted with a key‐encrypting key at least as strong as the keys being protected

✓ In a secure cryptographic hardware device

✓ Broken up into at least two components or shares

In addition to being stored securely, they must be dis-tributed in a secure manner only to those that require access to them. These individuals are designated as key custodians and must formally acknowledge their responsibilities.

19


An excellent resource for key management, as well as encryption in general, is the National Institute of Standards and Technology (NIST) Computer Security Division. Its website is http://csrc.nist.gov.

Protecting data in transmissionPCI DSS Requirement 4 addresses transmission of card-holder data over open, public networks such as the Internet, wireless, Bluetooth, and cellular networks. Encryption is explicitly required for cardholder data, and secure communication protocols must be used.

SSL and early versions of TLS are no longer considered strong cryptography. Current users have until June 30, 2016, to migrate to a more secure form of transmission, such as newer versions of TLS and SSH. New imple-mentations may not use them.

Secure transmission protocols may rely on certificates to verify the identity of the communicating hosts. These certificates must be issued by a trusted source, not be expired, and be associated with the host provid-ing them.

Maintaining Secure EnvironmentsCardholder data is only as secure as the environment in which it is processed. In addition to securing the data itself, you must also ensure that its environment is secure.

http://csrc.nist.gov

20


Protecting against malwareRequirement 5 addresses the importance of protecting systems from malware. This does not mean to only install antivirus software on systems that directly store, trans-mit, or process cardholder data, but also on systems in the same domain or network as the cardholder data.

The specific wording used by Requirement 5 is “commonly affected by malicious software.” Because this leaves room for interpretation, you’re also required to keep up with current trends and periodically evaluate whether these systems can continue to be without antivirus software.

The antivirus software must be able to detect, remove, and protect against various types of known malware including, but not limited to, viruses, worms, Trojans, key loggers, spyware, rootkits, and adware.

Not all antivirus software is appropriate for an environment that must be PCI compliant. Be sure to perform proper due diligence and select a suitable solution.

The following activities are also required:

✓ Regular updates to the antivirus software

✓ Periodic scans of systems

✓ Retention of scan and other audit logs

✓ Security controls preventing users from disabling or altering the software

Protecting against known vulnerabilitiesMalicious individuals and criminal organizations are constantly trying to discover application vulnerabilities

21


that will allow them to access sensitive data. As such, vendors regularly develop and release security patches to fix known vulnerabilities. Requirement 6.2 states that these patches must be applied in a timely manner to reduce the risk that known vulnerabilities will be exploited. The deadline for applying critical security patches is one month from release date.

Separating application environmentsThe separation of development and test environments from the production environment is addressed in Requirement 6. Development and tests environments are often less secured than production environments and if not properly separated, a successful exploit in development could result in compromised cardholder data. Separation may be logical, such as through VLANs, or physical, by using a separate network entirely.

The following requirements fall under separation of development/test and production environment:

✓ Remove test and development data and user accounts from production systems.

✓ Disallow production data in development and test environments.

✓ Ensure access controls are appropriate for each environment.

✓ Restrict the number of people with access to the production environment.

Policies, procedures, and processes that enforce these requirements are generally part of the application development process, which I discuss in more depth in Chapter 3.

22



Developing and Maintaining Secure Web Applications

In This Chapter▶▶ Looking at secure coding practices▶▶ Understanding identity and authentication▶▶ Addressing common coding vulnerabilities▶▶ Maintaining security through change control, testing, and monitoring

I n this chapter, I discuss PCI DSS requirements for application development, maintenance, monitoring,

and testing.

Reviewing High‐Level Development RequirementsSecure application development starts with a defined software development lifecycle (SDLC) or similar soft-ware development process. PCI DSS does not require the use of a particular methodology, so you’re free to select the most appropriate one or develop your own,

Chapter 3

24


as long as your selected methodology incorporates information security in all phases.

This requirement applies to software devel-oped in‐house and software developed for an entity by a third party.

Application development must also follow industry standards and best practices. Specific techniques for avoiding common coding vulnerabilities vary based on the development platform, but generally the same prin-ciples apply. I discuss common coding vulnerabilities and code review later in this chapter.

Additionally, the application itself must be compliant with applicable PCI DSS requirements. Requirements for secure storage, transmission, and display of cardholder data can be found in Chapter 2. I discuss requirements for identity and authentication in the next section and requirements for logging later in this chapter.

Looking at Identity and AuthenticationRequirement 6 specifically includes web‐based admin-istrative access to applications within its scope. Because users of this type of web application would be non‐consumer users, Requirement 8 applies.

Identifying usersAll non‐consumer users and administrators must have a unique identifier, such as a logon ID, in order to

25


access the application. The reason for this is twofold. First, it ensures that access to the application and card-holder data can be traced back to a specific individual. Second, it allows appropriate access controls to be applied to individuals.

Instead of applying access controls to individ-ual users, apply access controls to roles and associate individuals with roles. This is referred to as role‐based access control.

The following requirements also apply to non‐consumer user accounts:

✓ Creation, deletion, and modification of user accounts must be strongly controlled.

✓ Accounts belonging to terminated employees must be revoked as soon as possible.

✓ Accounts that have not been used in 90 days must be removed or disabled.

✓ Vendor accounts must be enabled only when needed and monitored when in use.

✓ No more than six attempts should be allowed before an account is locked out for no less than 30 minutes.

✓ Sessions must time out after no more than 15 minutes.

Authenticating usersThe purpose of authentication is to validate a user’s identity before allowing access to a system. A user ID in

26


combination with one or more of the following factors is sufficient for validation under Requirement 8:

✓ Something you know: This can be a password or a passphrase. It must be at least seven characters long and contain both letters and numbers. Additionally, it must be changed at least every 90 days, and the system should remember at least the last four passwords to prevent reuse.

✓ Something you have: This could be a token, smart card, or certificate. Each item must be assigned to a single user and never shared.

✓ Something you are: This is some type of biomet-ric, such as a fingerprint or retinal pattern.

Authentication credentials must be passed to the appli-cation securely, using strong encryption, so that a password or other credential is protected from inter-ception by malicious attackers. Strong encryption must also be used for credential storage.

Single‐factor authentication is sufficient for regular use, but two‐factor authentication is required for third parties and login requests originating outside the network.

Authenticating applicationsSometimes applications need to verify their identity, such as when they access a database. Applications have their own unique IDs and authentication creden-tials. PCI DSS restricts the use of these credentials to the application only, which means that a user cannot authenticate using the same credentials.

27


Only database administrators can directly access the database; all other users must access the database through the application or other programmatic means.

Modifying credentialsAll three of the authentication factors discussed earlier in this section suffer from a similar weakness: They can all be lost in some fashion. Passwords can be forgotten, tokens can be lost, and, tragically, body parts used in biometric identification can be damaged.

This requires system administrators or customer ser-vice representatives to modify the credentials in some way, such as resetting a password, issuing a new token, or letting the user select a different finger to use, to allow the user to log in to the system again.

If the credential to be reset is a password or pass-phrase, it must be set to a unique value and the system must require the user to change the password upon next login. This requirement also applies to temporary passwords issued at account creation.

User identity must be verified by alternate means before any type of credential modification. This may include answering a secret question or verifying other informa-tion that would only be known to the proper user.

Addressing Common VulnerabilitiesPCI DSS identifies common coding vulnerabilities that must be addressed during application development. In this section, I provide a high‐level explanation of each flaw and some suggestions for prevention.

28


Injection flawsMalicious attackers can inject their own data into an application as part of a query, command, or any place in an application that accepts user input. By doing so, the attacker can execute code that can compromise the confidentiality and integrity of application data, as well as availability of the application.

Common types of injection attacks include, but are not limited to, SQL injection, command injection, and log injection.

The primary defense against SQL injection attacks is query parameterization. Other forms of injection can be mitigated by encoding, input validation, and sanitization.

Buffer overflowsBuffer overflow occurs when input overruns allocated memory space and spills over into other memory loca-tions. This can lead to application errors, execution of malicious code, and even denial of service.

Languages such as Java, C#, and Python are not sus-ceptible to buffer due to built‐in memory protections. Buffer overflows can also be prevented by validating the size of the buffer before writing to it and truncating input to match the size of the buffer.

Insecure cryptographic storage and communicationWeak cryptographic mechanisms can lead to compro-mised data, which is why PCI DSS requires strong cryp-tography be used. Because what is considered “strong” is subject to change, it is possible for applications

29


using legacy code to use weaker encryption mecha-nisms that were once considered strong.

For example, SSL is no longer considered secure, and applications that rely on SSL are at risk of being exploited.

And let’s face it, cryptography can be difficult to under-stand and implement properly. Code review, which I discuss later in this chapter, can help identify crypto-graphic flaws.

Improper error handlingDevelopers need detailed error messages, and so do malicious attackers. Detailed error messages can reveal information about the operating environment, applica-tion configuration, and application architecture. As such, they should stay in the development and test environment.

Even error messages designed to help users use the system properly can be detailed enough to be useful to attackers. Messages like “User ID does not exist” or “Incorrect password” should be replaced with more generic error messages that do not tell an attacker what part of the input was correct.

Cross site scripting (XSS)XSS flaws are similar to injection flaws in that they’re the result of non‐validated input. But instead of execut-ing queries or commands on the web server, XSS exploits execute code in a user’s browser while making it appear to come from the vulnerable web application. This can result in compromised data or even compro-mise of the user’s computer.

30


There are multiple variations of XSS, and mitigation techniques can be quite intricate, but in general, con-textual encoding is needed to render attacks inert on a web page.

Improper access controlThere are several types of access control flaws, includ-ing access to objects, functions, and web pages. This occurs when applications do not authenticate users properly or do not properly enforce access controls throughout the system. For example, in a poorly designed application a user may be able to bypass access controls by accessing a page directly instead of through a menu system.

This can be prevented by enforcing access controls in both the presentation layer and the business logic of the application and ensuring users are properly authenticated and authorized throughout the application.

Cross site request forgery (CSRF)CSRF takes advantage of insecure authentication and authorization mechanisms to trick vulnerable websites into accepting authentication credentials from the browser instead of from the user. In this type of attack, a user clicks a malicious link that both authenticates with stored credentials, such as in a cookie, and performs an action.

This type of attack can be prevented through the use of secure coding techniques that do not allow authentica-tion credentials to be submitted automatically by browsers.

31


Broken authentication and session managementSeveral coding flaws allow malicious attackers to hijack user sessions and compromise account credentials. This includes, but is not limited to, exposing session IDs in URLs, not expiring sessions properly, and not flagging cookies as secure, forcing them to be sent through an encrypted connection.

Prevention includes designing secure authentication methods and session management schemes.

Identifying New Security VulnerabilitiesPCI DSS requires that organizations have a process in place to identify, prioritize, and address newly discovered security vulnerabilities.

New vulnerabilities are announced regularly by ven-dors, industry communication channels, and research organizations. Vulnerabilities are also discovered by malicious individuals and criminal organizations, but once in a while they’re researched and published by more reputable sources.

New vulnerabilities may be identified as low, medium, or high risks, based on the likelihood that the vulnera-bility will be exploited and the impact if it is exploited. Likelihood and impact vary based on industry and operating environment.

32


Following Change Control ProceduresChange control procedures are used to manage the risk associated with system changes such as security patches and software modifications.

A compliant change control process includes the following:

✓ Documented impact: The impact of the change must be identified and then documented so those affected by the change can make any appropriate changes to their processes.

✓ Documented approval: All changes must be approved by authorized individuals. This varies by company and by industry, and may be depen-dent upon local security policies and other regula-tory or legal mandates.

✓ Testing: In addition to standard testing for func-tionality, you must also verify through testing that security is not negatively impacted and the system will be PCI DSS compliant after the change.

✓ Backout/rollback procedures: Because you can always count on the unexpected, every change must have a backout plan. If something goes wrong, the system needs to be restored back to its previous functional, secure state as quickly as possible. Exactly how that is done is very depen-dent upon the operating environment.

Change control also encompasses separation of devel-opment and test environments from production envi-ronments, which I discuss in Chapter 2.

33


Reviewing CodeCode review is an integral part of both application development and change control. As part of the SDLC, code is reviewed for vulnerabilities and compliance with secure coding practices. As part of a change con-trol process, code review results are reviewed as part of the approval process.

Much like the inability to effectively proofread your own documents, you cannot effectively review your own code. Code must be reviewed objectively by other qualified individuals in order for the review to be effec-tive and compliant.

Errors or vulnerabilities that are identified during code review must be corrected prior to release.

Testing and MonitoringIn this section, I discuss the requirements for testing and monitoring as they apply to web applications. Additional testing and monitoring requirements apply to other system components and the network itself, but are outside the scope of this book. If you’re interested in those, you should review PCI DSS requirements 10 and 11.

TestingThere are two types of testing required by PCI DSS that apply to web applications: vulnerability scanning and application layer penetration testing.

Vulnerability scanningVulnerability scanning refers to tools, techniques, and methods that identify vulnerabilities on network

34


devices and servers. They can be automated, manual, or a combination of the two. Vulnerability scans directed at servers running or supporting web applica-tions can reveal vulnerabilities that may be exploited through the application.

Scans must be performed on internal network resources quarterly by qualified personnel and on external network resources by approved scanning vendors.

Penetration testingPenetration tests simulate attack scenarios and deter-mine just how far a malicious attacker would be able to penetrate a target system. It is a mostly manual pro-cess, although some tools may be used, and it requires a complex set of skills. For penetration testing to have any value, it must be performed by a qualified entity that could be internal to the organization or a third party.

PCI DSS requires that both internal and external pene-tration testing be performed annually and after signifi-cant changes to an application or its operating environment. Identified exploitable vulnerabilities must be corrected and the systems retested.

MonitoringMonitoring is addressed by Requirement 10 and gener-ally involves automating the logging of auditable events such as the following:

✓ User access to cardholder data

✓ Actions taken by privileged accounts

✓ Invalid login attempts

35


✓ Changes to accounts

✓ Creation and deletion of system‐level objects

For each of these events, the audit trail must include at a minimum the user involved, type of event, date and time, success or failure, origin of the event, and affected resource.

Additionally, access to the audit trails themselves must be carefully restricted, secured, and monitored. Requirements include the following:

✓ Restricting who can view logs

✓ Preventing unauthorized modification

✓ Backing up logs to a secure internal location

✓ Alerting when logs are changed

Logs and security events related to critical system components, security functions, and systems that store, process, or transmit cardholder data or sensitive authentication data must be reviewed daily.

36



Planning Compliance Strategies

In This Chapter▶▶ Looking at usage policies▶▶ Focusing on security awareness▶▶ Assessing risk▶▶ Identifying training requirements▶▶ Considering third‐party solutions

In this chapter, I discuss the components of a PCI DSS compliant security policy, the importance of

training developers and other personnel, and the use of third-party solutions to achieve compliance.

Creating a Compliant Security PolicyWhen you read the standards, you see a common theme over and over again: documented security policies and procedures that are distributed to

Chapter 4

38


affected parties. This is because a security policy is the foundation of an entity’s security program.

Requirement 12 addresses the specific policy compo-nents that must be developed, published, maintained, and reviewed at least annually. I summarize these components in the following sections.

Usage policiesUsage policies, sometimes referred to as acceptable use policies, serve two purposes. First, they explicitly allow or prohibit use of particular technologies. Second, they provide guidance for acceptable use and implementation of particular technologies.

Usage policies include the following required components:

✓ An approval process for implementation and use of technologies

✓ Authentication requirements to ensure that only authorized individuals have access to critical systems and cardholder data

✓ A listing of technologies covered by the policy, approved products, and approved locations for installation

✓ A listing of personnel authorized to access vari-ous technologies

✓ Acceptable uses

Additionally, the policy must specifically require the following controls:

39


✓ Sessions must be automatically disconnected after a specific period of inactivity

✓ Remote access for third parties are activated only when needed

✓ Storage of cardholder data is prohibited on local hard drives and removable media unless explicitly authorized and appropriately protected.

Risk assessmentThe policy must include provisions for a security risk assessment process that is performed at least annually and after significant changes. As part of the risk assess-ment, you’ll identify vulnerabilities in and threats to critical assets, particularly those that store, process, and transmit cardholder data.

This information is then combined with knowledge from reputable sources to determine the likelihood of a vulnerability being exploited or a threat realized. This likelihood and the impact that follows can be used to prioritize risk mitigation efforts.

Identification of responsible partiesThe policy must identify appropriate security roles and responsibilities for all personnel. With a few excep-tions, these roles and responsibilities are left up to the organization.

Responsibilities for information security management are explicitly defined by PCI DSS and require formal assignment in the security policy.

40


Security awarenessA formal security awareness program is required to raise awareness of cardholder data security require-ments. This program must include provisions for edu-cation of employees at hire and at least annually, as well as formal acknowledgement that they have read and understood the security policy and procedures.

Ideally, the awareness program should contribute to a culture of security in which each employee fully under-stands the importance of protecting cardholder data.

Other requirementsOther policy‐related requirements include the following:

✓ Personnel screening to reduce the risk of insider threats

✓ Management of service providers that includes formal documented acknowledgement of card-holder data security requirements

✓ Incident response planning and procedures

Training PersonnelApplication development is a complicated and complex process even without considering security require-ments. When security requirements are added, special-ized advanced training is warranted. It is also required for compliance with Requirement 6.5.

There is no restriction on how training should be per-formed, so organizations may choose a method that is effective and appropriate for their environment.

41


Application development managers having difficulty getting budget approval for developer training may want to present training as a risk mitigation activity. Properly trained coders introduce fewer vulnerabilities into applications and reduce the risk of impact to confidentiality, integrity, and availability of applications and data.

Training opportunities also exist for other personnel as well. As I mention earlier in this chapter, individuals may be assigned specific security responsibilities. Depending on their knowledge, these individuals may need specific training in order to perform their duties effectively.

You may recall that I discussed vulnerability scanning and penetration testing in Chapter 3. PCI DSS require-ments allow for some in‐house scanning and penetra-tion testing, provided they are performed by qualified personnel. Depending on the size of the organization, it may be beneficial to train existing personnel to perform those tasks.

Deploying Third‐Party SolutionsPCI DSS allows for and in some cases encourages the use of third‐party services and solutions to assist with meeting compliance requirements.

42



Ten Ways WhiteHat Sentinel Can Help Maintain Secure

Web Applications

H ere are ten ways WhiteHat Sentinel can improve PCI DSS compliance by maintaining secure web

applications:

✓ Continuous assessment methodology: Sentinel uses a continuous assessment methodology that constantly scans both internal and public websites for vulnerabilities and will tell you very quickly if your remediation activities were successful. This type of scanning meets Requirement 6.6.

✓ Easy to deploy and scale: Because Sentinel is offered as software as a service, it’s very easy to deploy and scale. No additional hardware or soft-ware is needed, which is important in today’s environment of limited resources.

✓ Unlimited access to web security experts: Sentinel includes access to WhiteHat’s Threat Research Center (TRC). The TRC’s expertise in verifying vulnerabilities means that less developer

Chapter 5

44


time is wasted dealing with false positives, and cardholder data is better protected by elimination of false negatives. The TRC also provides guid-ance on remediation.

✓ Integrates with web application firewalls: When Sentinel discovers a vulnerability, the web appli-cation firewall policies can be updated with explicit rules provided by Sentinel. This acts as a “virtual patch” that protects the system while giving developers time to fix the vulnerability.

✓ Source code scanning: As a Static Application Security Testing solution, Sentinel Source can directly assess source code for vulnerabilities, which improves the rate at which vulnerabilities can be fixed. More important, it catches common coding vulnerabilities identified in Requirement 6 before they make it into production!

✓ Application layer penetration testing: Sentinel PE fulfills the requirement for application layer pene-tration testing identified in Requirement 11, in a much more cost‐effective manner than trying to maintain a qualified penetration tester on site.

✓ Integration and data sharing: Sentinel integrates with other leading industry solutions through an application programming interface (API) based on open XML technology. This allows Sentinel vulner-ability data to be shared with risk management tools, security information and event management products, and bug tracking systems. This improves access to data for developers, security personnel, and executives, allowing website vulnerability remediation to be fast‐tracked.

45


✓ Safe for production environments: TRC members analyze production web applications to customize testing in production environments. Testing focuses on safety first, such as through the use of benign injections, and does not degrade performance.

✓ Improved SDLC: Sentinel can identify and remedi-ate web application vulnerabilities across all SDLC phases.

✓ Enhance developer skills: Because developers are provided with rapid feedback, including reme-diation recommendations, they can learn from the product and write more secure code.

46



WILEY END USER LICENSE AGREEMENT

Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

http://www.wiley.com/go/eula

Documents

These materials are © 201 - WhiteHat Security · These materials are John Wiley & Sons, Inc. Any dissemination, distribution, or unauthoried use is strictly prohibited. PCI DSS Compliance