Article

An IBM i Security Project Doesn’t Have to Break the Bank

Protect valuable data by identifying cybersecurity "quick wins"
IBM i
Posted:
Jan. 13th, 2017

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 a number of enforceable mandates, typically as a result of a scandal or high-profile breach. The growing list of these mandates includes PCI 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 also now face a dramatic increase in fines that may levied for data breaches after 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.

Even if data does not currently fall under the watchful eye of a regulation, it most likely will 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 small steps to protect the technology infrastructure would have been far less costly than those implemented during the panic following a major breach.

A Short Platform History

Power 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 land 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 forward compatibility that allows the latest generation of server to be able to restore and run 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’s also led inadvertently to a very serious level of security risk.

Most organizations restore their security settings and applications onto a new server without pausing to analyze whether their configuration remains appropriate. In many instances, several of these configurations pre-date 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 possess an enviable reputation for being one of the most secure operating systems available. However, HelpSystems’ popular State of IBM i Security Study shows that most security controls contained within the OS remain configured to allow users 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 with access to restricted server functions. IBM i security experts now use the term “securable” instead of “secure” to describe the platform.

Vulnerability Assessment

A vulnerability assessment is the most effective way to evaluate your level of risk.  HelpSystems performs numerous assessments for the IBM i community, satisfying a range of needs—from the casually curious to large international firms burdened with proving compliance with regulatory mandates. There are two distinct offerings:

  1. Risk Assessment is a professional service offering that leverages HelpSystems’ commercial Risk Assessor software in conjunction with expert review. As a chargeable service, this offering provides detailed insight into more than 100+ risk points tied together by an easy-to-digest document. Risk Assessment is a deep-dive offering that provides the granularity required for a commercial audit and comes with the oversight of a team of highly skilled, dedicated IBM i security experts.
  2. Security Scan is a fast, executive-level review of critical areas of security configuration and comes without cost or obligation. Using proprietary software plus a WebEx review with a security expert, a scan review will:
  • Analyze how many users are operating with powerful user privileges
  • Validate IBM i’s security system values adhere to best-practices
  • Determine if 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 if exit programs are monitoring and controlling access from PCs

Thousands of organizations worldwide have taken advantage of these offerings, 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 as AS/400. The effectiveness of IT regulations is further limited by the fact that the mandates struggle to keep up with an ever-changing threat landscape.

Has your organization chosen to avoid tackling security for being 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 article is written for those that are not yet entirely prepared to acknowledge the full extent of their vulnerabilities, as well as for those who suspect their issues and don’t know how to start fixing them.

While resistance to an audit is not uncommon, I still always recommend a vulnerability assessment. Start by scheduling one of HelpSystems’ FREE, no-obligation Security Scans.

This non-intrusive scan runs in only about 60 seconds and provides a tangible document that can be used to gain executive sponsorship and for later comparison.

If nothing else, it 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:

  • Command Line Permissions

Users who are able to access screens containing a command line are likely able to run a plethora of powerful commands.

The State of IBM i Security Study reports 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 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.

In only 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.

It should be noted that both levels of vulnerability assessment offered by HelpSystems provide information on the prevalence of users with command line permission. For more details on how the operating system evaluates a user’s ability to run commands and on limiting command permission, refer to the HelpSystems guide Managing Privileged Users on IBM i

  • Network Access

Despite the overwhelming prevalence of PCs and mobile devices in today’s modern network, 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 users’ actions over this type of connection is a relatively simple task, achieved by limiting the menu options they are allowed to use and by removing their direct command line permissions as outlined above. 

IBM i contains several additional, powerful TCP interfaces that permit the same user community to 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 untraceable, as IBM i contains no “file transfer” event log type, which is an immediate audit violation.

In addition, several network interfaces allow users to run commands. In some 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 talks 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 fulfills 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.

Utilizing a commercial-grade exit program solution ensures that the processing of the requests is efficient and functional. It also avoids the conflict of interest from internal programmers writing exit programs to audit and control themselves. HelpSystems' Network Security is recommended for organizations of all sizes and in all industry verticals. Deep integration with the IBM i OS ensures the two components communicate effectively to police and audit powerful data and command requests.

Seek Out The “Quick Wins”

When embarking on a new security project, it can be beneficial to obtain a quick win by making simple changes that are valued by the user community and that ease a burden on the existing resources.

A common example is to evaluate the frequency with which users require assistance with their accounts. Gartner and Forrester, reputable research firms, have written extensively about the financial impact of these actions on a help desk. Combine this research with an analysis of how often your users forget their passwords and disable their profiles to establish a clear return on security investment (ROSI). HelpSystems' Password Self Help solution is a popular answer to this problem.

To improve security without opening “Pandora’s Box,” also consider remediating the 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.

A Business Decision Leads to Funding

Administrators and even system managers are often frustrated with 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, and 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 those same IBM i administrators and managers.

Sharing information about risks with business leaders empowers them to make important business decisions on how to plan for the future. In reality, blame typically doesn’t get assigned until a breach occurs and it’s discovered that risks were known and not shared. Distributing the State of IBM i Security Study along with results of a Security Scan may gain the attention of a manager who is working under the (false!) impression that the Power Server is inherently secure. This attention would allow 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 IT. If a business running IBM i is to 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 IT 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.

Ultimately, IBM i security risks are not going to be fully resolved until leadership is aware of the current state, the cost to mitigate, and the possible ramification of not doing so.

The good news is that these two important configuration steps can be implemented easily and provide immediate benefits with minimal financial and resource investment.

Let's Get Started

To get a quick evaluation of your IBM i security, request a free Security Scan today.