IBM i enjoys an envious reputation for being highly secure. Eyebrows are raised when there is discussion about vulnerabilities in this technology as it undermines one of the most enviable and unique qualities of the platform.
The reality is a little more sobering. The State of IBM i Security Study reports that most servers continue to leverage security configurations that pre-date networking technology, not to mention popular business use of the internet. The IBM-supplied default for object permission is “allow all” instead of the more desirable “deny all” and there is little alteration of this during or after application deployment.
New user profiles are typically duplicated from an existing profile and this leads to a propagation of attributes that were appropriate only on the servers of yesteryear. In the ‘80s and early ‘90s, users leveraged green screen terminals and had physical point-to-point connections to the server. A menu was all that was needed to fence the user into having access only to approved application functions. Stripping the profile of command line privileges further increased the restrictions and provided important separation between the user and server tasks.
When network connectivity was introduced in the mid 90s, it brought with it an era of fast, easy-to-use services such as ODBC, DDM, and FTP. Users quickly discovered they had direct access to the databased and, in some instances, the ability to circumvent the command line restrictions. This new openness was great for the users and their productivity—but far less desirable to the security team who suddenly discovered application data was being corrupted and also leaving the server without generating an audit trail!
Misplaced perception about how secure an environment is remains a challenge to experts in the field and lowers the urgency for “fixing” what has been considered for decades as inapplicable to servers powered by IBM i. Certainly, many organizations do acknowledge that there is work that should be done and that their security configuration is likely out of date, often by generations, but the old adage of “if it ain’t broke don’t fix it” comes to mind.
Discard the dangerous notion that perimeter protection alone will protect an internal server from abuse. Also discard any perceived correlation between not having been breached in the past and the risk of being breached in the future. Security configuration review and remediation, along with critical event monitoring and notification, must be incorporated with OS and hardware upgrades as anticipated, budgeted, and mission-critical projects.
In a related observation, IBM’s X-Force Threat Intelligence Index 2018 reports that an overwhelming percentage of publicly disclosed security incidents that occurred as a result of inadvertent actors, 2015 through 2017, are attributable to misconfiguration rather than exploitation of an actual weakness. Thanks to the robust security features of IBM i, most of which are unfortunately not correctly deployed, this is the only real avenue to unauthorized access to application data.