PCI Requirement 5 states, “Protect all systems against malware and regularly update anti-virus software or programs.” For this requirement, we’ve discussed the 5 sub-requirements and topics such as anti-virus solutions, malware protection, commonly affected systems, and the evolving threat landscape. Meeting PCI Requirement 5 will protect your organization from being infected by malware attacks. But, as we’ve learned, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 5.
Requirement 5.4 states, “Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be implementing what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures. It is not sufficient that you generate documentation just for the sake of the audit. Your assessor should be reading these documents, familiar with the policies and procedures, and interviewing staff to make sure that anybody who is subject to the policies and procedures understands what they are.
PCI DSS Requirement 5.4 requires that you have a documentation program around your anti-virus program. Your assessors are going to be looking for the documentation, policies, and procedures to see that they’re appropriate. They’re going to make sure that whatever you’ve documented is actually what’s being used. Then, interview the staff that is subject to these policies, making sure they understand that.
Now that there is an anti-virus solution installed and running in your environment, we need to keep it that way. PCI Requirement 5.3 states, “Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.”
There may be situations when you need to disable the anti-virus mechanism for a very short period of time and for a very specific reason; this must be approved by management and management must understand the vulnerability associated with disabling your solution. The PCI DSS notes, “Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.”
We’ve seen attacks occur when anti-virus mechanisms are shut off. The reason could be that the mechanism is inconvenient for them or it might slow down their system; whatever the reason is, understand that it could be the gateway for a hacker to launch their attack within the rest of your environment. Your anti-virus solution should be running, it should not be disabled, and if it is disabled, there should be additional security measures in place. For example, this measure could be disconnecting the system from the Internet during the period of time when the anti-virus protection is shut off, then running a scan once it’s re-enabled.
Your assessor will take inventory of your systems, examine anti-virus configurations to verify that the anti-virus solution is actively running and cannot be altered by users, question situations where/if an anti-virus solution is not running, and observe processes to ensure that the anti-virus solution cannot be shut off without management’s approval.
Now that you have an anti-virus solution installed and running in your environment, we need to ensure that the anti-virus solution is actually kept running. We need to make sure that end-users cannot disable your anti-malware solution. However, we understand that there might be production issues where anti-virus might need to be disabled for a break/fix. In those situations, it’s okay that you disable it. When we look specifically at 5.3, it says that in those situations, we would only disable it for a very short period of time, for a very specific reason, and that management approves that. Management needs to be aware that they have a system that would be vulnerable to vulnerabilities.
We’ve seen attacks happen in the industry when people have gone in and shut it off for whatever reason; it might be inconvenient for them or it might just slow down their system, so they shut off anti-virus. Lo and behold, those become a footprint for where attackers would get a hold of that information and then launch their attack within the rest of the environment. So, your anti-virus solution should be running, it should not be disabled, and if it is disabled, it should only be for a very short period of time.
One of the things that the assessor is going to be doing is they’re going to be taking an inventory of all of your systems. They’re going to be looking at the running services and making sure that anti-virus is actually running on all of the devices. If there is a situation where they discover anti-virus isn’t running, they’re going to possibly ask for the change control or management’s approval that’s authorized those system to have their anti-virus solution shut off.
In short, your anti-virus needs to be running and it needs to be protecting those systems that are vulnerable to malware.
Because the threat landscape is constantly evolving, you must keep your organization’s malware protection abreast. PCI Requirement 5.2 exists to, “Ensure that all anti-virus mechanisms are maintained as follows: are kept current, perform periodic scans, and generate audit logs which are retained per PCI DSS Requirement 10.7.”
Your organization’s anti-virus solution must be kept current. Every day, new types of malware are created and new definitions are released, so your organization needs to stay up-to-date. Your definitions for malware and the scanning engine itself should be current. The PCI DSS’ reason for this is, “Even the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the latest security updates, signature files, or malware protections.”
The anti-virus solution that you have in place should perform scans periodically. It is not the assessor’s job to define what “periodically” is for your environment, but generally, we’re looking to see that you have business justification for when you’re running scans. Ideally, you should be running them every day or in real time. We understand that there are some situations when you can’t always run them every day; but, it’s not acceptable to shut off the anti-virus solution just because it’s inconvenient.
According to PCI Requirement 5.2, your anti-virus solution should generate audit logs in accordance with PCI Requirement 10.7, which states, “Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.” The PCI DSS further explains, “Retaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach.” If there is malware in your environment, your staff should see it because it should show up in a log that is periodically reviewed.
PCI DSS Requirement 5.2 says that the solution you have or have implemented needs to be capable of logging, and we’ll talk about that in some of the next requirements. You need to make sure that the solution is kept current. Every day, there’s new malware that comes out. There’s new definitions that are released, so we need to make sure that we keep the definitions for the malware up-to-date. We need to make sure we keep the scanning engine current and up-to-date as well. We need to make sure that the solutions that you have in place are performing scans periodically.
It’s not our job to define what “periodically” is for your environment. I can tell you, as an assessor, if the scans that you’re performing run more than a week, I get really nervous and I’m looking for some real business justification for why you’re not running it sooner. Ideally if you can run it every day or run it in real time, that’s perfect. However, there are situations, we understand, where you can’t always run it every day. If you tell me that you do not run anti-virus scans on your database because it brings the database to its knees, I would suggest you don’t run anti-virus scanning on the actual database itself. However, you would still need to run the anti-malwares scan against the server itself. It’s not acceptable to shut off an anti-virus solution because it’s inconvenient.
Continuing on with the requirements in 5.2, one of the areas that most organizations really struggle with is the requirement to retain the logs generated by your anti-virus solution. Understand that there’s a couple of places where the logging needs to occur. We have our anti-virus console or management – we absolutely need to be logging the anti-virus activities that are associated with that. However, we also need to be logging the events that occur on the workstations themselves. Specific to the requirement, it says that we need to be retaining those logs in accordance with Requirement 10.7. If you need some assistance with understanding what that requirement is, please look at the requirements around log retention for 10.7. We find a lot of organizations struggle with meeting this requirement, especially when they’re in a very distributed environment. We come into a retail environment or a hospitality environment where they might have 100 restaurants or 500 restaurants, and the log retention and log review becomes very difficult around this anti-virus solution. In many situations, the anti-virus solution has the capability of generating logs. The problem that exists is we’re not retaining those logs as required.
So, my recommendation to you is make sure that part of your log management solution for anti-virus captures the logs from the PCs, the workstations out in the field where the anti-virus solution is running. If there is malware in your environment, your staff should know about that. Really, the only way to know about that is if it shows up somewhere in a log that’s reviewed periodically.
[/av_toggle]
[/av_toggle_container]
The threat landscape is constantly changing; the trends for malware can change quickly, so it’s vital for your organization that PCI Requirement 5.1.2 is met. This requirement goes a step further than PCI Requirement 5.1. PCI Requirement 5.1.2 states, “For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.” Just because a certain platform isn’t susceptible to malware today, doesn’t mean it won’t be vulnerable tomorrow.
As part of your anti-virus program, you need to decide how to measure and look at the threat model of the industry. The PCI DSS states, “Trends in malicious software should be included in the identification of new security vulnerabilities, and methods to address new trends should be incorporated into the company’s configuration standards and protection mechanisms as needed.” Your anti-virus program should be able to provide an assessor with evidence that personnel monitors and evaluates evolving malware threats.
If you have systems that are not commonly affected by malware, you assessor should be asking for evidence or an artifact to demonstrate that you constantly assess these systems and compare them to developing malware threats. The systems not commonly affected need to be identified in order to prepare for future attacks. The PCI DSS also states, “Interview personnel to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software, in order to confirm whether such systems continue to not require anti-virus software.”
When we talk about Requirement 5 and the PCI DSS 5.1, it says that those systems that are commonly affected by malware should have some type of antimalware solution installed. That is not going to be the situation forever. Just because a certain platform today doesn’t necessarily become susceptible to malware, that doesn’t mean that’s not the case tomorrow. As part of your processes, for systems that are not commonly affected by a malware, you need to possibly look at measuring and looking at the threat modeling of the industry. You need to spend time making sure that’s still the case, that those systems are not commonly affected by malware.
If you as an organization have systems that are not commonly affected, you assessor should be asking you for some type of evidence or artifact to show that you’ve done your due diligence to demonstrate that these systems are not commonly affected. Understand that at some point, there will be a tipping point between not having an antimalware solution and implementing one. As assessors, it’s our job to make sure you’ve done your due diligence to ensure that what you’re doing is being done securely.
It’s crucial that your organization can protect itself from all types and forms of malicious software, including viruses, Trojans, worms, spyware, adware, and rootkits. PCI Requirement 5.1.1 requires that your organization’s anti-virus program is capable of three things:
Detecting all known types of malware
Removing all known types of malware
Protecting against all known types of malware
Some solutions perform whitelisting, which prevents malware from ever running in the first place, but often times that type of solution does not remove or detect malicious software. Whitelisting is a good element in a security program, but remember that your program must be capable of doing all three – detecting, removing, and protecting. During the assessment, your assessor should examine documentation and anti-virus configurations to verify that your anti-virus program can detect, remove, and protect against all known types of malware.
The anti-malware solution that you choose needs to be capable of detecting, removing, and preventing attacks. There are solutions out there today that do whitelisting that prevent malware from ever running in the first place. I think that type of solution is a good means as part of your overall program. When we look at tools like Solidcore, they’re really great tools, but it has been my experience that a lot of those whitelisting solutions do not necessarily remove or detect. In order to meet this particular requirement, the PCI DSS 5.1.1, we need to make sure that whatever solution you have implemented is capable of detecting, preventing, and removing malware.
