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, 8, and 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.
NoteIn 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 noted 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.
Confidentiality
The principle of confidentiality means to prevent disclosure of information to parties not authorized to receive it. This means that if Abigail in accounting should not be able to read prerelease earnings statements prior to their communication to the street, access controls should prevent her ability to do so. 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, there are many other types of information we need to block from unauthorized eyes. 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. Going back to Abigail in accounting, her level and responsibilities in her job do not dictate that she needs to be able to modify financial reports before they are announced to the street. In this case, she should not have access to modify those reports, and management must be assured that the integrity of the financial statements they approved is in fact intact. 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, logging data that is considered in-scope for PCI DSS 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. Abigail in accounting is responsible for collecting credit card settlement data and assembling all the information into one format for submission to her acquiring bank. When she arrives at work in the morning, the last daily batch of data must be available for her to work on, and when she receives clearing information back from the acquirer, she must be able to access the previous daily batch for reconciliation. 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. For PCI compliance, this 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.
Requirement 7: How Much Access Should a User Have?
Let's put the principles of confidentiality, integrity, and availability into practice. Remember, we want to balance integrity and confidentiality (which both restrict access) with availability (which allows access). 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. Just because Abigail works in accounting doesn't necessarily mean she needs access to all of your organization's financial information. 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. 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.
NoteWhy 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 a hacker. 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 accessing the cardholder data environment must perform a successful two-factor authentication before being granted access to the cardholder environment.
NoteMultifactor authentication does not need to consume your 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.
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).
NoteThere 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. 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.
Authentication and Requirements 8.5.1 to 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. 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 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-like 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.
ToolsWant 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½ hours 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 2
36). Adding special characters in it would take over 117,000 h with an effective key strength of 2
52. This is where user education is important.
Educating Users
Although PCI's password requirements are not incredibly strict, they may be much 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.
NoteSome of the most interesting research in recent years on how well users protect passwords has been done by the organizers of Infosecurity Europe. In 2002, they surveyed 150 workers on the way to work and found that two out of three were willing to give up their password when asked what their password was as part of a survey (
www.managinginformation.com/news/content_show_full.php?id=469). In 2003, the survey participants were offered a cheap pen in exchange for their passwords; 90 percent of the 152 people surveyed gave up their passwords and some after a little coaxing by the person conducting the survey (
www.theregister.co.uk/2003/04/18/office_workers_give_away_passwords/). In 2004, they moved from pens to chocolate bars and found that 71 percent of those asked were willing to give up their passwords for the candy (
www.informationweek.com/news/showArticle.jhtml?articleID=18902094). The organizers then decided to wait 3 years until 2007 to see if the situation had improved. In the 2007 survey, they also included some of the IT professionals attending the Infosecurity Europe conference. They found that 65 percent of the 300 people they surveyed were willing to give up their passwords in exchange for chocolate bars (
www.theregister.co.uk/2007/04/17/chocolate_password_ survey/).
Users should be educated to never give out their passwords under any circumstances to anyone, including the IT staff. In the same 2007 survey from the Note above the users were asked if they knew any of their colleague's passwords and 29 percent responded that they did, and 39 percent said they would give their password to their IT staff if asked for it. Yikes! Looks like we have a lot of educating yet to do.
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 to 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 5.1 that explains everything that your in-scope systems must enforce for password controls.
Table 5.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-like Systems) Access Control” sections of this chapter.
The Math of Password Complexity
We've thrown out some stats on how password complexity relates to the overall strength of the password. There are many measures to determine how strong a password is. One measure of password strength is the total possible combinations using your particular character set and length. Generally, the more possible combinations there are, the harder passwords are to crack. For example, using PCI requirements, you have 26 lowercase letters, 26 uppercase letters, and 10 numbers for a total of 62 total characters. PCI DSS requires that passwords are at least seven characters long, so for a seven-character password, there would be 627 = 3,521,614,606,208 possibilities.
The number of possibilities increases exponentially with the length. If your company required eight-character passwords, that would be 628 = 218,340,105,584,896 possibilities. On the other hand, if you left the length requirement at seven characters and instead required that users also use symbols or special characters in their passwords, it would add 32 more characters to the equation. Now you have 947 = 64,847,759,419,264 – just over three times less than if we had required the password to be longer, but over 21 times better than one that only complies with PCI DSS.
Locking Users Out: Requirements 8.5.13 to 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 hour 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. 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.
ToolsHere is a sample pg_hba.conf with IP-based limitations. Assume that the database is called “CommWebsite” and the ID used for access is “CommUser.” Your pg_hba.conf would look like this:
# TYPE DATABASE USER CIDR-ADDRESS METHOD host CommSite CommUsr 10.4.30.0/29 password
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.
WarningSystem 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.
NoteThe 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 (precrisis) 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.
WarningTo 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.
Creating a New GPO
In a Windows Active Directory environment, the best way to roll out a password policy to all the computers is to use a GPO. On your Windows 2000 or 2003 server, click Start | All Programs | Administrative Tools. Inside the Administrative Tools dialog, click Active Directory Users and Computers. This will open up a dialog box that will show you your domain as well as several folders for configuring users and computers in your domain.
Right-click on your domain and click Properties, then click on the Group Policy tab. At this point, it is a good idea to create a new policy rather than modifying the default policy. This will make it much easier to revert later if problems occur. To do this, click the New button and then give the GPO a name such as PCI Password Policy. Next, you will click on your new policy and click the UP button. This will move your new GPO in front of the default one so that it will be evaluated before the default GPO. Next, left-click on the PCI Password Policy and click No Override.
Enforcing a PCI Compliant Password Policy in Windows Active Directory
Now that we have our new policy in place, we will configure the password policy on it. Double-click on the
PCI Password Policy and the “Group Policy Object Editor” should appear. Expand
Windows Settings, then expand
Security Settings, and then expand
Account Policies. Next, click on
Password Policy. In Windows 2003, the default should look like
Fig. 5.1.
■ Enforce password history: The number of passwords that should be stored and not allowed to be reused. PCI requires at least four.
■ Maximum password age: The longest time users can go before they must change their passwords. PCI requires that this happens at least every 90 days.
■ Minimum password age: This is used to ensure that users don't change passwords back to the original ones, by changing them more times than is in the history and then back to their originals. This way they must keep their passwords for a certain amount of time.
■ Minimum password length: This specifies how long the password must be. PCI requires at least seven characters.
■ Password must meet complexity requirements: This must be enabled for PCI compliance, as it requires that a password is at least six characters long and contains characters from at least three of the following categories:
■ Store passwords using reversible encryption: This means that passwords will be stored in such a way that they can be retrieved if an application uses protocols that need the user's password. This is not much better than using plaintext passwords and should therefore be disabled.
NoteRemember 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.
Configuring Account Lockout in Active Directory
Although you're configuring the password policy settings, it's a good idea to also configure the Account Lockout Policy. 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. It should now look like
Fig. 5.2.
Setting Session Timeout and Password-Protected Screen Savers in Active Directory
Under User Configuration, go to
Administrative Templates |
Control Panel |
Display. Double-click on
Activate screen saver, click the radio next to
Enabled, and then click
OK. This will enable screen savers on all client machines. Now double-click on
Screen saver executable name and click the radio next to
Enabled and in the text box type
scrnsave.scr (see
Fig. 5.3).
This enables a blank screen saver on all computers in the domain. Now double-click on
Password protect screen saver, click the radio next to
Enabled, and then click
OK. Last but not least, click on
Screen saver timeout and then click on the radio next to
Enabled. PCI requires that all sessions timeout after 15 min, which is equivalent to 900 s (see
Fig. 5.4).
That's all there is to it. Now all the sessions on your Windows machines in your domain should time out after 15 min and require a login to get back in. In the end, your screen should look like
Fig. 5.5.
Setting File Permissions Using GPOs
GPOs can also be used to set permissions for the file system. This makes permissions easy to maintain and keeps all of your security settings in one place.
In the GPO that we created in the last section, go to
Windows Settings |
Security Settings. Click on
File System, and you will see a list of any files that have permission set on them in your GPO. To change the settings on a file currently listed, double-click on the
File and a Properties dialog box will open. You can change inheritance settings in this dialog box to tell Windows how subfolders permissions should be affected (see
Fig. 5.6).
Click on
Edit Security and a dialog box will open that will allow you to view and modify what kinds of rights user and group accounts have. To add a user or group 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 appears in the previous dialog (see
Fig. 5.7).
By clicking on the Advanced button, you can view and change special permissions settings. You can also modify auditing settings and owner settings using the Auditing and Owner tabs.
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. If you are using Windows 2003, you can use the built-in dsquery tool. To find all users who have not logged in during the last 90 days, the syntax is as follows:
dsquery user –inactive 13
The tool expects the argument in weeks, so we supply 13 weeks equalling 91 days. For Windows 2000, there is a tool called
OldCmp available at
www.joeware.net. This tool works with both Windows 2000 and 2003 and has features to not only find inactive accounts but to automatically delete them as well. It also makes easy-to-read reports in Hypertext Markup Language (HTML). Windows 2000 does not have a method to return the last time a user logged into an account, and this was added to 2003. We can, however, tell when a user's password was last changed. PCI DSS requires that passwords are changed at least every 90 days, so if a password has not been changed in the last 180 days, then we know it has been inactive for at least 90 days. If you have configured your system to require that users change their passwords more often than 90 days, it would be that amount of time plus 90.
OldCmp should be executed from the command prompt of the domain controller. The syntax to find inactive accounts using
OldCmp is as follows:
oldcmp –report –users –b dc=mydomain,dc=com –age 180 –sh
If you would like to use OldCmp against a Windows 2003 to do the same thing, the syntax would be
oldcmp –report –users –b dc=mydomain,dc=com -llts –age 90 –sh
After the command runs, a browser window will automatically appear with a report in it of what OldCmp found. You can then review this list of accounts to verify that there's no good reason for the account to have been inactive (e.g., that person has been on the road for a long time and will return shortly). After you have reviewed, you can use the –forreal switch, which will tell OldCmp to delete the inactive accounts it reported previously.
Enforcing Password Requirements in Windows on Standalone Computers
To set password policies for a Windows computer (including 2000, XP, 2003, and Vista) 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: 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.
You should now have a dialog box open that looks something like
Fig. 5.8.
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.
WarningAll these settings are 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.
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 (see
Fig. 5.9).
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 (see
Fig. 5.10).
By clicking on the Advanced button, you can view and change special permissions settings. You can also modify Auditing settings and owner settings.
POSIX (UNIX/Linux-Like 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:
ls –lg [filename]
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.
chmod 755 filename
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:
chmod u=rw filename
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:
chmod go-rwx filename
To change the file ownership, use the chown command. To change the user and group that owns a file, do the following:
chown newuser:newgroup filename
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:
password required /lib/security/pam_cracklib.so minlen=7 dcredit=1 ucredit=1 lcredit=1 retry=5
Depending on your implementation, you may see different names for the PAM configuration files where this information is placed (for example, 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:
exec-timeout 15 0
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:
aaa new-model
The next command generates the keys required to perform SSH encryption:
cry key generate rsa
Then finally, to disable Telnet for remote access, type the following two commands:
line vty 0 4
transport input ssh
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 (such as Mexico). 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 3 months.
Before PCI DSS version 1.2, this requirement has been interpreted to mean a wide variety of controls. PCI version 1.2 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 to 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!
NoteDuring 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 3 months (unless restricted by law), so expect to add dates and times to the above three items.
Handling Media: Requirements 9.5 to 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.
NoteWhat is periodic? Good question! Version 1.2 of the PCI DSS 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.