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.