IBM i file editors such as the i Data File Utility (DFU), the Start SQL (STRSQL) command, and third-party i file editors—allow shops to quickly and easily make critical file changes without writing code. While file editors allow you to quickly correct bad data, they can also be used by malicious or careless users to corrupt production data.
Worse, many IBM i file editors don’t provide audit trails, so you may have no idea who changed your data, why they did it, or what they did. Carelessly used, file editors can wreck balance sheets, violate system controls, destroy data, and commit fraud. Auditors hate uncontrolled IBM i file editors, for good reason.
The safest way to change critical production data is to use pre-authorized, pre-confirmed programs that have been vetted to your business strategy (a safe update). The most dangerous way to change critical production data is to use an IBM i file editor or another unauthorized program (a dangerous update).
Here’s what you need to know to implement safe updates using authorized programs on an IBM i system. To do that, you must know the difference between a dangerous and a safe update, how to make exceptions for using unauthorized programs when necessary, and how third-party file editor security products protect your organization from unauthorized updates.
Authorized versus unauthorized critical production data updates
Authorized or safe critical data updates are made by authorized users using pre-approved, authorized programs that are specifically vetted for your business strategy. A corporate financial system, for example, only allows an authorized accounts payable (AP) program to approve direct deposit payments. The AP system was specifically written to and approved for your business requirements.
Unauthorized or unsafe critical data updates are made by using programs that have not been specifically vetted for your business strategy. Instead of using your vetted AP program, for example, a programmer or manager with all object authority (*ALLOBJ) may authorize direct deposits using an IBM i file editing package, such as DFU or STRSQL. They may also write and run programs that haven’t been approved or vetted for your system. Unsafe updates occur outside your vetted programming. There is no audit trail. Unsafe updates don’t support your business strategy, and they may be fraudulent or destructive to your database.
Goals for safe critical data updates
Safe critical data updates support the following goals. Unsafe critical data updates undermine these goals and may even enable criminal activity.
- Safe updates ensure file integrity—They keep your data accurate and safe, using pre-approved code in properly vetted programs. Unsafe updates change data randomly, using programs such as DFU or STRSQL that are not easily traceable in your system.
- Safe updates prevent fraud—They keep users from manipulating data to their own ends. Data is always processed according to business rules. Where users can only make safe updates, unauthorized uses can’t change data outside of your vetted, pre-approved parameters.
- Safe updates ensure audit compliance—They follow change control policies. Unsafe data updates bypass change control policies. Safe updates prevent developers and others from sneaking in file updates as a shortcut, instead of writing pre-approved programs to enter data the correct way.
- Safe updates enforce documented workflows—They follow documented business workflows, providing audit trails; unsafe updates eliminate documented workflows and audit trails.
The exception to the safe update requirement
While it’s best to use safe vetted programs for critical production file changes, there is one scenario where critical data can be changed by an unvetted program: Emergencies where immediate data changes must be made that can’t be made using your authorized programs.
Organizations sometimes need to quickly correct bad data that occurred because of an application bug or another issue, such as when a program error charges customers 100 times their actual costs. In an emergency situation, management, database administrators, or programmers may be authorized to use an unauthorized program, such as DFU or STRSQL, to immediately adjust data. During an emergency, there may be no other choice than to use an unauthorized program to correct your data.
Auditing requirements can permit emergency changes, provided they follow a pre-approved procedure that specifies how emergency unauthorized changes are handled. The procedure should cover how the change was approved, which personnel were authorized to make the change, what program was used to make the change, and how the change authority was revoked after the change was made. You would also need to document and correct the issue that created the emergency.
Tools to perform authorized and emergency data updates
To prevent unauthorized updates, you can set up a do-it-yourself (DIY) program or you can purchase a third-party IBM i file editor security program, such as SEA’s iSecurity Safe Update. While most IBM i shops control data security through menu access, groups, or native IBM i security, file editor security programs add an additional security layer to your system that that can prevent and stop unauthorized critical file changes, even when the offending user has *ALLOBJ authority. File editor security programs enforce data update security in the following ways.
- By creating application whitelists that specify which programs and users are authorized to update production files. Whitelists ensure that only authorized programs and users can update your critical data.
- By creating application blacklists that specify which programs and users are not authorized to update production files. A blacklisted file editing program, such as DFU or STRSQL, cannot update critical data when iSecurity Safe Update is monitoring your critical files. Users won’t be able to update critical production files using a generic file editor.
- By using a work order ticketing system for emergency situations where updates must be made by unauthorized programs. For iSecurity Safe Update, a work order is created for an emergency update that includes the reason for creating the work order, the user who can perform the critical update, what file(s) will be updated, and the timeframe the approval remains active before expiration. Safe Update issues a temporary authorization, and logs the activity as the user makes the update. So even if you’re using STRSQL to perform a mass update to your Accounts Payable file, iSecurity Safe Update creates a full trace of updates, even if the file is not journaled.
An IBM i file editor security program protects your data while provides a framework for approving and auditing emergency changes when needed. Keeping your data safe and within processing parameters, even when things are going wrong.
Please contact SEA Software for more information on locking down critical data updates using an IBM i file editor security program like iSecurity Safe Update.
