Many Corporate Hosting Agreements Do NOT Apply To IBM i. Here’s Why?

Here’s Why:

If you are a regular reader of my blogs, you know my company offers Cloud400 to host IBM i applications.

Coincidentally, I have had 3 large, publicly traded companies provide us with their “standard” hosting agreement.

I can clearly understand that companies want their own hosting agreement to articulate mutual responsibilities, expectations, service level agreements, and technical requirements.

As a hosting provider, we have completed SSAE-18 SOC II audits to satisfy compliance with security best practices.

Even so, each of the hosting agreements I have reviewed had requirements that are not applicable to IBM i.

Let me highlight a few.

Ultimately Security Starts With The Client’s Security Team

Security starts at the network level. You have to stop it before if ever gets to the user. Not allowing the user to have an option to click on a nasty link. Locking down the firewalls, ports and subnets. Intrusion prevention is key.

Security starts with the firewall. In many cases, the client provides their own firewall for us to host. In such cases, issues of intrusion detection, user authentication and prevention of malware is the client responsibility.

When the client selects to work with our firewall, we are monitoring for intrusion detection, user authentication and malware prevention.

One of the big things that IBM i has going for it is that it does not use common management user names like “Administrator”, “Root”, “Admin” or “Sysadmin”. Most of the malware/ intrusion attempts we see are using those Window, Linux, AIX profiles. They are never trying QSECOFR.

“Your Hosting Servers Will Include Anti-Virus, Anti-Malware, Anti-Trojan Horse And Other Protective Software.”

I understand when your applications run on Microsoft Windows, UNIX or Linux that preventive measures are required.

On the other hand, the core IBM i architecture is not vulnerable to these types of software attacks for several reasons.

First, the IBM i will only permit properly designated data and programs into the system. This means that malicious programs that are “camouflaged” as data cannot execute when they are opened. A common want for malicious software is to infect a server or desktop.

Second, IBM i is written in a proprietary programming language known as Machine Interface or MI. This is an IBM proprietary object-oriented language unlike the languages other operating systems use, most commonly C. The population of programmers that know MI is extremely small and since the language is IBM proprietary, it is unlikely a programmer will create a malicious program with it.

Third, the IBM i OS kernel is a secret, unlike the other more popular kernels. This means that other than the extremely small number of entrusted IBM i OS developers, no one else has access to the specifics of how the IBM i works. If you don’t know how it works, how can you infect the OS with malicious code?

“You Are Responsible For Any Unauthorized Intrusion Or Hacking”

Corporate hosting agreements are designed to protect their company and their critical systems from unauthorized access.

Over the years we have all heard of exceptional access to huge volumes of confidential, sensitive and critical data. Clearly, this is a real life concern for all of us.

Nevertheless, I point out that the IBM i has a User Profile which identifies the specific user and security level for ANY authorized user.

I also stress to those who want us to host their applications, the User Profile is the clients’ responsibility not the hosting provider’s responsibility. A hosting provider generally does not know the applications (some do), does not know the client employees, and does not know the authorized security level of each user. Only the end-user company knows the details of the User Profile.

As much as the corporate hosting agreement wants to push this responsibility onto the hosting provider, in such cases I insist that this is their responsibility. If the user does not understand how to setup or manage the User profile, we can help them with these tasks. But ultimately this is the users’ responsibility.

IBM i Integrated File System (IFS) DOES Have Vulnerability

So let’s talk about the IFS vulnerability.

The IFS is designed to interface with Windows and share data. It includes IBM i NetServer and is part of the neighborhood network. The IFS includes a way for files and data to be exchanged between a Windows desktop/server and the IBM i server.

So a Windows user with a valid IBM i User Name and Password could get an infected file and pass it up to the IBM i IFS through a VPN tunnel and it will NOT be detected. Intrusion detection and anti-malware software will not catch this because the user has authenticated credentials and connects via an authorized encrypted tunnel.

While the integrity of the IBM i architecture will not be affected, an infected file exists in the IFS so if another or multiple users access this infected file, their Windows devices are affected.

For example if a ransomware product gets loaded to a workstation, it can transfer to the IFS and get pushed back out to other users or servers.

This is a scenario that the user network team needs to manage and prevent because the infected file came from the user network community.

“Data At Rest Must Be Encrypted”

More frequently we are asked to provide data-at-rest encryption.

Even so, many versions of the IBM i OS do not support this level of encryption.

So, depending on the IBM i OS level, data-at-rest encryption may not be a realistic request.

Conclusion

While we take client security very seriously, we do highlight the distinction of the IBM i relative to other operating systems when we finalize our agreements.

This process of hosting agreement negotiations works best when the client has IBM i expertise on their side to validate the points we make, and how IBM i is different (and way more secure) than the other hosted operating systems.