Archive for August, 2011

Would You Open This File?

August 26, 2011 Leave a comment

The screen shot below is purportedly an image of the actual email used to launch the zero day attack against RSA, thereby compromising their SecurID algorithm, allowing the bad guys to get into US defense contractors.

screenshot of RSA email

The full story of how the file was eventually found within RSA’s email and malware repository can be viewed here.

Would you open the attachment? Those of us in the security and controls world would probably have picked up on the poor grammar, the unexpected nature and title of the attachment and figured out that this was some kind of attempted compromise and just deleted the email.  Others would likely have assumed that the email was intended for someone else and opened it out of curiosity, thereby giving the bad guys a way in.

I’m putting it out here because it drives home the point that when combating these kinds of attacks, the only real hope you have is the vigilance and knowledge of your own employees in being able to recognize the bogus emails and attachments.  That can only be effective if you spend the time and the money required to train your employees and train them often.

It takes a certain level of cynicism and suspicion to recognize these kinds of attacks.  Many people just don’t have enough of those two qualities and as a result, will open every email and every attachment sent to them.  The bad guys keep doing it because it works.

The author of the full article raises an interesting question: “Why does Excel support embedded Flash?”  Are there really that many Excel users that thought embedded Flash was a “must have” feature?  Was there anyone from the security team in the meeting where they decided it was a good idea?  What could possibly go wrong?  It’s just Flash?

Hopefully the malware providers are already working on an option to identify Excel spreadsheets with embedded Flash and issue a stern warning or prevent infection.   In the meantime, we have to rely on good old fashioned training to try and combat the compromise of our company systems.



Categories: Uncategorized

Why Data Centers don’t need SAS 70 or SSAE 16

August 23, 2011 2 comments

Most large Data Center and Colocation providers that have Fortune 500 customers have been providing SAS 70 reports for several years.  Now that SSAE 16 has been announced as the “replacement” for SAS 70, most all of them are undergoing SSAE 16 reviews.   You can check my prior blogs SAS 70 is Dead and SSAE 16 is the New SAS 70 for more on the history of how we got here and the fact that “the customer is always right”.

I am continually amazed by how adamant many auditors and IT controls people are about why a data center or colocation provider needs an SSAE 16 audit.  I agree that DCs provide certain fundamental general controls that may impact the systems that are maintained there.  But even those general controls do not constitute Internal Controls over Financial Reporting (ICFR) which is clearly a requirement for performing a SOC 1 (SSAE 16) review.  With few exceptions, DCs and colocation centers do not WANT to be able to alter the processing of their customer’s transactions and do everything in their power to avoid direct access with their systems.

So what exactly is ICFR?  The SEC are the overlords of Sarbanes-Oxley compliance and the purveyors of wisdom regarding ICFR.  They define ICFR as:

“A process designed by, or under the supervision of, the registrant’s principal executive and principal financial officers, or persons performing similar functions, and effected by the registrant’s board of directors, management and other personnel, to provide reasonable assurance regarding the reliability of financial reporting and the preparation of financial statements for external purposes in accordance with generally accepted accounting principles and includes those policies and procedures that:

(1) Pertain to the maintenance of records that in reasonable detail accurately and fairly reflect the transactions and dispositions of the assets of the registrant;

(2) Provide reasonable assurance that transactions are recorded as necessary to permit preparation of financial statements in accordance with generally accepted accounting principles, and that receipts and expenditures of the registrant are being made only in accordance with authorizations of management and directors of the registrant; and

(3) Provide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use or disposition of the registrant’s assets that could have a material effect on the financial statements.

Now that’s a very long definition but important to understand what ICFR is.  Several key phrases stand out in that definition noting policies and procedures that:

  • “Pertain to maintenance of records” – does a data center maintain records? No. A DC maintains an environment of physical security, environmental controls, and connectivity.  The user organization is responsible for maintaining the records.
  • “Provide reasonable assurance that transactions are recorded as necessary” – Does a DC provide assurance?  No, the user organization does that.
  • “Provide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use or disposition of … assets” – Does a DC provide this assurance?  No, not unless they are providing managed services in addition to basic data center services.

So where is the link to ICFR?  When examining the types of controls that a typical DC or colo facility provides, there is no relevant link to ICFR.

“So Barton, are you saying that user organizations shouldn’t be concerned with controls at their third party colo or DC?”  Absolutely not.  I am saying that a SOC 1 SSAE 16 report is not the right answer for a colo or DC.  The more appropriate SOC report would be a SOC 2 report.

SAS 70 (and subsequently SSAE 16) were never meant to be a report on IT general controls.  They became popular for DCs and colos because auditors didn’t know of any alternatives to SAS 70 for understanding controls at service organizations.   Now that the AICPA is promoting SOC 2 as an alternative to SAS 70 for understanding IT general controls, there is no reason for a DC or colo to undergo an SSAE 16 review.

For most DCs and colos, the services provided are no different from those provided by the building management companies for large office buildings throughout the country.  Building management companies lease space.  That space includes physical security and environmental controls.  They don’t typically provide connectivity but there may be some that do.  DCs and colos lease space that includes physical security, environmental controls, and connectivity.  Those services do not constitute ICFR under the SEC definition.

So don’t ask your DC or colo provider to give you an SSAE 16 report.  Instead, look into an alternative like the SOC 2 or SOC 3 report to get an understanding of the IT General Controls they provide.