The PCI DSS standard ostensibly only has a few training requirements which, in my experience, most organizations do a good job of keeping up with. However, there are some not-so-obvious teams which get regularly overlooked with regard to training. So here are some thoughts to help you ensure that you address all training needs at least annually, per the PCI DSS standard.
First there is the obvious 12.6 requirement for a security awareness program which must “provide[s] multiple methods of communicating awareness and educating personnel”. For whom this training is required is never quite enunciated. Frankly, I think that all staff should be included since any person, even if they are not associated with the CDE, can get phished and bring in malware that provides a bridgehead into the CDE, or disclose information helpful to the bad guys just by observation or gossiping. The Heating, Ventilation, and Air Conditioning (HVAC) contractors changing filters for your data center, or the janitors cleaning it, probably have just as much sensitive area access as the administrator replacing a disk. Even if your implementation is wholly within a cloud provider or a co-lo data center, everyone needs to be able to recognize and understand the facility controls that protect Cardholder Data (CHD), and be able to notify the Incident Response team that something is going wrong.
Next we have the developers (which encompasses both systems builders and code developers) who need training specific to their assignments.
The systems builders, firewall rule developers, and administrators need to demonstrate “knowledge of common security parameter settings for system components” (Requirement 2.4). There is a separate blog on what I consider this to encompass, since some parameters are covered explicitly elsewhere in the standard.
It is not enough just to train developers in OWASP top 10, if any of them are working on server code, API’s for database stored procedures, securing access to the database, or iOS and Android mobile applications enabling ordering and payment. Each of these developers needs specific training regarding architecting for security and the security impact of the tools and languages they use to perform their tasks.
Code reviewers have to demonstrate that they are “knowledgeable about code review techniques and secure coding practices”. The quality assurance team (who are also reviewers of the development process) need to know such issues as how to declare or recognize threat surfaces, and how to model threats to ensure their reviews and tests cover as many eventualities as possible.
Therefore, the QSA should want to see specific technology security-related training for the DBA(s), the code reviewers, and the QA team(s), only one of whom is explicitly mentioned in the DSS.
Let’s not forget the Incident Response and Breach response teams who need training on how to respond to and diagnose incidents, communicate with any external source of incident reports, and write up the lessons learned after each incident.
Finally, the teams performing your penetration, vulnerability and segmentation tests all have to be able to demonstrate that they are “qualified to perform” such tests. So this implies regular training in current scanning priorities, and techniques to ensure a comprehensive result. If you use a third-party, have them detail their qualifications in their report and some kind of attestation that they have taken relevant training within the previous 12 months.
Truvantis is a PCI QSA company, ready and willing to assist you in making the best decisions to minimize your compliance burden for a new implementation, or provide an assessment of your compliance in addressing all the PCI DSS requirements if you have a more mature environment.