PCI compliance in a campus environment is akin to applying PCI to a small village. You are often dealing with a number of departments and schools that may have multiple ways of collecting and processing credit card payments. Too often the responsibility and burden of attesting to and maintaining PCI DSS compliance for a university is given to one poor soul in the Treasury or IT Security group. Not only does this individual have the joy of performing this task alone, they usually have no authority over the groups they are tasked to bring into compliance. This 'prophet in the wilderness' scenario where one individual is preaching PCI to the unrepentant masses is a recipe for failure. To build a successful campus compliance plan, try redistributing the knowledge and responsibility of PCI DSS compliance among the employees and administrators of the various campus entities that have chosen to accept credit card payments.
Before you begin to build such a distributed campus compliance model, you should attempt to get the appropriate authoritative backing. Begin discussing the importance of PCI compliance and cardholder data security with management (VP of Finance, CIO, etc.). Help them to understand the potential cost the institution would face in the even of a breach or the fines that could be levied by the merchant bank for non-compliance. It will be important to have this executive backing when you begin to work with individual campus merchants.
Once you have gained a sufficient amount of executive backing, spend some time reviewing the PCI DSS requirements that each merchant identified during the discovery phase (see the blog post titled "Understanding Your PCI Scope, a Journey of Discovery") will need to comply with. Determine which of these requirements will be handled centrally (either by central IT, the treasury, or other support group) and which can be delegated to the individual campus merchant. For most institutions policies and managed centrally while most procedural documentation can be managed by each campus merchant. Institutions with a consolidated central IT group may also manage firewall rules
(PCI DSS requirement 1), provide antivirus (requirement 5), perform vulnerability scans (requirement 11), manage data center security (requirement 9), etc. Some institutions will have the treasury manage service provider relationships centrally (requirement 12.8), while others will leave the annual compliance monitoring of service providers to each merchant. Usually processes and procedures surrounding the securing of physical media, security of POI device (requirement 9.9), and ensuring security awareness training has been properly performed would remain the responsibility of the individual campus merchant. If it makes sense to centralize the deployment of a PCI control, that responsibility could be removed from the campus merchants. For areas where procedures must be tailored for the individual merchant or where centralization does not provide improved efficiencies, you are better off leaving the responsibility with each campus merchant. By the end you should have a responsibility matrix for each campus merchant that identifies the group that will be responsible for each applicable PCI control. For a good example of such a responsibility matrix, look at the Windows Azure Customer PCI Guide.
Redistributive philosophies are not always popular and may be difficult to pull off, but the benefits are worth the effort. Gaining appropriate administrative support and assigning compliance responsibilities to groups throughout the campus will take a great deal of time and effort but in the end you will have a sustainable compliance framework that will be able to guide the institution's compliance efforts.
Wednesday, July 29, 2015
Understanding Your PCI Scope, a Journey of Discovery
Undertaking the task of bringing an institution of higher education into compliance with the Payment Card Industry's Data Security Standard (PCI DSS) can feel daunting to say the least. As with most large projects, the undertaking becomes more manageable when broken into smaller tasks. In order to begin to determine an organizations compliance to the PCI DSS, one must first understand the scope of the cardholder environment.
The scope of a PCI DSS assessment consists of the "people, processes, and technology that handle cardholder data or sensitive authentication data". This means that the institution's PCI scope will include any department or group on campus that receives, processes, stores, or transmits cardholder data or has cardholder data collected and processed on their behalf by a third-party entity. With most higher ed institutions, the best place to begin the scoping discussion is with the treasury or accounting department that manages the institution's merchant account(s). As they say in the movies, "follow the money". Begin with a list of all merchant accounts on campus. This list will help to guide the initial discovery phase.
During the initial discovery phase you will want to meet with representatives from each on-campus merchant to understand how cardholder data is used in their environment. The goal of these discovery meetings is to understand how cardholder data flows through each environment. Understanding the flow of cardholder data simply means knowing how cardholder data is received (card-present transactions, e-commerce website, over the phone, etc.), what systems the data traverses (servers, workstations, databases, etc.), if and where it is stored, and where it is sent for processing. Understanding the card flows in each environment is critical for properly defining your PCI scope.
By the end of your discovery phase you should have a list of 'campus merchants' and a basic understanding of their PCI scope. The next task would be determining the appropriate Self-Assessment Questionnaire for each merchant to be assessed against. The PCI Council has produced a document that helps define the different questionnaires that will be helpful as you begin to categorize your merchants. Below is a very brief summary of the different SAQ types:
SAQ A: This is for e-commerce or MOTO merchants who outsource all cardholder data functions to a PCI DSS compliant service provider. If e-commerce sites are redirecting to a service provider to collect and process cardholder data this must be a full redirect or i-frame implementation.
SAQ A-EP: This is for an e-commerce merchant that is redirecting cardholder data to a service provider but the code on their site can still impact the security of the data (like a direct post method).
SAQ B: This is for merchants using analog connected payment terminals (POI devices usually provided by the bank) or manual imprint machines (knuckle busters).
SAQ B-IP: This is for merchants who are using PTS-approved POI devices (usually provided by the bank) that connect to the IP network instead of dial-up connections.
SAQ C: This is for merchants who use a payment application (POS system) that is segmented from the rest of the campus network and is connected to the Internet for processing. The merchant cannot have any electronic storage of cardholder data.
SAQ C-VT: This would be used for merchants who are using a web browser to connect to an Internet-based PCI compliant virtual terminal to type in single transactions using the keyboard. Network segmentation is required and a swipe/dip reader cannot be used. No electronic storage of cardholder data is allowed.
SAQ P2PE-HW: This SAQ is for merchants who are using a validated P2PE (point-to-point encryption) solution to process transactions. No electronic storage of cardholder data is allowed. Solutions must be listed on the PCI Council's list of validated P2PE solutions.
SAQ D: The SAQ D is for all service providers and for any merchant that is electronically storing cardholder data or otherwise does not meet the qualifying criteria for any of the SAQ types listed above.
Most institutions of higher education that I have worked with will usually treat their central IT group as an SAQ D service provider and will then have multiple SAQ A and SAQ B merchants with a handful of SAQ C merchants and very few SAQ D merchants. You will quickly realize that the cost and burden on maintaining PCI compliance will increase rapidly based on the number of SAQ D merchants on campus. If at all possible eliminate or reduce the number of SAQ D merchants by the use of proper network segmentation and eliminating the electronic storage of cardholder data.
Now that we have a better understanding of our overall merchant environment, we are ready to start diving into evaluating the compliance of each merchant individually.
The scope of a PCI DSS assessment consists of the "people, processes, and technology that handle cardholder data or sensitive authentication data". This means that the institution's PCI scope will include any department or group on campus that receives, processes, stores, or transmits cardholder data or has cardholder data collected and processed on their behalf by a third-party entity. With most higher ed institutions, the best place to begin the scoping discussion is with the treasury or accounting department that manages the institution's merchant account(s). As they say in the movies, "follow the money". Begin with a list of all merchant accounts on campus. This list will help to guide the initial discovery phase.
During the initial discovery phase you will want to meet with representatives from each on-campus merchant to understand how cardholder data is used in their environment. The goal of these discovery meetings is to understand how cardholder data flows through each environment. Understanding the flow of cardholder data simply means knowing how cardholder data is received (card-present transactions, e-commerce website, over the phone, etc.), what systems the data traverses (servers, workstations, databases, etc.), if and where it is stored, and where it is sent for processing. Understanding the card flows in each environment is critical for properly defining your PCI scope.
By the end of your discovery phase you should have a list of 'campus merchants' and a basic understanding of their PCI scope. The next task would be determining the appropriate Self-Assessment Questionnaire for each merchant to be assessed against. The PCI Council has produced a document that helps define the different questionnaires that will be helpful as you begin to categorize your merchants. Below is a very brief summary of the different SAQ types:
SAQ A: This is for e-commerce or MOTO merchants who outsource all cardholder data functions to a PCI DSS compliant service provider. If e-commerce sites are redirecting to a service provider to collect and process cardholder data this must be a full redirect or i-frame implementation.
SAQ A-EP: This is for an e-commerce merchant that is redirecting cardholder data to a service provider but the code on their site can still impact the security of the data (like a direct post method).
SAQ B: This is for merchants using analog connected payment terminals (POI devices usually provided by the bank) or manual imprint machines (knuckle busters).
SAQ B-IP: This is for merchants who are using PTS-approved POI devices (usually provided by the bank) that connect to the IP network instead of dial-up connections.
SAQ C: This is for merchants who use a payment application (POS system) that is segmented from the rest of the campus network and is connected to the Internet for processing. The merchant cannot have any electronic storage of cardholder data.
SAQ C-VT: This would be used for merchants who are using a web browser to connect to an Internet-based PCI compliant virtual terminal to type in single transactions using the keyboard. Network segmentation is required and a swipe/dip reader cannot be used. No electronic storage of cardholder data is allowed.
SAQ P2PE-HW: This SAQ is for merchants who are using a validated P2PE (point-to-point encryption) solution to process transactions. No electronic storage of cardholder data is allowed. Solutions must be listed on the PCI Council's list of validated P2PE solutions.
SAQ D: The SAQ D is for all service providers and for any merchant that is electronically storing cardholder data or otherwise does not meet the qualifying criteria for any of the SAQ types listed above.
Most institutions of higher education that I have worked with will usually treat their central IT group as an SAQ D service provider and will then have multiple SAQ A and SAQ B merchants with a handful of SAQ C merchants and very few SAQ D merchants. You will quickly realize that the cost and burden on maintaining PCI compliance will increase rapidly based on the number of SAQ D merchants on campus. If at all possible eliminate or reduce the number of SAQ D merchants by the use of proper network segmentation and eliminating the electronic storage of cardholder data.
Now that we have a better understanding of our overall merchant environment, we are ready to start diving into evaluating the compliance of each merchant individually.
Subscribe to:
Posts (Atom)