From Here To There: Securing Your Future On IBM i (And In The Cloud)
September 23, 2020 Steve Grzybinski
The Connectria team presents a three-part series addressing concerns IBM users have about the platform and its future. Part Two: Security And Disaster Recovery.
Last month, we kicked off our discussion of common concerns about the IBM platform by taking a close look at the shrinking system admin pool and how to leverage remote administration to offset that risk. This month, we dive deeper into another area of concern for Power Systems platform users: Security (and I’m not talking about social security for all of us about to retire).
Security is a broad and extensive topic, so let’s break it down a bit further and touch on the things that are critical to a Power Systems shop. When we think about security, we classify risks and protection across three buckets: External Threats, Internal Threats, and Data Security.
External Threats are the exposures that get all the press. Hackers, (computer) viruses, and DDoS attacks (oh my!). The list goes on and on (and on, and on, and on) and seems to get worse each year. The weird thing is that many of us can remember a time before cyber security was a career path. In fact, while the first hacking events appear to have occurred in the 70s. They were confined to governments trying to steal each other’s secrets or academic nutjobs trying to see how they could access information they really weren’t supposed to see. It wasn’t until well after the birth of the AS/400 that security and threat prevention became a real conversation. In the early 90s the propagation of computer virus across desktop computers (Does anyone call them that anymore?) really brought the need for automated protection from external/network threats to the forefront (Viruses from sharing floppy drives? wow are we showing our age…).
For the longest time, conventional wisdom was that a.) who would ever want to hack into a boring AS/400 and b.) if I have good network level deterrence, I wouldn’t need to worry about my systems anyways. Partially from that mindset, security implementation has been different on the IBM i than the rest of the Intel/Windows world. Security protections are not inherent on the IBM i; they must be turned on. “Typically, what I see users, companies, or security and compliance teams get wrong is simply assuming IBM i is automatically secure,” said David Wiseman, Connectria vice president of solutions architecture. IBM i delivers a platform with tons of capability and durability (so much so, that sometimes people forget they need to take extra steps to secure it). Am I biased? Yes, of course I’m biased, security is kind of my thing, if you can’t tell. The IBM i can be one of the most secure platforms available, but it doesn’t happen out of the box. There are steps that the user or enterprise community need to act on to make that happen.
Addressing External Threats is a great start, but the often-overlooked threat lies much closer to home, Internal Threats. History has taught us that some of the most crippling security events have happened from the inside. One of the main issues that lends itself to Internal Threats on IBM i is granting too much access/authority to people who really don’t need it. A misconception is assuming security permissions can’t be touched and that once they are in place you’re done. There may be a role(s) in your organization for someone to need elevated rights like ALLOBJ access. But too often, we find that normal end users/team members within an organization also have that same security admin permission. While a lot of applications and companies think ALLOBJ is a requirement for things to run. This is simply not true.
To me, ALLOBJ is a red flag. It should be small subset of your team, not 50% or 75% of your organization. While most security teams and experts wax on and on about preparing for malicious attacks from outside your company, that mindset can overlook potential accidents from your own team members, which I’d classify as more likely of an event. Sometimes, I think the biggest thing we struggle to communicate is that properly handling internal security permissions, therefore minimizing Internal Threats, is what needs to be addressed.
A user that has full rights, can and has, accidentally deleted production libraries. If you take the time to do the simple things, some of those hard mistakes don’t have to happen. We have had a lot of companies with users with the ALLOBJ ability accidentally delete valuable company data. From a security perspective, that is probably one we see the most. Someone has too much access, they don’t know what they are doing and make a mistake. We see it a lot more than we do any kind of compromise, Bad Actor, or hacking. We see these kinds of accidents, notably more than any kind of malicious activity. However, I also want to be clear and not diminish security concerns on either front, external or internal. Overall, I just want to emphasize the probability of one event over the other. Don’t overlook the small or obvious thing. The course to creating a sound, stable, and ultimately secure environment should start with addressing internal team permissions and running lean teams of admins to prevent incidents with the potential to bring down your business.
So, what do you need to do, to develop a comprehensive External and Internal Security program? First, make sure you involve knowledgeable resources, that can pull and review data of how security is currently configured on the IBM i. Also, work with the business side, not just the technical side, to design and implement controls that do not create downtime. You then phase in your approach:
- Gather data
- Review the data
- Change security system values
- Start putting in password and user controls
- Look at your object level security
The third part of any good security plan focuses around Data Security. The truth of the matter is that even the best protections on your system may still get exploited from new and unknown exposures. Your best ultimate defense is safeguarding your data. There are two elements to a Data Security strategy: backing up the data and restoring someplace to keep the business running.
Backups are critical for not just small, accidental file deletions, and restore, but also for larger, more insidious events like ransomware attacks. Having your data properly backed up and stored in more than one location (fully encrypted of course) provides you a level of comfort even if the worst events take place. Your data is your company’s lifeblood. Without it or with it badly infected, you die (ok that was a bit morbid, but you get the point). Advancements in backup technology over the last decade or so have made this more cost effective and reliable than ever before. You can still use tapes (if you have to) but having virtual tape library options and/or Backup-as-a-Service offerings from any of the major players in our market are all excellent extra options to better safeguard your data. (You really should check them out.)
Ok, so your data is backed-up, now ask yourself: if a disaster strikes your office tonight, could you get your business up and running again in the morning or sometime tomorrow? How about within a week? Can your business survive a major outage? If you haven’t planned for a worst-case scenario, the answer is probably “no”.
This is why it’s important to have a DR plan. Assuming that you are doing a good job of backing up your data, in the event of a disaster, be it a flood, tornado, hurricane, wildfire, some other natural or manmade event, or a simple user permission accident compromising your data center, you need a place to restore your data and get back up and running. This is where a good DR solution can help. Building your own DR solution can be expensive and do you really have the time to manage something else? Disaster Recovery as a Service (DRaaS) options enable organizations to avoid high costs associated with maintaining and staffing your own data center while ensuring your detailed plans will work when you need them to.
There is no one-size-fits-all disaster recovery plan. The first step is to set recovery objectives based on your unique organizational needs and can also vary from workload to workload. Setting recovery objectives appropriately is critical since they’re primary factors when determining the best replication solutions for your business. The next step is to set how much will need to be budgeted for disaster recovery. Typically, the lower the recovery objectives, the more expensive the solution. With objectives set, you can immediately focus on selecting the best recovery options for you.
Connectria wants to help you find the right path. We believe that security comes first. When you work with Connectria, you get compliance and reporting tools as well as exit point controls. Over 800 IBM i workloads under management demonstrates the overwhelming success of Connectria’s IBM i solutions and effectively makes Connectria IBM’s largest service provider worldwide. We also have proven DRaaS solutions and all options include complete implementations from Connectria’s skilled engineers, as well as 24×7 continuous monitoring, annual failover testing, and full 24×7 support from our Command Center.
Connectria is constantly researching and retooling to address security concerns to effectively fortify your IBM i systems. We focus on safeguarding our own future in this space by constantly working ahead to preserve performance to the best of our abilities. We continue to add resources, security features, and focus on anything we can do to promote the longevity and stability of the platform for the future of our business, and therefore the future of your business. We diversify our offerings across multiple datacenters while also embracing cloud technologies so no matter where you are, we can help you get to where you want to be.
This content is sponsored by Connectria.
Steve Grzybinski is director of security and compliance at Connectria Hosting.
