Protect Your Organization by Preventing Ransomware
Ransomware attacks have been prominent in the news lately, but for every such breach that is widely publicized, there are many others that go unreported in the press. Companies of all sizes are affected by the problem.
Unfortunately, many don’t take proactive steps to limit their exposure until they have been victimized. A single ransomware attack can cost hundreds of thousands (or even millions) of dollars and can frequently lead to the dismissal of senior IT personnel. To make matters worse, paying hackers a ransom to unlock your data and systems doesn’t necessarily provide a solution. Even when you pay ransomware, the tools provided by the ransomware hacker may not immediately allow the recovery of your data. You can run into issues like getting the wrong key, a bad decryption utility, compatibility issues and other challenges can delay the recovery of your data.
If your organization is running IBM i systems, you may think that your risk is limited by virtue of its history as a relatively secure platform. Hackers have traditionally sought out targets running Windows-based systems or Linux variants that are in more widespread use. In fact, there is currently no malware in existence that is known to target the IBM i operating system per se, but businesses running IBM i should not take that as an assurance that they’re not at risk.
Many IBM i systems are plagued by poor security practices that leave them exposed to potential attackers. Here’s a review of some of the common sources of security risk on the IBM i platform, along with the experts’ recommendations on protecting against intrusions and malware infection.
How IBM i Systems May be Infected
There are two fundamental ways in which malware might be introduced into an IBM i system. First, it may be stored on the integrated file system (IFS) by a hacker who gains direct access. Second, malware may be introduced through a workstation where there is a mapped drive to an IFS share. The worst possible scenario is to have a read-write share to Root, which exposes your entire system to hackers. In this scenario, anyone with a user profile can compromise your entire system.
Unlike Windows, IBM i systems do not apply permissions to a shared directory. Instead, all shares are defined as being read-write or read-only, and users are granted authority to either access the directory or not and are granted authorities on specific objects within the directory.
Read our eBook
Learn more about actively securing your IBM i platform and how it is critical to keeping your entire business protected, and achieve regulatory compliance.
Controlling Access Via File Shares
To reduce risk, system administrators should remove unused shares and restrict existing shares to read-only status wherever possible. In addition, they should restrict user access to the objects within those shares, being careful to limit access on an as-needed basis. Very often, we see systems in which shares were created at some point in the past, but are not currently needed, and, in fact, have not been used for quite a long time.
As a first step, system administrators should perform an audit of existing file shares (either by using the IBM Navigator, or with the SQL tool (QSYS2.server_share_info service) to return a list of existing shares. Remove any unused shares, and wherever possible, set existing shares to read-only status. To the extent that shares must allow write access, limit authorities to those users who absolutely require it. This limits exposure to only those users who have access to the path, including users with *ALLOBJ permissions.
It’s also a good practice to set up shares so that they do not automatically reconnect at logon, unless they are used very frequently by the users at the workstation in question. It is common to find users who have not accessed such shares in a very long time, including those who have changed jobs and no longer require access to it.
Whenever possible, it is also a good practice to set up file shares to be hidden. By appending the sharing with the “$” character, the share will be invisible to attackers (or anyone else) who is simply browsing the system looking for open directories. This is commonly known as “security through obscurity.” Hackers cannot get information if they do not know that it even exists. While this does not prevent someone from connecting to the share per se, it does require that they be aware of its existence, know its exact name, and enter that information to connect.
Likewise, it’s good practice to turn off broadcasting of the NetServer. Again, this provides some protection by making it difficult for hackers to discover and navigate your systems. If a Guest profile is assigned to the NetServer, remove it.
The Risk of Read-Only Shares
Although much of the attention is focused on preventing hackers from gaining read-write access, system administrators should not neglect security with respect to read-only directories. In ransomware attacks, it is common practice for hackers to download information and retain a copy before they encrypt your data. Furthermore, attackers can do considerable damage to your organization simply by reading and exposing information in your IBM i system. If customer names and personally identifiable information are revealed, for example, your organization may suffer severe reputational damage and is likely to experience legal consequences as well.
Other Security Measures
A critically important security measure is to secure Root, which is open by default when IBM i systems ship. New directories created under Root inherit those permissions, which creates a security risk.
Experts also recommend securing your QPWFSERVER authorization list to restrict access to “QSYS.lib” from Windows Explorer and Navigator in cases where a share to Root is absolutely required.
It’s also good practice to segment your network, making it difficult for hackers to navigate and gain access to all of your systems.
Finally, educating your users is critical. Everyone in your organization should understand what a phishing email looks like, should know to avoid opening links within those emails, and should know who to call in the event that they receive potentially malicious messages.
A Proactive Approach to Security
Precisely has been working with IBM i systems for years. Our Assure security solution provides comprehensive malware defense, monitoring and reporting, data privacy, and access control capabilities for IBM i. If you are concerned about ransomware specifically, as every system administrator should be, then our Assure Security products can help you proactively manage security and establish confidence that your organization can operate with multiple layers of defense and minimal risk.
Learn more about actively securing your IBM i platform and how it is critical to keeping your entire business protected, and achieve regulatory compliance, read our eBook 5 IBM i Compliance and Security Success Stories.