Ask the Auditor: PCI Requirements 5 and 6
by Sarah Harvey / October 15th, 2015
As a PCI Qualified Security Assessor (QSA), we receive a lot of questions and concerns from clients who are just stepping into their first PCI assessment, particularly around PCI Requirements 5 and 6; maintaining a vulnerability management program.
We have recently sat down with one of our own QSA’s, Steve McEnroe, QSA, CISA, to answer some of the major questions we commonly hear. Here are the highlights from the interview:
Q: In regards to Requirement 5, do you recommend having the “periodic evaluations to identify and evaluate evolving malware threats” performed by a third party? Or should they be done internally?
A: This is something that is typically done internally and should be part of your ongoing Risk Assessment process. Keep up with evolving threats and be aware of industry developments and the potential threats your business may face. A lot of this information is distributed through various vendor websites and even mainstream media. Threats will also be identified through your ongoing scanning and penetration testing, which falls under Requirement 11 of the DSS, but certainly applies here.
Q: At a minimum, how often would you recommend periodic scans be performed? Why?
A: A full server scan is typically performed once a week, during off-business hours. Scanning of any work stations that are in scope should be done more frequently, and typically on a nightly basis. A lot of anti-virus and malware systems now have live, real-time scanning where workstations are being constantly evaluated. Why? Workstations are inherently a weak point because people are using them, and people are the weakest link in your security.
Q: What are some examples of instances where it may be okay to temporarily disable your anti-virus solution?
A: Occasionally it may be necessary if you need to install a particular software package. That should be a very temporary situation, and you should re-engage anti-virus software as soon as you’re finished with the installation.
Q: What are your thoughts on how often these “security policies and operational procedures for protecting systems against malware” should be updated?
A: All policies and procedures should be reviewed and updated at least annually. All documentation should contain a revision history so that your QSA can see the different phases the document has gone through. Anytime there is any significant change to the environment, at a technical or business level, your documented procedures should be updated. This is applicable to PCI Requirements 5 and 6.
Q: How often should organizations be checking to identify security vulnerabilities?
A: It’s really an ongoing process, but you want to be subscribed to any information coming out from your vendors (Microsoft or any other big software packages you have). Third-party websites (www.securitytracker.com) and mainstream media will address some of these issues as well. Do necessary investigations, relate any vulnerabilities to your environment, and take steps to keep your environment patched and secure.
Q: How do you go about finding out what security patches you need?
A: Vendors have made this much easier now and there’s a lot of great software out there for managing vendor patches. Most people will configure workstations to auto-install Microsoft patches on the workstation level. For servers, you let those download but you never let those go into production unattended because they can cause resets or other issues. Vendors will be one of the first levels of notifications, as well as your regular vulnerability scans, to help keep you on top of the security patches you may need.
Q: Are there any guidelines on how to incorporate information security into your software development?
A: Yes, there are a lot of good whitepapers out there that are good resources, particularly www.SANS.org. When developing an application, or making major changes to one, you want to think about security from the very beginning. Companies are moving fast, often with a limited budget and time to give to application development, resulting in security being left out. Keep in mind to bake it in from the beginning rather than tacking it on at the end. Make proper planning decisions to ensure you’re protecting cardholder data appropriately.
Q: Would you recommend an automated or manual process when it comes to code review? Why?
A: I would say a hybrid of the two. Code review applications can be a bit pricy, and there are other open source type solutions that can be useful, however, a peer should also be looking at your code. A set of human eyes is very beneficial to make sure developers are staying aligned with development best practices. Also, when undergoing a PCI assessment, your QSA is going to want to see documentation that this is taking place. Is there a checklist being used? If you’re using an automated tool is there a report that’s produced? These artifacts will be what your QSA will be looking for.
Q: Why is it important to separate development/test environments from production environments?
A: Development/test environments can be less secure in some cases. Sometimes you’re working with hardcoded elements in the software or information in the database as well that could be a weakness. You don’t want that information tied to your production environment. Typically, developers shouldn’t have access to the production environment. There should be some kind of admin role for the cardholder data environment (CDE) to do the actual deployments to the production environment. In a smaller organization, the developer is doing deployments, however, a proper level of oversight, and separate and unique user credentials to the system should be used. There are different security levels for these two different environments.
Q: How do you recommend training developers in secure coding techniques?
A: There is a lot of computer based training for this. OWASP is a great place to go for web based coding best practices and content on how to code in defense of a lot of web based vulnerabilities that are out there. Some organizations host internal training based on OWASP or various other material. The main thing we want to stress is that there needs to be a clear, documented process for training in place that can be demonstrated to your QSA.
Q: Are there any other coding vulnerabilities that need to be addressed?
A: When you analyze the information you get from the outside world, vendors, third-party websites (www.securitytracker.com), and your own vulnerability scanning results, you think about how those vulnerabilities could be related to a coding vulnerability.
Q: I know it’s recommended to review public-facing web applications for vulnerabilities at least annually, but how often would you recommend performing a review?
A: Any time you make a change to your web application you’ll want to test it, either using tools internally or through a third party to ensure that you have not introduced a vulnerability through this change that was just implemented.
Q: How frequently should your policies and procedures be reviewed?
A: Your policies and procedures should be reviewed at least annually. Any time a major change occurs, those should be documented immediately. The big thing to take away from this is that all policies and procedures should be clearly documented at all times. This is stressed in both PCI requirements 5 and 6 as well as the entire DSS. Relevant personnel should have this communicated to them, and acknowledge the receipt and review of that document.
Q: At what point in the process of preparing for a PCI audit should a company engage a QSA?
A: As soon as you know you need to go through the process, you should start looking for a QSA and get an agreement in place. You should consider doing a Gap Assessment so you can become familiar with the DSS, your QSA can become familiar with your company, and your QSA can help you understand any gaps in your processes.
Preparing for and undergoing a PCI assessment doesn’t have to be overwhelming. If you are in need of a Gap Assessment or a free consultation to see if you’re ready for your PCI audit, contact us today.
More Resources
Beginner’s Guide to PCI Compliance
