The need to scan is clear. Are you doing so effectively and efficiently?
For some years, the topic of viruses on System i has been hotly debated. Is it susceptible to viruses? Can it serve as the host for malicious code? Is it really necessary to scan the System i? The answer to all of these questions is yes. But that's not the end of the story. Even as many users have come to accept the fact that it is a good security practice to scan the System i, debate over the choice of tools persists.
To fully detect and eradicate malicious code from a server, a native tool is required. For System i, the same McAfee power that protects Windows is available through Bytware's StandGuard Anti-Virus. Despite this and IBM's inclusion of Virus Scanning Enablement in i5/OS since V5R3, many users choose not to use a native solution. Instead, mounting the server's IFS and scanning from a Windows PC seems like a cost-effective option, but doing so presents security risks that you may not have thought of.
At the top of the list is the chance that you may inadvertently introduce viruses to the System i while trying to protect it. In order to scan the files on the System i, the anti-virus software must be able to access those files. Of course, this means that you have to log on from the scanning PC with *ALLOBJ authority. Doing so opens a wide door to the server and grants privileges that can be inherited by malicious code.
If the scanning PC itself is infected, which can happen even though the scanning PC has virus protection itself, it can become the point of infection for your System i. Once the infected scanning PC is connected with *ALLOBJ authority, it can pass viruses to the IFS, including the QSYS.LIB file system. Once in, they can infect and spread to any files and folders within the IFS and quietly spread across the network, causing damage and resulting in substantial downtime.
The prospect of infecting the System i during the scanning process isn't the only reason to resist the temptation to use PC scanning software to protect the server. There's also the effectiveness of the scan to consider. Because of the architecture of OS/400, PCs can't detect all viruses stored in the IFS. Simply mapping a drive and scanning from a PC can result in many viruses remaining undetected.
To illustrate this point, let's look at Figure 1. This is the result of a scan of the IFS using an anti-virus solution designed for Windows. The table shows that one file was scanned, and it was clean. No viruses were found. Unfortunately, this is not accurate.
Figure 1: The results of this scan are inaccurate.
Now take a look at Figure 2. This is the result of a scan of the same file on the IFS using StandGuard Anti-Virus, a native solution written specifically for OS/400 (i5/OS, IBM i). It shows that one file was scanned, and the file was infected. The virus was detected, and the file was cleaned. Had you relied only on the Windows solutions, the virus would have continued to live on the System i and infect other systems on the network.
Figure 2: This scan of the same file used StandGuard Anti-Virus.
So why didn't the PC-based solution find the virus? The file was locked, and PC solutions cannot scan locked files. File locking is a typical modus operandi of virus writers. By locking an infected file, the virus ensures it won't be detected. PC scanning requires a mapped drive using Netserver. With Netserver running, viruses can lock files to prevent detection. A native server-based solution doesn't need to use Netserver or mapped drives and can even run in restricted state. With Netserver ended, open file locks are removed and StandGuard Anti-Virus is able to detect virus infections in situations that PCs cannot.
These are just two key reasons that using a PC-based anti-virus solution to scan the System i can actually harm your security. Other reasons include poor performance, the possibility of passing sensitive data over the wire in the clear, increased network load, and impact on SAVCHGOBJ and save/restore processes.
With the need for heightened security, plus regulations and objectives such as SOX and COBIT calling for anti-virus protection, the need to scan is clear. Doing so effectively and efficiently demands protection based on the System i itself.
You can learn more about StandGuard Anti-Virus, System i, and virus issues at www.sgav.info. You'll find articles, white papers, presentations, and a free trial.