While IBM i was not the direct target, Carol discusses lessons the IBM i community can learn from the SolarWinds attack.

The full extent of the SolarWinds attack continues to unfold, but suffice to say that the breadth and the lengths to which the perpetrators went are, to put it mildly, stunning. I’m not going to describe the attack, but here are several websites that describe the details of the attack, and the SecurityWeek link is kept up-to-date as more details become available:

• SecurityWeek
• Microsoft
• Symantec

While I haven’t heard of any IBM i systems being affected, it’s not outside of the realm of possibility that an IBM i was breached as a side effect of this attack. Regardless, this type of attack should make all of us sit up and take notice and determine if we have the practices in place to fend off this type of attack if one should hit our organization.

One of the remarkable facts about the SolarWinds attack is the length of time it took to discover. It was only because FireEye was brave enough to come forward and talk about how it was breached that the extent of the breach started to unfold. Other companies such as Microsoft and security firms such as Qualys, Mimecast, and Fidelis Cybersecurity have also come forward to provide additional information about how they, too, were breached. Some, like Microsoft and FireEye have provided guidance about the breach, including tools to help detect and/or prevent it in your own network. Hats off to the transparency of these companies. Otherwise, organizations would most likely be clueless that they, too, were attacked and the exfiltration of their data may have continued for years.

People have asked why it took so long to detect. Two answers come to mind. One is that the techniques used by the hackers were so insidious that the hack took unprecedented steps to avoid detection. The other answer, I believe, is because many organizations just aren’t paying attention to their security configurations, including organizations running IBM i. So I have to ask: Are you paying attention? Here are the questions I’d recommend you ask yourself about your preparedness to detect such an attack. If you answer “no” to any of these, I recommend that you consider taking action to help reduce the risk to your organization.

#1: Do you have alerts in place to let you know that a profile was created with or changed to have *ALLOBJ special authority?

One of the tactics the attackers took was provisioning themselves accounts with admin rights. On IBM i, the CP audit journal entry shows when a profile is created with or changed to have *ALLOBJ special authority. Vendors have software that will allow you to be alerted to this type of audit journal entry in near real-time. Or you can write a query to review the CP audit entries yourself. Whether you write something yourself or purchase software, it’s not difficult to be aware when a powerful profile has been added into your IBM i environment.

#2: Are you regularly reviewing profiles that have *ALLOBJ or are a member of a group that has *ALLOBJ?

Even if you’re generating an alert (via a text message, PDF, or spooled file), I recommend that you review the entire list of powerful profiles. This ensures that you catch profiles that may have legitimately been assigned *ALLOBJ (or some other special authority) at one time but now no longer require it. And by “regular,” I mean reviewing the list of profiles at least once a month. I know that many organizations will review this list once year before an audit. But that, in my opinion, is not frequent enough.

#3: Are you sending IBM i security-relevant information to your SIEM?

If not, it’s like you have five pieces missing from the middle of your jigsaw puzzle. If you’re not sending IBM i information to your SIEM, you don’t have a complete picture of what’s happening across your network. Some events should never occur on IBM i and could be a high-level alert for inappropriate activity. For example, if you’re seeing invalid sign-on attempts where the profile is ROOT or ADMIN and they’re coming from an external IP address, this should be an alert that your IBM i has somehow been made available on the Internet.

#4: If you have exit point software, are you using it fully?

I know of way too many organizations that have purchased this software and either don’t use it at all or use it only to log transactions…but never look at the logs. This software has the ability to block transactions by user, group, or object. But in the context of the SolarWinds attack, the most important feature is that you can block by IP address. That was one of the issues that was missed by most organizations suffering the SolarWinds attack: outgoing transactions to unknown external IP addresses. If you add rules to the exit point software to block access by unapproved IP address ranges and then review the logs for blocked transactions, you may be able to detect such an attack occurring on IBM i.

#5: Are you using multi-factor authentication (MFA) for IBM i log-on?

While some aspects of the SolarWinds attack bypassed MFA, in general, when an attack occurs that exploits a powerful profile (such as credential theft), the attack is not successful if MFA is in use.

#6: Is your development environment secure?

While it appears that there are several attack vectors used, the one that first came to light is that the build system for SolarWinds was breached by the attackers. They then inserted code into the Orion product’s build system, and the code was subsequently delivered to unsuspecting clients via patches to the Orion product line. This breach went undetected by SolarWinds until FireEye revealed how the compromised SolarWinds product allowed FireEye (and many others) to be attacked and its data exfiltrated.

I know that many (most?) IBM i development systems receive very little attention from a security perspective. Where development continues to reside on IBM i, developers often have *ALLOBJ special authority, reviews of configuration settings (including profiles and object authorities) are rarely performed, and auditing, if enabled, is not paid attention to. Many IBM i organizations have moved their code repositories to the cloud. In the security newsletters I read, there’s an article at least once a month about an organization suffering some type of loss because of a code repository being left unsecured. First question: Do you pay attention to the security configuration of your development environment? Second question: If a breach occurred on your development system or online code repository, would you know?

Summary

While I hope that no organizations running IBM i were affected by the SolarWinds attack, it’s so widespread that I’m guessing some organizations were. I’m hoping that those organizations had these items in place so that their IBM i aided in the detection of the breach. For all other organizations, I hope that you take this list into consideration. And if you couldn’t answer yes to the six questions I asked, you should seriously consider implementing technology that will help your organization detect and perhaps even prevent future attacks.

 

Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

 

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95 Now On Sale

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice