Turning boring PCI-DSS compliance into a meaningful exercise for everybody: Part 1 - AppSec16th April 2020
This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.
The word “compliance” isn’t very exciting. It’s formal, dry, directive… even a little restrictive in its tone. If it had a color, it would be beige. And, well, it seems at odds with any sort of creative environment or innovation.
As a developer myself, my experience of ‘being compliant’ usually meant (vertically) reading through some guidelines or watching a presentation, before going back to coding features and focusing on creating software that customers will use and love. Everyone retains what they can in the moment (and tries to do the right thing at all times), but compliance guidelines -- especially those surrounding security best practice -- are not typically written with developers as the target audience, and any required actions can be unclear. In that scenario, it’s all too easy to just stay on-task with current objectives.
The thing is, secure software development is no longer a “nice to have” in any company; it is (or should be) front-of-mind in every organization… and if it’s holding vast amounts of sensitive customer information, then that company is ripe for the picking when it comes to cyberattacks. Developers are the first to get hands-on with code, and as such, should be just as involved as the rest of the team in any security compliance measures.
But, wait… hear me out. This doesn’t mean everyone has to become a slave to rigid, creativity-free development and software outcomes. It means the business has the opportunity and power to create a higher standard of code, together. Ever so slowly, the world is catching up to the fact that, to date, developers haven’t exactly had the right tools at their disposal to make security a priority (and siloed security specialists cannot shoulder the responsibility alone). However, as the industry moves towards a DevSecOps future with security as a shared responsibility, they can help stem the flow of recurring vulnerabilities when set up for success.
The PCI-DSS guidelines cover online security compliance for card payment gateways - a service most of us use on a regular basis. These guidelines are globally applicable, and they have actually outlined in detail what developers must do to maintain standards in-line with their mandates, alongside several compliance documents across aspects of eCommerce business.
Data breaches are scary, reputation-destroying risks that businesses can ill-afford, and with Cyber Security Ventures tipping zero-day breaches to reach one per day in 2021, this is something that everyone in the software delivery process can help fight.
Let’s break down the PCI-DSS recommendations, and how they can work across the team:
Hey, AppSec and Compliance teams: All developer training is not created equal
Developers in large (or even small) organizations rarely have a whole lot of input into the training they receive on-the-job. In order to retain star employees, some companies do offer comprehensive programs, but these are still less common than they should be. A need for security training presents a great opportunity to not only kick-off organizational compliance without boring everyone to tears, but also start to warm up any frosty relationships with the development team.
In terms of PCI compliance, you can see that their guidelines are specific as to the outcomes they would expect from any software running payment gateways; among other objectives, they want applications hardened (vital for thwarting malicious code injection or tampering), least-privilege controls and full-scale awareness of common vulnerabilities… at a minimum. All personnel working with cardholder data must be adequately trained, and for developers, that training can make or break their success in writing secure code from the start of their process.
The official Best Practices for Maintaining PCI-DSS Compliance document details some direct concepts around security awareness, developer needs, and appropriate training, like:
Examples of Evidence
6.5. Address common coding
vulnerabilities in software development processes as follows:
The testing procedures for secure code development requires identification of training records as well as the personnel responsible for reviewing and addressing common coding vulnerabilities.
Simply providing a policy document that requires developers to participate in secure development training courses is not sufficient to demonstrate that the training has happened.
It is a common scenario that organizations do not rely on a single development platform or language; organizations commonly utilize multiple types of Software Development Kits (SDKs) to support their payment card processes.
Therefore, development staff should be adequately trained to understand the inherent vulnerabilities of each development platform and language utilized to support the organization’s payment card processes.
To that extent, a coding standard for one of the development languages is not adequate evidence that coding guidelines exist for all platforms and languages used by the organization.
Copyright © 2006 - 2020 PCI Security Standards Council, LLC. All rights reserved.
This gives insight into the specific, in-depth training required to arm developers with the necessary skills, but still doesn’t point to any particular types of educational solutions as more effective than another. The PCI-DSS Guide for Developers gets a little more direct, identifying the OWASP Top 10 as one benchmark for learning to find and fix the most common vulnerabilities, as well as some certification programs.
But… here’s the rub. As you would no doubt know from various workplace training and compliance initiatives, they can vary wildly in quality and future success. And when it comes to developers, so many secure coding training programs don’t seem to cater to our needs, ways of working or even our day-to-day jobs in any meaningful capacity. In this scenario, not all training is created equal, and not all training is going to result in software that is more secure. This is, of course, the exact opposite of your desired outcome, and won’t make the stress of your own job reduce in any significant measure. If you want to reduce the burden and stop common vulnerabilities from causing potential disasters, you’ll need to build a bridge.
Bridging the security skills gap with engineering managers on your side
Working directly with engineering managers to find a solution that is fit for purpose, while still being embraced by the people who actually have to do it, is a fast-track to positive security outcomes. They will have more immediate insights into their own team, and can speak to any blockers that have previously made compliance training difficult (other than it not being a great experience, most of the time).
Classroom-based training, video-on-demand and any once-off, tick-the-box exercises make staying current very difficult; these are static solutions that cannot keep pace with the ever-changing landscape that is the cybersecurity industry. Ultimately, the engineering manager will want to see value for the time commitment, and it’s important to work with them and provide viable options that work to meet everyone’s shared goal: code that is more secure and compliant.
So, what does good training look like? There is very little point to learning how to code securely via big, once-off hits of information. A bite-sized, gradual learning process makes it far easier to remember and apply in-context, and it absolutely must be in the languages and frameworks used every day. Personally, I want to be challenged, and I want to see a purpose for my efforts - we’re all busy enough as it is, right?
To comply with the PCI-DSS best practices outlined above, depending on the solution chosen, managers might find themselves a having to stitch together a patchwork of different courses to cover all languages and frameworks used across the business, and that’s when things get very messy, not to mention difficult for AppSec and compliance teams to assess as making an impact on security and vulnerability reduction in software. Work together to find the right fit, instead of rushing into the wrong option chasing a fast result. Otherwise, you might end up with a Frankenstein training solution… and that looks very scary.
Thanks for checking out part one of this PCI-DSS mini-series. In the final chapter, we will discuss how CISOs and CTOs can help this culture transformation, enable teams, and how the security front lines – your developer cohort – can use PCI-DSS awareness and compliance to their advantage.