The Four Hundred

Is your iSeries system secure? The answer is never a simple yes or no. We try to make our systems as secure as they need to be, keeping in mind that the return on investment, based on staff time and software purchases, is inherently fuzzy. Trying to get a grip on security is a difficult thing, as security requirements are evolving as new threats are uncovered.

The iSeries has a reputation for being one of the most secure systems in the world. However, the security of the iSeries, like any other platform, can be crippled through a lack of user knowledge or by an inferior implementation.

Few iSeries technicians have even a basic understanding of what might be the biggest security threat that faces the iSeries. The problem is vast in scope, and can render the iSeries a defenseless pawn.

The problem is the network. Unless you take specific, ultra-technical steps to securing your iSeries on the network, you are most likely leaving your system in a vulnerable state. Desktop tools like ODBC, DDM, FTP, iSeries Access (Client Access), and a myriad of others can lay waste to your iSeries database. For example, a simple FTP statement like "QUOTE RCMD CLRPFM PAYROLL" can delete all records from your production payroll file.

To fully understand this problem and the solution, it is helpful to look at the security history of the iSeries and its predecessors.

The iSeries is the most securable system in the world, for the least amount of effort. Consider the vaults at Fort Knox. They are highly securable, but if all the guards left their posts for a long weekend and someone left the vault doors open, just how secure would it be? The same can be said for the iSeries. It is highly securable, but the guards must be kept on duty and the vault doors locked.

In the networked world in which we live, every computer system is vulnerable to some form of attack. One fundamental principle of information security is that the host system, where the goodies reside, must provide the final line of defense. Yes, we have firewalls and packet filtering and various network authentication methods, but it is the host itself that must be its own protector. After all, over 80 percent of computer breaches come from inside the firewall, not from remote hackers.

To understand where we are today in the iSeries security game, we must go back to the early days of the IBM System/38 and its CPF operating system, the predecessors of the AS/400 and the iSeries.

Before the vast proliferation of PCs on office desktops in the mid to late 1980s, the method for online transaction processing was to enter the data into a green-screen, text-based workstation device. The only thing that traveled on the cable between the workstation and the host was the green-screen data stream.

When we designed security in the old green-screen days, we had it pretty easy. We simply created a text-based menu for our users, from which they could select a menu option and be presented with a data entry screen. All was right with the world; security was easy.

During the green-screen regime, system administrators didn't worry much about protecting their host files and programs, because users were trapped forever in their menu and submenus. If we didn't want a user looking at certain data, like payroll or sales figures, we just didn't place that option on their menu.

In the mid 1980s, IBM began to provide tools that gave users new data access methods. IBM had introduced the IBM PC in the early '80s, and shortly after introduced the first PC-based tools for the System/38. The Big Kahuna early on was System/38 PC Support File Transfer. You could actually transfer a file between a PC and an AS/400. What a breakthrough! You could now download a file from the System/38 into a PC spreadsheet.

As great as this new file transfer support was, it also opened a huge security exposure. Since, in those days, we did not worry too much about securing individual files, our files were left unguarded and the new transfer function allowed users to download just about any file from the system. The exposure was not due to poor operating system security but our failure to properly implement object level security.

That new exposure left only a few options for customers who did not want to simply maintain the status quo, rearchitect a new security scheme, or disallow all file transfers, which were tough pills to swallow. The one remaining option was to use IBM's new security exit point program facility to control the PC Support file transfer function. The purpose of this new exit point program facility was to allow users to write a program that would interface with the PC support transfer facility and intercept all file transfer requests, and allow or reject the request based upon the information provided to the exit point program. Writing one of these exit programs was pretty heady stuff for the majority of System/38 programmers, so the problem was mostly swept under the carpet and ignored.

When the AS/400 was introduced, PC Support was replaced by Client Access/400, which added more new capabilities to access data residing on the host. Newer implementations of IBM's DDM (Distributed Data Management) architecture made it painfully easy to get at AS/400 data and services from a PC. The connection method of choice soon switched from cables and green screens to PCs and Ethernet.

With each new networking enhancement, systems became increasingly vulnerable to security breaches initiated through one of the network interfaces. Access to data and system services using FTP, ODBC, Client Access file transfer, DDM, and other tools had become the norm, rather than the exception. During this massive change in access methods, the AS/400 community generally slept. It was only evident to the super-initiated that the green-screen menu-driven security model was no longer appropriate, and could not be relied upon to secure their systems.

The data access permissions you provide to a user via OS/400 security, for green-screen access using green-screen menus, is probably not be the same level of access you want to allow using network tools like ODBC. For instance, the OS/400 authority that allows a user to view the contents of a payroll file is the same authority needed to download that file to a PC and post it on the Internet.

Consider an example of our payroll supervisor, Bob. Bob has been granted *ALL authority to the payroll master file, to be able to make changes to pay rates and add new employees through the green-screen programs. However, Bob is also well versed with programs like MS/ExcelTM and MS/AccessTM. Using these PC based programs, Bob's *ALL authority is sufficient to add, change, and delete records from the payroll master. In fact, he can also delete all the records from the file, or delete the file altogether. With a simple typing mistake in Excel, Bob can wipe out the entire payroll file.

When tools like FTP, DDM, ODBC, and Client Access file transfer are used, there is virtually no record of that access anywhere on the iSeries. If you have ever looked for the iSeries FTP log to determine who did what with FTP, you have been sorely disappointed. There is no FTP log on the iSeries. And don't bother looking for the DDM or Client Access log, either. There is no log of most network traffic on the iSeries.

These two facts, that users have more authority to files and services than they should have, and that network access to these files and services is not recorded anywhere, are a loud wake-up call. So what's a conscientious system administrator to do? The exposure level is not acceptable.

There are several ways to solve the problem. These are basically the same options that were available back in the old System/38 days. One option is to just leave the status quo, with all the exposures, just make sure your résumé is up to date. At the other end of the spectrum is the option of shutting down all the network server programs on the iSeries and running completely in green-screen mode. This will effectively shut down network access and close the network security problem, but it's not a workable solution for most iSeries shops that require at least FTP and iSeries Access tools. Another option is to rearchitect your entire security scheme, which can be highly disruptive and will ultimately not get you to the promised land. This is not an acceptable option for most situations, because you don't want to allow the same level of authority for green-screen access as you do for network access. Another option that was available for the System/38, and is still available today, is to write and maintain your own exit programs for each server. At last count, there were more than 32 network servers, with over 180 network functions that may be monitored and controlled. That's a lot of exit programs to write and maintain.

If you simply consider the most often used servers like the FTP server, TELNET server, SQL/File servers, NetServer, and the remote command server, you're talking about needing several exit programs, some of which are very complex. This is especially true for the SQL/File servers that need an exit program to be able to understand and secure the system when the input is an SQL command string of up to 64k bytes in length. Most exit point program vendors parse the entire 64k byte SQL string and pick out the object names that are referenced to determine what will be allowed and what will be refused.

When I ask iSeries technicians if they have DDM running on their iSeries, many do not know the answer and many don't even know what DDM is. DDM, or Distributed Data Management, is an IBM communication application that allows record level access to files on a networked iSeries. DDM also provides the capability to send commands to a networked iSeries. And, yes, it is running on every iSeries as an integrated part of the operating system.

There are huge security exposures in DDM because of the way most shops fail to secure the application. If DDM is not secured correctly, as it can be with vendor-supplied exit programs, files can be accessed and commands can be run without the need for even an iSeries user ID and password. And to add to the DDM exposures, this application does not evaluate the OS/400 User Profile attribute named "Limit Capabilities (LMTCPB)", which prevents users from running commands at an OS/400 command line. So, with DDM, even limited capability users can run any command to which they are authorized.

Writing and maintaining a multitude of network exit point programs is not a realistic option for the vast majority of companies. However, there are exit point software packages that provide the network exit programs and management facilities needed to customize network access permissions. These exit point programs interface directly with OS/400 network servers to control and to provide an audit trail of all network access transactions. Some packages also provide intrusion-detection capabilities to alert system administrators when unauthorized access is attempted through the network.

Dan Riehl is the founder of PowerTech Group. He has authored books and articles on iSeries security. E-mail: dan.riehl@Powertech.com

Sponsored By

VISION SOLUTIONS

CIBC Banks on Vision Suite® to Make their Fiserv ICBS Application
Highly Available

The Company
Amicus Bank is a wholly-owned subsidiary of Canadian Imperial Bank of Commerce (CIBC), with more than 1.5 million active accounts. The bank provides its customers with a full-range of banking services delivered 24/7 through a variety of channels such as automated teller machines (ATMs), telephone-banking, the internet and in-store pavilions.

Business Challenge Faced
Amicus needed to find a solution for their banking systems to assure that no data would ever be lost due to planned or unplanned outages or disasters. From an operational perspective, the solution needed to allow for continuous operations with minimal to no downtime for both scheduled and unscheduled maintenance and zero downtime for backups.

The bank is one of the largest users of Fiserv's ICBS on the iSeries as the core business application. It also uses ACI Base 24 financial processing middleware, Websphere on AIX and an IBM workflow engine. For application integration and secure transaction processing, they use MQ series. From a network perspective, the bank uses both SNA and IP. The chosen high availability solution needed to be scalable enough to secure ICBS as well as all of the other applications to ensure the smooth operation of the complete environment.

The Solution
After a thorough investigation of all available solutions and vendors, Amicus chose to deploy Vision Suite from Vision Solutions. Vision Suite utilizes the journaling capabilities of iSeries to replicate all data and object changes in real-time to a second system. This allows Amicus to make daily tape backups, run queries, and process data intelligence work from the second system without impacting user uptime on the production server. For any planned or unplanned downtime, users can be instantly switched through IP address takeover to the second system with minimal downtime and without any loss of data.

Benefits
"Customers expect that our ATMs, internet banking, and other customer facilities are available at all times. Any downtime is unacceptable, independent of its cause, and therefore, avoiding downtime becomes a prerequisite for our business. Without Vision Suite we would run the risk of significantly disrupting our business, causing unhappy customers and customer turnover, said David Whyte, Senior Director of Technology for Amicus Bank. "Vision Suite's performance and ease of management allows us to perform maintenance and upgrades without having to take our customers down at any time," continued Whyte.

Return on Investment
Although one hopes that such never occurs, two years ago Amicus did have an unplanned outage when they lost a number of drives during maintenance. When the drives were put on, the server could not recognize and mount them. This could have resulted in a large loss of customer data and transactions and a huge financial and customer service disaster for the bank. After an hour and a half of downtime, the team realized that the problem was not going to be solved quickly and decided to let Vision Suite perform a roll swap to the second system including the rerouting of all customers, users and applications.

"It was incredible," said Whyte. "We didn't lose a single transaction which of course caused a great sigh of relief throughout the IT team and among bank executives. Once we allowed Vision to take over and switch all users and customer access, we were able to make a well-planned recovery. Based on this real-life recovery instance as well as planned events, we couldn't have more confidence in Vision. From our perspective, it is impossible to run a bank and its applications without Vision Suite. We sleep better at night knowing that Vision Suite protects our business and secures the corporate data assets."

To learn more visit:
www.visionsolutions.com