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.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcription’ tags=”]

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:

1. Detecting all known types of malware
2. Removing all known types of malware
3. 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.

There are more people than you think looking to harm your environment. We used to see viruses created just for the sake of creating viruses. Nowadays, organizations are attacked by software that is specifically written for their environment, probably by somebody that has knowledge of their environment. Your organization should take every precaution possible to prevent a potential attack; this is why PCI Requirement 5 states that all systems need to be protected from malware and regularly updated with antivirus software. Malware includes viruses, worms, and Trojans. PCI Requirement 5.1 specifically requires any system that is commonly affected by malware to have antivirus software.

If you have a device that is unplugged from the network and there’s no way to get data in or out of it, that system wouldn’t be considered commonly affected. If you believe Linux systems or Apple systems are not affected by malware or already have malware solutions installed, you’ve got some work to do. Wherever you have systems that are susceptible to malware, there needs to be some type of solution implemented to prevent an attack.

During the assessment, we’re looking to see you’ve done your due diligence to protect your systems. A sample of system components will be taken so that the assessor can verify that anti-virus software has been deployed wherever necessary.

There’s a lot of people out in the industry that look to do harm to your environment. It used to be, years ago, that people would create viruses just for the sake of creating viruses. You saw worms, you saw the Melissa virus, you saw the ILOVEYOU virus. Sometimes these worms or viruses have malintent, and sometimes they just spread and become a nuisance.

What we see in the marketplace today is organizations being attacked with software that is specifically written for their environment by somebody that has knowledge of their environment. When we saw one of the recent attacks, there was software that was installed in a sales system that actually scraped the memory of the system as the cardholder data flew through the environment.

We need to implement some type of solution that prevents systems that are commonly affected by malware from being attacked. When we look at Requirement 5.1, I want to have a conversation about “commonly affected” and what that means. As an assessor, if you tell me that you have a Linux system that’s not impacted by malware, I can guarantee you that is not the case today. If you tell me that you have a Mac and Mac is no longer affected by malware, I can guarantee you that is not the case today. However, in your environment, what we’re looking for is that you’ve done your due diligence about systems that may or may not be impacted by malware. Just because you have a Windows operating system or a Linux operating system, doesn’t automatically mean that you have to have a malware solution on it. From an assessor perspective, that is really our starting point. You should have an anti-malware solution on these devices. However, if you’ve unplugged it from the network and the system is only booted up in order to get information off of it and written down, there’s no way to get data out of or into it, and then you shut the machine down – no, that system wouldn’t be commonly affected.

From an assessment perspective and an inventory perspective on your side, you need to do due diligence if you are not going to be implementing an anti-malware solution. You need to make sure that these systems are not going to be impacted by malware, should it get into that environment. From an assessment perspective, it’s a really difficult conversation to suggest these operating systems. Just because Legacy, in years past didn’t need it, that is not the case today. There might be situations where mainframe environments, z/OS, we might have tandem mainframes or tandem devices that are not commonly affected. It’s kind of a given that those systems aren’t commonly affected, so we wouldn’t look for an anti-malware solution. Where you have systems where malware is available for those systems and those systems do get infected, the starting point should be that you have a solution installed.