11 Dec Quality control can check software manipulation
Small and medium-sized companies know how difficult it is to prevent computer programmers from having “write” access in production environments. Persons that write the programs often are the same people who support the systems in production.
Are there ways to allow your programmers into production while still providing some assurance that they are not accidentally jeopardizing or intentionally manipulating the software? Yes! Using Checksum software is one approach to provide this control.
What is Checksum? It is a value-generated software that uses a hashing algorithm after analyzing the contents of a file. Simplified, checksum software calculates a unique “fingerprint” value based on the exact contents of the file at that exact point in time.
Here is a real life example. I took a spreadsheet that contains financial information that would be approximately 20 pages if printed. I generated a Checksum before and after changing a single number in this file. The results are shown below:
1. Checksum before changing one number: 25E3C720
2. Checksum after changing one number: 122EFA33
As you can see, the checksum value is radically different even though I only changed one cell in this rather large spreadsheet. The software I used was wxChecksums, but there are many products available for free or at low cost.
Since the Checksum’s swing is so wildly based on file content changes, it can be used to determine whether a given file has changed. From a Sarbanes-Oxley perspective, we can get a very high degree of certainty whether a program in production is the same one that was tested before installation. And we can discover if a program was accidentally or intentionally changed without following the correct change process.
Here are ideas on how to use Checksum software for Sarbanes-Oxley controls work:
• To ensure that the correct program was installed into production: At the start of testing, calculate the Checksum for all the files that are to be installed and write the value onto the change request form. After the programs are actually installed into production, as a last step in your change-control process, calculate the Checksums again. The Checksums should match and if they do then you can be very confident that the correct software, as tested and approved, was actually installed. If there were any changes, additions, or deletions along the way, then the values would be different.
• To determine if changes were installed without permission: Periodically calculate the checksum of the programs in production folders. The value should be the same written on the last change request form. If any objects were modified, then it will be readily obvious.
• Controlling spreadsheets: Because spreadsheets contain data and business logic, this technique will be more difficult to implement. However, for a critical accrual or other spreadsheet information, capture the checksum right after closing the books. Then, at the start of the next close cycle, verify that the Checksum for that spreadsheet file is the same. Any alterations to either formula or data will be evident.
• Validating a file received via e-mail: When sending a data file through e-mail, if your company allows this, calculate the checksum and notify the recipient by some means other than e-mail of the Checksum value. When the person gets the file, they can make sure that the file is unchanged along the journey.
If you find yourself in a situation where you don’t have enough people to keep programmers out of production, then checksums may be a technique you can use to work around this limitation. It allows your programmers to provide support for live applications and also to provide assurance to management that they are not altering programs without permission.
• Jerry Norton: Why IT change management is more important than ever
• Denis Collins: Enron’s dilemma: A corporate governance nightmare
• Jerry Norton: Auditors paying more attention to IT woes
• Directors more assertive in corporate governance
• Online service makes board connections
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC. WTN, LLC accepts no legal liability or responsibility for any claims made or opinions expressed herein.