PCI-DSS requires organizations subjected to compliance to deliver three specific trainings, namely: Security Awareness, Secure Coding and Incident response. This newsletter describes what you should know about them in terms of What, Who and How.
Associated PCI DSS requirement: 12.6
Audience: Any individual having access to data or system components part of the PCI scope.
Objectives: In all domains, awareness of the risks and available safeguards are the first line of defense. According to NIST Special Publication 800-16, awareness is not training. The purpose of awareness presentations is simply to focus attention on security. Awareness relies on reaching broad audiences with attractive packaging techniques. Training is more formal, having a goal of building knowledge and skills to facilitate the job performance. Having said that the objective of a security awareness is to focus attention of individuals on the threats they could potentially face in their day to day job, their critical position and vulnerabilities within the security chain, get their deliberate collaboration, make them understand the security rules (policies and procedures) and the importance of applying and respecting them in their day to day activities.
Associated PCI DSS Controls:
- Organizations must Implement a formal security awareness program. The program must be endorsed by the senior management, be documented and address at least the following topics: Audience, content, channel of communication and supporting materials (multiple methods of communicating awareness and educating personnel is required), execution plan, and measures of quality.
- Organizations must ensure that personnel attend awareness training upon hire and at least annually.
- All personnel must acknowledge, in writing or electronically, at least annually that they have read and understand the information security policy.
Associated QSA Validation processes: Compliance with these controls is validated through the review of the documentation (Security Awareness Program and associated procedures), acknowledgment forms and personnel interviews.
Note: My personal opinion is that the majority of security awareness sessions are quite boring! They don't talk the users language and don't address their concerns. It's then not a surprise that the majority of users behaves gingerly when called to duty. The security awareness sessions talk about security and rules, a subject that, let's be honest here, bother the majority of the people. In such conditions, what is the best way to get them engaged, retaining the information and more importantly get them willingly to change their mind, behavior and applying the rules? For me, the best way is to make sure that have they have fun, enjoying the moment, spending a good times and therefore the main driver of this session should not be the content but the way we are communicating it. When I'm giving such sessions I make sure to apply the following quotes :
"If you can't explain a concept to a six years old child, it's because you don't understand and master it yourself" – Alfred Einstein
"Nothing is definitely lost while there is a good story to tell" – Alexandro Baricco.
"You cannot teach a man anything. You can only help him discover it within himself." - Galileo Galilei
So use simple concepts, simple words that a six years old child would understand. Make humor your strengths and tell a lot of exciting stories.
Associated Requirement: 6.5 - Develop applications based on secure coding guidelines.
Audience: Developers of custom application used within the PCI scope.
Objectives: Ensure that developers understand the threats when it comes to building secure applications and are aware of common application security threats in applications today.
Associated PCI-DSS Controls:
- Organizations software development processes must incorporate training in secure coding techniques for developers based on industry best practices and guidance. These trainings must be applicable to the particular technology in their environment. This control applies to any developers of (Web or no Web related applications) applications. There are however no requirement in terms of renewal of this training or follow up such as for the security awareness.
Associated QSA Validation processes: Compliance with this control is validated by:
- Verifying that the software development processes require training in secure coding techniques for developers, based on industry best practices and guidance.
- Identifying the industry best practices and guidance that training is based on.
- Interviewing developers to test their knowledge in secure development techniques.
Here as well we have "carte-blanche" in what concerns the content and the delivery form (on-site, Webcast, self-study,…). The problem that many businesses are facing, however, is, "What is a Secure Coding training and where can I get it?
“The essence of training is to allow error without consequence.”― Orson Scott Card, Ender's Game
Secure coding is the practice of writing programs that are resistant to attack by malicious or mischievous people or programs. Most secure coding trainings that you can find within the context of PCI are based on OWASP Top 10 guide but don't get it wrong as this control does not limit itself to Web application. The training must be aligned with the development technology used internally (C, C++, Java, perl, php,…). It must cover the most common programming flaws that affect that technology as well as provide secure solutions to coding problems.
Associated requirements:12.9.4 - Provide appropriate training to staff with security breach response responsibilities.
Audience: Staff who are responsible for managing incident response.
Objectives: Ensures they are properly trained on how your organization should handle incidents.
Associated PCI-DSS Controls:
- Security policies must incorporate a statement requiring that staff with responsibilities for security breach response are periodically trained.
- Security incident response procedures must indicate what need to be done to manage and respond to incidents.
- The Incident response plan/procedure must be tested annually. This could consist in the training itself!
Associated QSA Validation process: Compliance with this control is validated by:
- Verifying that the incident response plan includes: Roles, responsibilities, and communication strategies, specific incident response procedures, business recovery and continuity procedures
- Interviewing personnel to confirm that the incident response plan is tested according to the defined procedures
- Reviewing document requiring that staff with security breach responsibilities are periodically trained.
- Interviewing personnel to test their level of knowledge of the incident response procedure.
Strangely enough, one could have expected that the PCI-DSS training catalog be more voluminous. Indeed nothing is required for individuals with system and security administrative, operational or managing roles such as system administrators, network administrators, security operators, vulnerability managers, risk manager, and even CISO. Probably a forgivable oversight from the Council that could be filled in a near future. Stay tuned!
To close this newsletter let me quote Veronica Roth in "Insurgent" - “No matter how long you train someone to be brave, you never know if they are or not until something real happens.”
- See Viega and McGraw, Building Secure Software, Addison Wesley, 2002; for a general discussion of secure programming, especially as it relates to C programming and writing scripts.
- See Wheeler, Secure Programming for Linux and Unix HOWTO, available at http://www.dwheeler.com/secure-programs/; for discussions of several types of security vulnerabilities and programming tips for UNIX-based operating systems, most of which apply to OS X.
See Cranor and Garfinkel, Security and Usability: Designing Secure Systems that People Can Use, O’Reilly, 2005; for information on writing user interfaces that enhance security.
What's your opinion on this topic?
What's your field experience with these requirements?
Did you read our previous newsletter: PCI 30 seconds newsletter #29 - Do all PCI DSS requirements apply?