Many IBM i administrators have a comprehensive backup strategy, but for those who don’t, I’m hoping that this article will have you reworking how you approach backups.

Debbie Saugen was a colleague when I worked at IBM, and I’m happy to say she’s once again my colleague now that she’s joined HelpSystems. Debbie’s area of expertise is backup and recovery. Working with her again has reminded me of the security-related reasons to have a comprehensive backup strategy. Let’s take a look.

Data Retention Due to Regulatory Requirements

When people talk about data retention, most think of requirements to retain financial information. While that is a definite requirement, other regulatory requirements exist for other types of data. I’m specifically referring to audit journal receivers. These receivers are where audit journal information is kept. The Payment Card Industry Data Security Standard (PCI DSS) requires that you retain one year of audit data. In addition, the recently enacted New York Cybersecurity Law requires that audit journal receivers be retained for three years and database journal receivers retained for five years.

In many discussions with administrators, I’ve discovered that many organizations could not produce audit journal receivers for a specific date range. Either they don’t save receivers at all, or their tape rotation practices only provide receivers for the past three months, or the saves of receivers are performed too infrequently and some receivers have been previously removed and not saved.

To ensure you have a full set of journal receivers, examine how your audit journal receivers are saved and ensure you’d be able to produce a complete set if someone came to you and requested all the audit journal receivers for a specific two-week period, for example. Then, ensure your retention schedule keeps the receivers long enough to ensure regulatory compliance. If your organization is like many others, you’ll need to adjust how and when your journal receivers are saved and their save media retained.

Recovery from System Failure

While IBM i is incredibly reliable, systems occasionally fail or catastrophes happen in data centers and you have to do a full system recovery. Part of the recovery process is to restore user profiles, then restore objects, and then run restore authority to restore private authorities. My question is, how recent is your Save Security Data (SAVSECDTA)? If you perform a SAVSECDTA once a week, for example, do you have the forms, email requests, etc. to re-create all of the user profiles, authority changes, authorization list creations/deletions/modifications/assignments since the last SAVSECDTA? If not, you’re not saving your security information often enough.

Recovery from Making Changes

Cleaning up the system is a good thing. I always say that if it’s on the system, you need to care about it from a security perspective. I prefer that, if it’s not needed, it be removed from the system. This applies to inactive user profiles. Of course, prior to removing profiles—especially large numbers of profiles—it’s prudent to save all of the profiles currently on the system in case you accidentally delete a profile that’s needed.

Cleaning up also applies to back-level vendor products. Think of libraries containing financial data not legally required to remain on the system, or change management libraries. Ask yourself: are you really going to back out a change that was made three years ago? Then why are all the libraries containing rollback points still on your system? Other objects that need to be removed include copies of production libraries and individual files that are made prior to making a change or deleting records. I’m all for making a copy before starting on a major change, but once that change has been made and no problems have arisen, delete the copy!

The Payment Card Industry Data Security Standard (PCI DSS) and the recent New York State Cybersecurity Law both have requirements for purging data that is no longer in use. Most organizations don’t do that today, but I believe it will become more prevalent as more laws and regulations require it.

However, it should go without saying that a formal backup of data and user profiles should be made before removing them from the system, just in case they need to be restored.

Breach Recovery and Investigation

One question I get asked quite often is, “Carol, I don’t have time to look at reports from the audit journal, so why should I bother turning on auditing?” My response is that, even if you never look at a single entry in the audit journal, if you ever need to investigate a breach or incident, you need this information to perform an investigation. Yes, IBM i has been breached (due to misconfiguration by administrators, not weaknesses in the operating system). To perform a forensic investigation, it’s critical that you have a full set of audit journal receivers. And because breaches are often not discovered for several months after they start, it’s imperative that a complete set of audit journal receivers is saved—even when your organization isn’t under a regulatory requirement to do so. In the absence of a complete set of audit journal receivers, it will be quite difficult to perform a forensic investigation.

If hackers have infiltrated an organization and you determine that systems have been fully compromised, or you can’t determine whether a system has been compromised, or you’re unsure of whether you can fully clean up the breach, you may choose to completely rebuild the system. Hopefully, you’ve tested your disaster recovery procedures because you want to have a tried and true process when you’re trying to recover from a breach rather than testing it at that stressful time. And, once again, you’ll need to have a current SAVSECDTA to be able to restore user profiles, authorization lists, and private authorities to the most current settings possible.

Recovery from Malware

If you have a drive mapped from your workstation to anywhere in the Integrated File System (IFS), you are making the IFS available to be infected by malware. I’ve seen malware rename IFS directories as well as encrypt the contents of directories. IBM i is not immune to someone clicking on a link that downloads malware, infecting their workstation, and then infecting IBM i. To malware, IBM i looks like just another network drive, and away it goes, encrypting data, renaming directories, or whatever evil deed the malware is coded to perform. Your ability to recover from such an attack is as good as the last backup of the IFS. And if it has infected /QSYS.LIB, your last save of the libraries affected determines your ability to recover. If you think that you’ll just pay the ransom and not worry about your backups, think again. Ransomware is getting more insidious as time goes on. Some variants don’t provide you with the key even after the ransom (in bitcoin) is paid. Others look like they’ve simply encrypted the files but have actually deleted them. Bottom line: Do not assume that you can pay a ransom and get your data back.

Summary

Even though your backup practices may not be an obvious security topic, I hope that you’ve seen how a robust backup strategy will also help you with your organization’s security plan.