Challenging Security

Security standards, guidelines, recommendations and audit instructions seem to evolve from nowhere just like weed wherever you’d need it the least. And – to share the bad news first: There’s no way out, no way to avoid any new standard created – at least not as soon as anybody in the field decided to adopt it. You’ll be second best instantly.

“The nice thing about standards is that you have so many to choose from”

says Andrew Tannenbaum.

I dived into security standards recently and got pretty bugged by the standards to choose from, hence, started to note things down in a structured manner and – well — dumped it here to re-find it (and to get your thoughts on it, to be honest … )

Some slight differences to know

There’s (security) standards, (security) reporting standards and (security) attestation standards.

ISO 27001 – oftenly quoted a “data center security standard” – is actually a process and control definition for information security matters in organizations dealing with information in the broadest possible sense. ISO27000.org  names it a “specification for an ISMS” (Information Security Management System). Actually it is the only real standard dealing with information security as such.

SOC (“Service Organization Control”) – e.g. – is a reporting standard specifying how an organization or a certified public accountant (CPA) would issue reports according to common other (security control) standards such as SSAE16 or AT Section 101.

Having said that, it is further important to understand that – e.g. – SAS70 (deprecated) or its replacement SSAE16 describe a standard for attesting controls at service organizations. In other words, these standards set the guidance for assessment on (a set of) controls which shall serve the purpose for an organization to adhere to (security – but not only security) regulations, both financially and technically.

Finally: By ensuring compliancy with the respective standard as well as reporting on the respective compliancy the organization at the same time proves (to itself as well as to customers) that it adheres to the standard, hence has and keeps a respective level of security and (technical or financial) compliancy.

It is a matter of fact – unfortunately, if I may say – that ensuring compliancy as well as reporting this ensurement follows myriads of guidelines and policies and Cloud/SaaS providers will most probably need a bunch of analgesics to get rid of their headaches again

I’ll gonna provide an analgesics starter package in the next few lines …:

Attestation Standards

SSAE16 – Statement on Standards for Attestation Engagements No. 16

• replaces SAS70
• is issued by the American Institute of Certified Public Accountants (AICPA)
• has an international equivalent – the International Standard on Assurance Engagements – ISAE 3402
• is a framework
• requires service organization to provide a description of their system to control financial transactions
• plus(!) a written assertion by management of the organization (which as a significant addon to the former SAS70)

A good summary on SSAE16 can be found here. Overview on ISAE 3402 is provided here.

AT Section 101

To put it very simple, AT Section 101 adds additional guidance to service organization outside the area of financial controls. Having said that, AT Section 101 actually creates value for customers when assessing their chosen service organization towards its capability and compliancy in the areas of

• Security
• Availability
• Processing Integrity
• Confidentiality
• Privacy

The SSAE16 resource guide provides a comprehensible explanation of AT Section 101 here.

Trust Services Pricinples – in addition to AT Section 101 – describe the above principles in more detail. Comprehensible one-liners of these principles can be found here.

No question, there’s more. I wouldn’t have talked of a “myriads” otherwise; however, let’s keep it with those being most commonly talked about at the moment (please, do drop a comment if you feel, I’m missing one in this respect)

CSA CCM

The Cloud Security Alliance Cloud Control Matrix (CSA CCM) provides an addition to the before mentioned relating to information security tailored to the cloud industry. It is becoming increasingly common to add attestation according this standard to SOC 2 reports (see e.g. the Windows Azure Trust Center).

More on the CCM to find here

Reporting Standards

Let’s KISS – keep it simple and stupid: Recently what evolved to be THE reporting standard, is the (set of) Service Organization Control reports – or SOC reports. Their intention is to guide service organizations as well as certified public accountants (CPA) through how to compliantly report on a given standard.

SOC 1

• is used to issue reports in accordance to SSAE16
• can lead to SSAE16 Type 1 reports (reporting on the service organization’s control system itself)
• or SSAE16 Type 2 reports (reporting on management’s description of the service organization’s control system)

It has – according to SOC1 Reports and SSAE16 (at the ssae16.org webpages) – become common understanding, not to speak of a SOC1 report but rather of a SSAE16 Type 1 or SSAE16 Type 2 report.

BUT: SSAE16 Type 1 and/or Type 2 is simply not enough … because:

SOC 2

• is the standard to report on controls relevant to security, availability, processing integrity, confidentiality or privacy.
• is conducted in accordance to AT Section 101
• hence extends reporting of an organization’s control system on financial controls to those on the Trust Service Principles (see above).
• can be issued as Type 1 or Type 2 report in the same way as SOC 1

Fair to say, therefore, that an organization NOT issueing and providing a report according SOC2 may not be claimed compliant with security constraints necessary for Cloud/SaaS provisioning.

SOC 3

is an addition for SOC 2 in accordance with the Trust Service Principles (see above). Scope of any SOC 3 based assurance engagement is essentially defined by the 5 Trust Service Principles (Security, Availability, Process Integrity, Confidentiality and Privacy) as stated further above.

SOC 3 in essence comes into place when neither SOC 1 nor SOC 2 nor additional security standards such as payment card regulations (PCI DSS or HIPAA Privacy Regulations) or the like are considered appropriate.

Finally: SarbOx

And why all that?

In 2002 – after facing significantly serious loss of trust with service organizations out of well-known bankruptcies and control system breakdowns – the US Congress passed the Sarbanes-Oxley Act into a law.

SarbOx – aka: SOX, SOA (what an unfortunate abbreviation!) or simply “the Act” – requires management’s certification over their financial results as well as management’s assertion on the effectiveness of an organization’s control system. Thus said, it somehow forms the basis for all evolved standards in the respective area. If interested in that even more boring (yet: important!) aspect of security, check out this -> http://ssae16.com/SSAE16_SOX404.html

So, truth is: There’s no way out

Having only walked through all the high level definitions of the mentioned standards and at the same time having understood the importance that analysts – and customers respectively – pose towards service organizations to assert their internal control system successfully, I reckon that there’s quite a way to go if you intend to become a trusted Cloud provider. So, actually there’s good news only for those, who’ve already started pathing their security way …

Related articles

• Nexcess Successfully Completes SSAE-16 SOC 1 Type 2 Examination (prweb.com)
• Prolexic Successfully Completes SOC 1 and SOC 2 Examinations – Demonstrates Controls Relevant to Security, Confidentiality, Financial Reporting and Data Security (prweb.com)
• Ignition Strives For ESSAE & ISAE Accreditation (bernews.com)
• Prolexic Successfully Completes SOC 1 and SOC 2 Examinations -… (prweb.com)
• Atlantic Metro Completes SSAE 16 SOC 1 Type II Audit (hispanicbusiness.com)
• Asure Software Achieves SSAE 16 (SOC 1) Type II Certification (hispanicbusiness.com)
• Compliance Site on the Windows Azure Trust Center
• List os AWS Compliance Assurance Programs