CloudAudit simple assertions

[Sam Johnston]

Evening all,

Per the call, let's try to enumerate the "simple assertions" we're going to want to support. First thing's first we'll include the compliance packs:

• COBIT
• HIPAA
• ISO27002
• NIST800-53
• PCI

I would add to that list things like:

• SAS-70 (optionally with controls?)
• Safe Harbo[u]r
• SSA16(?)
• FDA
• CFATS (anti-terrorism w/ IT infra)
• EU Privacy Directive
• SOX
• FIPS-*
• NIST-*
• Others?

As for the requirements:

• Clients should need nothing more than a single HTTP HEAD to test for the assertion*
• Absolutely NO JSON or XML parsers — we don't need discoverability for a small, constrained list that can go inline in the spec or a registry[1]
• Absolutely NO server-side configuration — we want this to be very simple to deploy (often it will end up on marketing websites hosted by 3rd parties who can handle nothing more than a ZIP file containing static HTML)
• In some cases it may make sense to do a HTTP GET — for example, where an auditor supplied a PDF/ODF/DOC/etc. certificate
• Some formats (PDF/ODF/DOC/etc.) support inline signatures
• We may also want to support out-of-band signatures, for example:
• digsigs stored alongside the file at a well known location (e.g. thing.sig)
• digsigs in Atom
• relying on SSL tunnel (or that of the auditor themselves via a redirect — things get hairy here)

I think that's about it, but the main thing is I think it's critically important that we support these simple assertions if we're to get mainstream adoption (especially with large providers). Chris's suggestion to put it under a cloudaudit.org or cloudaudit.net namespace could be a good way to integrate rather than reinventing the wheel.

Cheers,

Sam

* if you're paying attention you'd be about to point out that some web servers (incorrectly) return 200 OK for every request, including 404's. To test for this unusual use case clients SHOULD retrieve a URL guaranteed not to exist — e.g. /.well-known/cloudaudit/__DOESNOTEXIST__

1. http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html

[Lewis Brodnax]

Sam,

 

I’d suggest adding FFEIC, GLBA, HITECH/HITRUST, FTC/FACTA Red Flag, and FISMA. Any thoughts from the group on applicability of Business Continuity standards/compliance? In particular I’m thinking of PS-Prep here which includes your choice of ASIS SPC.1-2009, BS-25999-2:2007, or NFPA 1600(2007/2010).

 

Regards,

 

Lewis

[Douglas Egan]

May I suggest integrating the following as well:
• European Network and Information Security Agency (ENISA) Cloud Computing Benefits, risks and recommendations
• Cloud Security Alliance (CSA) guidance
• NIST Special Publication (SP) 800-144 Guidelines on Security and Privacy in Public Cloud Computing
• SP 800-125 Guide to Security for Full Virtualization Technologies

Cheers,
Doug Egan

From:	Lewis Brodnax <lbro...@williamsgarcia.com>
To:	"cloud...@googlegroups.com" <cloud...@googlegroups.com>
Date:	06/20/2011 03:17 PM
Subject:	RE: CloudAudit simple assertions

---

[ciana...@gmail.com]

Please add isae being international standard alongwith with eu directive
Sent from my iPhone

On 21/06/2011, at 6:15, Lewis Brodnax <lbro...@williamsgarcia.com> wrote:

> incorrectly

[James Blake]

I'd like to see some of the CESG Good Practice Guides (GPGs) that aren't controlled.  I don't know if anyone else has mentioned it, but I get asked about compliance to GAPP too.

Jimmy

[Hoff]

Doug:

The "CSA guidance" is already supported via the CSA namespace
mappings...

/Hoff

On Jun 20, 3:41 pm, Douglas Egan <deg...@csc.com> wrote:
> May I suggest integrating the following as well:
> • European Network and Information Security Agency (ENISA) Cloud Computing
> Benefits, risks and recommendations
> • Cloud Security Alliance (CSA) guidance
> • NIST Special Publication (SP) 800-144 Guidelines on Security and Privacy
> in Public Cloud Computing
> • SP 800-125 Guide to Security for Full Virtualization Technologies
>
> Cheers,
> Doug Egan
>
> From:
> Lewis Brodnax <lbrod...@williamsgarcia.com>
> To:
> "cloud...@googlegroups.com" <cloud...@googlegroups.com>
> Date:
> 06/20/2011 03:17 PM
> Subject:
> RE: CloudAudit simple assertions
>

[Hoff]

IMPORTANT CLARIFICATION:

The discussion today was NOT meant to imply adding support for
additional full namespaces.

Rather, the point was to be able to create a "CloudAudit" namespace
that allowed one to ask atomic queries
regarding a summary assertion as to support for a particular "thing"
such as asking if a provider is:

- PCI Complaint
- SoX Compliant
- ...has barbed-wire fencing

...things that aren't necessarily called out within a namespace but
are otherwise the summary state of assertion/attestation
related to a corpus.

What seems to be bubbling up here in the comments -- and I may be
misinterpreting -- is people asking for additional full
namespace support. This is a CSA CCM decision.

Again, I could be misinterpreting what people are asking for, but I
just want to be clear.

/Hoff

On Jun 20, 1:39 pm, Sam Johnston <s...@samj.net> wrote:
> Evening all,
>
> Per the call, let's try to enumerate the "simple assertions" we're going to
> want to support. First thing's first we'll include the compliance packs:
>

>    - COBIT
>    - HIPAA
>    - ISO27002
>    - NIST800-53
>    - PCI

>
> I would add to that list things like:
>

>    - SAS-70 (optionally with controls?)
>    - Safe Harbo[u]r
>    - SSA16(?)
>    - FDA
>    - CFATS (anti-terrorism w/ IT infra)
>    - EU Privacy Directive
>    - SOX
>    - FIPS-*
>    - NIST-*
>    - Others?
>
> As for the requirements:
>
>    - Clients should need nothing more than a single HTTP HEAD to test for
>    the assertion*
>       - Absolutely NO JSON or XML parsers — we don't need discoverability

>       for a small, constrained list that can go inline in the spec or a
>       registry[1]

>       - Absolutely NO server-side configuration — we want this to be very

>       simple to deploy (often it will end up on marketing websites
> hosted by 3rd
>       parties who can handle nothing more than a ZIP file containing
> static HTML)

>    - In some cases it may make sense to do a HTTP GET — for example, where

>    an auditor supplied a PDF/ODF/DOC/etc. certificate

>       - Some formats (PDF/ODF/DOC/etc.) support inline signatures
>    - We may also want to support out-of-band signatures, for example:
>       - digsigs stored alongside the file at a well known location (e.g.
>       thing.sig)
>       - digsigs in Atom
>       - relying on SSL tunnel (or that of the auditor themselves via a

[Robert Brenis]

I would suggest the AICPA's Trust Services Principles, Criteria and Illustrations.  This is the replacement to the SAS 70 (it is being referred to as SOC1, SOC2 or SOC3).  SOC2 and SOC3 are specifically IT control audits:

 

The verbiage from the AICPA specifically states:

This section provides guidance to a practitioner providing attestation services, advisory services, or both that address IT-enabled systems including electronic commerce (e-commerce) systemsfn 1 and privacy programs. The guidance is relevant when providing services with respect to system security, availability, processing integrity, confidentiality, and privacy.

I am happy to provide more information for thos that need it.

 

Thanks,

Robert Brenis

[saundra kae rubel]

Hi

If you re going to make it INTL you just add

CA PIPEDA

Japan JPIPA

Australia and Nez Zealand laws...

see all relevant ones at https://www.privacyassociation.org/knowledge_center/data_protection_authorities/

sorry it is a big list, but they are almost all different in some way

Saundra Kae Rubel

Sr Security Engineer CRISC, CIPP, CIPP/G, CIPP/IT, CHP, CHSS, CCSK

[Anton Chuvakin]

> Per the call, let's try to enumerate the "simple assertions" we're going to
> want to support. First thing's first we'll include the compliance packs:

> PCI

On a semi-related note, can we also address the issues of "supporting
documentation" for each assertion? I am dealing with some PCI in the
cloud scenario now, where the true extent of assertions and control
sharing can only be clear with A LOT of such supporting docs. I almost
feel like that if we focus too much on assertions and lose focus on
supporting docs, the result would not be as useful...

For many CO-** controls, supporting docs might include dozens of
documents (e.g CO-02)

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106

[Christofer Hoff]

I dont understand your point, Anton, as currently CloudAudit provides exactly what you are

asking about -- the collection & presentation of supporting documentation.

See this as an example:

https://cloud.enstratus.com/.well-known/cloudaudit/

This is the CSA namespace only, but each control in the namespace can contain any

amount/type of supporting artifacts.

Did I miss your point?

hoff

[Anton Chuvakin]

> This is the CSA namespace only, but each control in the namespace can
> contain any
> amount/type of supporting artifacts.
> Did I miss your point?

Kinda of. I am well aware of the fact that there is a nice placeholder
for "Supporting Documents" - however, when was the last time you met
anybody who actually knew what to put in there? My question was about
what kind of supporting docs we should advise people to use.

I am thinking of this as of PCI SAQ questionnaire where you can
potentially attach/include evidence, but in many cases nothing or
random crap is included... I'd rather we don't make the same mistake
here and develop clear guidance on WHAT supporting docs/materials/etc
should be acceptable.

[Christofer Hoff]

Ah, the "let's be prescriptive about how to answer questions surrounding compliance" quandary.

It's simply not possible to require specific answers and specific formats as to what people could/should place

in the namespaces. No two audit responses are alike. 

The answer to you question is a much deeper one than CloudAudit can answer, and we're not in the business

of re-defining guidance that the compliance frameworks themselves can't/don't/won't.

The namespace isn't a "placeholder" in some mystical sense -- it's the container in which the CSP places

artifacts that help satisfy their claims.  I *totally* get your point and when we started we investigated being

more prescriptive about content and formats, but *MAN* this is a delicate problem.

Again, this thread needs to stay on track...we discussed and decided more than a year ago with input from

auditors, QSA's, CSPs and customers that we should proceed in this manner until/unless a better approach

surfaces...

Perhaps you'll want to bring this up to CSA management (re: the actual content of the namespaces) which 

is orthogonal to the namespaces themselves.

/Hoff

[Anton Chuvakin]

> The answer to you question is a much deeper one than CloudAudit can answer,
> and we're not in the business

I *TOTALLY* get your answer and I understand the underlying reasons as
well. Still, I feel like we should take an extra step, albeit small.

Regarding a better approach, how about going 1(one) step further and making:
a) an example that was found to be useful and acceptable inn at least 1 case
b) a type of entry acceptable as evidence: document, product screen
shot, handwritten note from somebody :-), etc, etc

I think the above the make CloudAudit much more useful, usable and -
yes! - even more trustworthy.

Otherwise, I am AFRAID that it will be [ab-]used as "Amazon = PCI-OK"
kinda manner....

[Sam Johnston]

A few basic "recommended" mime types like csv, pdf, odf, etc. may help here.

Sam

[Anton Chuvakin]

> A few basic "recommended" mime types like csv, pdf, odf, etc. may help here.

Yes indeed. Or even: "a document with policy", "an image of data flow", etc

--

[Christofer Hoff]

I don't think - based on your "PCI=yes" example - that we're in synch.

TODAY, CloudAudit does NOT provide for assertions such as "PCI=yes." That's actually what Sam's "simple" use case is lobbying for. That's what we are discussing here.

What CloudAudit DOES do today is require the CSP to place all the supporting documents/artifacts to allow someone to substantiate such a claim. That's what you seem to be asking for with one addition:

Adding suggestions/MIME types for documents...

...which is fine. However, people may place arbitrary formats also.

Is that more clear? I was concerned that what you were suggesting we don't do actually is (without prescriptive formats) what we do...

Did I misunderstand?

Hoff

--
Sent from my mobile so please forgive any fat-fingering...

Blog: www.rationalsurvivability.com/blog

[Anton Chuvakin]

> I don't think - based on your "PCI=yes" example - that we're in synch.

Ah, well, that was an analogy, not a statement what CloudAudit does:
the point of it was that "assertion without details" is not that
useful. And also "asking for details without providing a DETAILED
request" is not useful on top of the above.

> What CloudAudit DOES do today is require the CSP to place all the supporting documents/artifacts to allow
>someone to substantiate such a claim. That's what you seem to be asking for with one addition:

Yes, I realize that. I just want us to make 1-2 small steps towards
clarifying that "all the supporting documents/artifacts" means in each
case.

--

[versace]

I think statements like PCI=yes and the same plus details are
valuable, sometimes to the same audience and sometime to different
audiences. We saw this in the set of use cases developed some time
ago.

I've missed calls so not sure which u/c is being discussed. Will try
for the next call.