Channel Strategies for the CIOWhat are the biggest challenges when auditing cloud-based services, particularly for the
solution providers?
One of the biggest issues is their lack of understanding of how the cloud differs from traditional
enterprise IT. They're learning as quickly as their customers are. Once they figure out what to ask
and potentially how to ask it, there is the issue surrounding, in many cases, the lack of
transparency on the part of the provider to be able to actually provide consistent answers across
different cloud providers, given the various delivery and deployment models in the cloud. How does
the cloud change the way a traditional audit would be carried out?
For the most part, a good amount of the questions that one would ask specifically surrounding the
infrastructure is abstracted and obfuscated. In many cases, a lot of the moving parts, especially
as they relate to the potential to being competitive differentiators for that particular provider,
are simply a black box into which operationally you're not really given a lot of visibility or
transparency.
If you were to host in a colocation provider, where you would typically take a box, the
operating system and the apps on top of it, you'd expect, given who controls what and who
administers what, to potentially see a lot more, as well as there to be a lot more standardization
of those deployed solutions, given the maturity of that space. How does it work exactly?
What we wanted to do is
Requires Free Membership to View
essentially keep it very simple, very lightweight and easy to implement
without cloud providers having to make a lot of programmatic changes. Although we're not
prescriptive about how they do it (because each operation is different), we expect them to figure
out how they're going to get the information into this namespace, which essentially looks like a
directory structure.
This kind of directory/namespace is really just an organized repository. We don't care what is contained within those directories: .pdf, text documents, links to other websites. It could be a .pdf of a SAS 70 report with a signature that refers back to the issuing governing body. It could be logs, it could be assertions such as firewall=true. The whole point here is to allow these providers to agree upon the common set of minimum requirements.
We have aligned the first set of compliance-driven namespaces to that of the Cloud Security Alliance's compliance control-mapping
tool. So the first five namespaces pretty much run the gamut of what you expect to see most folks
concentrating on in terms of compliance: PCI, HIPAA, COBIT, ISO 27002 and NIST
800-53...Essentially, we're looking at both starting with those five compliance frameworks, and
allowing cloud providers to set up generic infrastructure-focused type or operational type
namespaces also. So things that aren't specific to a compliance framework, but that you may find of
interest if you're a consumer, auditor, or provider. Who are the participants in CloudAudit?
We have both pretty much the largest cloud providers as well as virtualization platform and cloud
platform providers on the planet. We've got end users, auditors, system integrators. You can get
the list off of the CloudAudit website. There
are folks from CSC, Stratus, Akamai, Microsoft, VMware, Google, Amazon Web Services, Savvis,
Terrimark, Rackspace, etc. What are your short-term and long-term goals?
Short-term goals are those that we are already trucking toward: to get this utilized as a common
standard by which cloud providers, regardless of location -- that could be internal private cloud
or could be public cloud -- essentially agree on the same set of standards by which consumers or
interested parties can pull for information.
In the long-term, we wish to be able to improve visibility and transparency, which will ultimately drive additional market opportunities because, for example, if you have various levels of authentication, anywhere from anonymous to system administrator to auditor to fully trusted third party, you can imagine there'll be a subset of anonymized information available that would actually allow a cloud broker or consumer to poll multiple cloud providers and actually make decisions based upon those assertions as to whether or not they want to do business with that cloud provider
…It gives you an opportunity to shop wisely and ultimately compares services or allow that to be
done in an automated fashion. And while CloudAudit does not seek to make an actual statement
regarding compliance, you will ultimately be provided with enough information to allow either
automated tools or at least auditors to get back to the business of auditing rather than data
collection. Because this data gathering can be automated, it means that instead of having a PCI
audit once every year, every 6 months, you can have it on a schedule that is much more temporal and
on-demand. What will solution providers and resellers be able to take from it? How is it to their
benefit to get involved?
The cloud service providers themselves, for the most part, are seeing this as a tremendous
opportunity to not only reduce cost, but also make this information more visible and available…The
reality is, in many cases, to be frank, folks that make a living auditing actually spend the
majority of their time in data collection rather than actually looking at and providing good,
actual risk management, risk assessment and/or true interpretation of the actual data. Now the
automation of that, whether it's done on a standard or ad-hoc basis, could clearly put a crimp in
their ability to collect revenues. So the whole point here is their "value-add" needs to be about
helping customers to actually manage risk appropriately vs. just kind of becoming harvesters of
information. It behooves them to make sure that the type of information being collected is in line
with the services they hope to produce. What needs to be done for this to become an industry
standard?
We've already written a normative spec that we hope to submit to the IETF. We have
cross-section representation across industry, we're building namespaces, specifications, and those
are not done in the dark. They're done with a direct contribution of the cloud providers
themselves, because they understand how important it is to get this information standardized.
Otherwise, you're going to be having ad-hoc comparisons done of services which may not portray your
actual security services capabilities or security posture accurately. We have a huge amount of
interest, a good amount of participation, and a lot of alliances that are already bubbling with
other cloud standards. Cloud computing changes the game for many security services, including
vulnerability management, penetration testing and data protection/encryption, not just audits. Is
the CloudAudit initiative a piece of a larger cloud security puzzle?
If anything, it's a light bulb in the darkness. For us, it's allowing these folks to adjust their
tools to be able to consume the data that's provided as part of the namespace within CloudAudit,
and then essentially in the same way, we suggest human auditors focus more on interpreting that
data rather than gathering it.
If gathering that data was unavailable to most of the vendors who would otherwise play in that space, due to either just that data not being presented or it being a violation of terms of service or acceptable use policy, the reality is that this is another way for these tool vendors to get back into the game, which is essentially then understanding the namespaces that we have, being able to modify their tools (which shouldn't take much, since it's already a standard-based protocol), and be able to interpret the namespaces to actually provide value with the data that we provide.
I think it's an overall piece here, but again we're really the conduit or the interface by which
some of these technologies need to adapt. Rather than doing a one-off by one-off basis for every
single cloud provider, you get a standardized interface. You only have to do it once. Where should
people go to get involved?
If people want to get involved, it's an open project. You can go to cloudaudit.org. There you'll
find links about us. There'll be a link to the farm. The farm itself is currently a Google group, which you can
sign up for and participate. We have calls every Monday, which are posted on the farm and tell you
how to connect. You can also replay the last of the many calls that we've had already as we record
them each time so that people have both the audio and visual versions of what we produce and how
we're going about this, and it's very transparent and very open and we enjoy people getting
involved. If you have something to add, please do.
 |
||||
|
|
|||
|
||||
How did CloudAudit come about?
I organized CloudAudit. We originally called it A6, which stands for Automated Audit Assertion
Assessment and Assurance API. And as it stands now, it's less in its first iteration about an API,
and more specifically just about a common namespace and interface by which you can use simple
protocols with good authentication to provide access to a lot of information that essentially can
be automated in ways that you can do all sorts of interesting things with.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation