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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online