Date: Sep 17, 2004
Concluding her two-part series on handling Sarbanes-Oxley compliance, Michelle Johnston explains how to audit your organization.
My previous article in this series described how to prepare your organization for auditing. Now we'll delve into the audit itselfwhat's involved, and how to survive it.
What To Audit
The Sarbanes-Oxley Act of 2002 (hereafter simply Sarbanes-Oxley) is designed to ensure the following within a business:
There are sufficient controls to prevent fraud, misuse, and/or loss of financial data/transactions.
There are controls to enable speedy detection if and when such problems happen.
Effective action is taken to limit the effects of such problems.
In many companies, most of these controls are IT-based.
Not only must controls be in place; they must be effective, and it must be possible to note exceptions caught by the controls and follow audit trails in order to take appropriate action in response to those exceptions. This requirement puts a new pressure on IT that until now few IT departments have faced.
Ultimately, Sarbanes-Oxley makes executives responsible for ensuring that these controls are in place and effective, and this fact is making Sarbanes-Oxley a high priority on most companies' agendas: Executives are aware that they could go to jail if these processes are not in place and/or are ineffective. Suddenly, executives are very interested in what's going on in the murky depths of the IT department!
For detailed guidance on IT auditing, many have chosen to use the ISACA subset of COBIT to ensure that the key IT aspects related to Sarbanes-Oxley are being tested and ISO 17799 for guidance on which security aspects to audit.
Key Controls Versus General Controls
Early on in the IT audit for Sarbanes-Oxley compliance, it's important to establish two main groupings of IT controls that should be checked: key controls and general controls.
For the purposes of Sarbanes-Oxley audits, key controls are controls that are key to ensuring that the values on the balance sheet are accurate and reliable. Every expense/transaction must be initialized, authorized, controlled, implemented, reported/documented, and validated/cross-checked using key controls. Some of these key controls will be IT based, and should be covered in the IT audit. An example might be a trigger on a database table that ensures that adding any entry into the accounts receivable table automatically creates an entry into the general ledger. It would be important to ensure that this trigger is in place, is correctly coded, and can be changed only by authorized personnel.
Another key control might be the use of database transaction-handling to ensure that either all sub-transactions involved in one big logical transaction are posted or that the whole logical transaction is rolled back, to ensure that the data is never in an inconsistent state. It would be important to check key transactions to ensure that the transaction code is written correctly and that guidelines/standards make it clear how transactions should be structured within the organization to ensure that this is the case.
In some companies, email is so crucial to a process that it's considered to be a key control; in such cases, this email should be subject to message queuing technology, to ensure that if the email fails to be sent, it's re-sent later.
Some other examples of key controls are reports that are used to check the totals of transactions or check that two separate systems tally with one another. Code reviews, design walkthroughs, unit testing, and user-acceptance testing are examples of ways in which reports should be validated as being reliable.
It's the IT auditor's job to ensure that key controls are effective, reliable, and reproducible.
General controls are controls that go across all IT systems and are essential to ensuring the integrity, reliability, and quality of the systems. All of the following are examples of general controls:
Security policies and procedures
Change management policies and procedures
Disaster recovery policies
Backup and recovery procedures
Service-level agreement policies
When assessing general controls, it's important to look at the effects of those controls across all IT systems that are within the scope of the Sarbanes-Oxley audit. General controls usually incorporate at least the following types of controls:
Change management procedures
Version management/release management procedures
Source code/document version control procedures
Software development lifecycle (SDLC) standards:
Clear process and structure, documented
Design documentation standards
Security policies, standards, and processes:
Intrusion prevention and detection policies
Physical access security
Internet usage policies (see Microsoft's article "Why You Need a Company Policy on Internet Use")
Incident management policies and procedures
Technical support policies and procedures
Hardware/software configuration, installation, testing, management standards, policies, and procedures
Disaster recovery/backup and recovery procedures
Generally speaking, if it's an IT "best practice," it's usually good from a Sarbanes-Oxley perspective. There are a few exceptions to this rule, though; for example, some open source strategies, while seen as a best practice in the IT world, are arguably not in line with Sarbanes-Oxley requirements, as they contradict the key ideas within Sarbanes-Oxley that access to information should be purely on a "need to know" basis, and that processes should be controlled. It's usually a good thing for Sarbanes-Oxley purposes if a policy, procedure, or process is
standardized across the company
Thus, it often makes sense for it to be automated (as this theoretically also makes it more difficult for individuals to manipulate the control either maliciously or by mistake). For example:
Many companies use a centralized software-driven source code control system or document management system in order to implement version control policies.
Backup and recovery procedures are often automated using scripts (centrally administered by the relevant MIS department) to back up data at regular intervals, as well as using clustering techniques, RAID, etc. to automatically transfer control to backup hardware when the primary hardware fails.
Authentication and access-control procedures are often automated using centralized directory services such as LDAP or Active Directory.
Intrusion prevention and detection processes are often automated using centralized services such as IPS/IDS software.
Antivirus policies are often automated using centralized software such as McAfee or Symantec antivirus software.
Even in smaller IT companies, to conform to Sarbanes-Oxley, it's a good idea to ensure the following:
The same SDLC/methodology (design, creation, and installation of IT systems) is used across all applications.
Coding standards exist and are adhered to, and code is reviewed to enforce the coding standards.
All changes to code must go through a documented approval process before being implemented.
Incident-management procedures should exist, and all involved should know how to respond to key incidents.
A centralized list should be kept up to date showing all IT infrastructure assets (PCs, firewalls, servers, routers, hubs, and so on).
All changes made to assets/objects within the IT infrastructure should be authorized, recorded, and reviewed.
An intranet (or other centrally held, easily available document repository) contains up-to-date versions of all key documentation (including the latest policies and procedures, emergency telephone numbers, etc.).
For each general control, it's important that the internal auditor can show how the relevant policies/procedures/processes are
Createdevidence of the policy/procedure documentation
Approvedevidence of sign-off/approval
Implementedtest system/procedure to ensure that the policy/procedure is followed
Reported uponevidence of ongoing reporting (not just a one-time report produced for audit)
Monitored/reviewedevidence that the policy is enforced and is reviewed
Improvedevidence of a process that includes a feedback loop for changes to be made in response to improvements
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 adherefor example, the requirements of Visa CISPthat 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 riskso 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.
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 requestedbugs (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.
Because security is such a huge concern within Sarbanes-Oxley generally, IT security should form a large part of the audit process.
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:
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
Which IDS/IPS software is running on which network components
Who is alerted when intrusions are detected
Policy for handling intrusions, etc.
Reviews of logs
Policy for acting on unusual activities
Access to logs/changes to logs
Firewall policies for content filtering, closing ports, etc.
Network antivirus policy
PC antivirus setup
Communication to users to educate them in how to deal with viruses
Access via modem/DSL/Bluetooth/wireless, etc.
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 assessmentto 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.
As a result of your research, you may realize that you need to implement new security policies. SANS offers a training guide (PDF) to developing security policies for your organization, and many sample policies are available on the web to use as a starting point for your own policy development:
Sample email policy guidelines (PDF)
Sample end user policy (Microsoft Word format)
Sample IT audit report (PDF)
SANS offers a number of sample policies to help you develop your ownvery basic but useful as a starting point.
Documenting Your Audit
For automatically documenting Sarbanes-Oxley information, you might consider an automated package such as the Microsoft add-on for Sarbanes-Oxley, or the IBM software for the same purpose. A number of security tools can provide "scoring" of systems against independent criteriasee the Center for Internet Security and others that provide documentation that can support an audit, such as NMAP (a tool that maps out the network and can be used to determine which hosts, OSes, packet filters, firewalls, and so on are in use).
Useful Security Links
SANS' top security threatsincludes tools to put right the threat and to detect whether you're vulnerable
The Sarbanes-Oxley "conspiracy"
Taking control of Sarbanes-Oxley (PDF)
Meeting the new federal requirements (PDF)