Home > Articles

  • Print
  • + Share This

Assessing General Controls

General controls can be assessed through design walkthroughs, code reviews, interviews to ensure that procedures are followed, sample testing to ensure that documents and records are kept concerning processes and procedures, and so forth. In the next section, I offer some guidelines for assessing some of the general controls.

Auditing the Administration of Duties/Rights

A key aspect of a Sarbanes-Oxley audit is checking that rights and duties are separately assigned to different individuals so that no individual has the power to divert business or transactions in a fraudulent manner.

Clearly, IT often plays a large role in this area. It is the Sarbanes-Oxley IT auditor's job to check that individual IT permissions and roles are organized in such a way as to not make the company vulnerable to fraud. For example, no single individual should be able to access all IT systems involved in financial transactions, because knowledge of the full path through those systems could make it easier for that person to commit fraud.

Within a database, one individual may be given the ability to carry out DDL commands (create tables/views/triggers/stored procedures, modify them, and delete/drop them), while another individual should be given the ability to assign permissions enabling individual users to execute queries, triggers, and stored procedures. The principle of separation of duties and rights is often implemented using the concept of "roles" within an IT system.

The principle of least privilege should be applied when assigning permissions within the operating system, the applications, and the databases. Any individual should be given only the permissions he/she needs in order to carry out his/her job. This principle should be enforced at the operating system level, the network (component) level, the database level, and the application level.

Some aspects of authentication/access control can be fairly easily enforced through the use of a central LDAP or Active Directory repository (or similar identity/directory management system), whereby the role and/or the group to which a userID belongs determines the privileges granted to that user.

An identity/directory management system can also make it easier to make administrative changes when, for example, an employee leaves the company or transfers to another department. Removing or transferring the employee from all groups to which he/she belonged removes privileges automatically, and any future attempts to access unauthorized systems will be logged and flagged in the review process.

User provisioning techniques should ensure that new users are set up with the correct privileges, by creating a standard profile for each type of user; this profile should determine the default permissions assigned to a new user of that type. Such techniques should also enforce rules that prevent users from being assigned the wrong privileges.

The auditor should ensure that the principles of separation of duties, least privilege, and user provisioning are applied to all users of any systems owned/used by the organization that are considered to be in the scope of the audit. The auditor should also be aware that there may be other external requirements to which the company must adhere—for example, the requirements of Visa CISP—that may be even more rigorous than those involved in Sarbanes-Oxley, especially in some of the network security areas.

Where the principles of separation of duties, least privilege, and user provisioning are not clearly in place, the IT system has, strictly speaking, failed to meet Sarbanes-Oxley compliance, and the exception should be noted and flagged up to management so that they can work on remediation.

Assuming that your external auditors are reasonable, the fact that this exception has been noted and flagged will be sufficient, unless it creates a significant risk—so long as you can provide evidence that a plan is in place to remediate the failure in the near future.

However, because Sarbanes Oxley is so new, there are no clear "pass" or "fail" criteria, and all auditors have different levels of comfort with exceptions, and it's best to discuss your individual situation with your own (independent) advisors and/or auditors.

Change Management

The purpose of testing for change management controls is threefold:

  • Ensuring that an unauthorized change that could be used for fraudulent purposes cannot be made to the system by a malicious employee

  • Ensuring that the company's money is not spent on changes that have not been properly authorized (and therefore may not even be required)

  • Ensuring that system integrity is maintained and reducing the likelihood of defects or bugs being introduced into systems

The auditor should check that a formal change management process is in place. The process should be documented, approved, effective, and in use by all those making system changes to systems within the scope of the audit.

To be effective, a change management process should usually include a procedure for emergency changes and a procedure for planned changes. It's inevitable that some changes will need to be made very quickly, and it will not be possible to follow the normal change management process for these kinds of changes.

The process should also deal effectively with the different types of changes that may be requested—bugs (usually requiring only a quick fix and a little testing) may need to be dealt with very differently from enhancement requests, which may require whole new development projects or sub-projects to be set up.

The change management procedures should ensure that a full documentation trail tracks changes made, so that it's possible to reenact or roll back changes if necessary, and it's possible to easily find out which program files were affected by any particular change request.

A QA process should exist in order to test changes in the test environment before such changes are placed into the live/production environment.

Ideally, testing should incorporate use of a tool for testing that can produce scripts so that such testing is quickly and easily repeatable.

Security

Because security is such a huge concern within Sarbanes-Oxley generally, IT security should form a large part of the audit process.

TIP

I've written extensively about IT security audits. If you want help on what to consider when reviewing security, see my earlier InformIT series "How To Perform a Security Audit" (part 1, part 2).

Many SOX security auditors are using ISO 17799 for guidance on which aspects of security to check. This is a very good practice, as it removes some of the ambiguity involved; however, it's also a high target to aim for, and for some organizations it may not be practical. The ISO 17799 News portal is a great source of information about ISO 17799. If you decide that you want to do a thorough job of auditing against the ISO 17799 standard, consider buying a tool that can help, such as the ISO 17799 Toolkit.

For those who are not prepared to use an extensive ISO 17799 approach, it's important to be able to illustrate that, at a minimum, policies are in place and are being followed effectively in the following areas:

  • Physical security:

    • How people get access to the building (how ID cards are issued, security guards are vetted, etc.)

    • Where the computer equipment is kept and how it's secured from theft, fire, flood

    • Policies dictating physical security

    • Laptop (and wireless devices) and workstation physical security

  • Intrusion detection/prevention:

    • Which IDS/IPS software is running on which network components

    • Who is alerted when intrusions are detected

    • Policy for handling intrusions, etc.

  • Logging:

    • Error logging

    • Incident logging

    • Reviews of logs

    • Policy for acting on unusual activities

    • Access to logs/changes to logs

  • Antivirus policy:

    • Firewall policies for content filtering, closing ports, etc.

    • Network antivirus policy

    • Email antivirus

    • PC antivirus setup

    • Server antivirus

    • Communication to users to educate them in how to deal with viruses

  • Remote-access policy:

    • VPN policy

    • Access via modem/DSL/Bluetooth/wireless, etc.

  • Configuration policy:

    • Firewall/router/hub setups to ensure that "back doors" are closed, patches are installed, etc.

    • Server (especially web server) setup policy to ensure that potentially dangerous protocols are turned off (such as Telnet and FTP)

    • Control over installation of new software (testing of software in lab conditions before installation)

    • Inventory to ensure that someone knows which network components exist and where they are, how they're configured and changed, etc.

  • Authentication/access controls (see above)

  • Regular vulnerability assessment—to include port scanning, checking for software patches that are not up to date, checking for antivirus updates that are not in place, and so on

For advice on the various aspects you should investigate as part of the security audit, many resources are available on the web to help you. For example, WebEx offers a number of VeriSign-sponsored seminars on security.

  • + Share This
  • 🔖 Save To Your Account