Why Requirement 5 Must Change

This issue came to a head recently when a colleague of mine attended an ISSA chapter meeting where there was a session given on anti-virus by someone from a US government intelligence operation. I had entirely forgotten about this until they brought it back up. The issue is the ineffectiveness of anti-virus solutions and why they are ineffective.

Most of us have seen the anti-virus testing results that are periodically pumped out by the various trade journals. They all point out that anti-virus is only around 30% to 40% effective in detecting malware. But what never seems to get brought up and clearly discussed is why anti-virus solutions are so bad at their job.

The reason is that anti-virus solution providers have taken a page out of the United States Centers for Disease Control (CDC) influenza playbook. The reason is the statistics that the speaker shared.

• For every current piece of original malware, there are around 400,000 variants of that malware making the rounds on the Internet. Variants are easy to make which is why there end up being so many so quickly.
• To scan a computer for every piece of malware developed since day one including variants would take around 40,000 hours (almost a month) to complete. And that is if you dedicate a core for that to run as well as a core to scan everything coming at you.
• The signature files required to track all malware and their variants from day one would take up a significant portion of your hard drive.

Like the CDC does a scientific wild-ass guess (SWAG) to figure out what influenza vaccine to make every spring, anti-virus vendors do the same thing with their signature files every day. What anti-virus vendors do is select the most likely malware and variants your computer will encounter and that is what your anti-virus signature file will contain. The idea is that their heuristic engines and firewalls will hopefully detect the malware not included in the signature file.

Getting back to the PCI DSS, requirement 5.1.1 states that anti-virus solutions:

“Detect all known types of malicious software, remove all known types of malicious software, and protect against all known types of malicious software.”

Guess what?

Given the aforementioned revelations that signature files are incomplete, there is no anti-virus solution available today that meets those requirements of detecting and protecting against “all known types of malicious software”. All of us have, unknowingly or not, been “checking the box” on this requirement.

I along with a number of other security professionals have stated for years that anti-virus alone has never been adequate for protecting systems as portrayed in the PCI DSS, by the PCI SSC and by the card brands. If you truly want to protect systems from “all” malware as specified in the requirement, you need to use anti-virus in conjunction with a whitelisting/blacklisting and/or file change detection solution. Anti-virus alone is just not enough as the repeated tests of these solutions have pointed out over the years.

The reason you still need to keep anti-virus is that these solutions do what the others do not – quarantine or remove the malware. Quarantining or removing malware is truly an art form and has gotten even more so as operating systems have become more sophisticated in how they manage applications. The reason for this is that, while it is easy to install software, it has become very tricky in uninstalling it, if you can even uninstall it at all.

Anti-virus vendors spend the bulk of their research and development time and money in determining the best way at quarantining and/or removing malware. While a lot of whitelisting/blacklisting vendors have promised to add the ability of quarantining and removing malware, most have come to the realization that providing such features are beyond their current capabilities and not as simple as they have portrayed it in their sales meetings. As a result, I would expect it will take these whitelisting/blacklisting vendors years to have this capability if they even bother to develop it.

So what should the PCI SSC do?

The Council needs to require additional malware detection measures to requirements 5 so that organizations are truly protecting their systems against malware. In the immortal words of Bruce Scheier, what we have now is “security theater” – the appearance of security without security. Anti-virus alone is not cutting it, so it is time to enhance that capability by requiring more than just anti-virus.

The Council should also work with and demand that the anti-virus, whitelisting/blacklisting and file monitoring vendors provide some sort of integration between their respective products. That way when the whitelisting/blacklisting or file monitoring solutions detect an issue, the anti-virus solution can do the quarantine or removal of the suspected malware which it is typically very good.

Is this going to detect every piece of malware?

Sorry, but some will still get through (remember, security is not perfect). But the amount that gets through should be significantly less than with just anti-virus alone.

How much gets through will be up to how the tools are configured. As a lot of you have found out, just installing file monitoring software does not detect all file changes. That is because the installation does not get tweaked to protect everything it should. That takes time and effort that a lot of people do not provide because they have other things to get done. The better you implement the other tools, the fewer pieces of malware that will get through.

Reach out to the Council and let them know that you also think that requirement 5 needs improvement.

Advertisement

PCI Check Box Compliance – Volume 1

We just started an engagement with a new client a week ago.  While reviewing documentation, we came across this situation that I had to share because it points out how some QSAs out there just want to check a box and not use their heads.  It is this sort of mentality that gives all QSAs a black eye and it needs to stop.

In order to meet requirement 5 of the PCI DSS, one of the biggest QSACs required our new client to get anti-virus software for their IBM iSeries (aka AS/400) mainframe.  The rationale?  If there is an anti-virus solution published for an OS platform, there must be a virus or malware out there that it protects it from.  Whoa!

This client also has AIX running, IBM’s UNIX derivative.  Technically, ClamAV can be recompiled and installed on AIX, yet the QSA did not tell the client that they needed anti-virus on AIX.  So much for consistency.

Even without a decent technical background, a review of the Web sites offering anti-virus solutions for the iSeries would tell you that your logic was patently wrong.  All of the anti-virus solutions for the iSeries are very clear that the iSeries does not have any viruses or malware, but it can be a carrier if you have mountable file systems for Windows or UNIX defined on your iSeries.  In the case of this client, they do not have any mountable shares, so there is no risk.

However, if you do have an iSeries that has implemented Windows or NFS shares, there is a much simpler way to handle this situation.  Just use one of your existing systems that does have anti-virus installed to scan the mountable shares on the iSeries weekly.  We had recommended this sort of approach for years for NetWare environments which had notorious problems with anti-virus solutions that were installed under NetWare.  The NetWare shares were scanned by a Windows system that had administrator rights so it could scan everything in the mountable volumes.

I will not bore you with all of the technical details, but there are a number of reasons why an iSeries, or IBM zSeries, Unisys ClearPath and other ‘old’ technology systems for that matter, cannot be infected like a PC.  These mainframe systems are almost impossible to infect directly if they are running their ‘old’, proprietary operating systems such as zOS, MCP and the like.  The controls surrounding true ‘root’ access on these OSes are such that you really must be a ‘Geek God’ to have such rights.  Even systems programmers in these environments do not have those kinds of rights.  And then, even if you did have the ultimate rights, there are other controls in place that would only allow your code to function on a particular computer complex, so it would not necessarily be transferrable to another system.  So much for infecting others.

But there is a risk with these platforms.  Most of these systems also will run slightly modified versions of Linux and UNIX and those can definitely be infected.  In those cases, all bets are off and you need to treat this big iron just like their Intel brethren.

So, the lesson to be learned from this experience?  If you do not have expertise with a platform, find someone that does have that expertise.  After all, not everyone working on a PCI assessment must be a QSA.  The QSA just needs to always be on-site when the work is being performed.  So, use someone in your organization that has the platform expertise or find a sub-contractor that has the expertise, but do not try to wing it.  Winging it only makes all of us look bad.