When we discuss the security and protection of sensitive data like credit card numbers, Bank Account Numbers and Social security Numbers we tend to focus solely on our storage of this information in our DB2 database. We perhaps use field level encryption, and set the library and file level security to allow only sanctioned users to view or change this data as it is stored in our production files. But, the database field is NOT the only place where this sensitive information can be compromised.

Here's a short list of other places where sensitive data might be compromised. I'm sure you can add some instances to my list.

Test versions of Files - Yes, we all have versions of the production files in our test, development and QA environment libraries. Unless we are using scrubber software for creating these "Test" versions, all sensitive data is available to anyone with access to these files, and copies of these files. Very few of us use any such scrubber tools.

Test data must be sanitized to make sure that all sensitive fields are changed to hide the actual sensitive data. There are a few commercial data scrubbers available specifically for the System i DB2 database.

Backup Files – Often backup files are created using command like CPYF CRTDUPOBJ CPYLIB. These versions, if created, must be protected as diligently as the production data it was copied from.

In most commercial High Availability solutions, we typically have an exact duplicate of production files on our backup system. But, often we have less strict controls over user access to the backup system. The data on your backup system must be as well protected as on the production system.

Backup Media – Our backup tapes and save files contain all production data. If a backup tape can be restored on to a different system, all files may be compromised. A save file containing production data may be moved to a different system using FTP or any file transfer facility. We must control the ability to save objects to save files, and to transfer data between systems. We also need to exercise strict control over our backup media.

Reports in Output queues – Printed reports often contain sensitive data. While we strive to protect the database, we often overlook the exposure of listing that same sensitive data within spooled file reports. The sensitive data is exposed to users that can view spooled file reports.

Just recently, I was working with a customer to secure their sensitive data, and we found it was painfully easy for users to view the payroll register reports while these reports were sitting on an unprotected output queue. The Name, Social Security Number, Pay Amount, Deductions, etc were listed in plain sight for any user to view.

IFS spreadsheets, PDF and text files – We often store spreadsheets and PFD reports in the Integrated File System. Don't forget to secure the sensitive data that resides there.

Data in transit, FTP, File Transfer, DRDA, DDM, ODBC, etc - Users who are authorized to their application data, and powerful IT users can usually transfer files using tools like FTP and File transfer. These types of transfers must be controlled, or at least audited and reported. Network Exit Point programs are required in order to have visibility to these file transfer events.