|
|
|
Features
< Back
Sarbanes Oxley : Technology : Sarbanes Oxley
Reducing SOX Compliance Costs in the IBM Lotus Environment
By
Ian Smith
|
|
Ian Smith
President
Teamstudio
|
The IBM Lotus Notes/Domino platform does not lend itself easily to process automation or adherence to compliance standards, but new systems and techniques are now making that vision a reality.
The Sarbanes-Oxley Act (SOX) of 2002 brought the most dramatic changes to United States federal securities laws since the 1930s. Its impact on IT has been and continues to be enormous?requiring documentation and controls, not only of financial data, but also of the software that processes the data.
For many IBM Lotus Notes/Domino development organizations, SOX-related controls are manual and detective rather than automated and preventive. Not only have these processes added significant costs to the software development lifecycle, but they cost even more to audit, cause significant application deployment delays and place a drag on business operations. The time has come to reevaluate these processes and apply automation wherever possible in order to mitigate costs and provide the Lotus Notes platform with a robust, efficient and long-term solution.
What is the Sarbanes-Oxley Act?
By the late 1990s, a small natural gas supply company called Enron had evolved into the largest natural gas and electricity trading company in the world. Trouble hit in 2001, when Enron?s accounting discrepancies flooded the news. Wall Street reacted, and the company?s stock plummeted, costing investors billions of dollars. Tens of thousands of workers lost their jobs and life savings. Indictments and prison sentences followed.
It may seem like the U.S. government took special efforts to prosecute Enron, making them an example; but other companies, such as WorldCom, McKesson HBOC, HealthSouth, Rite Aid and Cr?dit Lyonnais faced similar scrutiny. Public outcry forced the legal system to focus on white-collar prosecution, to pierce the corporate veil on liability, holding executives accountable.
After a fierce spate of criminal investigations, U.S. Congress approved new legislation that covers corporate accounting standards and controls for publicly held corporations?the Sarbanes-Oxley Act (SOX) of 2002. By forcing publicly held corporations to account for financial data using auditable systems and processes, SOX has radically redesigned/changed the face of public company governance and reporting obligations. It also significantly tightens accountability standards for directors and officers, auditors, securities analysts and legal council.1
The Impact of SOX Today
Initially, organizations scrambled to meet the deadlines for meeting SOX compliance standards. Without the time to plan properly, organizations focused on tedious, manual methods of documentation using forms and logs, required signoffs and additional levels of oversight. As a result, auditing firms have gained a significant amount of manual, time and cost-intensive business; while the individuals working with data and systems have suffered an increased paperwork burden.
Although SOX is a financial legislation, the audits are designed to uncover an organization?s lack of structural internal controls at any level. A SOX compliance audit can identify whether or not control documentation is up to date, the lack or duplication of control activity, uncontrolled access to systems and security, and change management issues.2 For many organizations the typical response to an audit has been to implement systems that attempt to catch non-compliant activities after they have happened rather than prevent them from happening in the first place. So what preventive measures can organizations take to catch these non-compliant activities from the onset?
Achieving SOX Compliance
Documented processes and procedures can help a software development organization move toward compliance; but automated processes and procedures can provide significant relief from the burden of extensive paperwork. Within the realm of software development, there are many initiatives and programs such as ISO IEC 90003 and the CMMI (Capability Maturity Model Integration) that can help organizations increase controls, evaluate processes and procedures for automation, and remove potential obstacles to compliance.
ISO IEC 90003 - A Phased Process for the Software Development Environment
ISO IEC 90003 is the global quality management standard that explains how ISO 9001 2000 can be applied to software and related services. Applying initiatives such as ISO IEC 90003 to a software development environment is a phased process involving: 3
1. Identification of information assets
2. Documentation of policies and procedures
3. Tightening or adding policies or
procedures as required
During this process, organizations can identify key metrics that allow them to track improvements over time, with the goal of continuous improvement and the minimization or elimination of any human factors.
CMMI - A Layer Upon the Foundation for Continuous Process Improvement
Capability Maturity Model? Integration (CMMI) is a process improvement approach that can be used across a project, division or entire organization.
After applying CMMI, organizations can expect:
• Reduced systems integration and test time, with greater probability of success
• Improved integration of, and interaction among, the various engineering functions
• Extended SW-CMMI benefits to the total project and organization
• Deployed software development best-practices within software development4
Each CMMI level is a layer upon the foundation for continuous process improvement, beginning with basic management practices and progressing through a predefined and proven path of successive levels. Higher-level processes have a better chance of success when the lower levels have been firmly established.
Manual Versus Automated
When applying these types of systematic controls, software development organizations often uncover areas of operation that have achieved compliance through stop-gap, manual processes. However, compliance issues are still cropping up because of the nature of human involvement. Even seemingly benign human factors, such as attrition, absenteeism, fatigue and forgetfulness can significantly increase the risk of control issues. Manual processes slow down the core operations of a business. They are a costly way of achieving control, and even more costly to audit.
IT executives need to take a closer look at automating many of their processes to eliminate the human factor altogether. Automated controls are more reliable. They are easier to test and less likely to slow down core business operations. When processes are automated, control and auditing become a simple matter of reviewing audit metrics. And the management team can focus on defining the control systems and monitoring the automated processes for exceptions.
The IBM Lotus Notes/Domino Equation
When striving to achieve SOX compliance, organizations with IBM Lotus Notes/Domino applications quickly discover that they have a unique set of challenges. IT executives responsible for IBM Lotus Notes/Domino applications enjoy the benefits of rapid application development?fast implementation of application requirements. Yet because of the history and nature of Notes, many of the software development best practices found in traditional IT development environments are absent.
IBM Lotus/Notes Domino, originally released in 1989 as an easy-to use workflow and application creation environment, was by 1996, a full-blown development environment that included a scripting language as well as Java support. Notes power users became software developers by virtue of the technology that they were using; yet without the benefits of formal software development training and exposure to best practices.
When faced with a non-compliant IBM Lotus/Notes Domino development environment, IT executives may start investigating whether to keep or migrate their applications, only to discover that not only are these applications essential for business operations, but they are also extremely expensive to replace.
In order to satisfy a SOX audit, they often resort to numerous manual processes that are error-prone and largely incomplete?poorly documented processes leading to build errors, poorly documented and unmaintainable code, few checks and balances.
This situation is untenable. Organizations need to build compliance into their systems?not inspect it in a haphazard, error-prone manner. The quick fix has proven to be rather expensive. A long term solution is needed that guarantees compliance and the absence of human errors. What is needed is process automation.
Automating Compliance in Notes: The Challenge
So how can software development best practices and standards such as ISO IEC 90003 be applied to the IBM Lotus Notes/Domino development environment?
How can IT organizations gain tighter control, promote process automation and ensure SOX compliance?
When proceeding through an ISO IEC 90003 initiative, Notes/Domino development organizations need to consider automating as many of their processes as possible; with the application build process, asset and security control and configuration management as likely candidates. The ultimate aim is a fully automated asset management system.
Build Processes are Typically Manual
A well designed build process for Notes/Domino applications can help organizations achieve increased efficiency, repeatability, segregation of duties and control. Automating features such as build time code analysis and application security settings will promote error-free builds, internal controls and audit compliance.
In the Notes environment, however, the build process is typically manual, making it slow and error-prone. A number of different individuals are usually responsible for builds, or several departments are required to participate in the process. The Notes environment does not lend itself to the separation of duties: the person performing the build must access both the development and the production servers.
Accurate Usage Statistics are Not Easy to Obtain
Notes applications, because they so are so easy to deploy, are often located in more than one department within a company. Using formal auditing services, it is possible to identify:
• Existing assets
• Application/templates that are being used
• Condition of applications
• Which applications to keep/save/migrate
Once they have been identified the most heavily used applications, can be more efficiently allocated across server resources, without additional hardware expenditures. By removing unused applications, hardware requirements can even be reduced, back up time and administration overhead minimized and user response time improved.
However, with Notes/Domino, there is no reliable way to tell what applications are being used either by users or other applications. The consequences of getting it wrong could be dramatic, considering that many Notes applications are mission-critical. The safe, practical approach has been to leave these applications in place. But this approach is wasteful in terms of server space, replication bandwidth and upgrade costs. The lack of control, however, is the biggest issue, especially during a SOX compliance audit.
Application Security Analysis and Enforcement is Time-Consuming and Manual
There are three key aspects to implementing a best practices application security system.
First, is the ability to gain a clear view of the security configuration at any point in time, with an added benefit being some form of automated reporting that is compatible with company or statutory reporting requirements. This reporting should highlight any anomalies or non-compliance.
Second is the facility to make wide scale security configuration changes efficiently and effectively. This is a key practical point when defining a security system that will work in the real world.
Last, the system should automatically enforce the chosen application security system and provide feedback and audit trails where there have been attempted breaches. While documenting these steps is essential, automating them will ensure regulatory compliance.
The main difficulty, however, in understanding and maintaining an effective overall Notes/Domino application security regime, is that tracking and analyzing individual settings is a manual process. Because it is manual, it requires a huge amount of detailed painstaking work, which is open to human error. The amount of cross-referencing required between different components of the security configuration (for example, between ACL listing and the Name & Address Book (NAB)) makes the task virtually impossible to perform manually in any reasonable timeframe. Often the result is an overall application security regime that is almost impossible to understand and validate without the help of some kind of automated assistance.
Nothing in Notes makes wide scale security configuration changes possible. Notes? inherent flexibility in using groups and nested groups with varying ACL settings gives organizations permission to create convoluted, incomprehensible application access regimes where spotting and correcting anomalies manually is a nightmarish task.
There is also nothing in Notes that tracks when security settings have changed, who made the changes, or the current state of settings across all applications.
Configuration Management ? Source Code Control
Whether driven by external regulatory changes, internal audit concerns or a simple desire to work in an efficient and controlled manner, implementing a best practices source code control system in any Notes/Domino development environment is essential to software asset control.
A unique consideration of the Notes/Domino development environment is that a Notes database is physically a single file. Most configuration management systems manage code at the file level; so for a Notes project using one of these systems, only one developer is able to work on a database at a time.
The best solution is a configuration management system that tracks Notes applications at the element level and supports Notes-unique features such as template linking and dependencies.
The standard Domino development installation, however, provides no audit trail to allow traceability of code changes. It also offers no system of version control, which can cause practical day-to-day issues to development and admin teams. Developers lack the ability to easily roll back to previous known versions of the application, compounding the effects of finding a problem in production. Development teams cannot work efficiently on the same code base due to the risk of save conflicts and/or over-writing of each other?s work.
Conclusions: SOX is Not Going Away, IT Organizations Must Automate
Many public corporations, having experienced a few years of SOX compliance audits, have tried a piecemeal approach, using manual methods to correct errors such as documenting processes and procedures via forms and logs. But errors are still cropping up and the cost burden is too high. What is needed is process automation?to eliminate the potential of human error altogether, streamline operations and minimize the cost of implementing and auditing for compliance.
Eliminating the human factor in the IBM Lotus Notes/Domino development environment means automating as many key functions as possible?such as the application build process. This will increase efficiency, introduce repeatability, decrease costs and improve application quality.
Adding tighter controls means identifying existing assets, bringing those that are used inside a controlled asset management system and eliminating those that are not needed. An asset audit will help Notes/Domino organizations identify what databases and templates they have and use, allowing them to focus on mission-critical applications and eliminate the rest. Hardware resources can then be freed up, decreasing costs, increasing end-user access time and improving the efficiency of their operation. The risk of non-compliance is greatly reduced when the assets in use are well understood.
Tighter controls also mean taking a hard look at application security considerations. A security audit can help identify security risks and anomolies, allowing organizations to restrict and monitor access to key information, short-circuiting possible legal exposure. Organizations need to be able to perform wide scale security changes, efficiently and effectively; automate the enforcement of those changes, and obtain feedback and audit trails on attempted breaches.
A configuration management system that handles Notes-specific entities and methodologies is essential for a well-run development organization. Teams of developers will be able to access and change code, without stepping on each other?s toes. Reactive support issues will be reduced, as will maintenance costs. But more importantly, a formal change control process will provide demonstrable evidence to internal and external auditors of all changes.
SOX is not going away, and neither is the constant pressure on Boards of Directors to hit earnings targets, partly through cost control. Facing up to these twin realities is forcing many IT organizations to automate as much of their compliance as possible. While IBM Lotus Notes/Domino has not lent itself easily to compliance automation in the past, there are systems and techniques available now that can make this automation a reality.
1 www.cpeonline.com/cpenew/sarox.asp
2 ?The Real Value in Sarbanes-Oxley,? Kathleen Melymuka, ComputerWorld, April 10, 2006
3 http://praxiom.com/#ISO%2090003%20LIBRARY
4 http://www.sei.cmu.edu/cmmi/
|
|
|
|
