September 2016 marks the 10-year anniversary of the Payment Card Industry Security Standards Council, a group created by the major card brands to manage the Payment Card Industry Data Security Standard (PCI DSS). Any business that stores, processes or transmits payment card information must comply with the PCI DSS. Through the enforcement of the Standard, the Council has set the bar for payment card data protection, although that bar marks the beginning of the road, not the end. Companies that solely strive to “check the box” in order to comply with the PCI DSS are selling themselves short and exposing themselves and their customers to a potentially catastrophic breach. As threats become more sophisticated and environments more complex, companies need to implement a process that focuses on cybersecurity first, making PCI DSS compliance inherent. However, many companies still struggle to achieve that goal, mainly due to the effort and cost involved.
Merchants that manage large, distributed, legacy environments, including proprietary point-of-sale systems that are in hundreds of stores, face significant challenges updating those technologies so that they continue to comply with the evolving PCI DSS requirements. For example, PCI DSS 3.0 requires merchants perform annual penetration tests to validate that segmentation methods used to separate the cardholder environment are “operational and effective.” For large merchants, that often includes the legacies of acquired companies and their infrastructure with distributed networks nationwide. Testing and evaluating the segmentation methods used across all of those networks can be a time-consuming and trying task.
Companies also face challenges when it comes to compliance reporting. Historically, security teams were never focused on reporting results in a structured way. They were focused on protecting the business. Gathering and making sense of a large amount of data to report to auditors is a resource-intensive, time-consuming, error-prone effort. In many cases, security and compliance teams collect the data manually, filling out spreadsheets which are stitched together into other spreadsheets. The manual process creates a major distraction, forcing them to take their eye off the ball of protection so that they can pull together spreadsheets and send out emails. Throughout the process, errors and bias will inevitably be introduced, so that it “fits” together. In some cases, the process takes so much time and effort, companies wait until the last minute and end up having to use outdated data to fill the gaps because they could not complete it on time.
The PCI DSS has created a baseline for security, and the requirements provide companies with a starting point for best security practices. However, as the Standard continues to evolve, companies must work on simplifying the implementation of a consistent PCI DSS compliance process. First, they must use automation. They must automate how they collect and make sense of their cyber risk data so that reporting is truthful, traceable and everyone involved is working off the same set of numbers. Automation is critical not just for compliance reporting to auditors, but also for IT and security executives, application owners and boards of directors to understand how well they are protecting their crown jewels.
Adhering to compliance requirements should also not solely fall on the security and/or compliance team’s shoulders. The PCI-DSS compliance process requires coordination between compliance, security, IT and the line-of-business application owners. Oftentimes the dance between these many parties is broken, resulting in firefighting and last-minute reactive activity. To stay ahead of the game, line-of-business application owners should be made an integral part of protecting the applications and data that they own, and not just a peripheral sign-off along the way.
Unfortunately, the challenges organizations face with complying with changing PCI DSS requirements will not change. As threats evolve and business environments become more complex, the PCI DSS must change as well to help organizations better protect cardholder data. However, if organizations focus on cybersecurity first, fulfilling changing compliance requirements would come more easily. For example, using two-factor authentication for remote access to a company’s network is a security best practice and a PCI DSS requirement. If organizations implemented two-factor authentication from the get-go, before it became a PCI DSS requirement, they would not have needed to make any changes once it became one. Having the right cybersecurity processes and methodologies in place, outside of complying with the PCI DSS, will minimize business disruption when inevitable changes to the Standard take place.
Steven Grossman is Vice President of Program Management at Bay Dynamics. Steven has more than 20 years of management consulting and industry experience working with technology, security and business executives. At Bay Dynamics, Steven is responsible for ensuring businesses are successful in achieving their security and risk management goals. Prior to Bay Dynamics, Steven held senior positions at top-tier consultancies such as PwC and EMC, where he architected and managed programs focused on security, risk, business intelligence/big data analytics, enterprise Program Management Offices, corporate legal operations, data privacy, cloud architecture and business continuity planning for global clients in the financial services and health care industries. Steven holds a B.A. in Economics and Computer Science from Queens College and has achieved his CISSP certification.
