Summary of May 17th call
5 views
Skip to first unread message
Ben Sapiro
May 17, 2010, 9:56:58 PM5/17/10
to CloudAudit
Rough notes from today's call (I'm attributing based on notes but
thanks to everyone who said something) :
(Edward Haletky)
The provider response format needs to accommodate lazy behaviour,
specifically, flat files should be an acceptable response as would
XML.
Returning the http response of "200 OK" is not an effective way to
indicate that control exists - need a way to indicate that a control
is not applicable (versus a Yes or No). Therefore, the 200 response
indicates that the provider has a response for the control (it's been
considered) versus a 404 response indicates no response (the provider
did not consider this control).
Need a way to sign artifacts, flat file or otherwise, SHA2 or better.
Need a way to validate the signature (look at ANSI x.9.9.5), consider:
1) provider presents file via self-hosted namespace (e.g.
amazon.com/.well-known/cloudaudit/...) and public cert is accessible
2) cloudaudit.org is hosting a provider response but the system used
to generate the response elements (with the public cert) is not
accessible via the internet
3) a provider is using an artefact created by an upstream provider
(e.g. twitter relies on AWS)
Additional suggestions/Roadmappy things (maybe):
- Doug Barbin - A catalogue / index for aligning control categories
with control statements; the provider can specify which security
objectives they're trying to achieve and map to specific control
objectives
- Michael Versace (I think) - Add a backwards reference, for the
returned object, to the control framework that the artefact was
originally generated for.
(case 1) /iso/27002/v2005/1/2 --> blob --> /iso/27002/v2005/1/2
(case 2) /iso/27002/v2005/1/2 --> blob --> /org/pci/dss/v1.2/4/2/2
- a TTL for responses (one at the root of the control structure as a
default plus individual TTL's per control node)
Agreed outcomes:
Spec will have three levels of response:
1) Basic - flat file containing YES/NO/MAYBE
2) Partial - flat file artefact (e.g. a PDF file)
3) Complete - XML object containing metadata and URI to
The Partial response can only be used to return single artefacts, if a
provider wishes to return multiple supporting artefacts, the Complete
response must be used.
The response, in any level of completeness, can be accessed through
a .current link, potential format is:
.current <-- the response file - text, arbitrary file or XML (a file
implies a yes)
.current.sig <-- digital sig
.current.ttl <-- ttl for the particular response
Action items:
1) Michael Versace - to draft use cases for trust chains (in which
providers use or present artefacts that did not originate with them)
2) Ben and George to take group input and incorporate into draft spec
thanks to everyone who said something) :
(Edward Haletky)
The provider response format needs to accommodate lazy behaviour,
specifically, flat files should be an acceptable response as would
XML.
Returning the http response of "200 OK" is not an effective way to
indicate that control exists - need a way to indicate that a control
is not applicable (versus a Yes or No). Therefore, the 200 response
indicates that the provider has a response for the control (it's been
considered) versus a 404 response indicates no response (the provider
did not consider this control).
Need a way to sign artifacts, flat file or otherwise, SHA2 or better.
Need a way to validate the signature (look at ANSI x.9.9.5), consider:
1) provider presents file via self-hosted namespace (e.g.
amazon.com/.well-known/cloudaudit/...) and public cert is accessible
2) cloudaudit.org is hosting a provider response but the system used
to generate the response elements (with the public cert) is not
accessible via the internet
3) a provider is using an artefact created by an upstream provider
(e.g. twitter relies on AWS)
Additional suggestions/Roadmappy things (maybe):
- Doug Barbin - A catalogue / index for aligning control categories
with control statements; the provider can specify which security
objectives they're trying to achieve and map to specific control
objectives
- Michael Versace (I think) - Add a backwards reference, for the
returned object, to the control framework that the artefact was
originally generated for.
(case 1) /iso/27002/v2005/1/2 --> blob --> /iso/27002/v2005/1/2
(case 2) /iso/27002/v2005/1/2 --> blob --> /org/pci/dss/v1.2/4/2/2
- a TTL for responses (one at the root of the control structure as a
default plus individual TTL's per control node)
Agreed outcomes:
Spec will have three levels of response:
1) Basic - flat file containing YES/NO/MAYBE
2) Partial - flat file artefact (e.g. a PDF file)
3) Complete - XML object containing metadata and URI to
The Partial response can only be used to return single artefacts, if a
provider wishes to return multiple supporting artefacts, the Complete
response must be used.
The response, in any level of completeness, can be accessed through
a .current link, potential format is:
.current <-- the response file - text, arbitrary file or XML (a file
implies a yes)
.current.sig <-- digital sig
.current.ttl <-- ttl for the particular response
Action items:
1) Michael Versace - to draft use cases for trust chains (in which
providers use or present artefacts that did not originate with them)
2) Ben and George to take group input and incorporate into draft spec
versace
May 18, 2010, 8:55:37 AM5/18/10
to CloudAudit
Hi - here's a simple use case that might be useful in teasing out
chain of trust questions/designs. The use case "description" come
from content already submitted. I cut the text in here since I can't
post to the google doc's site (not open).
Description: Regulated cloud provider customer combines the on-prem
regulatory audit results with service provider audit results obtained
from cloud provider and cloud provider audit data aggregator (s)
Functional Areas: Internal IT Audit
Actors: Large scale enterprise (cloud customer), cloud service
provider (cloud provider), third party audit data aggregator
Preconditions: Cloud customer operates a business (products or
services) supported by internal applications and application services
hosted by multiple cloud providers. Cloud customer must provide an
opinion on the state of IT controls supporting the business.
Scenario
1. Cloud customer performs audit of internal IT and application
controls supporting the business (risk assessment, control
objectives, testing, testing results) covering the period Jan 2010
through June 2010
2. Cloud customer requests audit tests /inquiries from cloud providers
3. Cloud providers performs tests/inquiries a the request of customer
4. Cloud providers return audit results to cloud customer via third
party information aggregator
5. Cloud customer obtains audit tests/inquiry results via third party
information aggregator
6. Cloud customer combines internal and external audit inform to
prepare opinion on the state of controls
Chain of Custody Questions
Who owns the data (audit results from cloud provider)
Who is the custodian
How is CIA maintained over the audit results end-to-end (from the
cloud provider, to the third party aggregator, to the cloud customer)?
chain of trust questions/designs. The use case "description" come
from content already submitted. I cut the text in here since I can't
post to the google doc's site (not open).
Description: Regulated cloud provider customer combines the on-prem
regulatory audit results with service provider audit results obtained
from cloud provider and cloud provider audit data aggregator (s)
Functional Areas: Internal IT Audit
Actors: Large scale enterprise (cloud customer), cloud service
provider (cloud provider), third party audit data aggregator
Preconditions: Cloud customer operates a business (products or
services) supported by internal applications and application services
hosted by multiple cloud providers. Cloud customer must provide an
opinion on the state of IT controls supporting the business.
Scenario
1. Cloud customer performs audit of internal IT and application
controls supporting the business (risk assessment, control
objectives, testing, testing results) covering the period Jan 2010
through June 2010
2. Cloud customer requests audit tests /inquiries from cloud providers
3. Cloud providers performs tests/inquiries a the request of customer
4. Cloud providers return audit results to cloud customer via third
party information aggregator
5. Cloud customer obtains audit tests/inquiry results via third party
information aggregator
6. Cloud customer combines internal and external audit inform to
prepare opinion on the state of controls
Chain of Custody Questions
Who owns the data (audit results from cloud provider)
Who is the custodian
How is CIA maintained over the audit results end-to-end (from the
cloud provider, to the third party aggregator, to the cloud customer)?
versace
May 19, 2010, 11:16:38 AM5/19/10
to CloudAudit
Correction:
The ANSI standard for trusted time stamps is X9.95, Trusted Time
Stamps
Mike
The ANSI standard for trusted time stamps is X9.95, Trusted Time
Stamps
Mike
Reply all
Reply to author
Forward
0 new messages