Carol provides her suggestions for doing things differently in 2021.

With the new year upon us, resolutions are being made. I’m not really a resolution person, but every year I do try to look forward and see if there’s something that I could to do differently. You know that old adage: to do something the same way over and over and expect different results is the definition of insanity. I think we’ve had enough insanity for one year, so let’s take a look at five actions I’d like to see IBM i administrators adopt this year and why.

#1: Stop thinking that your organization is somehow immune from ransomware, and take steps to reduce the risk. Obviously, you may not be the one to create your organization’s approach to defending against malware, but you can at least take steps to reduce the risk to IBM i. Two areas of the system need to be addressed: file shares and the permissions (object security) on directories. Think of it as controlling who can enter the building and then once in the building, what parts of the building can they access. A couple of things about malware. It’s not just ransomware that can affect IBM i. Many types of malware can affect IBM i via mapped drives. For example, I’ve seen a malware variant that first renamed all of the directories on the infected PC; then, because the user was mapped to a read/write share to root and they had not taken steps to secure their IFS, the malware renamed all of the directories that were *PUBLIC *ALL (that is, data authority *RWX and object authority *ALL), which was most of them.

The first step you can take to reduce risk of malware infecting the system is to analyze the use of file shares defined for IBM i. Here are some tips on analyzing shares:

• Just because someone is mapped to a share doesn’t mean they currently need access to the contents associated with that share. When the original map to the share occurred, it may have been configured to reconnect to that share at sign-on. Also, I’ve seen (actually been issued) laptops that came with drives pre-mapped. Regardless of the fact that I had no business reason to access the information on those shared drives, they were configured to map every time I rebooted.
• I’ve said this before, and I’ll say it again: DO NOT CREATE A READ/WRITE SHARE TO ROOT (/)! Mapping to this share exposes your entire system to malware.
• Create shares as read-only whenever possible and at the lowest point in the directory structure. You do not have to share root to share subdirectories.
• Remove shares that are not (or should not) be used.
• Reduce shares to read-only whenever possible.
• Take control over who can create shares by securing the Add File Server Share (QZLSADFS) and Change File Server Share (QZLSCHFS) APIs.

This is the perfect time to use the QSYS2.Server_Share_Info service I referred to in last month’s article to determine which shares are in use. The problem with viewing the active sessions using the Navigator for i interface is that it’s a point in time, meaning that the sessions are active at the point you’re viewing the page, but it doesn’t help if the user connecting is working a different shift or connects and disconnects between the times you’ve gone into Navigator for i to view the active sessions. Using the STRSQL command, you can use the service in a CL program, sending the information to a file as shown below. You can schedule your CL program to run every five minutes (or however often you wish) and know with much more confidence which shares are in use.

           RUNSQL     SQL('CREATE TABLE your_schema.SHARES   AS   +  

                (SELECT SERVER_SHARE_NAME,             +                          

                   CURRENT_CONNECTIONS,                     +        

                   TEXT_DESCRIPTION                         +        

                   FROM QSYS2.SERVER_SHARE_INFO           +        

                   WHERE SHARE_TYPE = ''FILE''             +          

                    AND CURRENT_CONNECTIONS <> 0 )          +                

                         WITH DATA') COMMIT(*NONE) NAMING(*SQL)  

The second step to take to reduce the risk of damage from malware is to secure your directories. Ransomware isn’t just encrypting data; many ransomware variants are now downloading the data prior to encrypting it. This is known as “exfiltrating” the data. Therefore, it’s important that any data you wouldn’t want published on the Internet be secured. (The thieves will threaten to publish your information on the Internet if you don’t pay the ransom.) If you have been ignoring the IFS, it’s likely that any directory you’ve created is set to the equivalent of *PUBLIC *ALL. In other words, you have some work to do.

Even if the share is a read/write share, the users’ authority to the directory can prevent malware from doing harm. For example, a user maps to a read-write share defined on the /Bank_Images directory. But that directory is defined as DTAAUT(*EXCLUDE) OBJAUT(*NONE) and neither she nor her group has a private authority to the directory. In this case, the malware would not be able to either exfiltrate the data in the directory or encrypt the contents of the directory because the user doesn’t have sufficient authority to perform either task. For more guidance on securing the IFS, see my article “Tips for Securing the IFS.”

#2: Consider switching to use IBM i Services rather than running CL commands from a command line. Many of the services are easier to use and perform better than their CL command or API counterpart. The one that may save you the most time as an IBM i Security Administrator is the QSYS2.USER_INFO service. This view is the same as running Display User Profile (DSPUSRPRF) to an outfile. The benefit of using the view is that this view is immediately updated when a profile is created, deleted, or modified. So you can be assured you’re getting the most current information without having to re-run DSPUSRPRF. You can find the list of IBM i Services available for your OS level here. You can find SQL tutorials and examples from Scott Forstie and Tim Rowe here.

#3: Stay current. There are many aspects to staying current. One aspect is to stay current with the industry your organization’s in: understanding the marketplace’s challenges, market leaders, etc. Understanding your marketplace can help you position your proposed IT changes in terms of how it will benefit your organization according to your marketplace. Proposing changes and additions using relevant business terms will always be more well-received than a technical dissertation. Staying current also means staying current with the technologies being released by IBM twice a year via Technology Refreshes (TRs). Staying current shows your organization that IBM i is an up-to-date technology and is a good investment choice. But I’d like to suggest two areas that are extremely important in which to stay current: PTFs and Access Client Solutions (ACS) refreshes. I know that, for some organizations, applying PTFs is difficult because they must run 24x7. But not all PTFs require an IPL, and many PTFs are critical to security even if they aren’t categorized as such. This is especially true for Java and open source PTFs. Leaving your systems unpatched may be leaving your systems vulnerable. Use the Group PTF service to know if your system is down-level from the current group PTFs. Simply launch ACS > Run SQL Scripts and run the following SQL:

select * from systools.group_ptf_currency;

It will do a “phone home” to an IBM website with the current group PTF levels and compare that information with the Group PTFs you have installed. The results will let you know exactly which Group PTFs need to be applied. Regardless of how you accomplish it, I encourage you to find a way to stay current with PTFs.

I also encourage you to stay current with ACS. I do understand that it may be difficult to upgrade your entire organization because other client-based software may have to be retested to make sure it’s compatible with a new version of ACS. But even if you only upgrade ACS on your workstation and that of your colleagues and upgrade the rest of your organization once a year, you and your technology team will be able to take advantage of the new examples IBM provides in ACS for using the IBM i Services. This, alone, is worth the upgrade, in my opinion. You can keep track of ACS enhancements added each version here. And you can download the new version here. (Note that you’ll need an IBM ID to use this link.)

#4: Implement encryption. If you haven’t already, encrypt your internal communications. More importantly, encrypt critical data in database files. Encrypted communications stops individuals or malware from reading your internal traffic to gain valuable information (such as user IDs and passwords). Encrypting data means that, even if it’s exfiltrated or otherwise stolen, it’s going to be difficult if not impossible for the thief to be able to use the data since they would need to be able to decrypt it first. For more thoughts on encryption, see my article “Why Encryption?”

#5: Once and for all, get rid of and prevent default passwords. I continue to see systems that have profiles with a default password. Some profiles are service accounts that were created on a development system and tested with a default password, and developers are afraid to change them. This is why I encourage you to switch all of your password composition rules to be listed in the QPWDRULES system value and include the values *LMTPRFNAME (the password cannot contain the profile name) and *ALLCRTCHG (rules apply even when the profile is created or changed) so that this cannot happen. Others are profiles that were created, but the person never showed up for work, yet the profile sits with a default password. Even though the password is set to expired, this is not protection! All I’d have to do is sign on with the default password and change it to something I know and I’m on your system. Still other profiles are service accounts that are being used but you’re not sure how. I’m sorry, but that’s not an excuse. The JS (Actions against job entries) audit journal entries provide information about the jobs a user profile is running regardless of whether they’re batch or interactive or are coming in from a remote server. Information provided in the JS entry include the job name, timestamp, whether the job was started, stopped, released, or held along with the IP address from which the request originated. Using this information, you can determine if the password only needs to be changed on IBM i or if a script on a remote server also needs to be updated with the new password. If you don’t already have or don’t want to add *JOBDTA or *JOBBAS to the QAUDLVL system value because it is going to generate too many audit journal entries, well that’s not an excuse either because you can turn on the auditing for the profile you’re trying to investigate by using this command

CHGUSRAUD USRPRF(YOUR_PROF) AUDLVL(*JOBBAS)

Finally, admins, some of the profiles with a default password I’ve seen are YOURS! Just because you have the power to set your password to something simple, you should not abuse that power!

Summary

You may have already changed your behavior in past years and these suggestions are meaningless for you. If that’s the case, bravo to you! But for those who are stuck and continue to do the same thing over and over, I hope that these suggestions will help get you moving in a new direction this year.