In their haste to become compliant, organizations often apply bandage solutions to their IT infrastructure. Unfortunately,...
this approach may leave your organization supporting costly legacy hardware and older software applications that do not provide competitive advantages and may need to be replaced as compliance requirements increase. If your organization is an SMB benefiting from the extended SOX deadline, now is a good opportunity to assess your compliance efforts and renew your effort to get it done right the first time.
The U.S. government extended the SOX Section 404 compliance deadline from July 2006 to the eligible company's first fiscal year ending on or after July 15, 2007. Eligible companies are those whose public float is less than $75 million. With this extra time on their side, information security practitioners should ask themselves: Where would your compliance effort be if the deadline were not extended to July 2007? If your answer is "fully compliant," then great -- your work is done! Or is it really? The earlier deadline may have forced your organization to take a short cut or "bandage" approach that may have met the first round of compliance objectives but may leave your systems lacking the competitive advantages that may be obtained from a more thorough or "replace" approach. Consider if you would have taken a different approach to compliance if you knew the deadline was going to be extended. If so, it is time to stop for a moment and assess the current progress of your efforts and to evaluate if this is the right time to alter your course in light of the time extension.
Essentially all compliance criteria points to a principle of IT control granularity that is capable of linking any one person or digital identity to any single piece of data; or the converse, to deny access rights to all others. Group and role access control models still present value, but only for data access where fixing individual responsibility is irrelevant. Take advantage of the SOX deadline extension to architect your systems so that you have the capability to not only control any data element within a database, but so that you can also select at will which individual users do and do not have rights to add, change, modify or delete a single piece of data. Then add to this level of control the ability to log and audit who created or accessed the data and made any changes, and exactly when they did. Finally, you should be able to extend this principle of complete access control to every identified IT asset in your organization, from laptop to network, to all applications and to privileges within the applications. In all likelihood, a bandage approach will not achieve this goal.
A comprehensive approach where all of the principles of an architectural design process are applied is the only way I know of to achieve adequate compliance success. For example, covering over legacy applications with additional branches of access control lists does not eliminate any underlying weaknesses that are present within the access controls of the application nor will it substantially improve the ability to audit who made changes to the data. Accept the fact that a comprehensive analysis of the weaknesses in your company's existing systems and applications may lead to a need for completely replacing the underlying application technology. Replacing dated programs and using modern database applications that interact well with LDAP directories and interface with identity management and identity provisioning technology may be the only path to compliance over the long run.
Each fundamental element of security (identified below in italics) must manifest itself in the controls design to reach the bar of being called adequate not only for this audit cycle, but every one to follow. An assessment must identify all, not just some, of the data resources requiring access controls. The administrative processes cannot present weaknesses in the up-front vetting and identification of end users or allow slapdash management practices to weaken the security profiles inherent in the design. Once end-users and devices are identified, the design must include authentication means sufficient to keep out all but authorized users. And finally your audit capability should be able to recognize who entered or accessed the data or resource. Remember to apply defined access controls across all seven layers of the OSI networking model as well as to the applications, databases and individual data elements.
By taking advantage of this time extension with the provision to get it done right the first time, the potential exists to not only meet the requirements laid down by Sarbanes-Oxley but every existing and any foreseeable externally imposed quality criteria for access controls legislators and regulators may create. The opportunity to gain competitive advantage is knocking – again. Perhaps it is time to invite it in and get the most out of this time and the resources you're going to invest anyway.
About the Author
Dennis C. Brewer is the author of Security Controls for Sarbanes-Oxley Section 404 IT Compliance: Authorization, Authentication, and Access published by Wiley, and released October 10, 2005 available on www.Amazon.com, www.BarnesandNoble.com, or from your local book store. His resume includes a BSBA degree from Michigan Technological University, Novell Network Engineer Certification, and over a dozen years as an information technology specialist with the State of Michigan. He is retiring in from his position as an IT security solutions specialist in January of 2006 from the State of Michigan, Department of Information Technology, Office of Enterprise Security and will open a IT consulting practice in Laurium , Michigan.
Dig Deeper on Sarbanes-Oxley Act