Key Points to Keep in Mind When Conducting a Software Audit

November 2007

Learning about the problems associated with software audit tools, as well as determining who will perform the audit, will enable organizations to better identify their software holdings and minimize their risks.

John Silltow
Managing Director
Security Control and Audit Ltd.

Many IT auditors will be faced with the task of conducting a software audit at some point in their careers. The purpose of these audits is often simple: Determine whether the software installed on company-owned computers was obtained legally and was authorized for use by the appropriate staff. Sometimes software audits are conducted for legal reasons (e.g., to verify that there are sufficient licenses to cover software use, as in a software copyright audit) or to make sure staff are using the same software versions or there are no surplus licenses.

Regardless of why a software audit review takes place, once it is completed, the audit needs to provide information that can help senior managers understand the purpose of the software and its value to the organization, the risks posed by the software program, and, particularly, whether it is necessary to have or use that software. Gathering this information is usually played down by vendors of software tools as something that the software audit program will do for the organization, but, in reality, it is probably the hardest and most time-consuming part of the entire software management process. Therefore, learning about the problems associated with software audit tools will help internal auditors and IT departments choose the audit tool or service that best captures information regarding the organization's software holdings.

SOFTWARE AUDITS — A BIRD'S EYE VIEW

There are different kinds of software audits. For instance, software licensing audit is performed to determine whether an organization is in compliance with user license agreements, while a software quality audit is performed to examine the software program's quality and effectiveness. In general, a software audit involves ascertaining which software programs are loaded on company-owned computers or are residing within the network and comparing this information with existing software licenses, proofs of purchase documents, and contracts. The end result of the audit is to show that software has been legally and legitimately obtained and its use is of benefit to the organization.

As part of the software audit, the person conducting the audit (i.e., the internal auditor, designated in-house employee, or third-party vendor) needs to identify software holdings by name, after which all programs need to be identified based on their:

Function (i.e., is it a business tool or a music, video, or game program?).
Version (i.e., does the organization support multiple versions, which can lead to potentially costly support and data movement processes?).
Risks (i.e., will this software attract an attacker?).
Continued need (i.e., does the organization need this software to perform day-to-day functions or special activities?).

In practice, there is no standard approach for conducting a software audit. Some software audit programs may only identify executable applications by comparing these with their internal databases of software signatures, while others recognize only executable programs or program files from their extensions (e.g. EXE, COM, and DLL files). Finally, more advanced software audits may read all files to distinguish between actual programs and executables files and identify whether they have been renamed.

COMMON PROBLEMS ASSOCIATED WITH SOFTWARE AUDITS

One of the keys to a successful software audit is the audit tool's selection and proper use. This is because different software audit tools will generate different views on a company's software holdings. As a result, it is important for internal auditors to be aware of the tool's capabilities, especially if the organization wants to confirm whether its software holdings are legal or appropriate. Otherwise, the organization could be making assumptions on insufficient or misleading data.

Although in many cases identifying current software holdings during the review can be easily achieved by comparing the software in use with existing licenses, contracts, and other kinds of proofs (i.e., purchase invoices and service-level agreements), sometimes the auditor will not be able to identify all software holdings. Situations like these may occur because the software audit tool used to perform the review:

Fails to identify an executable file or does not recognize it (e.g., it is not in the tool's internal database).
The software was renamed or hidden in the recycle directory, which not all software audit tools search.
The tool may not be able to link files that are found in general or shared company directories to a particular software product that may be residing in someone's computer.

Besides identifying the software products currently in use, another problem is finding out what the software actually does. Simply clicking on an executable and running it might be the intuitive action to take, but what if the unidentified file is a virus, Trojan, or a stub program (i.e., software that is only partially installed or deleted) that causes the computer or, worse, the network to crash? As a result, many auditors may simply list unknown files in their audit reports without properly identifying what they do or write comments such as, "We couldn't determine what the file is, but when we tried to delete it the machine crashed" or "The system identifies this as a shared file and, as such, it would be unwise to delete it."

Additionally, the person conducting the audit needs to consider how the tool is to be used. Are users going to be involved or will the whole audit take place from a single machine in the audit or IT department? Another aspect that needs to be considered before using or selecting an audit tool is the purpose of the audit. For instance, software audits may be used to identify all MP3, graphic, or video files, as well as trace sensitive documents or spreadsheets. As can be expected, the whole purpose of the audit can be undermined if the software audit tool does not recognize different file formats from its internal database.

TO OUTSOURCE OR NOT — WHICH IS BEST?

As discussed earlier, different software audit tools may differ based on their cost and how they work, so auditors should evaluate the tool before recommending or purchasing one that best meets the organization's needs. Therefore, the audit needs to be performed with a software audit tool the organization is comfortable with. Besides selecting the appropriate software audit tool, organizations need to consider whether the audit will be conducted in house or by a third party (i.e., outsourcing the audit). The differences between using a third-party or in-house staff to perform the audit mostly relate to cost (i.e., an in-house audit is usually cheaper), experience (i.e., outsourcers generally have more experience), and time (i.e., an outsourced audit is usually completed faster). Below is additional information on things to keep in mind when either outsourcing the audit or conducting it in house.

Outsourcing the Audit
To make sure software audit reviews properly identify all software holdings and what they do, many organizations outsource or sub-contract the software audit process to other providers who have the necessary skills and expertise. Besides having access to a larger database of software signatures than the client organization, thus being able to identify what the software is and does, sub-contracting this part of the audit makes the outsourcer responsible for identifying the software holdings and not the organization.

However, it is virtually impossible for any outsourcer to have information on every software package in the market. In addition, the software audit tool used may not be able to identify all software holdings as explained previously. As a result, the outsourcer may not be able to document all of the software products currently in use by the organization. When this occurs, the outsourcer may simply provide a list of the software products they were able to identify and disregard the small amount they could not document or list them as unknown. While this approach may not be entirely effective in identifying all software products, it may be a satisfactory approach for organizations that lack the financial resources to identify all software holdings, especially if the unidentified software is only present in a handful of computers.

On the negative side, by not identifying all software holdings, even the ones the audit tool wasn't able to recognize, the organization will be completely unaware of their presence and the risks they pose. A good example of this is the inability of many audit tools used by third-party vendors to identify the sheer number of software products that are downloaded directly from the Internet without the need to purchase a hard copy. While the downloaded programs may have been purchased from a legitimate Web site, many free software products are full of malicious adware or spyware that can adversely affect a computer's performance.

Conducting the Audit In-house
If the organization wishes to further mitigate the risks created by software use or prefers to keep the whole process in house, options become somewhat limited. When selecting a software audit tool, the organization may wish to contact reference sites or other tool users to document any of the unidentified software that was found. While the organization might be able to identify all of its software holdings, it will have to spend valuable company time and resources tracing the software by conducting online searches and staff interrogations.

A good point to keep in mind when trying to obtain references is that many audit tool providers do not like to share their client lists. Although one or two clients may be named and used as site references for potential buyers, most organizations do not want their software choices broadcast; hence, they do not encourage software publishers to list their names. In addition, publishing the name of smaller organizations may also not be meaningful in any way to the wider community. This does not mean that contacting other users isn't ideal; it simply may not be possible to do so. Nevertheless, other sources exist, such as different discussion boards and forums that may be able to provide further help (refer to the end of this article for examples of discussion boards). The use of these services enables organizations to more effectively manage their software holdings by providing information that is either freely available or within easy reach.

One such source is a free software audit service from the United Kingdom called Liken. Developed for smaller organizations with scant resources in mind (i.e., those with 300 computers or less), Liken enables its members to share their knowledge on software products used in the field. Thus, the service may be a good alternative for internal auditors of all levels who would like to understand how to deal with software identification, what software signatures are, and how these signatures can improve their audit process. In addition, Liken provides information to help auditors and IT staff who are about to start their first software audit and need support and advice.

MOVING FORWARD

Software audit reviews have become more mainstream over the years and are now a regular feature on many internal audit plans. However, challenges remain, many of which are related to choosing the tool that best meets the organization's audit and assurance needs and the needs of the person who performs the audit (i.e., a third-party vendor or an internal IT or internal audit staff member). In addition, internal auditors and organizations need to remember that software publishers are still the owners of the product and, as a result, can ask for and expect users to account for how they are managing the software. This is a risk that is never going to go away.

For additional information about software audit reviews, internal auditors can visit the following Web sites:

Wikipedia's software audit review Web page.
The UK's Federation Against Software Theft, which provides a software audit process for organizations and a membership group for software publishers similar to Liken.
Microsoft Software Inventory Analyzer (MSIA), which locates only Microsoft software downloaded in a computer.
The Institute of Internal Auditors' Discussion Group message boards, where members and nonmembers can post questions on a variety of topics, including IT auditing.
ITAudit's Reference Library and Auditnet.org, which provide links to vendors and organizations that offer software audit tools and services.

In addition, the following articles published on ITAudit discuss the software audit and management process, as well as how to review different software tools:

"Reporting Capabilities of Software-audit Tools" (Oct. 15, 2003 issue).
"Customizing Software-audit Tools" (Sept. 1, 2003 issue).
"Tools for Software Inventory Audits" (Sept. 1, 2003 issue).
"Using Audit Tools to Audit Software Assets" (Aug. 1, 2003 issue).
An 11-part software management article series published from 1999 to 2001. To access these articles, visit the ITAudit Previous Issue Web page and select "Software" on the "Browse archives by category" menu, which is the third drop-down menu on the page. Once the page opens, scroll all the way down to read the first article in the series. Please note: All articles have the words "Software Management" as part of the title.

John Silltow has more than 20 years' experience working with government and financial information systems in England, focusing on computer audit and security. He is now managing director of his own company, Security Control and Audit Ltd., and specializes in Internet security, software management, and IT and audit training.

Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.

To make something bold:
<strong>Text to bold</strong>

To make something italic:
<em>Text to italicize</em>

To make a hyperlink:
<a href="URL">Text to link</a>