 |
 |
 |
Introduction
Working with PCI compliance is more challenging than ever for organizations globally. Verizon reports in it’s latest payment security report that “15 years after the launch of the PCI DSS … just over a third (36.7%) of organizations were actively maintaining PCI DSS programs in 2018.” The report cites several key failures by members in not measuring control effectiveness, following an unchanging compliance script and approaching compliance as a box ticking exercise.
In my experience, working in security on compliance programs for the last 25 years, here are 10 must have steps that every organization should pursue to make material changes to their compliance posture.
1. Strong Contracts
Prevention is the best remedy. Weak, ambiguous or non-existent contracts with third parties, particularly with ones handling your customer data can cost you when there’s a data loss incident. Without clear definition of whose responsible for what in contracts, along with who else and where else your data goes, can have serious consequences when you starting incurring costs for investigations and probes from financial and data protection authorities and various penalties from the card brands. Doubly so, if card data is compromised negligently. I like this link from Andy Roth about privacy and security language in contracts. It mentions the right to audit in contracts, this is often overlooked and without it, your flying blind when it comes to vendor security.
2. Documentation
Documentation is an expansive area in the context of IT in most medium to large size organisations. In the context of PCI compliance, the first words out of an assessors lips are, show me your network diagrams including firewalls and the card data environment. The second might be, show me an inventory of devices in PCI scope (assuming you have agreed a scope). Then we can talk about your acceptable use policies, code build and release polices and much more. Many companies fail to clearly define the card data flows, as required by PCI-DSS and overlook components such as POS terminals, vendor CPE equipment or forget about ESX hosts, hosting PCI related VMs. PCI Documentation, needs serious planning, down to justification for each rule or ACL on firewalls and switches. Your change management process must be robust in that all changes requiring approval must demonstrate that documentation has been updated, particularly in PCI world.
3. Security as BAU
Gone are the days of I’ll wait till patch Tuesday and we’ll all be ok again. The Verizon PCI Report says it clearly that “Sustainability [of compliance] is low” as companies don’t have robust procedures in place for managing and maintaining it. I see this too and as a result I’m a strong believer in automating the mundane as much as possible. SOC’s, analysts and helpdesk personnel become snow-blind to performing daily tasks such as checking firewall, IPS, IIS and file integrity logs or application security logs. I’ve had success with automating the checks process using point and click forms based entry system with dashboard reporting. When combined with taking the time to map out your PCI estate (hence the importance of good documentation) and throwing more than just a week of integration effort to get actionable security data, you might be on to something. Just remember that in PCI terms, anything that stores, processes or transmits PCI data is in scope, all of the nodes in the chain have to monitored daily,
4. Patching
While it doesn’t evoke a sense of patching being a new thing, what is new, is that if your systems are compromised in the PCI-Zone due to some malware for instance, technically your into PCI breach category with notification to the card issuer and/or data protection office, Lovely!!, The devil is in the detail with patching, so, how are you managing patching of that telephony server that’s managed by your provider that you don’t have credentials for?, how about that java version dependent application in your CDE or that unsupported browser you found on 10% of machines in the user estate. With PCI 3.x, your company culture has to change to a military style discipline in many cases. Patching is not just a technology challenge, it must be enabled by provisions in vendor contracts, awareness efforts and good documentation.
5. Governance
Following on from company culture in the previous must-do. PCI compliance is not the exclusive prevail of IT, a collaborative approach works when one foot knows what the other is doing. In my experience, heads of compliance, risk, security, vendor management, HR and legal must have joined up thinking on the PCI-compliance challenge. HR will have to be involved in training, advising staff on not using phones in customer call centres for example. Legal on the contracts side of things for examples. Processes must be established with an overall owner e.g. CIO that factor in the 12 areas of PCI compliance. IT will not be the ones nominated to speak to the media if a breach does happen..
6. Pen Testing Methodology
If you haven’t read the latest PCI standard 3.2.1, might be a good time to refresh your knowledge on testing requirements particularly on pen testing. Having taken the SANS web app pen testing training myself, I can safely say that pen testing needs special attention after 6 days of intensive class. The rules state that internal and external pen testing must be performed on CDE applications at least annually and/or after any significant application changes. It must follow a “Methodology eg. SP800-15”, must test for segmentation and be performed by a qualified individual. Skipping some details here, but your testing should not be just be your testers report. Plan your pen test schedule well in advance (pen testers are busy people), ensure it conforms to a standard like SP800 which should be reflected in your policy suite. Ensure that your application development processes are designed with OWASP vulnerabilities in mind so as to mitigate vulnerabilities when testing does occur. Remember here that the standard requires that you pen test the network as well as applications, important to remember in your scoping exercise.
7. Software Development
In a word “Training” supported by tools. The development lifecycle and security issues are timeless. Whether it’s lack of formal security gates in the development lifecycle, lack of documentation on workflows, business pressure to get products out the door or the lack of understanding between security and development teams. The fundamental 1st line of defense is training and processes. So many problems are avoidable by using targeted training of developers, testers, business analysts and end users. Familiarizing teams with the OWASP top 10 attacks, common misconfigurations and tools like Burp and Nikto which can be run internally independently of Security. Of course with PCI 3.x, more expensive code verification tools like Veracode and Quotium have come in to play, but this has become the cost of doing business. Security is often understaffed or lacking the knowledge to support developers properly, hence the importance of external and frequent training. Exploits are being found with a frequency now, your developers need to be kept up to date on them.
8. Logging
Logging could take up its own standard but from the point of PCI compliance there are a few things often overlooked. ESX hosts, firewall OS, access switches, building security management systems, SCADA type systems (remember anything connected to the CDE), domain controllers, 3rd party edge switches and servers in your CDE and even RACF logs. QSAs will undoubtedly focus on remote access logging, firewall intrusion attempts and IIS logs for payment systems. Often companies will get caught up in sporadic weeks of integration work while not having an overall map of where all known log sources are, and defining what’s relevant. This is where your network discovery tools and detailed documentation of network assets comes in. Factor in that most companies misjudge the volume of traffic generated by firewalls alone, careful attention needs to be paid to message rate calculation.
9. Red Team Exercises
If you want assurance, you’ll want a red team exercise. This is the matrix moment where Morpheus says to Neo “Show Me”. SANS has a nice write-up on Red Team exercises as a critical control. This is closely related to item 6 on my list, but it need it’s own space as many organisations are not battle hardened against real-world attacks (albeit by White Hat attackers in this case). Nothing impresses a CEO more than when he/she asks, “are we secure” then when you respond with a red team test results and remediations completed.
10. Collaboration
Having worked in the States with industry security organisations like InfraGard and industry roundtables, I can’t stress enough how important the value of cross pollination of ideas. It’s much of a human nature approach to internalise problems but in reality discussions (under NDA if need be) with peer organisations and government rep’s on a first name basis can save so much time and avoid costly mistakes. To that end attendance, at industry events and participation in roundtables yield benefits. Better to get off the island and meet the neighbors.
