My team is planning to audit the patch management process. Instead of checking whether the patches have been applied to the boxes, we would like to assess the effectiveness of the patch management system—for example, how to distinguish the various roles played by different parts of IT operations, IT security, etc. Can you please provide us with a high-level checklist?

Depending on the size, nature and complexity of the business organisation, the following roles can be played by one or more individuals:

• Patch manager
• Patch deployment manager
• Patch testing manager
• Asset owner
• Patch process owner

Figure 1 explains the various roles and their responsibilities.

I would also recommend a patch management guide recently published by the Institute of Internal Auditors as good reference material for this audit.

To prevent potential theft of proprietary information, my organisation is planning to deploy software that will restrict USB usage, even though we are told that USB usage can be controlled by the new Windows Vista Group Policy. Given that we have a number of devices with different operating systems, we would like to adopt the software restriction route. What are the features we should look for while buying such software?

I do not wish to recommend any particular product because I have seen a number of "whiz kids" from my own team making such software dysfunctional. However, I am happy to comment on some of the features that you need to look for when buying software, including (but not limited to) the following:

• Price, obviously
• List of operating systems supported, given that your organisation has multiple systems
• How access control is performed—kernel mode or user mode (kernel mode is considered more secure)
• Complexity of the installation process
• Deployment, management and possible removal of the remote agent from console
• Ability to disable local administrator privileges
• Possibility to add custom devices
• Management by group policy
• Ability to control users' access to different types of storage devices
• Ability to define read/write access to storage devices
• Ability to set time-dependent permissions
• Provision of temporary access where necessary
• Application of access policy whether the user is online or offline
• Ability to draw a white list—permissible ones—of USB devices by their unique IDs
• Audit users' access permissions
• Audit users' access to devices and files on these devices
• Ability to maintain a trail of data copied into devices
• Logging of changes to settings
• Ability to generate reports on plug-and-play devices in use
• Ability to generate reports on settings defined on network computers

My organisation is planning to deploy Internet messaging (IM) for internal and external communications. What are the risks that we should consider when making the decision whether to deploy?

The list is not exhaustive, but it will serve as a good starting point:

• Unlike e-mail applications, IM applications do not automatically scan messages and shared files for viruses; hence, the risk of virus proliferation exists.
• Logging has to be enabled manually and is typically limited to logging of conversations.
• Use of IM with logging may breach local regulatory or legal requirements.
• Public services do not provide logging at server levels; logging is possible only at the client end.
• Logs are often stored locally on a client machine and can typically be deleted or modified by the user.
• Encryption of messages or files being transferred is not available by default, unless it is aided by use of a third-party software.
• Certain IM applications install toolbars and other additional software that may contain adware, thereby opening the doors for malware.
• Authentication mechanisms place reliance on just a user ID and password; local storage of the user ID and password is possible.
• Use of just an e-mail ID for registration increases the difficulty in proving identity of users.
• Identities are defined by users, so impersonation is a distinct possibility.
• Public servers do not provide the capability of integrating with corporate directories to create a restricted user list.
• The application has a "save password" feature that is in use for direct login, increasing the risk of a malicious third party discovering these authentication details.
• Frequent change of password is not a mandatory requirement.
• Proprietary mechanisms or weak encryptions are used during the authentication process.
• Blocking IM ports is ineffective as they are configured to use alternate ports, such as port 80.
• Most IM clients are port-agile in the sense that they can use common ports if default ports are blocked.
• It is difficult to differentiate between normal HTTP traffic and web-based IM traffic.
• Virus, worms and Trojans are being written for specific IM clients.
• Buddy lists can be exploited for spreading worms and virus.
• Extensive use of IM, especially with large file transfers and video conferencing, consumes a great deal of bandwidth and impacts genuine users.
• Most IM applications support voice and video, enabling users to get involved in unauthorised voice and video conferences, again impacting bandwidth.
• IMs also support Voice-over Internet Protocol telephony, which could be illegal under local regulations and laws.
• A lack of compatibility amongst different IM applications causes users to install multiple applications, thereby increasing the number of avenues for malware distribution and bandwidth consumption.
• The lack of content monitoring increases the risk of spam messages.
• Excessive messages could cause a system overload.
• Confidential information may be shared via instant messaging, as file transfers can occur without any logging or monitoring.
• Organisations may be under legal risk if inappropriate material or materials in breach of copyright are transferred via IM.
• Unauthorized installation and configuration of IM by users may lead to conflict with standard desktop configurations used by the organisation.
• Public services do not provide functionality to include disclaimer notice along with the messages.

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.