Archive for July, 2011

Got Bots?

While I was at lunch today I happened to see a short video on CNN about a company (Unveillance) that provides Security as a Service relative to the identification of compromised computers (bots) in private and corporate networks. For all the time and money spent by organizations to install and update anti-malware on their networks, the real bad guys are using and sharing new techniques to compromise devices without triggering  anti-malware software.

A bot is geek-speak for a software version of a mechanical robot.  A botnet is a collection of compromised computers used for malicious purposes. 1  In most cases the compromised machines are used to collect information such as account numbers, user ids, passwords, etc.  This information is then automatically sent back to the Command & Control (C&C) server which is controlled by a botnet administrator.  They are sometimes used to distribute spam or to execute Distributed Denial of Service (DDoS) attacks against websites.  Because the attacks come from compromised machines it is difficult to trace these attacks to the person actually initiating and controlling the attack.

The CNN piece goes on to discuss the current threat level which Unveillance estimates at 6% of the total IP addresses globally. That translates to an astounding 240 million computers that may be compromised and controlled to some degree by the bad guys.  Since the techniques used to compromise machines are not detected by conventional anti-malware, the owners and operators of compromised machines typically don’t even know the machine has been compromised.  In most cases, the computer acts normally, but is recording keystrokes and copying data undetected in the background.

This news, while disturbing, is consistent with some of the conversations I had last Friday at the Atlanta Technology Summit.  Several security experts that I spoke with at the conference told horror stories of entire corporate networks being “pwned” (owned) by foreign governments or organized crime rings in the far east and eastern Europe.  Multiple attempts to “clean” these corporate networks have been initiated, but ultimately within a short time, the evidence of compromise resurfaces.

After listening to my colleagues at the Atlanta Technology Summit and seeing the CNN piece, I realized that most of the IT risk assessments I have done in recent years did not address this issue.  So what am I going to change as far as my methodology for performing risk assessments?  First, I will ask management what policies and training are in place to help reduce the risk of compromise.  Many of the machines get compromised as a result of a social engineering techniques that rely on a valid user clicking a link to an infected website or execution of a payload program imbedded in an email.  So how do you combat that kind of an attack?  The key is effective and frequent education and training.   You should also constantly look for ways to improve the effectiveness of your spam filtering and website traffic monitoring.

In some cases, awareness of the risk and vulnerability is the first step toward designing and implementing appropriate controls.  Unfortunately I don’t have the cure on this one, but it appears that Unveillance at least has a method for identifying the disease.

1 – Wikipedia – – July 2011


SSAE 16 is the new SAS 70? Not So Fast!

July 24, 2011 4 comments

As you know, the AICPA officially retired Statement on Auditing Standard number 70 (SAS 70) as of June 15, 2011. The AICPA has released three new standards for service organization audits. They are known as Service Organization Control (SOC) reports, more specifically SOC 1, SOC 2, and SOC 3. SOC 1 has published guidance, SSAE 16 associated with it. SSAE 16 is the “official replacement” for SAS 70.

Due to the timing  and publicity around SSAE 16, many organizations (and CPA firms for that matter) do not fully understand the differences between the three new SOC reports and when each report is most appropriate.  Instead, they assume that if a SAS 70 report had been issued in the past, then an SSAE 16 report should be issued after June 15, 2011.  Depending on the type of services being provided and the intended use of the report, an SSAE 16 report may not be the most appropriate choice.

Part of the reason the AICPA created the new standards was to attempt to rectify the misuse and abuse of SAS 70 reports.  In years past, many colocation facilities and data centers have been asked by their customers to provide them with a SAS 70 report.  In many cases, these data centers have nothing whatsoever to do with the processing of their customers transactions or the operation of the software they utilize.  They merely provide a physically, environmentally and logically secure environment for the computing equipment owned and operated by their customer.  They have little if anything to do with logical access controls, processing controls, change controls, or reporting of processing results.  They are not unlike the landlord of many office buildings that supply facilities, heating and cooling, and limited building security to businesses every day.

SAS 70 reports were intended to assist financial statement auditors in understanding the controls present at third party service organizations that were relevant to user entities financial statements.  Would it make sense for auditors to request a SAS 70 report from the landlord of the building where their client’s business resides?  No. And it doesn’t make sense for auditors and customers of a colocation facility to ask the colo to provide an SSAE 16 report.  Why?  My primary argument is that the services provided by the colo have very little impact on the customer’s controls over financial reporting.  But before you all go flaming me and bringing up Sarbanes-Oxley and IT General Controls, read my next argument.  My secondary argument is because there is now a better alternative to SSAE 16 and its predecessor SAS 70 for reporting on the ITGCs at a colocation facility.  It is the AICPA SOC2 and SOC3 report.

There are many readers that will disagree with my statement that the services provided by a colo have little impact on controls over financial reporting because Sarbanes-Oxley requires auditors to understand the IT General Controls (including environmental and physical) that support applications and systems that are relevant to financial statements.  I agree that it is important to understand these foundational controls.  However, the controls that matter most in systems that have relevance to financial reporting are not under the control of the data centers and colo providers.  Logical access controls, segregation of duties, program change, operations controls are normally the responsibility and domain of the customer, not the colo.  These controls are far more relevant to the ongoing control over financial reporting.  A locked facility with adequate environmental controls is important but does not have the same impact over financial reporting that good logical access, program change, and operations controls will have.

Wouldn’t it make more sense to have a standard set of ITGC  controls criteria so that every processing environment (i.e. data center, colocation facility, IT “closet”) could be graded on a standard scale?  Wouldn’t that make everyone’s life a little easier and provide better information for the auditors AND the customers?  Yes, it would. And the good news is that the AICPA has given us a working tool that is far superior to the wildly fluctuating quality and coverage of SSAE 16/SAS 70 reports.

SOC 2 and SOC 3 reports are based on the AICPA and CICA Trust Services Criteria.  The Trust Services Criteria are divided into 5 Principles: Security, Availability, Processing Integrity, Confidentiality, and Privacy.  Each of the five Principles contains a list of criteria that support that Principle.  For most data center and colocation service providers, an audit based on the Security and Availability Priniciples would provide ample evidence of the state of ITGCs applicable to whatever systems the customer is operating. Granted, once a service provider moves into the realm of Platform as a Service or Software as a Service, then you will likely have to add Processing Integrity criteria to the mix.  Confidentiality and Privacy could also be part of the scope of an audit based on the types of data being maintained and the industry or compliance requirements of the customer.

I will be the first to admit that the criteria currently published by the AICPA and CICA are not a silver bullet.  My initial impression is that the Principles and criteria are in some cases difficult to interpret and poorly organized.    But they are still a superior alternative to allowing every DC and colo to write their own criteria which is what happens with SAS 70 and SSAE 16 audits.

So before you request an SSAE 16 report from your client or service provider, take the time to understand SOC 2 and SOC 3.  I believe that for most data center and colocation providers, these new report offerings are a better alternative to SSAE 16 reports because there is a pre-defined set of controls criteria that we auditors will be using as a baseline for evaluation.  The best place to begin your education about SOC 2 and SOC 3 is the AICPA website:


Just as I Predicted……

July 20, 2011 7 comments

C7 Data Centers Completes SSAE 16 Certification — Colocation and IT infrastructure provider C7 Data Centers, Inc. (C7) today announced the completion of the SSAE 16 audit certification for its data center facilities. C7 is the first data center provider in the West to meet this new standard.

The link and press release summary above is just one of several in the last few weeks touting “SSAE 16 Certification”.  This one goes above and beyond by stating “The SSAE 16 defines all of the requirements applicable to data centers and other hosting providers.”  Really?  Having read the standard pretty much cover to cover, I don’t recall seeing ANY requirements applicable to data centers and other hosting providers.  SSAE stands for Statement on Standards for Attestation Engagements.  It is an ATTESTATION standard, not a data center standard.  It does NOT define requirements for data centers or any other type of business. And by the way, the data center provider in question didn’t meet the SSAE 16 standard.  Their auditor did, or at least attempted to.  More on that later.

The CEO of the company in question makes matters worse by stating “We are pleased to have met all requirements for the SSAE 16 certification (emphasis mine) for our data center facilities. Passing the SSAE 16 audit demonstrates C7’s commitment to our current and prospective customers. They can be confident that C7 is operating in a transparent and professional manner consistent with the highest control guidelines and standards in the data center industry.”

Passing an SSAE 16 audit merely demonstrates that the system description provided to (or developed by) their audit firm of choice was accurate and complete and that the controls they described (again not based on any written standard for data centers or otherwise) were described accurately.  Note that the article does not specify if this was a Type I or a Type II report.  Based on the level of hyperbole utilized in this release, I’m betting it was a Type I report.  If that is accurate, then passing the audit merely means that the independent accounting firm that produced the report agreed that the design of the controls that C7 presented to the auditors was adequate.  No testing as to whether they were actually working as described would have been conducted.   In fact, the opinion letter would include something like, “Our responsibility is to express an opinion on the fairness of the presentation of the description and on the suitability of the design of the controls to achieve the related control objectives stated in the description, based on our examination.”

In other words, based on what you told us, the design of the controls is suitable.  Nothing more, nothing less.

Now, about their auditor.  The new SSAE 16 standard is very clear that these reports “focus solely on controls at a service organization that are likely to be relevant to an audit of a user entity’s financial statements.”  So the question becomes, what relevance does a colocation provider’s services have to the financial statements of their customers?  The obvious answer is little or none.  So why did their auditors agree to perform the SSAE 16 audit in the first place?  The short answer is “Because the customer is always right”.

Look back at my prior blog entry to see that my predictions are coming true already.  Sometimes I hate being right.