Yes, it really does happen. Sometimes I think we forget that people really DO steal data. It is our responsibility as system administrators and security officers to keep our data safe and secure. Whether it is Personnel and Payroll data, Customer data, Pricing information or "private" health information, we are ultimately responsible.

One afternoon, a while back, I received a rather frantic phone call from the IT security administrator from a large US company. He explained that he suspected that an IT staff member had stolen some very sensitive data files and he wanted me to find the footprints to lead back to that person. He expected the theft was performed using an FTP file transfer, but was not really sure. He did not share any information on how he knew the theft had occurred, but did supply the names of the sensitive files that were allegedly stolen.

Note: To ensure privacy and anonymity, many of the details of this story are omitted or modified from this otherwise factual account. After all, nobody really wants to show off their dirty laundry. But, even with my modifications, the story offers some great food for thought.

As I began my analysis, I checked the sensitive files to determine if access to the files was being audited by the system using the QAUDJRN journal and using the CHGOBJAUD(Change Object Auditing) command. Sadly, the files were not being audited. I then checked to see if the files were being journaled, using database journaling (STRJRNPF). Again sadly, they were not being journaled. These two things told me that I did not have any system level record of who had opened the files, and when. But I remained undeterred.

The company had long ago purchased network exit point software from one of the leading commercial security vendors. Using this software, a record was kept of each network access using the IBM supplied servers like FTP, ODBC, File Transfer, DDM, etc. I felt like I would surely be able to find the "smoking gun", but then, the surprise. The IT staffer in question, did not even have a user account on the production system. This user only had an account on the Test and Development System i systems. And those systems did not have the network exit point software installed. But they did have numerous copies of the sensitive production data files that had been allegedly stolen.

I ran the vendor reports for file transfers and accesses to the sensitive files on the production system, just to determine if anyone had downloaded them. Two of the files had been accessed using ODBC SELECT statements, but those accesses were from authorized application End users that were running a canned script from their MS/Windows PC. There were no file transfers using FTP or File transfer for these files, and no access using DDM or DRDA.

Since there was no file level auditing, and no network exit point software on the Test and Development systems, it was impossible to tell who may have accessed or downloaded the sensitive files on those systems. BEANS! There will be no "smoking gun" found from the System i side in this investigation.

Lessons Learned

Since we routinely copy our production data files to our Test and Development systems, we need to enforce some security over those copies of our data as well as the copy that lives in Production. When we implement network exit point software on the Production box, we need to also implement that software on our other boxes that contain the exact copies of our production data files.

Recommendations before the next time

There are two possible solutions to our problem that quickly come to mind. The first one, and the best option, is to utilize some kind of data masking software, or test data generator to create modified versions of our production data sets that can safely be used in our test and development environments. In this way, our REAL production data lives only on the Production machine, and only has to be protected in one place.

The second option is to install and activate network exit point software on all of the systems that hold your sensitive production data files. In this case, if network exit point software had been running, I could have reviewed every file transfer on the development and test systems going back a year or better. But without this software in place, it is impossible to track this kind of data theft from the System i side.

You can write your own network exit point programs, but, for a number of reasons I recommend buying a commercial network exit point solution. When selecting a network exit point commercial package, make sure it has the ability to monitor/control and record the transactions of all of the IBM documented communication exit points that can be used to transfer data off your system. That includes the well known services like FTP, file transfer and ODBC, but also includes support for data access and transfers done using DDM and DRDA. These exit points are missing, or not implemented correctly in some popular commercial packages.

A little over a year ago I wrote an article for System iNEWS magazine that discussed this topic. Invisible IBM i Data Access: Preventing Undetectable Data Theft

I encourage you to review that article. Had the IT Administrator at this company read the article, and followed the advice, he might have installed exit point software on all his systems, and I might have been able to find the "smoking gun" on this alleged data theft.