PCI DSS 3.0: What Higher Education IT Needs to Know

Mark Lucas is vice president, Managed Services, and senior strategist, Higher Education, for Coalfire.

When it comes to payment card industry (PCI) compliance, the challenges for higher education institutions are fairly well known. Colleges and universities might have decentralized IT and payment environments. Campuses might have relationships with more than one acquirer or payment processor, and independent campus groups may use the college or university name but have separate financial processes. And sometimes the full extent of payment operations is unknown, or key campus leaders might not be aware of PCI compliance expectations.

The new PCI Data Security Standard (PCI DSS v3.0) has an impact on information security at colleges and universities, and security professionals need to stay on top of the recent updates and deadlines to ensure protection of their organizations. The changes are not dramatic, but the new standards offer many clarifications, real-life examples, and flexibility that allow merchants to meet the intent of the requirements. The major updates in PCI DSS 3.0 include education awareness, continuous compliance ("business as usual"), and security as a shared responsibility.

Major PCI DSS 3.0 Drivers

Key drivers behind the changes in the PCI DSS standard include the need for education, the need to make compliance a normal practice, and making security a shared responsibility.

Education

One major driver that led to the new version stems from the PCI Security Standards Council's insight into the lack of education as a key contributor to many security breaches. The new standard emphasizes intent and proper implementation of controls. Awareness of the problem and education on how to ensure proper attention to these issues are an absolute must. The PCI DSS 3.0 highlights the need to establish a culture of security through more education to maintain accountability throughout the institution. It also points out the need for processes to ensure that payments are secure, rather than only a confirmation that a merchant has a specific security technology in place.

Compliance

Another key change for merchants is the need to make PCI compliance a normal practice. The new version added a "Best Practices for Implementing PCI" section with the purpose of turning it into a business-as-usual process. It recommends that organizations make PCI DSS compliance activities continuous rather than an annual, point-in-time validation exercise. In the past and still today, many organizations never considered PCI's requirements full-time changes. Instead, many would go into a panic mode shortly before their assessor arrived each year, attempting to cram a year's worth of PCI preparation into a month or two. The business-as-usual practice addresses this issue.

Best practices include:

• Monitoring of security controls
• Detecting and responding to failures in security controls
• Reviewing all changes to your environment
• Considering organizational structure changes
• Conducting periodic reviews, to include annual hardware/software review

The monitoring of security controls — such as firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), file-integrity monitoring (FIM), antivirus, access controls, etc. — is crucial to ensure they operate effectively and as intended.

Processes to detect and respond to security control failures should include:

• Restoring the security control
• Identifying the cause of failure
• Identifying and addressing any security issues that arose during the failure of the security control
• Implementing mitigation (such as process or technical controls) to prevent the cause of the failure from recurring
• Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating effectively

You'll need to review changes to your environment, such as the addition of new systems, changes in system or network configurations, etc. prior to completion of the change, and then perform the following tasks:

• Determine the potential impact to PCI DSS scope (for example, a new firewall rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS)
• Identify PCI DSS requirements applicable to systems and networks affected by the changes (for example, if a new system is in scope for PCI DSS, it would need to be configured per system configuration standards, including FIM, AV, patches, audit logging, etc., and would need to be added to the quarterly vulnerability scan schedule)
• Update PCI DSS scope and implement security controls as appropriate

Review hardware and software technologies at least annually to confirm that the vendor continues to support them and they meet your security requirements, including PCI DSS. If you discover that technologies are no longer supported by the vendor or cannot meet your security needs, you should prepare a remediation plan, up to and including replacement of the technology, as necessary.

Security

Increased recognition of the business and technical complexity within today's payment environment is one of the drivers for the new emphasis on shared responsibilities for security and control among business partners. Merchants and service provides express confusion about responsibilities for security. The new version adds guidance to service providers and merchants to ensure that responsibilities are fully understood and documented. The merchant can't outsource accountability because it has shared responsibility with the service provider to comply with the PCI standards.

An emphasis on shared responsibilities requires these elements:

• Managing PCI compliance on campus as not just an "IT" or "finance" issue
• Good compliance programs that establish responsibilities across campus and require buy-in from all impacted entities
• A PCI risk management function that can help build awareness and responsibility
• Important representatives to lead this function, including from finance/treasury, IT, general counsel/legal, and information security to set the tone for compliance (figure 1)
• Agreement on preferred credit card processing methods

Buy-in through a Cross-Campus Council

Program management requires special talents that no one person can provide. Compliance requires a team effort with collaboration between merchants and campus leadership. Because PCI compliance results from ongoing, effective security processes and a solid risk management program, it's vital to include all stakeholders. The PCI risk management function objectives and best practices include:

• Ensure that risks associated with campus card processing are understood and appropriately managed
• Document accountability of merchant entities for their compliance and for any additional risks they assume in their processes
• Create a dialogue and mechanisms for PCI compliance issues among campus merchants
• Allow merchants to have a voice in PCI risk management issues
• Encourage cooperation between merchants to find common solutions
• Build a vehicle for education on important topics and issues
• Foster a sense of community: "We are in this together"

The PCI DSS 3.0 also includes requirements to increase awareness of the Cardholder Data Environment (CDE) definition. Most organizations tend to underestimate the size and scope of their CDE and overestimate their level of control. New requirements in PCI DSS 3.0 focus on building total awareness of your CDE components: you must have an accurate payment flow diagram and an accurate inventory of all systems in the CDE (figure 2).

What about service providers and the PCI DSS 3.0? Using a third-party service provider does not exclude you from PCI compliance responsibilities. It may cut down on your risk exposure, reduce scope, and consequently reduce efforts to validate compliance, but it does not mean you can ignore PCI compliance. To keep you (and your service providers) honest, the PCI DSS 3.0 now includes an interesting requirement:

PCI DSS 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

What does this mean? Well, traditionally you (the merchant) just needed to verify that your service providers were PCI compliant. Get an attestation of compliance (AOC) letter and you're good. See your service provider's product listed on Visa's PCI-certified service provider registry? You're good. With the DSS 3.0, that's not necessarily good enough, especially if you rely on a third-party service provider for managed services, hosted services, or managed operations. Now you have to pinpoint precisely which DSS controls your service providers manage, which controls your organization manages, and which controls are co-managed between you and your service provider.

This can be especially challenging for campuses that rely on internal service provider organizations to deliver a part of the CDE, like your centralized campus computing group (who may be managing your firewalls, network, or data center). Just be sure to keep an open dialogue with all your service provider entities to work through these issues. As the DSS 3.0 is implemented across the industry, your IT department is likely to create standard messages for compliance to help you (and them) resolve questions about control responsibility. Of course, consulting a qualified security assessor (QSA) to help negotiate these issues is never a bad idea.

PCI DSS 3.0 Changes and Higher Education

The updates in PCI DSS 3.0 affect all merchants, but specific changes have greater importance for higher education.

• Expanded penetration testing expectations. The penetration testing requirements are much more detailed and now require testing to validate segmentation technologies (best practice until July 2015). Criticized for the lack of a common definition and consistent assessment approach for years, DSS 3.0 finally calls for a methodology to be in place to achieve consistency in penetration testing results. Without an industry-standard methodology, anything can be passed off as a penetration test as long as the QSA signs off on it.
• Protect devices that capture card data from physical tampering. This applies to swipe or "dip" devices that read magnetic or chip data on the card. You must maintain a list of all such devices, train employees to recognize modifications, and periodically inspect devices for tampering. This update focuses on better training and oversight of point-of-sale (POS) devices in order to reduce tampering and theft. This requirement could potentially have a significant impact on many organizations, but some of the changes might be ineffective because of pressure to make the requirement flexible to avoid having a costly impact on the merchant.
• Key management and anti-virus updates. The key management testing procedures outlined in PCI DSS requirements 3.5 and 3.6 have been modified and clarified. Organizations must now fully understand the entire key-management lifecycle for all encryption keys used to protect cardholder data at rest. Requirement 5, anti-virus updates, indicates that you must now "evaluate evolving malware threats" for systems not typically affected by malware.
• Logging requirements. For new logging events, an enhanced logging requirement includes stopping or pausing of the audit logs. Daily log review requirements for critical components have been split into two categories: critical systems and "everything else."

What's Missing, and What Are the Deadlines?

Some areas that might have been expanded or included within the new 3.0 requirements were mobile OS/mobile payment acceptance and cloud/virtualization requirements. Technologies like mobile and cloud could use some standards that QSAs can assess against to create a solid baseline from which to improve. Another promising technology is point-to-point encryption (P2PE). Using P2PE, merchants can significantly reduce their risk and save time and money on their PCI compliance assessments. It's important to note that these solutions must be implemented carefully and in accordance with a whole new set of standards governing P2PE. Let's not forget that there will still be controls needed before and after encryption occurs. The process of moving from traditional in-house systems of various hardware and software components to a secure model that promotes outsourcing key processes to offsite data centers and the cloud is a technology trend that's here to stay.

Some of the requirements outlined in the initial PCI DSS 3.0 draft were dropped from the final version released in November, including this notable line: "Document how cardholder data is handled securely in memory." Speaking of memory, remember that you're allowed to validate on the PCI DSS 2.0 standard through the end of 2014; however, as of January 1, 2015, the 2.0 version will no longer be accepted. The PCI DSS 3.0 self-assessment questionnaires (SAQs) were released in February 2014. While there's no specific language that requires organizations to take a risk-based approach to security, merchants — definitely including those in higher education environments — should move to this approach sooner rather than later.