Stop neglecting IBM i security. Consider a risk assessment and two control layers to enjoy substantially less risk of data loss—without sending your organization into the red.

The time is now!

While some companies take a proactive stance on becoming more secure, many more act as a result of regulation. Governments and industry bodies have enacted numerous enforceable mandates, typically as a result of a scandal or high-profile breach. The growing list of these mandates includes PCI-DSS for credit card data, MAS-TRM for financial organizations in Singapore, BASEL for the banking industry, SOX for publicly traded companies, and HIPAA for those in the U.S. healthcare industry. Operators in the European Union face a dramatic increase in fines that may be levied for data breaches since the General Data Protection Regulation (GDPR) was adopted in April 2016. This replacement for the previous “directive” will become law in May 2018, and the financial impact on companies within this territory could be quite dramatic.

Hardening security to best-practice standards should be done out of due diligence. Even data that does not currently fall under the watchful eye of a regulation will likely do so eventually, and best practices state that all data should be treated with care to promote its protection as well as its accuracy. Sadly, many organizations can now attest to the fact that proactively taking even small steps to protect the technology infrastructure would have been far less costly than those actions implemented during the panic—as well as the aftermath—of a major breach.

A Short Platform History
IBM Power Systems servers and the IBM i operating system represent the latest in a long evolution of midrange servers manufactured by IBM. Once known as the “AS/400,” early generations of the server grew through the iSeries and System i monikers to settle at the current name in 2009 when IBM i v6.1 was released.

Despite the various changes in name and underlying architecture, one of the platform’s greatest strengths has always been the unprecedented level of forward compatibility that allows the latest generation of server to restore and use objects saved at any prior level of the OS and server hardware. Not only will the restore succeed, but applications written for the original 48-bit hardware will benefit from the newer 64-bit architecture, often without any modification or recompilation of the application.

This unique capability simplifies a migratory path spanning almost three decades; however, it also inadvertently resulted in very serious levels of security risk. Most organizations restore their security settings and applications to a new server without pausing to reflect on whether their configuration remains appropriate in this modern era of interconnectivity, remote access, and endless data breaches. In many instances, many of these restored configurations predate personal computers, network connections, mobile devices, and the Internet. Servers and databases are left dangerously open and highly vulnerable to access from overly powerful users using profiles that were created with only “green-screen” (5250) menus in mind.

The State of Platform Security
IBM i possesses an enviable reputation for being one of the most secure operating systems available. However, a popular security study reports that the majority of the security controls contained within the OS remain non-configured, allowing unrestricted access to application data. In addition, the popular practice of duplicating existing profiles during user provisioning leaves most organizations with a startling number of users who have access to restricted server functions. In an attempt to dispel a dangerous myth, IBM i security experts now use the term “securable” in place of the more common reference “secure” to describe the platform.

Start with a Scan!
A vulnerability assessment is the most effective way to evaluate the level of risk. IBM i is serviced by several people and companies within the community who perform these for a variety of organizations, from the casually curious to large international firms burdened by regulatory mandate to prove compliance.

Risk assessments should be performed by someone familiar with the nuances of this unique platform and who has a formal audit certification, attesting to an investment in ongoing education as well as an indication of adherence to a code of ethics.

Even a basic assessment should:

• Analyze how many users are operating with powerful user privileges.
• Validate that IBM i’s security system values adhere to best practices.
• Determine whether OS-controlled anti-virus scanning is active.
• Assess the number of unauthorized/failed connection attempts.
• Evaluate whether the audit controls have been activated and configured.
• Detect whether exit programs are monitoring and controlling access from PCs.

Thousands of organizations worldwide have conducted some flavor of assessment, but some inevitably become victims of “analysis paralysis,” intimidated by the large number of changes that often need to be made. In addition, a surprising number choose to avoid looking, assuming they are already “secure” or preferring to remain uninformed about the risks simply as a way to avoid having to act.

Don’t Ask, Don’t Tell
Regulatory compliance is designed to enforce good security practices and lower the risk for those that may not otherwise act on their own volition. However, regulations don’t apply to everyone, and many big-firm auditors simply don’t know how to correctly audit IBM i, still referring to the server by the obsolete “AS/400” name. The effectiveness of I.T. regulations is limited further by the fact that the controls struggle to keep up with an ever-changing threat landscape.

Has your organization chosen to avoid tackling security the project seems too complex or expensive? Is there a sense that data on your IBM i server is not valuable to a hacker? Or are you simply unsure of where to begin? If any of these objections ring familiar, I recommend considering a couple of basic controls to help assure the integrity of the server and to protect the database—which always has some intrinsic value to someone—from unauthorized access, both malicious and accidental.

Do Something…Do Anything!
This short article is written for those who are not yet entirely prepared to acknowledge the full extent of their vulnerabilities as well as for those who suspect their issues but don’t know how to start fixing them. While resistance to an audit is common, I still always recommend a vulnerability assessment. Take advantage of one of the IBM i vendors offering free automated scans to obtain executive sponsorship and for later comparison. If nothing else, documenting the risks is a way for the technical staff to cover themselves by reporting the vulnerabilities and requesting the necessary funding from management.

Now, with that being said, let’s cover two of the most basic considerations that can dramatically reduce the levels of risk without breaking the bank or overwhelming the available resources:

1. Command-Line Permissions
   
   Users who are able to access screens containing a command line are likely able to run a plethora of powerful commands. Ten years of audit experience has taught me that the majority of users are granted command-line permission via the limited capabilities (LTMCPB) attribute on their profile. This allows them to leverage all of their public and private object permissions, as well as utilize the reserved functionality afforded by their special authorities and those belonging to any groups they are a member of.
   
   Only in rare instances should end users be allowed to run commands directly from a command line. By limiting access to this capability, a user may operate with excessive privileges with lower risk than would normally be observed when operating with an administrative-level account. This is an easy offset against overly powerful users operating within a “green-screen” environment and can be configured to still allow certain individual commands that you may deem benign.
   
   
2. Network Access
   
   Despite the overwhelming prevalence of PCs and mobile devices in today’s modern networks, a significant percentage of IBM i applications remain designed to be accessed via the green-screen environment. Users sign on using a Telnet emulator and access the application via menu options. Limiting the actions of users over this type of connection is a relatively simple task by limiting the menu options they are allowed to take and by removing their direct command-line permissions as outlined above.
   
   IBM i contains a number of additional, powerful TCP interfaces that permit the same user community to also connect directly to the database. These connections are established without the restrictions imposed by menus or the application, often granting users free reign to directly view, change, and even delete data in files. These activities are mostly transparent as IBM i contains no “file transfer” event log type, which is often an immediate audit violation.

In addition, several network interfaces allow users to run commands. In a couple of instances, this can be done independently of the command-line permissions that have been configured. So why even bother establishing command-line restrictions? Because the restrictions do remain effective in the green-screen environment and do apply to most of the TCP interfaces.

These significant shortcomings can be addressed very effectively via the deployment of “exit” programs registered to the exit points within IBM i. Conceptually, an exit program merely extends the function of an existing system operation. An exit program can intercept a request originating from monitored network services—such as ODBC and FTP—and process it before the OS takes its turn. Experts recommend that an exit program should be used to determine whether the request should be permitted or rejected, as well as whether it should also be logged (audited). This latter capability fulfils an important function lacking within the OS. The ability to reject a request is performed without regard to the authority that the user would otherwise have. This solves the challenge of users with too many special authorities and databases with permissive private and public authorities. It also remediates the risk of users without command-line permission running server commands.

Custom exit programs can be written in-house, but utilizing a commercial-grade exit program solution ensures that the processing of requests is efficient and functional. It also avoids the conflict of interest from internal programmers writing exit programs to audit and control themselves. Regardless of their origin, the integration between exit programs and the IBM i OS ensures that the two components communicate effectively to police and audit data access and command requests.

Seek Out “Quick Wins”
To improve security without opening Pandora’s Box, remediate the two specific vulnerability points outlined above. While longer-term security projects may entail reducing the assignment of special authorities, changing system values, and establishing complex object-level security controls (a task made easier by the “authority collection” feature introduced in IBM i v7.3), a significant amount of risk can be resolved by enacting these two very simple controls. Obtain a quick win by making simple changes that improve security but that are largely transparent to the user community and that do not impose a burden on the existing infrastructure.

Quick wins should pave the way for additional milestones. Tasks that involve more time, money, and resources should be proposed and can be budgeted for in much the same way as the initial steps. It’s turning into a cliché, but “security is not a destination but a journey,” speaking to an evolution of threats and the associated response. You may fear that evolution, but you simply cannot afford to avoid adopting commonsense security basics.

A Business Decision Leads to Funding
Administrators and even system managers are often frustrated by the lack of a security budget for IBM i. This audience is beginning to realize that there are vulnerabilities in their configuration that need to be addressed, but the perception remains that blame will be apportioned for the shortcomings. There is also resignation that business leaders won’t allocate the necessary funding to solve the problem anyway. And, ultimately, who will be charged with the responsibility and workload for achieving, managing, and maintaining that secure configuration? Most likely them.

Sharing information about risks with business leaders empowers them to make important business decisions on how to plan for the future. In reality, blame doesn’t get assigned until a breach occurs and it’s discovered that risks were known but not shared or that nobody even bothered to check. Distributing an IBM i security study along with results of a risk assessment may garner the attention of a manager who is working under the (false!) impression that a Power Systems server is inherently secure and sets the stage for executive sponsorship and the assignment of the necessary monies and resources.

Isolating vulnerabilities should lead to the evaluation of remediation costs. In some instances, those costs may even be covered by separate departmental budgets, such as audit and compliance, rather than I.T. If a business running IBM i is to ever be secure, it’s critical that action be taken before it is too late—even if regulatory compliance is not yet demanding it. With most I.T. teams being over-extended, automation and operating efficiencies must be employed to ensure that new projects do not force the existing ones to take a back seat.