impossible for ideas to compete in the marketplace if no forum for
EXAMINING THE SARBANES-OXLEY ACT
By Robert P. Abbott
This paper briefly describes sections of the Sarbanes-Oxley Act (SOX)1 that are relevant to Information Technology (IT). The subjects of Controls and Control Objectives are introduced enroute to identifying the properties of Sygate products beneficial to complying with SOX. The bulk of the paper identifies specific control objectives wherein Sygate products provide audit evidence of compliance. A number of control objectives are also put forth as state-of-the-art contributions to the overall need for IT controls and for the automated monitoring of those controls.
The Sarbanes-Oxley Act
The Sarbanes-Oxley Act addresses many aspects of the responsibilities and conduct of Chief Executive Officers (CEO), Chief Financial Officers (CFO), and Certified Public Accountants (CPA). It also speaks to maintaining and preserving the integrity of financial records. Though SOX makes no specific mention of IT in any form or shape, IT certainly enters the playing field through the Sections 3022 and 4043 of the Sarbanes-Oxley Act.
Section 302 establishes corporate responsibility for financial records. Most, if not all, financial records are stored in one or more of a corporationâ€™s IT systems. The word responsibility translates to accuracy of financial records. Responsibility also translates to protection against unauthorized modification, destruction, or disclosure of data relating to financial records. By extension, IT systems must also be protected against unauthorized modification, destruction, or disclosure of financial data.
Section 404 requires Management to establish an overall system of controls throughout the entire corporate entity. These controls include all aspects of IT - starting with application systems and continuing on through operating systems, communications, networks, and network infrastructures. These areas are well known to the IT professional. In general, however, what may not be generally familiar to the IT professional is the concept of controls. As a result, controls are often overlooked or misunderstood.
Controls, in the corporate sense, are defined to as points, within the corporate entity, at which “Managementâ€™s best interests” are verified as being followed and protected. As an example of a non-IT control, consider a corporationâ€™s requirement that prior approval must be obtained for the purchase of a new telephone system. This approval usually means that the signature of a high-ranking corporate person has been obtained. This authorization is a control because the high-ranking official must review the proposal for acquiring the telephone system, the selection process for the vendor, and other aspects of the intended purchase to make sure that the company's best interests are being pursued.
Other examples of non-IT controls include an approval of travel before an employee makes a business trip, the trip expense report filed after the trip, the requisition form needed to hire a new employee, etc.
Now let us turn to IT controls. Change Procedures (for the updating of software) are controls. Security policy is a control. Anti-virus software is a control.
The screening of employees might also be considered an IT control, although it is not a control that can be enforced by an IT system.
IT has, of its own accord, installed a number of controls within its structures simply to maintain an efficient and effective operating posture. SOX compliance seeks to utilize and to extend those existing IT controls as well as develop and install new IT controls.
A Framework is a general guide to be followed in carrying out some process. Controls are typically organized in a hierarchical framework with goals and objectives at the highest level and detailed control attributes at the lowest. Control Objectives consist of the topics or major areas of interest that are to be controlled. Ensuring IT Security could be, and is, a Control Objective.
Managing Operations is another Control Objective. Neither of these two, nor any other high-level4 control objective specifies how to accomplish the control objective. In other words, a Control Objective statement defines what must be controlled rather than how to control it. This approach takes into account the possibility that changes to a control regime may be needed over time to meet either Managementâ€™s needs, an advance in technology, or the requirements of compliance.
The processes of implementing SOX, and that of traditional auditing both employ the same framework, the COSO Framework. COSO was developed, and published by the Committee of Sponsoring Organizations (COSO) of the Treadway Commission. COSO was developed primarily for the financial auditor and, in keeping with the high level statement nature of Control Objectives, does not provide granularity for the field of IT.
This omission is addressed by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI). They mapped their detailed CobiT5 framework of IT Controls against the more general Control Objectives from the COSO Framework, thereby verifying compatibility with the COSO. That mapping of control objectives is shown in Figure 1 below.
An examination of line items in the mapping reveals that many of the control objectives are of a “paper chase” nature because written records must either be developed or examined to achieve a control objective. An example can be found in the Control Objective for Management of Human Resources. This control uses IT as a storage and retrieval medium. There is no automatically engaging algorithm processing the HR data to make sure Managementâ€™s best interests are being followed. Consequently, this control is not an IT-based control. For the Control Objective to Ensure System Security, both a “paper chase” and a large component of IT-based actions (e.g., a written security policy that goes beyond the validation of passwords during the logon process) are required.
The issue of IT granularity can be addressed in two ways. The first methodology is a classic top down approach and is the methodology employed by ISACA and ITIG. First, they identified four domains that contain the subset of CobiT Control Objectives addressing the requirements of SOX6 (aligned with business processes). The four Domains are further broken down into 34 Control Objectives. The 34 Control Objectives are supported by more than 136 Control Statements. Please note that, as indicated elsewhere in this paper, the exact number of Control Objectives and Control Statements vary both as a function of advancing technology and as a function of the individual enterprise.
This three-level approach is often employed in other industries where regulatory compliance is required. For example, in the healthcare industry, we might consider cleanliness as the highest level Control Objective for operating rooms in a hospital. One supporting subsidiary control objective might be that an antiseptic must be used in meeting the control objective of cleanliness. And, finally, at the lowest level, Clorox might be specified as the current best antiseptic agent.
The lowest level of control, Clorox from the example, may be changed within the next few years to something else - perhaps Lysol. Over several years, the subsidiary control objective of an antiseptic could be changed to something else - perhaps irradiation. The basic control objective - cleanliness - is rarely changed.
The second methodology of achieving IT granularity is a bottom-up approach in which new IT control statements and subsidiary objectives are developed based on the emerging state-of-the-art in IT. This approach to IT granularity will see continual change, or better yet, continual improvement, as IT continues to “grow” its capabilities. In the 1970s, the federal government issued a control statement prohibiting the placement of a telephone within six feet of a computer processing classified information. That represented the state-of-the-art in communications controls in 1970. Today, we have encryption, which does a far better job with or without a nearby telephone. Consequently federal control statements regarding classified computing have been changed in recognition of the current state-of-the-art in communications controls.
Enforcement of SOX also requires controls to be monitored. To understand the complexities of monitoring, consider an example of an alarmed door. When it is opened, it will sound an alarm. How do we know it is functioning? One way is to open the door and count the seconds before it alarms.
An auditor comes around once each year, opens the door and verifies that it sounds an alarm. He is monitoring the control. But, what happens during the rest of the year? The Auditor is not aware that the alarm was disconnected from May through July. In other words, controls may be established but not consistently monitored or acted on.
Monitoring is a process that assesses the quality of the internal control process over time.
Detection and timeliness of response are two key factors in maintaining and monitoring a system of internal controls. Management is given the responsibility to establish and maintain controls to ensure that they operate as intended or are modified as appropriate. Now, consider an Intrusion Detection System (IDS). Once it has been installed, how do we know that it is working? The IDS audit trail (log) is a history of actions taken and shows that the IDS is working. A logistical challenge may emerge if an entry point is under serious attack and the audit trail becomes quite large as a result.
The sheer volume of data generated by automated processes will be meaningless to management and auditors alike, unless summarizing methods and algorithms are applied to the information. Monitoring of automated controls is an area of development that will demand a significant effort to satisfy this SOX requirement.
Before we focus our attentions to the details of implementing and auditing IT controls, let us examine the Sygate Product Suite to see where each product fits into the picture of IT controls. Taken as a whole, the Sygate Solution is, of and by itself, a system of internal controls for tracking and maintaining integrity of the network infrastructure. Individually, each Sygate product controls and monitors specific devices connected to the network:
Sygate Magellan guards against the attachment of unauthorized or so-called “rogue” devices to the network. Magellan also provides notification when unauthorized changes are made to the contents of a network device and specifies which network devices are currently unmanageable according to the corporate IT security policy.
Sygate Secure Enterprise (SSE) Places software agents on all laptop and desktop devices to ensure policy compliance prior to the granting of network privileges. Once these privileges have been granted, the Agents are able to monitor and enforce policy compliant behavior.
Sygate On Demand Agent (SODA) provides data protection to devices without Agents and to which sensitive or proprietary data are being sent, manipulated, or generated.
The types of IT controls that Sygate Products can implement include policy enforcement, intrusion detection, network access controls, software change logs, and network usage logs. In the following attachments, we show how these controls can be applied to provide compliance with specific SOX control objectives.
SOX is a relatively new law. As such, it often lacks the clarity and definitive controls that can be found with other regulatory requirements. The COSO Framework and CobiT mapping are on the leading edge of generally accepted SOX requirements. The situation is still fluid, and Controls and Control Objectives will continue to evolve. Generally speaking, though, Control Objectives will not regress. They will build upon what has already become generally accepted. The following attachments represent examples of Illustrative Controls and Illustrative Tests of Controls. The word illustrative means that in a given situation, additional controls are expected to be identified and applied. Networks, corporate cultures, devices and distributed software differ from one company to another.
We would be foolish to assume that a specific implementation of SOX within Company A would also work in Company B. Similarly, the type of controls in Company A are most likely different than those in Company B. Whereas the COSO Framework provides the general guideline as to how to proceed the framework will, over time, be augmented and made more granular to take into account the unique nature of each IT system.
Attachment A - Ensure System Security begins with controls that relate to written records. Page 6 is the beginning of suggested control objectives which are specific to IT Networks.
Attachment B - Monitoring describes control objectives at a granular level that is not addressed by either CobiT or COSO. The governing body of SOX, Public Company Accounting Oversight Board, has indicated a need for active monitoring of controls.
Control Objective: Ensure Systems Security Notes:
Control Objective: Monitoring
Note: All items in the italic font are our contributions to the state-of-the-art of internal controls for IT networks.
About the Author:
Prior to joining Sygate Technologies, Inc., Robert P. Abbott was founder and CEO of EDP Audit Controls, Inc. - a consulting firm providing IT security reviews and IT security design services. Previously, at Lawrence Livermore National Laboratory (LLNL), he served as Principal Investigator of the RISOS (Research In Secured Operating Systems) Project, a DARPA-funded effort to define the meaning and boundaries of IT security. Before LLNL, Mr. Abbott was Principal Investigator in the application of computer technology to medical research. During this time he held grants from the National Institutes of Health. The project produced the first physiological monitoring system for patients recovering from open-heart surgery. The medical experience followed a previous position as Division Leader for research projects at LLNL. In that capacity, he designed the first multi-user, multi-tasking operating system to go into 24x7 operation. It ran on Crayclass computers for over 20 years. His career began at LLNL as a scientific programmer in the weapons program. He holds a bachelors degree in mathematics from the University of California at Berkeley.
Visit the Authors Web Site
Inquiry Only - No Cost Or Obligation
Click Here for The Business Forum Library of White Papers
Search Our Site
Search the ENTIRE Business
Forum site. Search includes the Business