In the event that you've been doing that Rip van Winkle thing and haven't been paying attention to anything in
the world of business or finance for the past few years, there is a regulation called the Sarbanes-Oxley Act. It seeks to eliminate financial fraud (think WorldCom and Enron) by enforcing more regimented financial controls and adding significant accountability for CEOs and CFOs of publicly traded companies. The regulation is in full effect now, and even though there's still discussion about how strictly it will be enforced, it certainly cannot be ignored. In this tip, we'll discuss how compliance frameworks -- COSO and COBIT, and ISO 27001 to a lesser extent -- can be applied to SOX compliance efforts.
COSO & SOX: Start at the highest level
Now, to be clear, SOX is actually meant to be a guideline for the reporting of financial data with reliability and integrity. That's not necessarily an IT security function, but as with most high-profile business initiatives, significant security components are needed to ensure an organization is SOX-compliant. Given that there haven't been many highly publicized SOX enforcement actions to date, how can corporations know what to do and how much is enough?
Like most legislation, SOX is pretty nebulous about the business requirements that need to be met in order to be considered SOX-compliant. The fine folks at the Treadway Commission published a framework called COSO to improve the quality of financial reporting back in 1992 when Sarbanes and Oxley were wee Congressional pups (well, sort of). The COSO framework was updated in 2004 to reflect the changed reality of the world. To break it down further, COSO consists of eight different components:
None of those components mention firewalls or IPS devices, do they? Not even encryption, so how should a security practitioner translate such a wide-ranging, business-oriented framework like COSO into useful SOX compliance advice? In response, the folks at IT Governance Institute and ISACA were kind enough to define a list of governance control practices that help to define a structure for IT governance The resulting COBIT framework is an IT-specific governance framework designed to help translate business risk into actions for the technical folks.
The reality is most organizations looked to solve the SOX "problem" like every other problem out there, i.e. buy a product and the problem goes away, right? Well, not by a long shot. COSO and COBIT offer controls and processes that, when assembled, can provide a measure of reliability and integrity for financial controls. They are not products that can be bought, and unfortunately, there is no easy way to get them. An organization needs to figure out what is faulty -- process, technology, etc. -- and fix it.
To clarify a bit more, COSO is used by the finance group to build their business processes and associated controls. Once again, COSO is NOT IT-specific. COBIT, on the other hand, takes many of the objectives of COSO and translates them into a language or framework that IT people can understand and work with.
COBIT & SOX: Apples and oranges?
Since most people like easy choices, the initial path of least resistance to SOX compliance (from an IT standpoint, anyway) is to be able to report specifically to the COBIT set of controls. The decade-old guidelines are a favorite among auditors because of their specificity and their regard for no particular platform. There are similar alternatives as well, including ISO 27001 or maybe even something ad hoc. Regardless of your organization's preference, a constant focus on security diligence -- as opposed to compliance "box-checking" -- will be effective in keeping auditors happy.
COBIT and ISO 27001 can help by providing accepted and somewhat widely used vernacular and structure to define how to communicate the controls that are probably already in place in your organization. Without that common structure, an enterprise runs the risk of having to educate an auditor on the breadth and depth of its specific framework; whereas going with a standard framework eliminates that.
But frameworks come and go, and the need for a strong set of controls is always there. I'm not big fan of throwing unnecessary and expensive software at the problem, but if I worked for a big company, I would look at mapping engines, also known as IT governance software. Security vendors including Archer Technologies, and ControlPath Inc., and broader offerings from vendors like OpenPages Inc. and consulting firm Paisley can ease the process mapping controls to the language and vernacular that auditors have come to know and love.
Corporations can also build their own control maps if they don't have the budget to buy a product. As with every other software category, these products offer a number of features you probably don't need, but I think the mapping capabilities are very helpful to keep a set of controls consistent over multiple regulations and frameworks.
So the reality is that COSO and COBIT -- and ISO 27001, for that matter -- are helpful in providing a map to solve the puzzle that is SOX. Not because they offer some silver bullet for compliance, rather because they offer a common language that all parties are likely to understand.
About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com's expert-in-residence on information security management. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at) securityincite (dot) com.