Chances are you've already felt the effects of sections 404 and 302 of the Sarbanes-Oxley Act of 2002 (Sarbox), whether you realize it or not. Sarbox addresses the growing trend of corporations that fail to accurately and truthfully report their financial situation and address and effectively manage risk in all its forms, including IT security risks. As a result, Sarbox has ramifications for the CEO and board of directors all the way down to IT professionals like us. Knowing what areas of Sarbox affect IT security will help you understand why certain things are being asked of you, how you can contribute to your company's compliance, and how to protect yourself from problems.
Controls
With regard to IT security, Sarbox doesn't contain any new concepts. Instead, Sarbox turns what used to be best practices into law. At the highest level, written policies, memos, and meeting minutes must demonstrate that management is taking the lead and involved in risk management and financial report controls. At a lower level, corporations must demonstrate that processes are in-place that effectively implement the higher-level policies and directives on risk management and financial reporting controls.
IT auditors base their criteria on widely accepted control frameworks such as COSO (http://www.coso.org/) and COBIT (http://www.isaca.org/cobit.htm). By reviewing these frameworks, you can learn which criteria auditors use when reviewing your department's practices. COSO and COBIT are too large to take on in this article, but let's look at the major types of controls that auditors look for. At the level of an IT professional, auditors look for general IT controls and application-level controls. Both types of controls can be preventive or detective.
As the names imply, preventive controls are designed to prevent a problem and detective controls are designed to detect problems that slipped through preventive controls. An example of a preventive control is a password lockout scheme designed to lock out accounts after repeated logon failures with a bad password. An example of a detective control would be a regular review of group membership additions compared against access control changes approved by the application's owner.
General IT controls are controls that affect multiple applications or data within your company. General controls might be strictly technical controls or processes followed by IT staff. For instance, a technical general control might involve your domain's password and lockout policy or workstation settings such as password-protected screen savers and disk encryption. The latter examples are general controls because they address risks to multiple applications and data (e.g., if you can't log on to the domain, you can't access or modify a spreadsheet used to track your company's proven oil reserves). General controls might also include technologies and components that you deploy for fault tolerance, disaster recovery, and business continuity. General controls are valuable for providing overall protection and auditors get very nervous if your general controls aren't up to par. But general controls can't address every type of risk; thus the need for application-level controls.
Application-level controls provide assurance of the integrity of business processes and application transactions and data (e.g., guaranteeing to an insurance company that a given employee can't originate a claim and approve it). Some application controls never involve IT and are simply policies and procedures implemented within the business process. Other application controls are directly implemented within the application. Although most technical application controls primarily affect developers and operations staff, they can impact IT administrators as well. For instance, you might be subject to certain policies dictating that before you grant a user access to certain data or a level of access in an application, you must receive approval from the application or data owner-usually a manager in a department closely related to the resource. Or, you might have certain tasks removed or added to your responsibilities to support separation-of-duty controls. The concept of separation of duty requires that one person not have the authority to perform a combination of tasks that let him or her circumvent controls, easily perpetrate fraud, or introduce a conflict of interest. Classic examples of separation of duty include not using the same person who administers user accounts to monitor user account changes and not having the IT staff perform an IT security audit of themselves.
When an auditor can't verify a given control, the auditor will often accept a compensating control that provides an alternative way of controlling a risk that management can't or chooses not to control using more classic methods. For example, management decides not to implement a strict password policy requiring a certain length and combination of characters, thus leaving the network at risk to easily guessed passwords. As a compensating control, you perform a monthly crack of passwords and follow up with users and their manager, if necessary, to correct passwords that your documented criteria designate as weak.
Sarbox directly addresses specific IT issues in several other areas, including IT asset management issues (e.g., acquisition, retirement, licensing) and records retention. Emails communications, and in some cases Instant Messaging (IM) communications, might need to be archived for years for potential future investigations.
Documentation and Reporting
Far beyond a memo stating that security logs should be monitored for changes to user access of critical applications or information, you need to demonstrate that such a procedure is actively and consistently being executed. During an audit, you might be called upon to produce monitoring reports from a certain period as well as a record of who reviewed them and whether anyone reported to management and followed through on any exceptions. So, in addition to documenting the existence of security controls, Sarbox also requires that you document the performance and enforcement of such controls.
If you work for a publicly held corporation, your management team should already be addressing these concerns. More than likely, you've been called upon to document your current security procedures, develop procedures to implement high-level policies from management, document the execution of such procedures, and respond to increased emphasis on reporting security exceptions to management in a formal, auditable method. Reporting to management is necessary because Sarbox requires management to be actively involved in the risk management process so that they can make informed decisions that involve risk to the company or affect the accuracy of its financial reports. After Sarbox, there's no excuse for "I wasn't aware of …". Proper reporting and documentation is in your best interest because employees can face criminal charges for failing to meet Sarbox compliance. (Admittedly, it's expected that such criminal prosecution would be directed against upper management.)
Testing
Sarbox requires that controls be regularly tested. Your auditors will test controls by collecting policy and procedure directives, interviewing key personnel, watching processes being performed, reviewing documentation, and in some cases by repeating execution of a process for a sample set of transactions. In IT administration terms, this last step might take the form of an auditor asking to walk through an imaginary account creation for a new employee or randomly selecting a user and requesting the documentation that justifies all the groups to which that user is a member. The auditor will expect to see application change control requests signed or otherwise authorized by each group's corresponding business owner.
Sarbox is a huge undertaking for corporations and admittedly creates a lot of extra work-especially documentation-that's seldom considered a rewarding activity by technology people like you and me. But it's the law and everyone must do his or her part to help comply with the law and contribute to accurate reporting to the company's investors. Make sure you understand which controls defined by management affect your job. And make sure you know when and to whom you should report security issues and document everything you do for the sake of your company as well as your career.
