Much has beenwritten aboutSarbanes-

Oxley (SOX) in thelast few months. Butin this article, I amgoing to take a con-trarian’s approach. I am veryconcerned that some organiza-tions may be seeking ways toappear to be in compliance withSOX from an information tech-nology standpoint when in reali-ty they are not.

The legislation is very clear.IT controls are required, andsignificant IT control issuesmust be disclosed. I am in com-plete agreement with this disclo-sure requirement, as I believe itwill result in stronger controlsand a more secure businessenvironment.

SOX MEANS BUSINESS

For years, IT auditors andsecurity managers identified sig-nificant control weaknesses. Yetmanagement chose not toaddress them. With SOX inplace, significant issues not onlyare being identified, but they arebeing resolved! From a publicrelations standpoint, it is far bet-ter to protect the data properly

than it is to admit that there areserious control issues in theSOX disclosures.

That’s why I am very con-cerned that some organizationsmay not be forthright in theirSOX reporting. And I’ve seensome worrying things. Forexample, we recently received aproposal to conduct a SOX secu-rity test. The test would be limit-ed to specific machines that con-tain financial information. Therewere very specific rules ofengagement. We could only testthe prespecified machines. Wewere not permitted to attempt toescalate access to the adminis-trator or root level if we gaineduser access. Also, if we found away to gain direct administrator-type access using an exploit ordefault passwords, we were notpermitted to perform the test.Any issues we identified wouldbe disclosed at the completion ofthe preliminary audit. We wouldreturn after the IT folks had timeto correct the issues. However,

only items that werenot corrected would beincluded in our auditreport.

This proposed test-ing had several flaws.The prohibition against

gaining administrative rightsprevents the audit team fromassessing the security on themachines. Without these rights,we cannot test the security set-tings, which can include theaccount, audit, and passwordpolicies. In the UNIX environ-ment, we cannot determine ifroot-protected trust relationshipsexist that could compromisesecurity, or if there are otherweaknesses that could enablefinancial data to be altered or,even worse, deleted. Administra-tive rights are necessary to gainthe encrypted passwords in theWindows environment and theshadow password file in theUNIX environment. Passwordstrength cannot be tested unlessthe audit team has access to therequired files.

These test restrictions turnedthe audit into a sham, in myhumble opinion. Limiting testssolely to the machines that con-tain SOX-related data does notenable the audit team to test for

The author, an IT auditing expert, warns that somecompanies may be looking for ways to appear tobe in compliance—when they really are not.

© 2004 Canaudit, Inc.

Gordon Smith

Sarbanes-Oxley: Compliance or Sham?

featu

reartic

le

3© 2004 Canaudit, Inc.Published online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/jcaf.20048

network-wide vulnerabilities thathave a negative impact on SOX-related machines and applicationdata. For instance, if the teamcould gain administrative accesson a poorly secured Windowsmachine, we could downloadand crack the password file.Using these compromisedaccounts and passwords, we maybe able to access the machinescontaining SOX-related data.

If executives are going tosign off on the internal controlstructure, then they should havethe knowledge they need to doso. This information should notbe skewed or altered in any way.Only a complete and unrestrictedtest can provide the assur-ance they need to complywith the legislation. Wechose not to bid on the job,given the constraintsplaced upon the audit teamby the potential client.Independence is an essen-tial component of our auditphilosophy. Without it, we can-not and will not perform an auditor security review.

The question that now mustbe resolved is, why would theclient want to skew the test?Well, the answer is in Section302 of the SOX legislation. Thissection requires that the CEOand CFO certify that the finan-cial statements and disclosuresare fairly presented. A violationoccurs if the CFO or CEO know-ingly and intentionally certifiesstatements that they should notcertify. If the audit does notidentify any serious issues, thenthe CFO and CEO will not knowof any reportable internal controlissues. They can sign the state-ments in good faith. Since theywould not know that the test wasskewed, they really did nothingwrong—at least, that will be thespin released by the public rela-tions person after a serious SOX

violation is discovered. I believethat limiting testing to ensurethat serious issues cannot be dis-covered may not be illegal, but itdoes violate the spirit of SOX.

EXECUTIVE MANAGEMENTRELIES ON THE SOX AUDIT

Your executives want assur-ance that all financial data areproperly protected. They are theones signing on the bottom lineand it is their bonuses that are atrisk should there be a restate-ment. I believe it is important toensure that SOX testing is boththorough and independent. Theexecutives want to know if there

are serious issues and, moreimportantly, they will want anyissues corrected or mitigatedprior to the issuance of thefinancial statements and therequired certifications.

Unfortunately, there may bepolitical reasons for others towant to influence the testing. Ifexecutive management has beenassured that the required con-trols are in place, they will besurprised to find serious controlissues. They will question thosewho gave them false assur-ances. It is highly likely thatthey will want the person whomisled them terminated imme-diately. Some managers believethat there will never be a prob-lem at their organization.Therefore, they are willing totake the risk for their own per-sonal and political gain. Theseindividuals will issue instruc-tions to control the test, thereby

ensuring that no serious issuesare discovered. The cover-upwill be sustained until a seriouscomputer incident occurs and isreported on the front page ofthe Wall Street Journal.

HOW CAN I DETERMINE IF THESOX TEST IS COMPROMISED?

The first place I look is inthe disclosure section of theaudit report. Any restrictionsplaced on the audit will normallybe stated here. You should alsocheck the original request forproposal (RFP) that was sent topotential bidders. Normally, theproject scope and any constraints

will be documented in theRFP. Often vendors areasked to submit any ques-tions they have in writing.You should check the ques-tions and the answers todetermine if any audit limi-tations are detailed in theanswers to the questions.

The testing performed willbe explained if the report wasprepared by a reputable firm.Testing should encompass fulloperating system and networktests of the machines containingSOX-related data. Identifyingcontrols through the interviewprocess is convenient but doesnot confirm that the control isactually in place. Each machinerequired to be protected for SOXpurposes must be tested toensure that it is properly hard-ened and that all required con-trols are in place.

WE HAVE TOO MANY ISSUES TOCORRECT—WHAT DO WE DO?

There could be some majorissues in your network that can-not be fixed before the statementsmust be issued. In that case, thereare several solutions. The first isto thoroughly test the machines to

4 The Journal of Corporate Accounting & Finance

© 2004 Wiley Periodicals, Inc.

Your executives want assurance thatall financial data are properlyprotected.

identify those with significantcontrol issues. Missing requiredpatches and poor password con-trol are the most common issues.Other items, such as legacy soft-ware issues, are more complexand may not be correctable in theshort term. Once the testing iscomplete, identify those itemsthat have a high SOX impact yetare inexpensive to correct. Theseshould be corrected right away.Items that have a high SOXimpact and are expensive to cor-rect may be handled differently.For instance, if a legacy softwareapplication would need to bereplaced at a cost of $50 millionand would take several years tocomplete, obviously it cannot becorrected prior to releasing theSOX reporting.

We suggest that other con-trols be used to protect themachines that cannot otherwisebe protected prior to the issuanceof the SOX report. One tech-nique we recommend is to placethese machines into one or twonetwork subnets. They can bephysically located in any securefacility; however, logically theyare clustered into one subnet.Once these machines are clus-tered in the required subnets,they can be protected with afirewall, switch, or router usingaccess control lists (ACLs).These lists limit access to those

who need access to the machinesto perform their business func-tions. Clustering users intogroups facilitates this process.The example I used aboveenables the installation of astrong control to prevent unau-thorized access.

A secondary control is alsorequired. Since we know theoperating system or applicationis soft from a control standpoint,we can add in a honeypot todetect when the network seg-ment containing SOX-relatedmachines is under attack. Wesuggest the use of Back OfficerFriendly, a free shareware prod-uct, for this purpose. You candownload a copy of this toolfrom the Canaudit Web site(http://www.canaudit.com). Byusing these two simple tech-niques, you will have protectedthe poorly controlled machinesand will know if someone is try-ing to attack them. When anattack is detected, intrusion-inci-dent mitigation and investigationprocedures should be invoked.

PROTECTING SOX MACHINES

There are many ways to pro-tect SOX machines. The aboveexample was just one method ofdealing with machines that can-not readily be secured. There areother techniques that can also be

used to improve control whileseeking a better and more per-manent solution. It is better toinstall a control to mitigate theissue than limit SOX testing.Corporate executives and theBoard need to know the trueextent of internal control and theweaknesses. This will enablethem to fully understand theneed for enhanced controls andthe funding required to properlyprotect financial information.They will fund longer-termremediation projects, providedthey understand the full extent ofthe security issues.

In closing, I want to empha-size that the “don’t test/don’tknow” philosophy will eventual-ly backfire. One day, there willbe a computer incident. When itdoes, the executives are going tohave egg on their faces for sign-ing the SOX disclosure. Theymay even have to pay back theirbonuses. At that point, you canbe sure they will be looking forthose who deceived them intobelieving that controls were“adequate.” I believe it would befar better to tell the executivesand Board now that there areissues, we have a short-term mit-igation plan, and we are seekingfunding for a mid- and long-termremediation plan. Not only is ittruthful, but it is also soundbusiness practice.

September/October 2004 5

© 2004 Wiley Periodicals, Inc.

Gordon Smith is president of the consulting firm Canaudit, Inc. (Simi Valley, California).