The threat of malware infecting your IBM is a real danger. Use these tips to lower your risk of being affected.

Several things can be done to reduce your exposure to malware - be it some sort of virus or ransomware or the latest type of malware, cryptomining software. I often talk about the need to implement multiple layers of defense, or "defense in depth." This area of security demands the same sort of planning. Determine what technology should catch the first layer of threats and then determine what would happen if that layer is breached. What's stopping the malware from wreaking havoc with your system?

Stop the Clicking!

Let's face it, one of the best things you can do is to stop your user community from clicking on phishing email. How do you do that? Education. This is a prime example of the need to perform security awareness training on more than just the first day of work. Employees need to be educated on the latest threats. Training users to not click on links or open attachments from email they don't recognize is a must. They also need to be trained not to provide information such as passwords or personally identifiable information when requests come via email and especially when the request is from senior management. Employees should understand that those types of requests will never come via email and most certainly never from senior management.

Limit the File Shares

If someone clicks on a link that downloads malware, what will protect your IBM i next? That all depends on what has been shared. A file share allows you to map a drive where the drive is IBM i. Once mapped, whatever path is associated with the file share looks to the PC like another drive. If the user maps a drive to the root directory via a read/write file share and downloads malware, once the malware has affected the PC, it will start walking the drives on the PC - including the IBM i drive - and will infect every directory and/or object to which the user has authority. But it's not just limited to directories. Sharing root also shares the /QSYS.LIB file system - in other words, your libraries and objects in the libraries could also be encrypted and held for ransom. The message? Avoid read/write file shares to root if at all possible. If you have to share root, make it a read-only share. A read-only share doesn't allow malware to infect the file system. It still allows the entire system to be accessed (read) but not infected.

Shares should be defined at the lowest level possible - meaning the share should be defined for the directory (or library) containing the objects to be shared. You do not need to share root to share other parts of the IFS.

Set Appropriate Access Controls on the Directories

Another aspect to whether the virus will be successful is whether the profile running the process has sufficient authority to change the object. I've seen a virus where it renamed directories. It was successful because root had been shared and it had also been left at the default *PUBLIC authority of data authority *RWX and object authority *ALL. This caused all subdirectories to be created with the same *PUBLIC authority setting. The virus walked through the entire IFS, renaming all directories and subdirectories that had been left at the default authority.

After first checking to ensure no processes are writing directly to root, consider changing the *PUBLIC authority of root to DTAAUT(*RX) OBJAUT(*NONE). This is the equivalent of *USE authority, which allows you to read the contents of root and traverse through it to the subdirectories but not modify, create, or delete a directory.

It should go without saying that limiting the users who have been assigned *ALLOBJ special authority must also be accomplished; otherwise, it doesn't matter what authority is assigned to the directory. The users' *ALLOBJ will provide all authority to all directories and objects in them.

Virus Scan the IFS

IBM i is considered to be the perfect host. It stores documents, images, etc. that have been infected with malware but doesn't actually get infected itself. If an infected document gets uploaded to a folder, for example, IBM i itself won't be infected, but the next person who opens that document will. The solution to this issue is to run a virus scan against the IFS. And I recommend running a natively running virus scan solution such as HelpSystems' StandGuard AntiVirus rather than mapping a drive to the IFS and running the virus scanner from another location in the network. Using a non-native solution is very problematic; it requires a share to root, produces huge amounts of network traffic because the objects have to be brought over to the device doing the actual scans, produces many false positives because they don't know what to do with IBM i objects, causes exposures as the objects are sent over the network in cleartext, and requires the process to run as a profile with *ALLOBJ if any corrections or quarantines are to occur. StandGuard is highly configurable and doesn't cause issues on the network.

Back Up!

The ability to recover from malware - especially ransomware - depends on the quality of your last backup. Take some time to review your backup script to ensure that you are fully backing up the IFS should you ever need to restore some or all of it to recover from a ransomware attack. Also review the frequency to ensure you are saving it often enough.

Summary

Viruses can and do affect the IFS. I hope you implement these tips for a strong "defense in depth" security strategy.