Free! Registration is required.
Our great System i has long been considered a security strongbox—a hacker's worst nightmare. Some even consider it to be unhackable. This perception has caused some of us to become complacent in our due diligence related to system security. But security through perceived obscurity is insufficient protection in a world of wily cyber criminals and malicious insiders.
According to the Open Security Foundation and the Privacy Rights Clearinghouse, since 2005 more than 234 million people have had their personal information hacked, stolen, lost, or misplaced. Hundreds of computer-related data thefts occur every year—often one or more per day. To view those of public record, you can visit the Data Loss Database at datalossdb.org. According to the Data Loss Database's published list, some of those thefts are occurring at System i shops both large and small.
Securing the System i is made especially difficult by tools that access data but leave no footprints. How can you 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: When you go out in the morning to start your car, it isn't where you left it. But how can you know whether someone has stolen a sensitive System i database file? The file is still there and there are no traces of illegitimate activity, but that doesn't prove that the file hasn't been breached or stolen.
IBM ships the System 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 on the built-in IBM-supplied IBM i tools that access data invisibly.
If I download a database file using FTP or the System i Access file transfer facility, there's no built-in audit trail of the activity. There's no FTP log for the FTP server and no logging or history of System i Access file transfers. These file transfers are invisible, even to the systems administrator. If I use one of these tools to download an employee personnel file, the payroll file, the 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 the ODBC, Distributed Data Management (DDM), and other data access servers shipped as part of IBM i? All data movement using these servers is invisible.
Let me ask you this: Have any of your sensitive database files been stolen today? For most of us, the honest answer is "I don't know." That's right—how could you possibly know?
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 should ask that question of companies that have had their data compromised. For example, ChoicePoint Asset Company, LLC, is reported to have spent more than $50 million on fines, legal fees and settlements, consumer notification, and other expenses related to the theft of about 163,000 consumer records. And that doesn't include revenue lost to diminished company goodwill or money spent on PR campaigns deployed in an attempt to mitigate the damage. ChoicePoint wasn't the first breach or the biggest so far, but it was the one that made most of us realize that there is a market for our personal information.
Perhaps one of the largest breaches was at The TJX Companies, Inc. (TJX), where a ring of international hackers broke into the network and hijacked about 45.7 million customer credit card and debit card account numbers. TJX expects its cost to approach $118 million.
Another consequence of your company appearing on the data breach hit parade is that you might very well be looking for other employment—and with a data breach on your record.
Is Your System i Secure?
As I reviewed the data breaches listed on the Data Loss Database and by other sources, it became abundantly clear that although some of the largest breaches are due to professional cyber criminals, most are initiated by company employees and contractors. The US Department of Justice estimates that well over 80 percent of computer crimes are carried out by insiders.
I go to System i sites to teach technical classes and perform IBM i vulnerability assessments. Almost everywhere, I find a shocking indifference to system and data security. During an RPG 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.
At a paid security class open to the public, I used payroll data as an example of data that must be secured from prying eyes. Two young men at the back of the room exchanged glances. When I asked for questions, one of them piped up and said, "How are we supposed to know what to ask for on our next review if we don't know what other people are making?" I was amazed, and almost speechless. These gentlemen were a company's top System i security staffers, and they didn't know that prying into payroll records constituted a security breach.
My employer, a well-known System i security software and services company, publishes an annual report on the state of System i security. The report is based on information gleaned from about 200 companies, and the results are almost exactly the same from year to year: The System i is generally not very well secured. Even with the great IBM-supplied security capabilities at our disposal, we don't pay nearly enough attention to security. (You can view the study at powertech.com/powertech/PowerTech_Web_Study.asp.)
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 System i shops. It's not unusual to have a user who, from prior employment, knows applications by J.D. Edwards, Infinium/S2K, JDA Software, or Lawson 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 System i Access file transfer. Many power users, such as data analysts and sales and marketing folks, are familiar with file names and libraries. In most business schools, students are taught tools such as Microsoft Excel and Microsoft Access and learn how to use ODBC to directly access data from those and other PC applications.
And let's not ignore the technical staff. Programmers and operations, help desk, and tech support people know how to use FTP, ODBC, and System i Access file transfers, and they know the names of your sensitive files.
How many salespeople leave your company 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, and vendor cost files. 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.
You can't rely on the ignorance of your employees and contractors to secure your sensitive data. They are likely not as ignorant as you think.
Object-Level Security Will Protect Me
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 IBM i 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 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 System i Access 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 System i Access file transfer.
So What's the Answer?
This disparity in the access requirements for Telnet green-screen access and network access using tools such as ODBC has spawned several third-party security software products. These products make available exit programs that provide a custom level of object access control and audit invisible access attempts by tools such as ODBC and FTP.
More than 30 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 the rate at which IBM updates them, most organizations use one of several third-party products.
When a user attempts to use FTP to download a file, the 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 logged for your inspection, and if configured to do so, the exit program sends an intrusion message to a pager, cell phone, or email address.
All the IBM-supplied network servers work in a similar fashion. When an access request is detected, the exit program is called. The exit program records the request and decides whether the access should be allowed or denied.
Detecting the Undetectable
I've often heard 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 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 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 exit programs. The two work hand-in-hand to secure your system and give you the visibility and control you need.
Dan Riehl is a System iNEWS technical editor.