Security Controls for Sarbanes-Oxley Section 404 IT Compliance
By Dennis C. Brewer
John Wiley & Sons ISBN: 0-7645-9838-4
Chapter One The Role of Information Technology Architecture in Information Systems Design
How many laws and regulations affect your business? How many of them affect your organization's computer applications? Do your computer systems comply with all of them? All are good questions with transitive answers. Sarbanes-Oxley (SOX) is one of many new regulations making its mark on how business is conducted. There will more new ones not too far down the road.
By taking action now in conforming to the mandate for adequate controls on information technology systems and applications required by SOX, you also position your organization to meet privacy protection mandates, disclosure requirements, and what may be needed for the next round of regulation that could affect your data systems.
Meeting the SOX Challenge
The Sarbanes-Oxley Section 404 requirements to maintain adequate security controls over information technology systems forge a challenging and perhaps somewhat intimidating task. Add to them a multitude of regulatory agencies at all levels of government that are endlessly generating requirements (federal HIPAA statutes and California's privacy protection initiative that requires firms to make individual disclosures of known compromises to anyone's private information that might result in identity theft, for example) that your information technology security and privacy protection controls also must meet, and the whole undertaking could seem overwhelming.
With all of the sometimes confusing and often conflicting requirements placed on an organization's IT (information technology) practitioners today, charting a practical course for compliance with Sarbanes-Oxley seems very hard to achieve. IT managers face the ever-present need to provide easy-to-use applications on systems that directly support the business processes to efficiently get the work done. They also are now required to place on the end users and systems a set of controls that support and meet the requirements of the regulatory agencies. SOX brings all of the historical requirements of cash controls, accounting standards, and audit oversight and reporting to the micro bits and bytes information technology realm often ruled by a more laissez-faire approach to getting things done "yesterday if possible."
Understanding the New Definition of Adequate
The big story in Sarbanes-Oxley for the IT professional is that earlier approaches to quickly getting applications built and in place to support the business (punch a few holes in the firewall and worry about security later) will no longer pass the inevitable audit. Access controls that give everyone in the same OU (organizational unit container) the same access rights are no longer considered "adequate" security controls. Meeting the test of maintaining effective internal control structure and processes supporting accurate financial reporting requires treating SOX 404 compliance with a focus and discipline not always evident in existing information systems designs.
The annual audit findings that report substantial weaknesses in controls will attest to these shortcomings in existing IT designs in small and large companies alike. Looking forward, there's just no point to building tomorrow's audit failures today. Legacy systems and existing applications must be brought into compliance. Failure to do so has the potential of a big negative impact on the value of the public companies that do not meet the compliance tests during audits. Public audit of internal controls linked to Section 404(b) requires auditors to assess whether the internal control structure and procedures contain any substantial weaknesses of any kind. The audit reports are expected to attest to the success of the company's internal control structure and procedures for financial reporting purposes.
Any flaw in an organization's control relationship between identity, authentication, access control measures, and the links made to financial or privacy data are subject to audit and adverse reporting. As the rules are refined and auditors become more knowledgeable about the technologies involved, any imperfections in the controls will likely be discovered over time.
High Stakes for Compliance Failures
One could easily imagine a corporation that doesn't look too bad on its first audit, but some material findings emerge related to SOX 404 issues. The company fixes some things and then gets audited by a different team capable of a more detailed technology audit, leading to more negative findings in audit year two. The company fixes the year-two findings only to be audited in year three by yet another more sophisticated team, and behold, more negative audit findings related to the quality of controls. After a scenario like that, Wall Street analysts may feel compelled to point out to the stock-buying public that company X seems to be having difficulty correcting its compliance issues, and they may downgrade the outlook for the company because it just can't seem to get a grip on instituting the necessary controls.
The control issues surrounding compliance with SOX-like mandates do not apply only to public companies. Governments at all levels, the nonprofit sector, and closely held companies all face the need to satisfactorily protect the integrity of their confidential information and provide adequate controls on access to data stores and to counter the liability of losses of clients and members personally identifying information. For some nonprofit organizations, the financial risk of litigation resulting from inadequate controls may be far greater than any harm from adverse audit findings.
This book is intended to help those responsible for establishing and maintaining adequate information technology security controls. The information applies regardless of the kind of business. As the oversight and regulation environment is perfected, it will inevitably require organizations of all types to put in place controls that will be deemed adequate for compliance with SOX, HIPAA, or other oversight entity's rules. Even if the controls are not required by laws or regulations, it simply makes sense to implement and maintain sufficient controls for just generally protecting privacy information or access to confidential or valuable information.
Examining the Role of Architecture
Using ITA(information technology architecture) design concepts and the documentation used to express IT design is the only approach to successfully bring existing or new applications, systems, or networks into the condition of having an "adequate internal control structure," quoting the phrase used by SOX in section 404.
Regardless of the source of the control criteria, be it internally or externally imposed, there is value in using a systematic approach to the overall design of the security controls. ITA is a disciplined process that provides the method and defines the documentation necessary for successful technology designs. All of the other architectures - data, technology, systems, or network - become subcomponents of the whole ITA approach. Sometimes the term enterprise architecture is used to define the "go to" or goal architecture. In reality, each of these subsets in an existing organization could have three architecture stages: the existing, transition, and target architectures.
The most important message is how to use the discipline of architecture as described in this book to organize and manage the design process whether you're designing from a blank slate or trying to fix a complex existing system. The process fits each of the architecture work areas from network design to data structures with only minor modification involving the required documentation.
Later in this book, the seven essential elements of the security matrix are defined as the framework encompassing security controls. This framework is important because it helps define the outside limits for the security controls design work. You'll explore some of the limitations inherent within each area of concern.
Several chapters center on using the architectural process to focus on all of the principles and design tasks necessary to deal effectively with identity, authentication, and access controls relating to protecting any categories of applications, information, or data. The role of directory services and meta-functionality is examined, and you'll see how they can be designed to work together to provide the basis for links between identity and access control.
Toward the end of the book, you'll look at the value present in federated identity schemes and how they might be treated, as well as potential risks in going too far with federated identity in light of SOX oversight. The end describes a vision of the future perfect world in which privacy and confidentiality boundaries are respected and enforced by design and digital credentials can be trusted.
Several appendixes provide useful information and guidance for the process.
Blending Science and Art
At a very fundamental level, Sarbanes-Oxley is calling for the genteel merging of the science of accounting and auditing with the science and art of information systems design. If there were no computers or calculation machines of any type, all of the SOX controls would be relegated to the physical world of locks and keys, combinations, paper trails, and security guards. Because computers and applications and Internet access are integrated into so much of what is done today in business and private lives, stepping up of the controls in the digital world is long past needed. It is easy to predict that SOX over time will prove to be just another in a long line of access control quality issues facing organizations. The time to meet the security controls challenge and lay the new digital control foundation is now.
That bridge to the design of desired state of access controls is what this book is about. The science and art of applying architecture principles will get you there.
Seeing the Whole Picture
Security controls must be dealt with in a complete context. You can't just check a box because you are using SSL to secure the data transmission and are requiring a user ID and password. Yes, those steps are necessary, but they're only two of many layers and dimensions that must be considered individually and collectively to achieve adequate control mechanisms over access and data. Applying a systematic method of ITA design principles and enforcement documentation is the way to succeed. The documents resulting from the ITA effort capture the requirements for the controls, provide the basis for implementation, facilitate operations and ongoing management, become input into any needed analysis or change process, and provide proof of due diligence during audits. When the ITA process relating to security controls is ongoing, it shows an expected level of due care.
Reaching a fundamental understanding of what ITA is and how to recognize it is necessary. Technology terms are often used inappropriately, creating confusion. This is often true of the use of the word architecture when applied in the context of IT. Some in the IT field, in sales pitches or design discussions, present something way less than architecture and call it architecture anyway. Others with a business operations focus or in management roles think they know what IT architecture is, although they cannot explain to you what it means to them or, more importantly, what benefits it can bring to their IT operations or in meeting the organization's business goals and objectives. What's often being passed off as architecture is more like IT confusion or a game of "my picture is better than your picture."
This book provides you with some valuable insights into what constitutes ITA. More important, it will help you learn how to systematize your thinking on the subject and become better able to properly document your organization's technology plans and designs. Using the process of ITA design for security controls will, within a short time period, help you and your organization achieve a bold and understandable architectural model for successfully designing for the currently critical security areas of identity management, access control, and authentication. The process provides a basis for creating adequate protection of private or protected information and data in your information systems designs and projects.
My own transition from a facilities management specialist working with hundreds of building architects and civil, mechanical, and electrical engineers on scores of construction projects over a 10-year period to an IT specialist made the concept of IT architecture easy to grasp but the details equally elusive. The effort and person-hours necessary to design and fully document an IT architecture supporting a complex heterogeneous enterprise scattered over a large geographical area with diverse lines of business and operational requirements is a daunting task. When it is divided into smaller building blocks or subcomponents, the job is much easier to envision and actually complete and implement during the build phase.
Document, Document, Document
Soon you'll see the documentation components required for successful ITA implementation of security controls in modern enterprises of all kinds that utilize computer information systems, networks, and data applications that do financial processing or house confidential information.
The order of doing the ITA design work is important. Just as buildings are rarely constructed from the roof down, when certain computer technology components are chosen that become foundations for follow-on components, the rest of the effort necessary for the design, documentation, and implementation all become easier to achieve within the overall systems environment one layer at a time. The foundation-first principle is truer in the technology field. There is a succession of thought that must follow a line of natural progression to develop the architecture from nothing for a new organization or from an "as-is" condition for one already invested with computer systems and applications to a new or desired vision state. The vision state or "to be" may also be called the target state or desired target or even target condition. You will see one path of this progression in Chapter 3 where the documentation process begins with business objectives and builds from there to successively include more detailed and often more complex documentation, each building on the documents that preceded its own development.
Seeing Caution Flags
All too often a CEO or CIO allows a single contractor or a mix of vendors to quickly decide what is in the best interest of the project or what best meets the company's needs in a given area of technology. This is as understandable as it is pitiful. The principal cause for this situation is the time pressure to get it done right now, which frequently gets in the way of getting it done right. Unfortunately, vendors rarely have time to sufficiently understand a client's business needs and are also reluctant to suggest a competing product as the best fit to solve a problem.
Companies on both sides of the contractor/contracting relationship rarely have sufficient time or all the in-house talent necessary to get every piece of the technology puzzle 100 percent correct in the specification or within the implementation process. "Correct" in this instance means performing to a standard as good as it can be, given the current technology available.
Shortcomings always exist in request-for-proposal specifications or in a project's management or within the implementation and delivery, hence the incredible forced popularity of the usually undesirable and expensive change-order process. Failure to apply a methodical design process is manifested in the worst situations where a technology consulting contract takes shape in only days or weeks and is given an expected delivery duration of 9 to 12 months, and after 3 years, the consultant still occupies a corner office. The company's comptroller is still writing or approving checks for cashing in a faraway bank. To add insult to injury, the original project scope is not finished yet and few if any of the original project deliverables perform as envisioned by the management group that first approved the project.
Excerpted from Security Controls for Sarbanes-Oxley Section 404 IT Compliance by Dennis C. Brewer Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.