Vol. 10, December 10, 2007
Auditing Version Controls for Installed Applications
Version controls are an important aspect of an application's change management process. Knowing the different issues associated with application-version controls will enable internal auditors to provide recommendations that help IT departments mitigate security and operational risks.
Ike Ugochuku, CIA, CISA
IT Audit Consultant, TLK Enterprise
An important aspect of change management is to identify that any changes to applications — whether these applications are built in-house or purchased from a vendor — are documented and tracked properly. This is important because the use of effective application-version controls can help IT departments mitigate security risks, such as those posed by hackers, viruses, and unauthorized changes.
Besides leading to stolen information and corrupted data, a substandard application version-control process can create system failures and the disruption of business operations. Internal auditors play a crucial role by reviewing the application-version control process and by evaluating if security and operation risks are mitigated properly. As a result, auditors need to learn about the different audit issues associated with application-version controls and help organizations determine whether application changes follow established change management procedures.
CHANGE MANAGEMENT CONSIDERATIONS FOR VENDOR APPLICATIONS
Commercial products are designed to address the needs of a specific audience or business function and target a particular technology environment. These products usually are compiled into one package and consist of a standard version that is released for public use. The change control process for commercial applications often involves making changes to software files as the need arises. Below is a description of the main application-control issues internal auditors need to keep in mind during audits of third-party software.
Issues to Keep in Mind
Problems with commercial applications may occur when a change is made to the software's configuration by the organization's IT support staff. As a general rule, auditors should recommend that IT departments refrain from making changes to compiled files — such as those ending in DLL or EXE — without the vendor's knowledge, because doing so could violate any support agreements in place. Changes made to critical vendor files should be part of an automated patch that can be applied to the released software version currently installed in the organization's production system. Changes made to text readable files, such as configuration files, should be added to the application's installation document, which defines the hardware specifications and steps necessary for installing and configuring the software to work in the organization's IT network.
Together, the patch, software, and installation document form a working copy of the application that is part of the organization's production environment. All elements of the working copy should be documented in the application's or IT department's disaster recovery plan (DRP) and stored properly in the software repository — the designated location where all software used by the organization is stored. The DRP should include information about all application patches, changes to configuration files, and the current version in use. (Refer to Figure 1 for an example of the change management process for commercial products.)
Figure 1. Change management process for commercial products
Oftentimes vendors release application updates to fix a security issue or add new features that enhance the functionality of the previous version. This update may result in changes to the application's version number. If an organization decides to upgrade the current application, it is important for the IT department to follow the organization's change management process to minimize any unwanted effects stemming from the change that may disrupt company operations. For instance, a change management process can mandate that new software versions be tested and released to the organization's production system only after the testing phase is completed. In addition, the new version may result in the elimination of currently used patches because these are probably incorporated as part of the new version. As a result, company policy may require for the installation document to be updated immediately after application changes take place.
Audit Considerations for Commercial Products
When reviewing a commercial application, internal auditors should contact the vendor to find out the current version number. Auditors also should compare this number with the local version installed to determine if there are any discrepancies between the two. If a discrepancy is found, the auditor should work with the system administrator to obtain more information about these changes. For instance, the auditor might find that the updated released version is not certified for use (i.e., the version has not been tested by the IT department and evaluated to ensure it works properly in the production environment). This is important because not all software updates may be relevant to the organization's needs. If the latest released version is not certified, the system administrator should explain why, especially if the third-party vendor is no longer supporting the version installed in the production environment.
In addition, the auditor should verify that a workable copy exists in the organization's software repository. The word workable refers to a functioning software version that is installed on a specific hardware or software platform. During audits of workable copies, auditors need to verify the repository copy was used during the installation. One way to do this is by reviewing the application's latest installation report. If a copy other than the repository copy is installed, the repository copy may become obsolete and inoperable in the production environment over time.The auditor also should check if any problems occurred during the installation and when the most recent installation took place. Answering these questions will help auditors determine whether the repository copy is being updated according to the organization's change management policies and procedures.
CHANGE MANAGEMENT CONSIDERATIONS FOR IN-HOUSE APPLICATIONS
Unlike commercial software, organizations may own the source code for all in-house programs. In-house applications are built by an internal software developer or a hired contractor. These applications are designed to meet specific business objectives and may consist of small independent modules working together. Below is a description of the main application-control issues and considerations for internal auditors.
Issues to Keep in Mind
Right after the project's completion, the organization should have a workable final version of the software. If the application consists of small modules, these should be compiled or released as one package. The IT department also should establish a central location to store the application's source code, such as the organization's electronic library or a designated shared file that is backed up regularly. Storing the source code in a secured location will help to prevent unauthorized changes that may affect the application's functionality and efficiency.
Changes to in-house applications can be scheduled ahead of time or made without prior notice due to an emergency or system failure. For scheduled changes, the application's implementation group should test all changes before the updated application is uploaded for use. Developers also should place the new release code in the organization's software repository to safeguard it.
Emergency changes usually consist of unplanned, quick, or untested updates to application files. It is important that emergency changes are reflected in the installation document after the change is completed. Because these updates can be applied to any application version and not just a particular copy on a server, the repository copy should be updated after the change is completed to ensure it is the most current updated version. Due to the time sensitivity of the situation, all emergency changes should be tested after they are made. (Refer to Figure 2 for an illustration of the change management process for in-house applications.)
Audit Considerations for In-house Applications
For the application control change process to be effective, internal auditors need to review scheduled and emergency changes to determine if they followed the application's change management policies and procedures. The auditor can do this by taking a sample of all scheduled and emergency changes. The organization's change management policies and procedures need to explain the review and approval process. For instance, all planned changes should involve application users during the testing stage, while emergency changes should be tested in a laboratory by the IT support staff before implementation. The auditor also should look at the time the changes were made to make sure the change was made within the approved change request time window.
Figure 2: Change management process for in-house developed applications.
When reviewing planned changes, auditors should verify that the repository copy is updated. If changes were made to a configuration file, the auditor should determine whether the installation document was updated to reflect the file change. To do so, the auditor could take a sample of all planned changes made during the audit report period and confirm whether the appropriate documents and files were updated.
In the case of emergency changes involving a code fix, IT support staff may have to call the program's developer or hired contractor. Auditors should check that the installation document and repository copy are updated by taking a sample of all emergency changes made and making sure these changes are reflected in the repository copy — for DLL and EXE files — or the installation document — for editable files, such as configuration files. If the emergency change didn't involve a code fix, the auditor should still verify that any application changes are reflected in the installation document.
OTHER AUDIT CONSIDERATIONS
Besides the audit considerations explained above, internal auditors need to examine how file changes are being monitored in both vendor and in-house applications to ensure that the production file and repository copy are similar. This enables the organization to identify any unauthorized file changes and remedy the situation. When examining file changes, auditors need to identify if a process is in place that allows the production file version to be compared to the repository file version. This control will help monitor changes to critical application files and ensure that the repository and production copies are similar. Configuration management applications are available that can be configured to do this task. Another alternative is to write a script to perform this comparison.
File attributes such as time and dates should be compared. To check file attributes, internal auditors need to work with the IT security team to review the organization's comparison report — also known as the security report or version review report — generated by the version management software purchased by the organization or the command script created in-house to manage software versions. This comparison report shows which file version is currently in the repository and which file version is in production. How often the comparison review takes place depends on the risk rating of the application. (For more information on the application's risk rating, security staff should consult the organization's enterprise risk report.) Version control management software also can be configured to alert application owners when an important file has been changed.
In addition, internal auditors should examine the process of data collection to identify:
- How often data is collected. This frequency should correlate reasonably with the risk rating of the application.
- Who determines which critical files are being monitored. The vendor or developer's documentation should be consulted to answer this question.
- How often are review or security officers alerted about changes. This frequency should correlate with the risk rating of the application.
Furthermore, auditors should examine the review process by taking a sample of all changes and identifying whether they match problem support tickets or scheduled planned changes. Audit results can then be compared with the organization's review process to determine if they arrive at the same conclusions as the review team, as well as identify who is conducting the review process to ensure there is a proper segregation of duties. The review process should be done by a group of people independent from the application support group and shouldn't include anyone involved in the change management process.
Finally, auditors should verify that version management controls are working properly. To do so, the auditor could take the current production copy and compare the identified critical files with the repository copy. The auditor can then compare the audit report with the comparison report to confirm if there are any differences between the two. Finally, the auditor should verify that any changes to text files are reflected in the installation document by surveying a sample of the application's configuration or text files. If changes are identified that are not in the text of the installation document, the auditor should ask the system administrator why the changes were omitted.
Managing IT changes effectively is vital for organizations to function properly. Otherwise, a poorly supervised change management process can cause serious damage to the entire IT infrastructure. Version control is an important aspect of an application's change management process because it helps IT departments mitigate security and operational problem areas. When an IT department looses track of changes made to an application over time, the organization can experience a serious security risk.
For additional information on how to audit an organization's change management process, auditors should read The Institute of Internal Auditor's (The IIA's) Global Technology Audit Guide, Change and Patch Management Controls: Critical for Organizational Success, available on The IIA's Web site, www.theiia.org/index.cfm?doc_id=5167. In addition, auditors might want to refer to the following IIA Practice Advisories also available on the IIA Web site, www.theiia.org/index.cfm?doc_id=4298, which discuss various aspects of effective controls:
- 2120.A1-1: Assessing and Reporting on Control Processes.
- 2330.A1-1: Control of Engagement Records.
- 2100-11: Effect of Pervasive IS Controls.
- 2100-13: Effect of Third Parties on an Organization's IT Controls.
- 2120.A1-2: Using Control Self-assessment for Assessing the Adequacy of Control Processes.
- 2120.A4-1: Control Criteria.
Ike Ugochuku is president of TLK Enterprise, a professional services organization focused on technology risk analysis and audit. For the last four years, Ugochuku has been involved in technology risk audits and advising business units on effective policies and procedures to mitigate IT risks.
Should reviews of application-version controls become a routine aspect of internal audits of the organization's change management process?
To discuss this question, visit the ITAudit Discussion Board, www.theiia.org/go?to= ITAudit_Discussion.
Once you register, click on the "ITAudit Article Discussion" folder.
All contents of this Web site, except where expressly stated, are the copyrighted property of The Institute of Internal Auditors Inc.