CloudAudit and Atom
G. Hussain Chinoy
- Architecture and utilization of atom protocol/format as a signaling mechanism for cloud audit events
- Atom and digital signatures (see RFC 5023 15.5)
- Utilizing Atom for attestation
- Extensions as necessary to Atom
Ramon Codina
Ray Kaplan
hear any of the discussion about Atom.
As I understand it, Atom is going to the the underlying mechanism for
communications between "principals" (to borrow a term) in the Cloud
Audit System.
A few things:
- In my experience, attestation is something that an auditor does
based on evidence gathered. This is not anything that Atom can do.
Atom (and extensions) is a communications protocol.
Right?
- I propose that what we are building are methods of communicating
between principals in the cloud audit ecosystem. These include
assertion mechanisms, query mechanisms, signaling mechanisms, etc.
Assertion mechanisms are needed for principals to assert their
conformance to a part of a standard, guideline, or best practice.
Query mechanisms are needed to query the assertions of principals.
Signaling are needed to alert principals when a change in a
principal's assertions has occurred. Etc.
Right?
For instance, and accordingly, a cloud service provider might assert
their conformance with a specific part(s) of a standard, or guideline
or best practice by using atom to communicate this to client, or a
potential client.
"Conformance" rather than "compliance" since compliance implies some
enforcement authority, etc. So, you say that your systems(s) are
conformant to PCI until a QSA attests to that. Then, you can say that
your system(s) are PCI compliant.
We are apparently going to have to adapt all manner of other terms
from other disciplines. For instance, what do we call a user who is
relying on an assertion made by a principal? A "relying party?" Then,
the principal that is making assertions is an "asserting party?" Etc.
Would seem to me that other groups must have been working on systems
that are similar to what we are building. In this, they must have
developed methods, systems, protocols, and terminology. Someone must
have published the details of such things and possibly already
reduced this to practice. I certainly have seen such things and
fiddled with doing such systems form myself.
Either that, or what we are building here that is (cringe) patentable
as the first ever system like this that has been reduced to practice.
For the sake of a better name, let's call this the Cloud Audit System
for want of a different name. Chris, what is your name for what we
are building?
Yours in research...
RayK
At 6:54 PM +0200 4/18/11, Ramon Codina wrote:
That's all right Hussain
Thanks FYI.
2011/4/18 G. Hussain Chinoy <<mailto:ghch...@gmail.com>ghch...@gmail.com>
Hoff, et al.,
Please correct me if there's anything I'm missing - a summary of
CloudAudit & Atom assistance needed from the last call
Architecture and utilization of atom protocol/format as a signaling
mechanism for cloud audit events
Atom and digital signatures (see
<http://tools.ietf.org/html/rfc5023#page-38>RFC 5023 15.5)
Hoff
On Apr 18, 11:47 pm, Ray Kaplan <r...@rayk.com> wrote:
> My apologies, I missed a good part of the call today so I did not
> hear any of the discussion about Atom.
>
> As I understand it, Atom is going to the the underlying mechanism for
> communications between "principals" (to borrow a term) in the Cloud
> Audit System.
>
> A few things:
>
> - In my experience, attestation is something that an auditor does
> based on evidence gathered. This is not anything that Atom can do.
> Atom (and extensions) is a communications protocol.
>
> Right?
mechanism we're using to
ultimately render the artifacts offered by the Cloud Provider.
HTTP(S) is the transport protocol
leveraging HTTP and XML. The only element that represents
"attestation" is the capability to
leverage the timestamps and digital signatures to assert integrity and
version control.
>
> - I propose that what we are building are methods of communicating
> between principals in the cloud audit ecosystem. These include
> assertion mechanisms, query mechanisms, signaling mechanisms, etc.
> Assertion mechanisms are needed for principals to assert their
> conformance to a part of a standard, guideline, or best practice.
> Query mechanisms are needed to query the assertions of principals.
> Signaling are needed to alert principals when a change in a
> principal's assertions has occurred. Etc.
>
> Right?
enable
a consumer (or principal in your terms) to query a provider and
retrieve information
offered specific to a compliance framework. We already have the
"query mechanisms"
defined and working (over HTTP via a web browser or tool like Archer)
and we'd like
to leverage ATOM to provide change notification.
>
> For instance, and accordingly, a cloud service provider might assert
> their conformance with a specific part(s) of a standard, or guideline
> or best practice by using atom to communicate this to client, or a
> potential client.
>
> "Conformance" rather than "compliance" since compliance implies some
> enforcement authority, etc. So, you say that your systems(s) are
> conformant to PCI until a QSA attests to that. Then, you can say that
> your system(s) are PCI compliant.
>
does not
assert 'compliance' or ever 'conformance.' It offers a standardized
way of organizing
artifacts that will be used by a consumer (auditor, as an example) to
make decisions
on things like compliance/conformance...
> We are apparently going to have to adapt all manner of other terms
> from other disciplines. For instance, what do we call a user who is
> relying on an assertion made by a principal? A "relying party?" Then,
> the principal that is making assertions is an "asserting party?" Etc.
>
'role' of
the consumer of data can be varied....
> Would seem to me that other groups must have been working on systems
> that are similar to what we are building. In this, they must have
> developed methods, systems, protocols, and terminology. Someone must
> have published the details of such things and possibly already
> reduced this to practice. I certainly have seen such things and
> fiddled with doing such systems form myself.
>
> Either that, or what we are building here that is (cringe) patentable
> as the first ever system like this that has been reduced to practice.
>
> For the sake of a better name, let's call this the Cloud Audit System
> for want of a different name. Chris, what is your name for what we
> are building?
>
> Yours in research...
>
> RayK
The protocol
uses HTTP and ATOM -- standards based mechanisms. What's "unique" is
the mapping
of the namespaces to the CSA CCM. We can extend and utilize OTHER
protocols and/or
methodologies in addition to the "transport" and "namespace"
capabilities of CloudAudit.
For example, we plan to provide deeper synergies with CSC's Cloud
Trust Protocol which
utilizes SCAP.
In short, I was waiting for a punchline...not sure I got saw one?
We don't have any issues with "... methods, systems, protocols, and
terminology." What
we need is to simply leverage the additional capabilities of ATOM to
complete our roadmap
work.
Am I confused by what you're raising?
/Hoff