In this tip, we explore the third major requirement of PCI DSS: maintaining a vulnerability management program. This portion of the standard contains requirements covering antivirus software, secure coding, patch management and change control. As with all of the tips in our PCI DSS series, remember that there is no substitute for an in-depth reading of the entire PCI Data Security Standard.
SERVER, WORKSTATION ANTIVIRUS REQUIRED
You're probably not particularly surprised to learn that PCI DSS requires the use of antivirus software, but you should pay attention to the scope of this requirement. First, it applies to personal workstations and servers alike. Second, it requires that you regularly update your signatures (daily updates would be ideal, but are not required), perform periodic scans and generate logs that feed into your PCI DSS log management program.
The bottom line here for most organizations is that you'll need to ensure you adopt formal antivirus management practices. If you're already using a centralized antivirus management system, you're probably all set on this account. Otherwise, you may wish to save a lot of elbow grease by implementing such a system in your organization.
CRITICAL PATCH UPDATES MUST BE INSTALLED PROMPTLY
Staying compliant with PCI DSS requires that you regularly patch operating systems and applications when new security flaws are discovered. To do this, you'll need to stay abreast of security vulnerability announcements for all of the products you use. Subscribe to the security mailing lists published by your vendors and consider using a vulnerability monitoring service, such as the free Cassandra service offered by Purdue University.
When a vendor releases a critical security patch, PCI DSS gives you one month to install it on your systems. There's a little wiggle room in this requirement, as the standard allows you to use a "risk-based approach." The example offered by the PCI Security Standards Council proposes applying patches to critical infrastructure systems within one month and other systems within three months.
6 SECURE CODING BEST PRACTICES
This is a biggie. If you're developing software for your card processing environment, you'll need to comply with a number of secure coding practices. These requirements can be so onerous that I must first prompt you to ask yourself whether it's absolutely necessary to write your own card processing software, rather than purchasing an off-the-shelf solution that is Payment Application Data Security Standard (PA-DSS) certified. If you must develop your software, here's a sample of the requirements you'll need to follow:
- Test all changes prior to deployment to ensure input validation, error handling, secure cryptographic practices for storage and transmission, and proper implementation of role-based access controls.
- Maintain separate development/test and production environments, ensuring real credit card information is only used in production environments and any test accounts are removed prior to go-live.
- Enforce separation of duties between development/test and production environments.
- Code review prior to go-live.
- For Web applications, follow the guidelines in the Open Web Application Security Project Guide.
- Also for Web applications, either perform code reviews (via manual or automated techniques) each time you change the application or install a Web application firewall.
Again, the requirements and standards for developing your own card processing software are rigorous, and for good reason. This is not something to attempt unless you are serious about secure coding practices and willing to make a significant investment in software development and testing.
DOCUMENT SYSTEM CHANGES
The last major requirement introduced in this section of PCI DSS is that you follow industry standard change management practices each time you make a change to any system in the card processing environment. These practices must include a documentation of the change's impact, management approval of the change and testing/back-out procedures.
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a contributor to SearchMidmarketSecurity.com, a technical editor for Information Security magazine and the author of several information security titles, including the "CISSP Prep Guide" and "Information Security Illuminated."
Send comments on this technical tip editor@searchmidmarketsecurity.com.
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.
