The Threat - Invisible Data Theft on IBM i

By Dan Riehl

How many times has your most sensitive data file been downloaded today?
For most of us, the honest answer is "I Don't Know."
That's Exactly Right! How could you possibly know?

Our great IBM i (iSeries and AS/400) has long been considered a security strongbox—a hacker's worst nightmare. Some even consider it to be unhackable. This gross misconception has caused some of us to become complacent in our due diligence related to the security and integrity of our systems and sensitive data. But IBM i security cannot rely upon it's perceived obscurity as sufficient protection in a world of potentially malicious insiders and highly trained and well-financed cyber criminals.

According to the Open Security Foundation Data Loss Database, since 2013, almost a billion people have had their personal or credit card information hacked, stolen, lost, or misplaced. Hundreds of high profile computer-related data thefts occur every year; often numerous occurrences per day. To view those of public record, you can visit the OSF's Data Loss Database. According to their Data Loss Database's published list of compromised companies, we can tell that some of these major incidents are occurring at IBM i shops, both large and small.

Securing the data on the IBM i is made especially difficult by our ubiquitous tools(e.g. FTP, ODBC, DDM) that access our data but leave no footprints. How can you reasonably expect to protect the sensitive information in your care when it can be accessed without your knowledge?

Invisible Data Access Methods

When a thief steals your car, you know it. But how can you know when someone has stolen a sensitive database file? The file is still there and there are no traces of any access to the file. But, that doesn't prove that the file hasn't been breached or stolen.

IBM ships the IBM i with a variety of data access tools, many of which access data invisibly. We often add third-party data query tools, and we even write our own data access methods using socket programs and the database APIs. Although non-IBM data access tools might reside on your systems, I want to focus this article on the built-in IBM-supplied tools that access data, and do not leave a trace of the activity.

If I download a database file using FTP or the IBM i Access for Windows file transfer facility, there's no built-in audit trail of that activity. There is no FTP log for the FTP server and no logging or history of IBM i Access for Windows file transfers. These file transfers are invisible, even to the system administrator. If I use one of these common tools to download an employee personnel file, a payroll file, a customer file, or any other file to my PC, you can't know it. Neither the IBM FTP server nor the IBM-supplied file transfer facility makes or keeps a record of that activity.

What about using ODBC applications, Distributed Data Management (DDM), and other data access methods shipped as part of IBM i? All data movement using these services is invisible.

(Caveat: Database Journaling can be used to produce an audit trail of add, change and delete record level activity. But, if the data is accessed for "read-only" in order to steal the file(e.g. FTP or ODBC download of a file), there is no record level activity recorded, and absolutely no footprints to follow.)

What's the Worst That Can Happen?

Suppose my files are stolen by an insider or a hacker. Why do I care? What's the worst thing that could happen?

You could ask Target Corp, Adobe Systems, TJX Companies, Heartland Payment Systems, ChoicePoint and the list goes on and on. Data Security Breaches cost each of these companies tens of millions of dollars in added expense, not to mention the diminished company goodwill and customer relations nightmares. Target Corp alone says they will need to spend over 100 million dollars to modernize their credit card systems.

Another consequence of your company appearing at the top of the Data Breach Hit Parade is that you might very well be looking for alternate employment.

Is Your System Secure?

As I reviewed the data breaches listed on the OSF Data Loss Database and other sources, it became abundantly clear that although some of the largest breaches are perpetrated by professional cyber criminals, many are initiated by company insiders; employees and contractors. The OSF sights over 30% of all incidents in 2013 were from the inside.

I often visit IBM i customer sites to teach technical classes and perform IBM i security vulnerability assessments. In many of these places, I find a shocking indifference to system and data security. While teaching an RPG programming class at a regional bank, class members didn't hesitate to volunteer that none of the bank's data was encrypted. Account numbers, Social Security and driver's license numbers, and even ATM PIN codes were stored as clear text in customer account files.

In another example, I was teaching an IBM i Security Workshop which was open to the public. During the workshop I referred to Payroll data as an example of data that must be secured from prying eyes. Two young men at the back of the classroom exchanged quizzical glances. When I asked if there was a question, one of them piped up and asked, "How are we supposed to know what to ask for on our next review if we don't know what the other people are making?" I was floored. These fellows were their company's top IBM i security staffers, and they felt it was just fine to pry into employee payroll data.

Security Through User Ignorance

If your users don't know how to use FTP and file transfer and don't understand ODBC and DDM, you might reason that their ignorance protects you. Further, you might believe that outside hackers don't care about your data. Let's examine these rationales.

Most of us have employees who came from other IBM i shops. It's not unusual to have a user who, from prior employment, knows applications by J.D. Edwards, Infor/Infinium/S2K/Lawson Software, BPCS, MAPICS or JDA Software. At their previous job, those employees might have learned the names of files and libraries for use with query tools or file upload and download tools. They might have routinely used FTP or IBM i Access for Windows file transfer. Many power users, such as data analysts and sales and marketing folks, are familiar with file names and libraries. In schools today, students are taught tools such as Microsoft Excel and Microsoft Access and learn how to use ODBC to directly access data.

And let's not ignore the technical staff. Programmers and operators, Help Desk, and Technical support people know how to use FTP, ODBC, and file transfers, and they know the names of the sensitive files.

How many salespeople leave your company to go to work for a competitor? How difficult would it be for them to tuck a USB drive loaded with customer information and sales activity reports into their pocket as they leave? While they're at it, they might get the pricing files, too. Or instead of a USB drive, maybe they just download the files and email them to a buddy who works for the competitor.

If you work in the healthcare industry, what would happen if your patients' personal health information were stolen and published on the Internet? Company financial data such as a retailer's comparative store sales can drive a stock up or down. Stealing such information and making it public before the company formally reports its earnings can be hugely profitable. But, thankfully, it is also illegal.

You cannot rely on the technical ignorance of your employees and contractors to secure your sensitive data. They are likely not as ignorant as you might suspect.

I am not trying to impugn our fellow workers. But, under certain circumstances, I have seen even the most trusted employee succumb to the allure of a big pay day through stolen or manipulated data.

Object-Level Security Will Protect Me - Really?

IBM and industry pundits have long embraced the concept of object-level security, which stipulates that every user be granted access only to the files, programs, and other objects necessary to perform his or her job and receives only the minimum permissions needed to each object. An accountant, for example, would have the authority to read only certain accounting files and to update only the files necessary to accomplish his or her work. The accountant would be unable to access any file or object that doesn't directly relate to the job and couldn't run any program that was outside the scope of his or her responsibility.

Many consider properly implemented object-level security to be the highest achievable level of security. If you believe some of the pundits, properly configured object-level security is all that's required to secure your system. However, the object-level authorities that are in place for Telnet access via the green screen are also in place when tools such as FTP, ODBC, and file transfer are used. If a user has the object-level authority to update a file, that user can also update the file by using ODBC and download the file by using FTP or file transfer.

Note:

So What's the Answer?

This disparity in the access requirements for Telnet green-screen access and network access using tools such as FTP and ODBC has spawned several third-party security software products. These products provide network server Exit Programs that typically provide a custom level of object access control and also provide the sorely needed audit trail of the otherwise invisible access attempts by tools such as ODBC and FTP.

More than two dozen IBM-supplied network servers in the IBM i provide Exit Points that let you specify an Exit Program to be called on every data- and service-access request. You can write your own Exit Programs, but due to the complexity of network Exit Points and ongoing maintenance requirements, most organizations use one of several third-party products.

The typical activity of a 3rd party commercial Exit Program to log and control FTP transfers is as follows.

When a user attempts to use FTP to download a file, the supplied FTP Exit Program intercepts the download request, records the activity in a secure log, and checks the request against your set of FTP rules to determine whether the download is permitted. If it is, the data transfer is allowed to proceed. But if the Exit Program's rules determine that the file transfer is not allowed, the file is not transferred and the user receives a message that the file transfer has been rejected. All FTP server activity is typically logged for your inspection, and if configured to do so, the Exit Program may also be able to send an intrusion alert message to a message queue, cell phone, email address or SIEM Event Log.

All the network server Exit Programs work in a similar fashion. When an access request is detected, the Exit Program is called. The Exit Program can record the request and decide whether the access should be allowed or denied.

Detecting the Undetectable

I've heard some people say that as long as you have strong object-level security, you don't need network Exit Point programs. But, the only way to detect the activity of FTP, ODBC, file transfer, and the other network servers is by having an Exit Program for each server that logs the request. Without network Exit Programs, how do you get visibility of your network traffic and detect file transfers of your most sensitive data? And when a user has *USE or *CHANGE authority to all their files, how do you permit the user to download some files and not others?

Yes, you need a good security scheme. But you also need network Exit Programs. The two work hand-in-hand to secure your system and give you the visibility and control you need.

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn