Chapter 6
Strong Access Controls
Information in this chapter:
• Which PCI DSS Requirements are in this Domain?
• What Else Can You Do to Be Secure?
Access controls are fundamental to good security in almost any situation. We put locks on our cars and homes to restrict access to them to only authorized parties—presumably those with keys. We put passwords on computer accounts to protect them. In this chapter, we describe some basic security principles and approaches that should be understood and implemented any time access control systems are implemented—not just for PCI DSS. By understanding these basic principles, you will find it easier to make decisions on implementing each proposed access control. After learning a general understanding of access controls, you learn how PCI DSS addresses access controls and the requirements you must meet. Then, you learn about procedures that should be in place and how systems should be configured to enforce PCI compliance. Once you learn about logical access controls, as in locking down access on your systems themselves, you learn about the requirements to physically secure systems and media that contain sensitive information.
Note
Still, many times the easiest way to protect data is not to store it at all. It’s a good idea to review the data you’re keeping and verify that you really need to keep it. Remember, securely deleting the data is MUCH easier than safeguarding it from attackers!
Which PCI DSS Requirements are in this Domain?
You will find references and inferences to access controls littered throughout PCI DSS. Implementing strong access controls is important enough to PCI DSS to have a toplevel heading dedicated to them, as well as three rather beefy requirements (Requirements 7–9). Requirement 7 is the shortest of the three but is probably the most important from a policy and procedure aspect. Requirement 8 delves into many of the technical controls in-scope systems must enforce, and Requirement 9 concentrates on physical security. Before we go into Requirement 7, let’s walk through some of the basic principles of access controls as defined by information security professionals worldwide.
Principles of Access Control
To understand the goals of access controls, it’s important to understand the three pillars of security: confidentiality, integrity, and availability, or sometimes commonly known as the CIA Triad. As you implement access control in your organization, you should always consider how you are meeting or violating these three pillars.
Note
In the last decade, much criticism has come upon the CIA Triad. Opponents of the triad cite that the three pillars do not fully address the basic requirements of the expanding responsibility of information assurance. One of the most notable is the “Parkerian hexad” proposed by information security legend Donn Parker (term coined by M.E. Kabay). Parker argues that the CIA Triad only covers half of the information security pillars. The other three proposed are Possession or Control, Authenticity, and Utility. For the sake of argument, only the basic CIA Triad pillars will be covered here, though other philosophies of information security may be relevant to your organization. CIA Triad might not be enough, but it is a very useful tool for understanding information security.
Confidentiality
The principle of confidentiality means to prevent disclosure of information to parties not authorized to receive it. For PCI DSS, we want to ensure that unauthorized users cannot access cardholder data. This data is defined as the primary account number (PAN), sensitive authentication data, and full track data, but it also includes other information about a cardholder or credit card account that is stored near the PAN. This means that an expiration date stored by itself is not considered cardholder data, but the expiration date stored next to the PAN would.
Aside from PAN data, the main focus of PCI DSS, there are many other types of information we need to block from unauthorized eyes in order to protect cardholder data. Employee passwords or encryption keys are not considered cardholder data but may be used to grant access to such data and should be kept confidential.
Integrity
The principle of integrity is an assurance that data has not been altered or destroyed in an unauthorized manner. You must put measures in place to ensure that data cannot be altered while it’s being stored or while it’s in transit. For example, log data that is collected for PCI DSS monitoring should be stored in a manner that an administrator would know if it had been altered from its original form. Log files are not the only data with integrity requirements. Other data includes files that contain cardholder data, system files, logs, and other critical application files that would be covered under Requirement 11.5.
Availability
The principle of availability means that the data will be accessible to those who need it when they need it. Although the first two pillars are concerned with locking down access, this one is concerned with allowing enough access that those who need the data can get to it. In general, PCI DSS is NOT concerned with the third triad leg—availability. It is presumed that the business would already be concerned about it. Still, availability in PCI context means that employees needing access to cardholder data and other critical information to perform their jobs are granted the necessary access as part of Requirement 7. However, if a security measure—such as data deletion—can make the card data unavailable to attackers, it is a definitely a valid and effective PCI DSS control! As we pointed out elsewhere in the book him, deleting the data is often a much more effective control compared to, say, encrypting it or placing stringer role-based access controls on it.
Note
When using PCI DSS as the foundation for your security program, keep in mind that PCI DSS does not mandate availability of your systems and data.
Requirement 7: How Much Access Should a User Have?
Let’s put the principles of confidentiality, integrity, and availability (despite its somewhat tenuous connection to PCI DSS) into practice. Remember, we want to balance integrity and confidentiality (which both restrict access) with availability (which allows access and enable the business to actually function). To do this, we use the principle of least privilege. This means that we want to give an individual enough access, so they can do their work but no more.
Requirement 7 mandates that all access to cardholder data be restricted by business need-to-know. “Need-to-know” is used by governments to help define what access an individual should be given. Lee is an FBI agent and has Top Secret clearance. He gained this clearance by proving he was trustworthy through extensive background checks and several years of service. Lee is at the end of his career and has been given a boring desk job. Because his case load is fairly light, he decides to look for other Top Secret cases the FBI is investigating. Because of need-to-know, Lee is prevented from browsing through files unrelated to his cases even though he has Top Secret clearance. Unless Lee can convince his superiors that he needs access to such information, he will not be given access.
The same rules should apply in your organization. For example, Sydney’s job as a purchaser is to buy inventory to sell at her company’s store locations. Because her job does not dictate that she should work with customer data, she does not need access to cardholder data and should, therefore, be denied access to it.
Your company must determine exactly what access each user needs. You need to make sure they can access things for their jobs, and they should be automatically locked out of everything else (Requirements 7.1.1 and 7.2.3). Companies typically do this by defining roles and assigning employees to those roles (Requirements 7.1.2 and 7.2.2). The first thing you need to do is determine what access the role needs to do its job. Management must be involved in this process, and a manager should sign off on the access granted (Requirement 7.1.3). The easiest way to accomplish this is to assume that no access is granted, and list the areas or resources that the role must be able to access to perform its job as exceptions. Once the roles are defined, the permissions should be input into the automated access control system (Requirements 7.1.4 and 7.2.1) built into the system where the data transits or is stored.
As you are looking at what access a role needs to complete its job, make a note of any information it will need read access to but not write access. For example, Abigail may need read access to cardholder information to be able to process it for settlement, but she would never need write access to change it. In this case, we would set permissions that would protect the integrity of the information. You should also determine if certain data can be retrieved via other employees when needed. For example, Abigail’s manager may need access to certain financial data only once per quarter. Because Abigail works with this data every day, she could provide a quarterly report to her manager as needed.
Requirement 8: Authentication Basics
Requirement 8 mandates specific controls for individuals who have access to cardholder data as a part of their normal job. This largely sets systems up to be able to comply with Requirement 10, which we cover in Chapter 9, “Logging Events and Monitoring the Cardholder Data Environment.” Each user of the system must be held accountable for his or her actions, and it’s virtually impossible to hold an individual accountable for his or her actions when he or she shares his or her username and password with dozens of coworkers. Without shoulder surfing, screen scraping, other monitoring technology, or high-definition cameras installed on each person’s workspace, we must rely on our systems to help us properly authenticate users.
This starts with Requirement 8.1, giving every user a unique ID before they may access systems in-scope for PCI DSS. Most companies provide unique accounts for things such as network resource access and e-mail, but things fall apart when administrator-level accounts get introduced into the mix. Nearly every system comes with a common administrator or root level account for administrative purposes. Most security best practices instruct administrators to rename and disable that account before the server is placed into production.
TIP
In Windows (especially prior to 2008) it is a best practice to rename the RID = 500 account and set an extremely long passphrase. Activity using this account should not ever occur as administrators should use their own unique accounts. Events from the RID/SID = 500 account can be monitored with a log management system.
This is relatively easy when you have infrastructure such as Lightweight Directory Access Protocol (LDAP) or Active Directory deployed, but it can be a challenge when you have machines that stand alone.
Note
Why do operating system manufacturers insist on continuing the trend of providing a root or administrator user account that has access to the whole system for whatever it wants to do? Poorly developed software with global administrator privileges will surely lead to a root-level compromise, whereby a system is then “pwned” by an attacker. Software that needs elevated privileges must be limited to sandboxes on the servers and should never require administrators to run it under the root-level administrator account. If your vendor tells you it is a requirement, tell them you will be taking your business elsewhere.
Once you have all users working off of unique, individual IDs, you must add some kind of password (or password-like) authentication to it to meet Requirement 8.2! Many security administrators look at this requirement and think, “Well DUH, guys….” The intent of this requirement is to both define acceptable methods of authentication and prod companies to think about more than just a password for their authentication needs. The most common way companies meet Requirement 8.2 is by assigning a password to the unique account. The makeup of the password is described in the section “Password Design for PCI DSS,” later in this chapter. Alternatively, you could use some component of a multifactor authentication solution to access in-scope systems. Multifactor authentication might include a fingerprint reader embedded into your laptop or a certificate installed on your machine. Your assessor asks you to provide documentation on the authentication methods used, as well as performs the authentication for each method documented to ensure design matches reality. We’ll discuss some of those exact settings in the “Windows and PCI Compliance” section of this chapter.
Two-Factor Authentication and Requirement 8.3
Requirement 8.3 mandates at least two-factor authentication for remote users accessing in-scope systems. As of this writing, it is rare to see a company without remote access technologies deployed into its environment. Administrators need remote access to machines in break-fix situations, and general corporate users may need remote access for tasks like responding to e-mail or uploading documents to collaboration products. Not all users need a two-factor solution to comply with this requirement. Remember your scope! Most companies only have a small subset of employees that need this type of authentication. Network and user segmentation is an excellent way to reduce the scope of this requirement, dramatically decreasing the cost and effort required to deploy a solution. Any user (be it an employee, contractor, or other third-party company’s employee or contractor) who is remotely accessing the cardholder data environment must perform a successful two-factor authentication before being granted access to the cardholder environment. If you want to shrink your scope, you could even consider your corporate network semi-trusted, and require local users to use two-factor authentication to access the environment, thus effectively shrinking your PCI DSS scope.
Note
Multifactor authentication does not need to consume your entire Information Technology (IT) budget! A cost-effective solution would be to set up a certificate authority inside your company, and issue user-based (not machine-based!) certificates that require a password to be used to “unlock” the certificate. As long as both the certificate and password are uniquely assigned (and not group-based), this is a perfectly acceptable solution to meet Requirement 8.3. When building this environment, ensure you are using good security practices around these certificates. Check NIST for some guidelines around PKI.
Rendering Passwords Unreadable in Transit and Storage
Requirement 8.4 has far reaching impact to most organizations. Companies sometimes get confused on exactly what is required here and struggle with the interpretation, especially as it relates to Requirement 2.3 (described in Chapter 4, “Building and Maintaining a Secure Network”). All passwords for in-scope systems and users must be transmitted encrypted to the system in question to prevent someone from capturing the password with simple network sniffing technology, and all passwords stored on a system must be encrypted at rest. The easiest way to delineate which users and systems this requirement applies to is to ask the following question: Does this system process, store, or transmit cardholder data, meaning is it in scope for PCI? If so, then all users with administrative privileges or access to cardholder data must use some kind of encrypted channel for their authentication like Secure Shell (SSH) or Secure Sockets Layer (SSL).
Note
There is some gray area with this requirement. What if a user’s authentication credential could also be used for access to systems not in scope for PCI? For example, let’s say that Rob is a UNIX administrator and is responsible for both in- and out-of-scope systems. Some of the out-of-scope systems do not have SSH deployed on them, and Rob must use Telnet to administer them (as if he still lives in the 1980s and uses Telnet…). For ease of management, both types of systems authenticate to the same LDAP server. Would that mean that all systems must be upgraded to support SSH because credentials captured while Rob authenticates to an out-of-scope server could be used to authenticate to an in-scope server?
By reading the requirement alone and considering the scope, you might think you don’t have to deploy SSH everywhere. If you read the Navigating PCI DSS Document (www.pcisecuritystandards.org/saq/instructions_dss.shtml#navigating), it seems to suggest that those systems would need to be upgraded to require SSH. The best thing you can do is err on the side of common sense. Why protect a credential in one place and not another? You should deploy some kind of encryption for anything using that credential. Also, telnet and other remote access tools that expose the passwords should in fact be left in the 1980s….
Authentication and Requirements 8.5.1–8.5.7
Requirement 8.5 describes much of the technical and procedural aspects for handling usernames and passwords for PCI DSS. Because Requirement 8.5 is grayed out as far as a compliance requirement (and is really a roll-up requirement for everything below), we will start off with Requirement 8.5.1. For 8.5.1, your assessor selects a sample of user IDs from your entire population, asks you to supply the form authorizing the access, and then validates that the access on the system is set up exactly as authorized. Before your assessment begins, you should go through this process with your own sample. If you find that your authorization forms do not match the access granted, your assessor will probably find the same.
Requirement 8.5.2 is another one of those “Duh, guys” moments, but you would be surprised how easily companies are compromised because they didn’t check to make sure that the person on the other end of the phone asking for a password reset was the actual owner of the account! One tactic used in penetration testing is to obtain the name of an actual employee, and then call the help desk posing as that employee and request a password reset. It works more often than you imagine. Social Engineering is far beyond the scope of this book, but if you are interested in learning more you should check out Christopher Hadnagy’s book called Social Engineering: The Art of Human Hacking (ISBN: 0470639539, Wiley). Requirement 8.5.2 aims to prevent that by making sure that if Steve requests a password reset that the help desk person on the other side of the phone or e-mail request, or the process on the other side of the browser verifies Steve’s identity before doing it. Your help desk may need access to pertinent employee data such as an employee number, last four of a national ID (Social Security Numbers in the United States are essentially that), address, home phone, or other types of information known only to the employee. Help desk personnel should be trained on social engineering tactics (keep in mind is that PCI DSS does mandate such security awareness training) and be prepared to deal with an outsider trying to beat the system.
First time passwords are often an easy way to compromise an account. For example, when Steve joined his company, he was provided with a cell phone and a laptop. His user ID was his first initial and last name, and his password was “Newuser1.” The initial password was the same for every user and would technically exceed the complexity requirements of PCI DSS. The password is alphanumeric and includes a mixture of uppercase and lowercase letters. But because every user gets the same password, compromising a new account might be a trivial operation with a little bit of social engineering. Requirement 8.5.3 mandates that all new accounts have a unique password that expires immediately after its first use. We’ll cover configuration methods to do these for both Windows and UNIX in the “Windows and PCI Compliance” and “POSIX (UNIX/Linux Systems) Access Control” sections of this chapter.
Another source of compromise is old or stale authentication information from users no longer employed with your company. If you terminate a user, you must immediately revoke his or her access per Requirement 8.5.4. If a user does not authenticate with his or her password for a period of 90 days, the account must be removed or disabled per Requirement 8.5.5. Reviewing logs, as we cover in Chapter 9, “Logging Events and Monitoring the Cardholder Data Environment,” is one of the ways to track successful access from terminated employees. The account login IDs should never be seen in access logs after their termination.
Requirement 8.5.6 mandates tight controls around accounts that vendors may use to support systems. Although vendor accounts vary in their level of authorization on systems, they should be disabled any time they are not being used and monitored while they are in use. These support accounts can come in more than one form. Sometimes the original equipment manufacturer supports it, such as IBM or Cisco, and other times you may have a third-party, such as SunGard or a division of a Big 4 to support it. Regardless, any common vendor accounts must be disabled when they are not in use. To monitor what happens during a session, you could have your vendor log into a Citrix portal to then access your machines and log the entire session. Command-based machines could make use of logging utilities built into common applications like sudo, or even using the history function of a UNIX shell and offloading the logs somewhere outside of the vendor’s write access.
Finally, Requirement 8.5.7 mandates that you communicate all the password procedures in PCI DSS to the in-scope user base. An in-scope user is a user who has access to cardholder data as a normal part of his or her job. These users must be made aware of the password procedures, and your assessor will randomly sample users and ask them what they know about password procedures. Assessors may do this as a part of an interview for another area of PCI DSS, or they may specifically ask for a list of users and randomly call them for a phone interview.
Tools
Want to see how strong your passwords are? Mandylion Research Labs (www.mandylionlabs.com) created a fantastic brute force calculator that you can download (www.mandylionlabs.com/documents/BFTCalc.xls) and test to see how long it would theoretically take to break a password or key. Plugging in the elements of the password above (Newuser1), it would take the average computer just over 2½ h to break that password. Let’s say that you didn’t know that the password contained one uppercase letter, six lowercase letters, and one number and assumed an eight-character random mix of uppercase and lowercase letters and numbers. If you made this assumption, the average computer would take a little more than 6300 h using a brute force attack to crack the password (an effective key strength of 236). Adding special characters in it would take over 117,000 h with an effective key strength of 252. This is where user education is important.
Educating Users
Although PCI’s password requirements are not incredibly strict, they may be stricter than what your company was using before becoming compliant. If your company is going from a very relaxed password policy to a stricter one, you will probably meet resistance from employees. Of all the changes you may have to make, this is one that affects an employee’s day-to-day work. Some employees have a hard time seeing the benefits from using strict password policies—some may even grumble that this is just another way the IT department is making their lives more difficult.
Instead of forcing policy upon users and communicating it through e-mail or newsletters, meet with employees to personally explain the policy to them and answer any questions they may have. This is a great opportunity to educate them on what makes a good password and why they are important, and this could even be considered part of your security awareness training for Requirement 12.6.1. Management should be involved in this meeting, and it makes sense to tie it to some other form of All Hands event. As we learn from our mothers (thanks Mom!), it’s best to lead by example. If employees observe management interested in and adhering to the policy, they will take it more seriously. You may want to get someone from management to briefly introduce that the company will be implementing a new password policy to become more secure.
One of the things you want to cover in this meeting is the password complexity requirements that will be enforced. Many times, users get frustrated when it’s time for them to change their password because they don’t understand why any of their new passwords are not being accepted. Give them examples of passwords that both conform and violate the policy, with information on why they do not comply.
You may also want to go over some tricks to help them choose good, secure passwords that will be easy to remember. For example, some security experts advocate writing out a sentence and using the first or second letter from each word. One of our colleagues suggests having users pick two items always present on their desk (such as a coffee cup and a monitor) and the password might be “c0ff33Cup&m0n!tor.” Another trick is to take certain letters and interchange them for numbers that look like those letters (e.g. 3 for E, 7 for T, 1 for L) or take letters and interchange them for symbols the same way (e.g. # for H, $ for S). For example, the sentence “Bill grabbed a brewdog at the high school reunion gathering” could become the password “Bg4bathsrg,” and the verse from one of the author’s favorite songs “Show me, how you want it to be, tell me baby, cause I need-to-know” could become “Sm#yw1tbtmbc1ntk.” The effective key strengths of those passwords are 245 and 272, respectively. Users could also use a passphrase as long as it has uppercase and lowercase letters and numbers to comply with PCI requirements. A great reference is Mark Burnett’s book, Perfect Passwords: Selection, Protection, Authentication, (ISBN 978-1-59749-041-2, Syngress). Much of the book is dedicated to helping users select passwords that are unique and easy to remember.
Users should be educated to never give out their passwords under any circumstances to anyone, including the IT staff.
Use this opportunity to help them understand how often password changes will be required (at least every 90 days), and that they will not be allowed to reuse old passwords (at least the last four). You should also review company policies about disclosing passwords. Passwords should never be disclosed to anybody for any reason. Employees should understand the process that’s in place to reset their passwords if they forget it. You should always ask users if they have any questions when rolling out a new policy.
Password Design for PCI DSS: Requirements 8.5.8–8.5.12
When PCI DSS was really gaining steam, one big complaint from companies forced to comply was that the password controls were too stringent or could not be supported on the hardware that ran their businesses. Nearly every currently supported system has the capability to comply with the PCI DSS password complexity requirements. If during your compliance efforts you find systems that are unable to comply, check to make sure that it is still supported by the vendor and is not just horribly out of date. To simplify the subrequirements contained within PCI DSS Requirement 8.5, see Table 6.1 that explains everything that your in-scope systems must enforce for password controls.
Table 6.1 PCI DSS Password Complexity Requirements
| Req. No. | Control |
| 8.5.8 | No group or shared passwords. Each user should have his or her own user account and unique password not to be shared with others. Furthermore, requests for group or shared IDs should be denied |
| 8.5.9 | Expire passwords every 90 days. All users must be forced to create new passwords for their accounts at least quarterly |
| 8.5.12 | Password must be different from last four. When users change their passwords, they must not be able to use a password that has been used in the last four changes |
| 8.5.10 | Seven element minimum length. Users must be forced to create passwords of at least seven elements |
| 8.5.11 | Passwords must contain letters and numbers. Of the at least seven elements or positions in each password, at least one of them must be a number and at least one must be a letter |
For these requirements, systems must enforce these controls. Having only a policy that describes the proper procedure for making passwords is not acceptable. All the above requirements can be met by modern UNIX and Windows operating systems. We’ll show you how to accomplish this in the “Windows and PCI Compliance” and “POSIX (UNIX/Linux Systems) Access Control” sections of this chapter.
Locking Users Out: Requirements 8.5.13–8.5.15
The first two requirements help to protect accounts against brute force attacks as well as the nefarious individual from abusing an abandoned, logged-in terminal. Requirement 8.5.13 mandates that systems automatically lock an account after six failed login attempts, and Requirement 8.5.14 mandates that systems maintain that locked status for at least 30 min for an automated system or until an administrator resets it for a manual system. To test this, an assessor may ask a user to perform six failed login attempts to make sure that the account locks, or they may just examine the system’s settings to make sure it is set up properly.
Requirement 8.5.15 mandates that idle sessions time out after 15 min of inactivity. This requirement led to a myriad of interpretations, some of which actually broke a business function. For example, Matt manually runs some processes on a mainframe that takes just over 1 h to complete. When he types in the command, the session essentially freezes while the task runs but becomes interactive again when the job completes. Some Qualified Security Assessors (QSAs) interpreted this to mean that after 15 min of starting the job, the session should time out (forcing the process to terminate abnormally). This requirement should not be applied to every possible way a session could be started but instead should be smartly applied to the environment as a whole. If all mainframe sessions must be initiated from a Windows-based workstation, then make sure the workstation meets the session timeout requirements since the mainframe session runs inside the Windows one. This may not work in every case, but take the concept and find the best way to implement it in your environment.
Databases and Requirement 8.5.16
Databases contain lots of information valuable to a hacker, yet the security around databases is sometimes the worst in the entire enterprise. Many compromises occur because of administrator-level accounts with blank passwords. Requirement 8.5.16 has two testing procedures. Procedure 8.5.16a requires assessors to verify that all users are authenticated prior to being granted access to the database, direct user interactions with the database are done through programmatic methods such as stored procedures, and that direct queries to the databases are restricted to administrators only. If you have power users that log into your database directly instead of going through an application, take any common actions they may perform and put them into stored procedures or functions, and then restrict their access to those elements. Better yet, code these actions into the application and force users to use that method instead.
Procedure 8.5.16b requires that assessors verify that application IDs and their passwords can only be used by the authorized applications and not by individual users or other processes (typically meaning that the accounts do not allow for interactive login and you avoid using passwords over keys and certificates). This can be challenging depending on your infrastructure. Older versions of database servers may not be able to sufficiently distinguish users from applications. Consider the following example.
Diana is a Database Administrator (DBA) and manages two main locations where enterprise data is stored. Her business critical information is stored in various locations on a mainframe. The security added to the mainframe allows batch processes to operate under noninteractive login credentials, thus preventing those credentials from being used for an interactive session with the data. Diana’s Web farm for her e-commerce site pulls its data from a PostgreSQL database. In her pga_hba.conf, she set an Internet Protocol (IP)-based restriction on the application’s ID by adding in the source IPs that are valid from her application servers. She has four different ones in her enterprise, so all four of the IPs are in her pga_hba.conf, and the application IDs can only be used from those machines which are considerably locked down.
Windows and PCI Compliance
If you work in an organization where Windows is widely deployed, you’re probably using Active Directory to authenticate users. One of the great things about Active Directory is that it is easy to roll out many of the requirements for PCI to the enterprise. Using Group Policy Objects (GPOs), you can enable password-protected screen savers and set up password policies all from your domain controller. You may also have standalone Windows computers that aren’t part of the domain (e.g. a Web server that’s at a hosting company), so we’ll show you how to configure these for PCI compliance as well.
Windows File Access Control
Windows Access Control Lists (ACLs), or Discretionary Access Control Lists (DACs), are used to configure and enforce access control. ACLs contain a list of Access Control Entities (ACEs), and each entity defines permissions. To set ACLs in Windows, you must have proper administrative privileges. Because Windows uses discretionary access control, the owner of the file and administrators can configure ACLs for an object. When using Windows access control mechanisms, you basically have three options: you can explicitly allow permission, explicitly deny permission, or implicitly deny permission.
When you implicitly deny permission, this means that you did not explicitly allow or deny access. By default, Windows denies all access to objects that do not have rights set on them. This is a great best practice to follow for all systems and is particularly good because it helps us comply with PCI Requirement 7.2.3 without doing anything. Because Windows implicitly denies access, explicitly denying access should only be used in special cases where you are denying permission to a subset of a group. One user you would normally never deny access to is the built-in “Everyone” group because this will deny access to all users including the administrator. The correct way to do this would be to add users and groups that should have access to the file and then simply remove the Everyone group from the allowed users. Because Windows follows an implicit deny for anyone not explicitly given permission, this will likely give you the desired result.
Warning
System administrators are busy. Sometimes they will give all users administrative rights instead of properly reducing each user’s (or role’s) rights to the minimum necessary to do his or her job. This is bad for many reasons, including higher support costs when “Acts of CLOD” occur. With everyone acting as an administrator, Windows no longer follows the default deny policy required by PCI Requirement 7.2.3 because all users are allowed full access to all files.
When configuring access controls in Windows, there are several tricks that can save you time in initial configuration and later maintenance. Remember the roles you created as part of the Requirement 7, “How Much Access Should a User Have?” section earlier in this chapter? Here’s where we use them! Once you have the role, you must create a group with those permissions and assign all the required users to that group. With users belonging to roles or groups, you can set access permissions for the whole group instead of each user individually. This also makes maintenance much easier because you can change permissions for the entire group and remove and add users whenever needed. It’s not uncommon to have users who are assigned to more than one group. For example, one user may only need access to unprocessed cardholder information, whereas another user may need access to unprocessed and processed cardholder information. In this case, both users would be members of a group with access to cardholder information, but only the second user would also be a member of a group with access to processed cardholder data.
Note
The process of defining roles is not a weekend or after-hours gig. One author assisted a customer in creating a detailed set of roles for a top 10 financial institution in the United States. What started as an initial set of 900 defined roles escalated to over 3000. Although the exercise ultimately yielded a much more secure company with an easily managed set of permissions, the effort was much larger than anticipated.
Another great time saver, but a potential minefield, is to use inheritance as much as possible. When you set permissions on a file or folder, you can also specify how subfolders will inherit those permissions. This makes it much easier to configure access control on a few folders that are near the root folder, instead of needing to configure each subfolder individually. Just remember that if you set up inheritance, by default, subfolders have the same permissions. Security templates can assist with this if you find that you have common types of folders to which you grant access often. This keeps all security settings in the same location and makes them much easier to manage.
Warning
To be able to effectively secure data in Windows, you should always use the New Technology File System (NTFS). FAT32 does not cut it because it does not have the capability to do access control.
Note
Remember that new password requirements will not be enforced until the next password change, so to be PCI compliant today, you would have to have all users change their passwords today.
Finding Inactive Accounts in Active Directory
One of the PCI requirements is to find all accounts that have been inactive for 90 days or more and remove or disable them. In Active Directory, there are several ways to find inactive accounts, although in many cases you have probably struggled to find one that works well. For some tips outside the scope of this book, check this TechNet article: http://j.mp/yodXCl.
Enforcing Password Requirements in Windows on Standalone Computers
To set password policies for a Windows computer (including 2000, XP, 2003, Vista and later editions) that is not connected to the domain, you should use the Local Security Settings dialog box, which is set up basically the same way as a GPO, except that it will only affect the local computer.
• Windows XP: Click on Start | Control Panel. Inside the Control Panel, click on Performance and Maintenance | Administrative Tools | Local Security Policy.
• Windows 2000: Click on Start | Programs | Administrative Tools. Inside the Administrative Tools dialog box, click on Local Security Policy.
• Windows 2003/2008: Click on Start | All Programs | Administrative Tools. Inside the Administrative Tools dialog box, click on Local Security Policy.
• Windows Vista: Click on Start | Control Panel. Inside the Control Panel dialog box, click on System Maintenance | Administrative Tools. In the Administrative Tools dialog box, click on Local Security Policy.
• Windows 7: Under Computer Configuration and User Configuration, click on and expand Windows Settings to see the Security Settings. Now open the Local Security Policy editor.
Now expand Account Polices, then click on Password Policy (for an explanation of what these settings mean, refer to the earlier section “Enforcing a PCI Compliant Password Policy in Windows Active Directory”). Enforce password history should be changed to at least four times to meet PCI requirements. The Maximum password age should be set to at most 90 to meet PCI requirements. The password length should be at least seven characters for PCI requirements, and passwords must meet complexity requirements and should be set to enabled. It’s also a good idea to set the Minimum password age to at least 1. Otherwise, when a user is required to change their password, they could change it four times then back to their original password. When this setting is set to 1 or more, the user must keep the same password for at least that many days before they can change it again.
You should also configure the Account Lockout Policy to comply with PCI requirements. To do this, expand Account Lockout Policy. Double-click on Account lockout threshold. In the Account lockout threshold, Properties dialog box change number of invalid login attempts to 6. A dialog box will pop up and ask if it should also change the Account lockout duration and Reset account lockout counter after attributes as well. These should both be changed to 30 min to comply with PCI requirements, which is what the default is in this new dialog. Click OK.
Warning
All these settings may be irrelevant if the users who connect to them have local administrator privileges! Do yourself a favor and remove all local administrator access from your users’ accounts, or look to your specific installation to ensure this cannot happen.
Enabling Password Protected Screen Savers on Standalone Windows Computers
Setting screen saver options is much easier to maintain and enforce using Active Directory. If you have computers that are not connected to a domain, these options can be set on each computer individually.
• Windows 2000, XP, and 2003 Server: Click on Start | Control Panel. In the Control Panel, double-click on Display. Inside the display dialog, click on the Screen Saver tab. The Wait option should be set to 15 min at the most. Also verify that On Resume, password protect is checked.
• Windows Vista: Click on Start | Control Panel. In the Control Panel, click on Personalization and then on Screen Saver. In the Screen Saver dialog box, set the Wait time to a maximum of 15 min. Also verify that On Resume, display logon screen is checked.
• Windows 7/2008: Click on Start | Control Panel. In the Control Panel, click on Appearance and Personalization. Click on Change screen saver under Personalization. In the Screen Saver dialog box, set the Wait time to a maximum of 15 min. Also verify that On Resume, display logon screen is checked.
Setting File Permissions on Standalone Windows Computers
In Windows Explorer, navigate to the file or folder you would like to modify permissions on. Right-click on the file or folder and then click on Properties. In the Properties dialog, click on the Security tab. To add a user to the list of Group or user names, click on the Add button and the Select Users, Computers, or Groups dialog box will appear. You can then type in the name of a user or group. The Advanced button gives you more options to help you find the correct group or user to add. After you click OK, the user or group will appear in the previous dialog box
POSIX (UNIX/Linux Systems) Access Control
UNIX-based systems such as Linux used POSIX-style access control lists. This means files have three permission modes: read (r), write (w), and execute (x). These modes can be assigned either using the letters just listed or they also have equivalent numbers. Read is 4, write is 2, and execute is 1. If file permissions are being set using letters, it will be a string of letters or dashes (e.g. a file with read-only permission would show r– and a file with read, write, and execute would show rwx). When using numbers, they are added to denote permissions. Read permission would simply be a 4, and read and write permission would be 6 (4 plus 2). When using POSIX-style access controls, there are three groups or users you set permissions for. The first set is for that specific user who owns the file. The second set is for the group who owns the file. The third is for all other users who do not have any ownership over the file, similar to the Everybody group in Windows. So, a file that allows the owner to read and write, and everyone else only read access would look like this –rw–r–r– or in numeric format it would be 644.
Linux has great command-line tools for changing file permissions and file ownership. Although exploring all that these commands can do is beyond the scope of this book, we will discuss some basics here. In Linux, to list file permissions, the ls command can be used. The syntax to list the file permission and the group and user who own the file is as follows:
To change file permissions in Linux, you usually use the chmod command. You can run the chmod command using numbers. The following example uses POSIX permission number format to set a file to allow the user who owns it to read, write, and execute the file, and everyone else to read and execute but not write to it, similar to a standard executable file:
Or you could use letters and specify if you are going to add them or delete them from users (u), groups (g), others (o), or all (a). For example, to allow the user who owns the file to read from it and write to it, you would do the following:
To take away permissions use a—in front of the permissions parameter. To deny read, write, and execute permission to the group that owns the file and to all users other than the one that owns the file, you would do the following:
To change the file ownership, use the chown command. To change the user and group that owns a file, do the following:
In POSIX-style systems, there are three additional attributes that affect how files are executed are accessed. These are set user ID (SUID), the set group ID (SGID), and sticky. These settings work differently when they’re applied to files or directories. The SUID bit can be configured to tell the file what user it should run under when the file is executed. Many times this is used to allow a nonroot user to run a file as the root user. This is used if a user needs to run a file that requires root access, and you don’t want to give their account root access or the root password. SGID for a file works the same way as SUID, but it specifies what group the file should execute as. The sticky has no effect on individual files. The SUID bit has no effect on directories. If the SGID bit is set on a directory, any new files created in that directory will be owned by the group specified using the SGID instead of the group of the user who created the file. This is sometimes used in directories where many users will share files. When the sticky bit is set on a directory, only the user owner of the file or root can delete or rename a file (the group owner cannot). This is sometimes used in shared directories where you don’t want users other than the owner or root to delete or rename a file.
In Linux, there are also several mandatory access control systems. Most of them are somewhat limited to protecting only a subset of files on the system (normally only critical system files). SE Linux is an example of this. SE Linux was developed by the National Security Agency (NSA) and has been incorporated into the 2.6 series Linux kernel. SE Linux uses targets to specify what files it will control and how it will control them. Other mandatory access control systems that are currently being used in Linux include Suse’s AppArmor, Rule Set Based Access Control (RSBAC).
Linux Enforce Password Complexity Requirements
Most Linux distributions support password complexity enforcement using Pluggable Authentication Modules (PAM). This is normally set in /etc/pam.d/system-auth. To comply with PCI requirements, a password must be seven characters long and contain uppercase, lowercase, and numeric characters. pam_cracklib has parameters to help you meet these requirements. The minlen parameter is used to specify the minimum length of a password. The dcredit parameter is used to requite digits, the ucredit is used to require uppercase letters, and the lcredit parameter is used to require lowercase letters. The retry parameter is used to specify how many attempts a user gets before the password program exits. Let’s put all these together to show the entry in /etc/pam.d/system-auth:
Depending on your implementation, you may see different names for the PAM configuration files where this information is placed (e.g. in Debian, you would find this information in the /etc/pam.d/common-password configuration file).
Cisco and PCI Requirements
Cisco devices have some important settings that should be used for you to become PCI compliant. All passwords should be encrypted when stored or in transit. Most operating systems do this and do not really give you an easy way to store them unencrypted even if you want to. Cisco devices are an exception, however, so it’s important to check this.
Cisco Enforce Session Timeout
To force Cisco devices to automatically timeout if a session is left inactive, use the exec-timeout configuration under the appropriate line configuration. The syntax for this command is exec-timeout [minutes] [seconds]. For PCI compliance, this should be set to as follows:
Encrypt Cisco Passwords
The current best practice from Cisco is to always use “enable secret” and “username secret,” instead of enable password. Enable password encrypts the password using a very weak encryption algorithm that has been broken for a long time. The secret command uses Message Digest 5 (MD5) to hash the password. Although MD5 has shown some weaknesses lately, this is far better than the alternative and the best Cisco is giving us right now. Alternatively, you can use directory-based authentication models such as RADIUS or TACACS+ to prevent these usernames and passwords from being stored directly on the device.
Setting Up SSH in a Cisco Environment
By default, Cisco routers allow Telnet access to the line vty 0 4 port for remote configuration. To disable this and set up an SSH server, you must first have an IOS version that supports IOS with the appropriate feature pack (typically the crypto pack). You need to set up either local authentication or as suggested above, tie the device to a directory. When managing any more than a few devices, pointing the authentication to a directory service makes administration much easier.
If you have already directed your device to a directory service, skip to the next configuration step. Otherwise, you need to enter this into your router after entering the “Terminal Configuration” mode by typing config t:
The next command generates the keys required to perform SSH encryption:
Then finally, to disable Telnet for remote access, type the following two commands:
Then, save your configuration!
Requirement 9: Physical Security
There are three basic types of physical security. The first type is obstacles such as doors, walls, and other barriers, which can help stop or at least delay intruders. The second type is detection mechanisms such as alarms, lighting, guards, and television cameras that help detect attacks. The third type is response, which includes things you would put in place to stop an attack in progress or soon after. It’s important to use all these types of physical security to protect sensitive information. For example, you may put sensitive data behind a locked door and have security cameras monitoring that door, recording everybody who goes in and out. You may also have a guard on duty who can quickly respond to stop anyone who’s trying to circumvent the lock. Security measures in plain sight act as a deterrent to attackers, sometimes preventing the attack in the first place.
Requirement 9.1 mandates “facility entry controls” for in-scope areas including computer rooms, data centers, and other physical areas where in-scope systems may live. Acceptable controls include lock and key, badge access, or some other barrier that automatically locks and only unlocks for the people authorized to access these rooms (Hint: the President of your company should not have access). Requirement 9.1.1 mandates the use of video cameras or other access control mechanisms to monitor individual physical access to “sensitive areas.” No doubt those areas include the ones mentioned in 9.1, but arguably they would include a large physical storage area of paper records that contain cardholder data. These large storage areas exist in many places in the United States, and the payment systems in some countries require exchanging a significant amount of paper data. Those areas should be protected in the same way and should have cameras monitoring access. In addition to simply placing the camera there, you must protect the video data from modification and regularly review and correlate the data, as well as store it for a minimum of three months.
Before PCI DSS version 1.2 (note that we are at 2.0, but we just wanted to provide you with some historical context), this requirement has been interpreted to mean a wide variety of controls. Current PCI version does a good job clarifying exactly where these cameras should be stored. For example, placing cameras over each cash register is not required, but if you store cardholder data in a server room at a store, that would need to be monitored.
Requirements 9.1.2 and 9.1.3 aim to protect inherently vulnerable areas of your environment. Requirement 9.1.2 targets publicly accessible network jacks and mandates the access to such jacks be restricted. This one can be challenging as far as its intent. If you have conference rooms or common areas with network jacks that are outside the restricted areas of your company, you should disable them or segment them away from networks where cardholder data may be processed. This requirement would not apply to a conference room behind a secured area where visitors must be escorted. QSAs in the past have incorrectly read this requirement to mean that all conference room jacks must be disabled. This is incorrect, only those areas considered publicly accessible (i.e. with no physical access such as a badge reader protecting them). Another area to look out for with respect to 9.1.2 is retail store locations where network jacks may be placed throughout the store in plain view (or otherwise unrestricted) that might also sit on the point of sale (POS) network (or a network where cardholder data may be processed).
It is time for a real-life example. One of the authors was working with a customer who had a chain of cafes. When sitting down at one of the tables in the cafe, a network jack was discovered slightly obscured by a plant. This jack was actually hooked up to the same network as the POS systems, and an attacker could easily hide a device that could take advantage of this major design flaw.
Requirement 9.1.3, discussed in Chapter 7, “Using Wireless Networking,” mandates protection for wireless access points, gateways, and handheld devices.
Handling Visitors: Requirements 9.2–9.4
First, we begin with documentation! Requirement 9.2 talks about procedures to distinguish employees and visitors, and the testing procedure 9.2.a determines if the procedure covers granting badges, changing access, and revoking terminated or expired badges. The other testing procedure 9.2.b sees if you actually follow your own policies! In 2.0, you will notice 9.2.c which adds an additional examination by your assessor to make sure that visitors and on-site personnel badges are easily distinguished.
Note
During your assessment, make sure you make your assessor follow the procedures you set! There is nothing that says FAIL more than when a company being assessed forgets to give the assessor a visitor badge.
Requirement 9.3 deals with visitors exclusively. Requirement 9.3.1 is a test to make sure that the badge you give to the assessor does not open doors where sensitive information is stored. This is what the Council means by “unescorted access.” You can expect your assessors to try and get their badge to open a data center door or other sensitive area. Obviously, if you issue plain paper badges to your assessors, this will be a fairly easy requirement to pass. Your assessor will also look at the badge you give them and compare it to your badge. Requirement 9.3.2 mandates that employee badges and visitor badges visually appear different and have distinguishing marks such that an employee of your company could easily identify someone as a visitor by the badge used to identify him. Finally, Requirement 9.3.3 mandates that visitor badges are surrendered upon leaving the facility. Your assessor will probably perform the required testing procedures without you even knowing, so be sure your company is following the policies and procedures you set out!
Requirement 9.4 is documentation-based but not in the way you might think. When visitors are allowed to visit the facility in general, data center or other sensitive areas, they must sign in. The three items that must be captured for every access are the person’s name, the firm represented, and the name of the employee authorizing the access. You must also retain this log for at least three months (unless restricted by law), so expect to add dates and times to the above three items.
Handling Media: Requirements 9.5–9.10.2
Up to this point, the main focus with cardholder data has been online or live data. Data is not always online or live and exists in many different places. Requirement 9.5 deals with backup tapes and how they are stored off-site. These should be stored in a secure location, and if they are stored off-site, the security of the facility in question should be reviewed at least annually. Backups are not required to be stored off-site, however! Several companies make use of on-site tape vaults in their primary data centers to ensure that the data remains secure. If the media goes off-site, don’t send it home with one of your employees to put in her house. Be sure it is a facility that is secure and that the contracts comply with Requirement 12.8.
Requirement 9.6 mandates physical protection of all kinds of media that contain cardholder data. The term “media” is intentionally broad here, and the examples they list include computers, removable electronic media (such as USB drives), communications hardware, telecommunication lines (arguably not required if all data over the wire is encrypted), and paper (receipts, sales reports, chargeback or dispute reports, faxes, mailrooms). Although this is a procedural requirement (your assessor must review your procedures to ensure that this is addressed), your assessor may validate that you follow your procedures and ask to see areas where this type of data may be stored.
When media is distributed outside your company’s secure facility, you must protect the media in three distinct ways. First, Requirement 9.7 mandates a policy be put in place to strictly control the distribution of cardholder data. The fewer places you send in-scope data, the less likely you will have a breach because someone did not adequately protect the data. Requirement 9.7.1 states that all media must be classified in a manner such that it can be identified as confidential. This requirement could literally be interpreted to say that the media must have the term “CLASSIFIED” written on it, or more loosely interpreted to state that if you label tapes with a colored dot, the red ones are considered classified by your policies. Finally, Requirement 9.7.2 mandates that any media transported outside the facility is done so via a secure courier or in a manner by which it can be tracked. Something like your Iron Mountain driver or a FedEx package would suffice.
When media is transported off-site, you need to enter it into a log so that you know where your media inventory is at any given point. Your assessor will review several months of logs, per Requirement 9.8, and make sure that both the tracking information are included as well as proper management authorization. Someone capable of providing proper management authorization could be your data center manager or another person with the delegated authority (and accountability) for authorizing the transport of media.
Requirement 9.9 mandates strict control over the media such that it is only accessible to the employees who need it and periodic inventory of the media (per a policy). The testing procedure for Requirement 9.9.1 requires your assessor to review the media inventory log to make sure that periodic inventories are performed.
Note
What is periodic? Good question! Recent PCI DSS updates removed many ambiguous terms like “periodic” and replaced them with concrete terms like “every quarter.” Use this as a general rule of thumb. You must have an assessment performed annually, so do any periodic requirement at least annually so you have something recent to show your assessor.
Requirement 9.10 deals with the destruction of cardholder data. In cases where you need to dispose of any media containing cardholder data, it needs to be destroyed in a manner by which the data is not recoverable. This means that if you are done with a hard drive, you must either electronically destroy the data or physically destroy the media—a simple delete does not work. Requirement 9.10.1 describes some methods that could be used for hardcopy media and mandates that shred bins are available for employees to use (where applicable), and those bins are protected by some kind of locking device. Expect your assessor to walk through your areas and jiggle that lock a bit. Requirement 9.10.2 mandates that electronic media is destroyed appropriately. This type of media could be electronically destroyed with something like a bulk eraser (only for magnetic-based media) or physically destroyed with a giant shredder, incinerator, or just a bad day with a steam roller. Your assessor may want to review a sample of any electronically destroyed media to ensure that the data is not recoverable.
If you are now deploying Solid State Disks (SSDs) or use USB Flash media, you must understand that traditional secure wipe does not work effectively to destroy data on these media. In order to protect these, be sure that you are encrypting the drive or working from an encrypted volume before deleting. This can accomplish the same effectiveness of making the data unrecoverable without access to the keys.
What Else Can You Do to Be Secure?
This chapter covers how to create PCI Compliant access controls for in-scope data. One of the most effective things you can do is reduce the storage of in-scope data to both make it easier to comply with these three major requirements and to improve your general security. Let’s explore some areas where you might store in-scope data that could be reduced or eliminated.
Retail stores are notorious for storing data well beyond their useful lifespan for various purposes. When retailers started to embrace the concept of a computer to run their POS and process credit card transactions, it appears that the equipment first deployed was unreliable. Why else would you store 90 days of transaction logs on an in-store server? From an electronic perspective, remove all cardholder data older than two or three days from your POS controllers. POS terminals should never store this information once it has been passed to the controller (which could arguably be done on a daily batch basis). If you feel that you may need this data, collect the transaction logs or electronic journals in a central location. Bringing data from 50 stores is much easier to maintain in one place versus 50 individual places.
Next, look for paper data. If you are still printing the entire card number on the receipt that a customer signs, all of that paper must be protected in accordance with PCI. Get it centralized, then possibly imaged and destroyed. Even if you make a change to your process to mask that number when it is printed, be sure you don’t have any legacy data in the stores. One of the authors remembers visiting a retail location that had 10 years of paper cardholder data in clearly labeled boxes next to the bathroom used by customers, even though corporate policy prohibited keeping data any longer than one year.
Tools
Did you know that you only need four elements to uniquely identify any transaction in your enterprise, and one of those is not the full card number? These elements are as follows:
Customers who have used this method have never reported that two transactions matched these elements identically but had different card numbers.
Do your retail stores still contain knuckle-busters, those old manual credit card contraptions that used carbon paper and made a “kerCHUNK-kerCHUNK” sound as an imprint of a customer card is made? If so, you better believe there is probably someone who has used it recently and that some data is stored on hardcopy media (i.e. paper) in that store. Just like above, be sure that once you fix the policy or remove that equipment from the store that you have removed all the legacy data.
Here’s another one that you may not have thought about. If you have certain business or high volume customers that phone or fax orders in, how do they pay for their orders? Do you keep a credit card on-file so that when they come in they can just sign and leave? Work on removing that data or changing how you deal with your high-profile customers.
If you run a call center, how are calls monitored? Do the phones rely on Voice Over IP (VoIP) technologies to operate? Do you record the calls? The Council has specific Frequently Asked Questions dealing with call centers on their Web site (www.pcisecuritystandards.org) that will address your particular situation.
Finally, look to your corporate headquarters. Do you really need a credit card more than a couple of months after the transaction was initially processed? Many companies tell you that they absolutely need it until you ask them why at least three times. Why is three the magic number? Who knows, but the truth usually sounds like “Well, we’ve always done it that way.” Then, you ask them what they might do if the data was not available after 60 days. They will usually figure out a way to either handle the dispute with a truncated number or simply realize that the cost to secure this data far exceeds the potential losses associated with not having the data.
Note
Propaganda is powerful. Some industry pundits think that the card brands require merchants to store data. If you have heard this, read the next sentence very carefully. Card brands do not require that you store data! In most cases, your acquirer is taking a short cut, thus transferring risk to the merchant! In the authors’ experience, companies can easily deal with dispute resolution without the full number when they press their acquirer. Acquirers will compete for your business, so if your current acquirer is not willing to help you, consider another one! You’d be amazed how quickly something like this is resolved. Furthermore, law enforcement typically provides you with the full card number they want you to pull transactions for, so you can still assist them by asking for specific dates and times. There are some exceptions to this rule, but virtually every one can be altered to off-load risk from the company trying to comply with PCI DSS.
Tools and Best Practices
Aside from challenging the useful life of data and ensuring that you do not retain data longer than is absolutely required, here are a few other best practices you might consider.
Enforcement of a password policy in conjunction with other factors of authentication helps to protect systems from potential compromise. Here are some simple password rules, above and beyond changing default passwords that will provide stronger security. As this book is going to press, we are seeing more and more security professionals calling for the death of passwords. Since we may not see wide scale adoption of alternative methods in the super near future, some of these tips may be useful to you:
• Accounts that have system-level privileges must have a unique password from all other accounts held by that user.
• Give administrators different accounts for administrative actions; do not tie the privileges to their primary domain accounts.
• Do not transmit passwords over the Internet by e-mail or any other form of communication without being encrypted.
• Allow users to craft longer passwords in conjunction with some element of password complexity to ensure strong passwords.
• Deploy a token-based, system-wide two-factor authentication solution such that any system access to sensitive information requires a token or another factor of authentication. Even using risk-based models can make a tremendous difference.
• Deploy a single sign-on solution that synchronizes passwords so that users do not have to remember multiple passwords, thus encouraging users to select more secure passwords.
Many of these methods can help you bolster your overall security, but in many cases, they also make authentication easier on users. After all, if security professionals impose difficult requirements on users, they will come up with ever more creative ways to get around them!
Random Password for Users
PCI requires unique first time passwords. There are many possible ways to do this, and a quick Google search for password generators returns many options. These may work well for you; however, if you’re ultra paranoid, then you may want to use one installed on your own computer.
Here is a short Ruby (www.ruby-lang.org) script to help you create good, first time passwords. Notice that certain letters and numbers will never be used in passwords that this program creates. For example, 1, l, and I are not included because they can often be mistaken for each other. Also 0 and O have been removed. To run this script, you must have Ruby installed (it runs on many operating systems including Windows and Linux) and have the Crypt::ISAAC module, which is a more secure random number generator than the one included with Ruby. This can be found at http://rubyforge.org/projects/crypt-isaac/.
Common Mistakes and Pitfalls
This sections covers many pitfalls and mistakes related to this PCI domain.
Poor Documentation
This domain of PCI DSS starts with documentation, and poor documentation will set you up for failure when you try to meet the rest of it. Companies that struggle the most with this domain have two major issues they fight. The first is a poor analysis as part of Requirement 7, thus poor (if not nonexistent) documentation to support this requirement. Because content in Requirements 8 and 9 often rely on Requirement 7 to be completed, companies that often miss parts of Requirements 8 and 9 have set themselves up for failure by missing Requirement 7. Do your homework, and make sure Requirement 7 is handled well!
Legacy Systems
The other big trip up is legacy systems. There aren’t as many of them out there as there used to be, but with a new group of companies looking for the services of a QSA for the first time, there will be no doubt a ton of these out there. Legacy systems have many issues complying with PCI DSS, and this is one of the major ones.
Is there an avenue for a compensating control? There is always a possibility for a compensating control unless you are dealing with Requirement 3.2. For these systems, you will most likely need to use network segmentation and Virtual Private Networks (VPNs) or a “jump” server environment like a Citrix box or a Windows Terminal Server. Keep in mind, systems that are this legacy tend to be riddled with holes and struggle with just the basics of limiting network traffic to them. Most companies soon discover that this option will break their business, and they must ultimately upgrade.
Physical Access Monitoring
For Requirement 9, the biggest mistakes people make are on camera coverage. PCI DSS version 1.2 does quite a bit to clarify where cameras are required, and what you must do with them. Don’t over cover (i.e. put a camera on every cash lane), and don’t under cover (i.e. no cameras in stores at all).
Case Study
The following two case studies explore when bad things happen (or could happen) to people with good intentions. The PCI Requirements, when followed correctly, are designed to reduce the risk that companies carry by holding this data. The moral for both of these case studies is that you should store the absolute least amount possible, but protect what you store like a mama bear protects her cubs.
The Case of the Stolen Database
Alice’s Activity Atrium is a startup that aims to revolutionize how families shop with young children in malls. Alice pitched the concept of an activity center inside her local mall, with a safe, indoor playground, physical security around the play area, and pagers to reach parents inside the mall if problems occur with their children. Her goal was not to take up a store front but to make use of existing atrium space in an aesthetic manner such that it could be part of a seasonal offering for malls. The general manager for the mall granted her proposal on a trial basis, allowing her to set her business up for the back-to-school rush. Provided that things went smoothly, she would win the contract for the coveted Christmas season shopping that often occurred during November and December.
Alice bought some daycare management software for her laptop based on Microsoft Access, and opened her business in late July with amazing success. Her quick rise in popularity required her to hire some additional help. Alice contracted Darlene to run the laptop during peak times so that Alice could help with keeping the kids busy and safe. The software on her laptop captured relevant information about each customer and captured a credit card for payment. Customers paid by the tenth of an hour for the service, so the card was preauthorized for a 6-h stay, much longer than any stay she envisioned, and then finally authorized and settled for the actual amount used. The laptop was placed at her location’s entrance so that customers could check in and out quickly without having to step inside the facility, and repeat customers quickly were able to drop their kids off because the information was retrieved from storage.
One evening, one of the children under Alice’s care fell at an awkward angle and sprained his ankle. During the commotion of moving the child to a safe place and calling the mall’s medical personnel and the child’s parents, Darlene left her post to help out. A passing thief seized a rare opportunity and stole Alice’s new laptop.
Some readers may stop there and say, well, it’s just a stolen laptop and that’s not a big deal. Except, the laptop contained customer data on it, including credit card data. Although this is definitely a small scale breach, the concept could also occur at a well-established business (say at a day care or jewelry store) with thousands of customers. Alice made three key mistakes when she set up her business.
First, Although Alice took every precaution to prevent a child from “escaping” from her area, she didn’t lock down the physical assets that ran her business. A laptop out in the open of a crowded mall won’t last long before someone picks it up. Alice should have physically secured the laptop such that it was not openly available for a thief to steal it during a crisis.
Second, Alice’s desire to make it easier for kids to be dropped off had good intentions, but fell short when she stored the cardholder data of all of her customers. Instead of storing all that data, Alice should have instructed Darlene to ask for the method of payment for every transaction. Although this request would force her customers to spend another 1–2 min per transaction, she would not put her customer data at risk, and this breach’s reach would be much smaller.
Finally, the software Alice used to manage her business did not protect the information it stored. Because it was written in Microsoft Access, the data is easily retrieved. The thief not only had accesses to each of her customers’ credit card numbers but also had their home addresses and medical insurance information too! Should the thief figure this out, he has more than enough data to begin the process of stealing an identity or fraudulently charging transactions.
The Case of the Loose Permissions
Melissa works in the marketing department for Ben’s Body Boutique, a regional fitness and health center. Ben charged Melissa with merging data from a mass mailing campaign to purchase records from the last six months. Ben wanted to determine how effective the original marketing campaign was, and if there were certain geographic areas where the response was higher, so he could concentrate future outreach programs on those areas that yielded the largest amount of business.
Melissa made a request to IT to get access to the current customer database, and through her basic database skills, she learned as a business analyst in a former job, and she was able to perform direct queries against the data. IT gave Melissa a different username than her normal username, and she had to use a different password from her current Windows password because the complexity requirements did not match. She had a hard time remembering the password, so she temporarily wrote it down on a sticky-note and placed it inside her closed laptop.
Melissa began performing some basic queries based on the database layout provided by one of the DBAs. The data map seemed to be missing a few key elements that she needed to complete her analysis, so she tried calling the DBA. He was out sick, and nobody else was available to help her with her question. So relying on her previous experience, she ran a few commands to get a more complete layout of the schema. She noticed that most of the fields were ones she thought she would need, so to save time, she used a wildcard when listing the database columns she wanted to see, thus effectively dumping the entire contents of the table to the Excel spreadsheet she would use on her machine. Unfortunately, her wildcard selection pushed customer credit card data down to her machine without her immediate knowledge.
It was getting late in the day, and she decided to finish the analysis later that evening after she put her children to bed. Not realizing the data she had, she simply copied the customer data file and the direct mail list to a USB disk she kept in her purse, left her laptop at her desk, and headed home. After putting her kids to bed, she loaded the data on her home computer and started to perform her analysis.
Without going any farther into the story, let’s stop for a minute and find the issues with this case, some of which happen every day in our companies. First, knowing Melissa’s background, IT gave her a database account with unlimited select permissions on all the tables in the customer database. The IT department violated Requirement 8.5.16 by giving a user direct access into the database and not regulating her use to just the data she needed. Instead, they should have asked her for the requirements and performed the data dump themselves and further ensured that the data was not PCI related. Next, she wrote her password down because the authentication for the database was different from her main Windows account. This action should be prohibited by security and password policies. Finally, she took the data home and put it on a noncompany-owned or controlled PC. Although her home machine may have all of its patches and be up to date on antivirus, she may forget to delete the file and could open Ben’s up for a breach further down the road if she sold the computer or fell victim to a Trojan horse or virus.
Summary
Access controls are an extremely important part of protecting your data. It is important to understand your systems and the best ways to control access to your data. Once access controls are set, they must be constantly maintained to be effective. As we have talked about in this chapter, it’s important to have many layers of security to be effective. Not only is it important to have strict access controls in place on computer systems, but it’s also important to control physical access.
Spend time to fully define your access requirements for PCI so that you can comply with Requirement 7. Although this is the shortest of the three requirements we covered in this chapter, it may require the most amount of effort to effectively meet. Defining roles and access profiles takes time, but the work you put in will allow you to centrally manage a diverse set of permissions effectively and efficiently. Next, put those profiles into action and assign permissions to them on your systems. Put users into containers, and ensure that their access complies with the diverse requirements in Requirement 8.
Then, take a step back and focus on physical security, and don’t forget stores and satellite locations! Don’t defeat the corporate security at your headquarters by leaving wide open electronic access to your store or satellite locations. Finally, discover how much money you can save by destroying the data quickly after settlement. Remember, you don’t have to protect what you don’t store!