Occasionally, I’m confronted by a frustrated C-level executive questioning the fallacy of “AS/400″ security and how they were falsely sold on how impenetrable this infamous server is. These comments are typically heard when I’m working on an assessment project and discussing the opportunities their users have to access application data and perform server administration tasks.
Almost a decade has passed since FTP and ODBC were enabled on the iSeries, but I still hear remarks that IBM should be ashamed of itself for facilitating transparent data access through these interfaces, and for providing an open door to critical data. This opinion might rear its head after an auditor discovers just how easy it is to use network-based tools to access DB2 data.
Much of the controversy stems from the server’s default security configuration. Under most operating systems, if a user is not granted access then they have no access. IBM i, however, operates with a unique concept called “public authority,” which grants a default level of access to anyone who is not explicitly given—or denied—access to an object. IBM ships this default value as *CHANGE, which provides rights to read, change, and delete data.
So, in light of these issues, how did IBM i gain its reputation as a highly secure operating system? Can we trust IBM i to run our critical applications? I have been working on the platform for more than two decades—nine of those years in security—and I say unequivocally “Yes!”
I inform those frustrated C-level executives that this operating system earned its reputation with world-class integrity features. When configured correctly, IBM i stands head and shoulders above most others. The problem is that most organizations do not adequately configure the integrated security controls, instead choosing to retain the shipped defaults or to leave the security configuration in the hands of an application software vendor.
IBM i has incredible security capabilities. But, like virtually every other operating system, those controls don’t come configured out of the box. You wouldn’t dream of deploying a Windows server without carefully architecting its security. So why would anyone think that IBM failed their responsibility by requiring the same?
Perhaps it’s not unreasonable to question why IBM i isn’t shipped in a deny-by-default configuration, however this would conflict with the execution of many applications. IBM designed the mechanism, but it’s the responsibility of the server’s owner and the provider of the applications to configure it appropriately. Sadly, many applications do not incorporate well-designed security controls. Of those that do, it’s possible for overly-powerful users to undermine the controls.
Many applications are written with no regard to security. Programs are compiled without any consideration to the users that will utilize them and the configuration of the server that will server them. Regardless of whether your applications are home-grown or commercial, if they rely on menu security—or controls that are internal to the application—then there’s a good likelihood that the data could be accessed by users; possibly without an audit trail.
You should be aware that some aspects of IBM i security are best fulfilled by commercial providers, such as HelpSystems. Our Network Security product is a good example—one that provides access controls and auditing of the FTP and ODBC connections I mentioned earlier. We have established our reputation by developing a portfolio of security solutions that leverage and extend the controls included within IBM i. We also have experts on staff who can help you assess what controls are currently in place, and what could and should be implemented based on the server’s purpose.
Utilizing IBM i’s world-class integrity features will establish an unshakable foundation for any security initiative, but you have to use and deploy the configuration options that are available. If you don’t, you only have one person to blame… and it’s not IBM.