In this chapter, we discussed that although your IT infrastructure may have been part of your normal year-end audit, the Sarbanes-Oxley experience promises to be quite different in terms of depth, cost, and resources. Since Sarbanes-Oxley requires all publicly held companies to prove compliance, it will affect virtually every person in your organization.
While we reserve the discussion of what Sarbanes-Oxley is specifically, we wanted to give you an idea of why this book was written and its intended audience. There are two main focuses on open source as it relates to the Sarbanes-Oxley discussion: first are those of you who have or are considering deploying open source in your IT organization; and second is to illustrate the some of many opportunities to make your life easier and reduce the amount your audit may cost in terms of resources and money by employing open source technologies to help in the monitoring, process, and documentation aspects regardless of your current IT landscape.
We hope this book is useful to many different people. Non-IT management will gain an over-arching understanding of how open source can help reduce their Sarbanes-Oxley costs and how open source fits into the picture. IT management will see how open source can assist with and automate the task of documenting and tracking compliance and internal controls, independent of whether they are derived from proprietary or open source systems, and understand the benefits gained from such an environment. IT/financial consultants will be able to use the tools and technologies on the Live CD as a valuable toolset to improve their clients' IT processes, and hopefully make their SOX compliance a less painful and costly experience. Finally, principals of nonpublic companies who might be considering an IPO can better understand some of the implications SOX will bring to the table, and get an idea of how open source can offset some of the requirements.
We finished the chapter with a look at the Live CD. The CD is based on the XFLD distribution, which was originally derived from the original Knoppix Live CD. We chose this particular distribution because of its low computer requirements. When the Live CD is running, nothing on your original setup is disturbed, because the program runs completely in memory. Since the running image is a virtual file system in memory, changes are not saved between reboots. However, if you want to save any changes, there is an option to save to USB pen drive, ZIP disk, or an available hard disk partition. Additionally, if you want to install the Live CD so it runs from a hard disk as a normal distribution, we provide the means to do that. The portal sites are an integral part of this book because they demonstrate the actual compliance process in real time with many examples of open source tools and applications you can use for your own compliance needs.
In this chapter, we discussed how Congress enacted the Sarbanes-Oxley Act of 2002 in an effort to prevent financial scandals such as those that occurred at Enron and MCI. We also discussed how although Congress had the best of intentions when they enacted the Sarbanes-Oxley Act of 2002; there are some fundamental issues with how the Act was drafted:
- No IT-specific wording for IT compliance
- Section 404 and 302 appear to overlap
- De facto standard for SOX (COBIT) does not scale based on a company's size
Based on the aforementioned issues, we established that small to medium-sized companies will face unique challenges in their effort to pursue compliance of Sarbanes-Oxley Act of 2002. Given the unique challenges with which small to medium-sized companies will have to contend, their ability to leverage SOX and position it with executive management will be critical to their success.
We continued by delving into how the Sarbanes-Oxley Act of 2002 and COBIT came to be synonymous, and how different standards exist, but COBIT has been most widely adopted by audit firms. From there, we learned the six components of COBIT and the four COBIT domains. We continued by drilling further down by defining an Entity Level, a Control Objective, and the difference between the two.
Building on the section on COBIT, we established that while the COBIT guidelines are good, standard operating procedures (SOPs) for an IT organization, it is impractical for any company to implement all of the COBIT guidelines as written. From there, we developed a fictitious company to demonstrate how, with planning and knowledge of an environment, the COBIT guidelines could be culled into something more doable and manageable.
In this chapter, we discussed the need for SOX compliance and the possible consequences of noncompliancelawsuits, negative publicity for the company, and fines for executive management. Although it's important to understand the consequences, it is paramount that you realize that with planning, knowledge, and a great deal of work, it is possible to comply with the Sarbanes-Oxley Act, even in a small company. To this extent, we looked at some applications and tools that are readily available to assist in compliance with the Sarbanes-Oxley Act. Regarding application and tools, it is imperative that you minimize the number of applications and tools you select, maximize their capabilities, and minimize overlap.
The remaining two areas we discussed were "The Human Factor" and "Walk the Talk." While perhaps not as interesting to IT people as the applications and tools discussion, it is just as vital that you evaluate and manage these items as they pertain to your environment. In "The Human Factor" section, we discussed reasons why employees, including IT staff, may not embrace the changes that SOX compliance may bring, and steps to try to effectively negate any resistance to change. Given the importance of change management, we re-emphasize these steps here:
- Overcommunicate to the IT staff what you are doing, what their roles are, and the consequences of failure.
- Get buy-in on the plan and what needs to be done.
- Wherever possible, delegate decisions to the IT staff.
- Bear in mind that change is a process, and usually a slow one.
- Retain responsibility for reaching the ultimate goal.
- Lead by example.
- If necessary, demonstrate any consequences with staff and user community.
Finally, we discussed "Walk the Talk," and the importance of the following:
- Keep your policies/procedures and or controls as simple as possible.
- You have to be to sustain whatever you implement.
- If you can't sustain it or won't, do not define it
In this chapter, we set aside the Sarbanes-Oxley discussion for a moment to investigate the entire open source phenomenon and the fundamental differences between it and nonfree software. After an examination of closed source development, we examined the open source methodology in some detail and articulated the tangible and intangible reasons why open source software can save you money and give you freedom of choice. Because of the rapid development cycle and the "release early, release often" mentality, the bar of quality and security is raised owing to massively parallel peer review of the source code. When a bug is identified by an end user, often he or she is a hacker who also supplies the fix, or at least a directed report on how to reliably reproduce the bug for the developer to test.
Linux Torvalds' "Given enough eyeballs, all bugs are shallow" theorem essentially states that someone, somewhere, will know the fix to a bug no matter how difficult it may seem to the original developer.
We continued by examining the use of open source in your environment. We learned that there are many opportunities for the use of OSS software, even if you are currently on a primarily Windows-based infrastructure, as most prominent open source software runs on diverse architectures, including Windows. This investigation was further refined by discussing the two main ways in which open source software fits into the SOX compliance equation, both as elements of your IT infrastructure and as support systems such as document control, system monitoring, workflow, and approval management. We also discussed some of the items you should consider if your environment is in a state of transition. One must be diligent to document and subject any changes to the same approval and testing mechanisms as those identified for internal controls procedures.
When evaluating your IT infrastructure, your internal controls universally fall into the categories of prevention and detection; however, all controls share some common characteristics and constraints. All controls must be testable; a well-defined test must be in place to validate the control. All control tests must be repeatable; the same test should yield the same result every time. All control tests should be sustainable; that is, they should enable you to maintain your controls and certification processes over time.
In conclusion, we introduced the sample companies that will be used as case studies for the remainder of the book to illustrate concrete examples of open source software deployment as the subject of certification, and the use of open source software in the compliance process. The sample companies demonstrate two completely different architectures; BuiltRight Construction is a small public company with an infrastructure based entirely on Microsoft Windows and other closed source technologies, and NuStuff Electronics is a medium-sized global organization with a mixed platform environment.
In this chapter, we discussed the difference between SOX and COBIT. We also discussed a basic process for developing IT strategic plans in an effort to comply with the Planning and Organization domain. Finally, we looked at some real-world examples of forms and processes used to comply with the Sarbanes-Oxley Act. In summarizing this chapter, there are three fundamental things you should take away with you:
- Let your unique organizational structure drive the applicable domain items.
- When developing processes, ensure that they follow a good quality methodology, such as PDCA (Plan, Do, Check, and Act).
- Above all, if you have existing processes that are good sound processes and are already ingrained within the organization,
customize and modify them to work within COBIT.
We also explored the definition and approval routing of your IT business policies, which form the core of your IT strategy and are the basis from which all procedures grow. Several policies are outlined as a representative set of items you will need to consider for SOX compliance. You can define or modify your own policies; we give you the details on how to accomplish this. You can also define or modify the policy approval workflow process if it does not suit your needs.
We also looked at the first concrete examples on the Live CD in the context of planning and organization. Once you have identified your controls as an organization, it is important to state this in a policy that can later be applied by implementing solutions later in the book that fulfill the requirements of your policies. In addition, we introduced the "approval" type of workflow, the first of many workflow categories we will explore in the remaining chapters. The approval workflow in this example demonstrates the ability to route specific versions of your policies to a chain of approval.
In this chapter, we discussed automation and why it should be a key component of any small to medium-sized company's Sarbanes-Oxley compliance activities. We also developed guidelines by which you can assess your in-house expertise as they relate to the skill sets that will be necessary to use open source tools. We also provided actions and alternatives for acquiring the necessary skill set if it does not currently exist within your organization.
Additionally, we looked at the various control objectives of the Acquisition and Implementation domain, and identified those that relate specifically to Sarbanes-Oxley compliance, using our fictitious company as an example. In summarizing this chapter, there are three fundamental things you should take away with you:
- Let your unique organizational structure drive the applicable domain items.
- Automation will be critical, but resist the urge to over implement.
- Use of good project management methodologies will better position your compliance effort for success.
The remainder of the chapter shows examples of automation, project planning, and tracking for the sample companies. BuiltRight construction has decided to redeploy a Web application to improve availability and security. The project consists of migrating an IIS Web server using ASP scripting and an Access database to an Apache server using PHP and a MySQL database. NuStuff Electronics has opted to augment its security infrastructure with an IDS. Snort has been selected as a network-based detection system, since it is the leading open source solution and there is copious documentation and several books written for its deployment. To leverage the hard work of the open source community, the NST Live Security CD will be deployed since it contains both the Snort IDS and a testing framework. These project examples are then put through the COBIT framework for approval, planning, and implementation, using the example workflow, project management, and documentation modules on the Live CD. The chapter closes with a discussion of additional example change management workflows where there might be special considerations, such as the need for additional activities on one side of the spectrum and the desire to simplify the generic change management workflow on the other, which ultimately demonstrates the flexibility of the system.
This chapter discussed the COBIT Delivery and Support Domain and why it is important, not only to SOX compliance activities, but also from an IT Department repositioning perspective. As part of this discussion, we identified the two biggest potential barriers to successfully executing the necessary control objectives identified in this chapter, which are:
- Given the number of IT resources, can these activities be sustained?
- Do we really need all of this bureaucracy?
We provided guidelines by which the control objectives in the COBIT Delivery and Support Domain can be minimized and customized.
Finally, we discussed what constitutes an SLA, what are the key elements of an SLA, and the importance of SLAs as they relate to this chapter and the third domain of COBIT. The key elements of SLAs are:
- SLA metrics levels should be driven by business objectives and meet user requirements, be agreed upon by the parties involved, and be attainable.
- Executive management should understand the correlation between IT funding and the ability to deliver agreed-upon services and service levels.
- SLAs matrices should have performance cushions to allow for recovery from breaches.
- To avoid user dissatisfaction, it is essential that the service levels defined are achievable and measurable.
- Service levels should be monitored, managed, and measured on a continual basis. Monitoring and alerting should be done in a proactive manner and should contain a performance cushion.
- All performance matrices should be included in the appropriate documentation and, if feasible, contain sign offs.
- Communication is essential. If a problem arises or an SLA cannot be met, proactive communication regarding the problem and a plan of action goes a long way in establishing credibility for your department.
We looked at security and what it means to SOX compliance. We began with a look at network security in the context of open source solutions such as firewalls, intrusion detection and prevention systems, and then took a brief look at network devices. We continued with Enterprise identity management and how it affects your ability to prove provide the three aspects of identity: authentication, authorization, and auditing. We looked at the various open source authentication systems such as LDAP and Kerberos, and took a brief look at Active Directory. Our security discussion continued with data and storage permissions and access controls, and we finished with a look at application security and a revisit of password policies.
Configuration management is an important aspect of SOX compliance as it relates to both security availability concerns. We discussed how open source tools such as Webmin, Kiwi Cattools, and CVS can help establish a baseline for configurations and manage changes in a controlled and structured environment, while capturing the necessary audit trail via logs.
We then took a brief look at storage backups and data retention, to give you some ideas on what you may need to consider. Although SOX does not explicitly define what a data retention policy should be, it is important from an audit perspective that you have a policy in place.
This chapter discussed Deming's continuous quality improvement process, specifically how it was predicated on a closed-loop process. It examined how the COBIT Guidelines have a surprising resemblance to Deming quality cycle. This resemblance should crystallize the point that if an IT Department has been following and implementing good sound quality practices all along, then they are already half-way to SOX compliance. Utilizing the Open Source tools listed in this chapter, should enable users to obtain the remaining practices required for SOX compliance.
The various control objectives of the "Monitoring Domain" were discussed, and the items that relate specifically to SOX compliance were illustrated in the context of the sample companies. We then looked at monitoring in practice and some of the Open Source tools that can be leveraged to meet your compliance goals. One important tool is Nagios, which is an enterprise-ready monitoring and escalation tool.
Others that can be useful are centralized dyslog (that can be scanned for security anomalies and system problems), Tripwire, AIDE, which can help establish a baseline of files on your critical systems and report any unauthorized changes, and Kiwi CatTools, which can monitor and manage changes made to the networking devices.
Monitoring is not limited to hosts and services; there are quite a few ongoing compliance objectives to meet and maintain over time. This is where compliance monitoring workflows can be of great assistance, as they remind you of important recurring compliance activities that you may need to perform, combined with review routing to make sure the proper management team keeps up with their requirements.
This chapter closed with a look at some of the samples provided on the enclosed CD, which includes working examples of Webmin and Nagios, as well as a complete tutorial on how to roll your own workflow processes by creating a simple "General IT Request" workflow.
This chapter discussed the how and what of repositioning an IT Department utilizing COBIT for SOX. We attempted to illustrate quality processes and the tie between Policies, Processes, and SLAs. As a subset of quality, we reviewed an example test plan and its components.
The following criteria are key elements that you should keep in mind when testing control objectives:
- Documented test plan
- Appropriate controls identity
- Appropriate test for control
- Selection of correct sample size
- Rational of sample size
- Method to capture test results
This chapter also discussed SOX and Open Source ROI, and why SOX does not lend itself to a traditional ROI format.
