As part of ISACA Series about cloud computing, we find the document "Security Considerations for Cloud Computing"  (link) with the objective of provide a practice guide and facilitate the decision process for IT and business professionals when taking the decision of moving to the cloud.

ISACA Security considerations for CCWe have thought that it could be interesting to analyze it because one of the main advantages of rating systems as the one proposed by leet is, precisely, facilitate this decision making. ISACA document is organized in four big chapters that collect, besides the explanation of the own document, a brief summary of what is cloud computing, a general vision of risks and threats related specifically with the cloud and, finally, the guide regarding how to evaluate cloud potential as answer for business needs (providing decision trees and checklists). We agree with ISACA that the key element is trustleet vision about how achieve it is radically different from ISACA proposal. While ISACA bet is act intrusively over cloud service providers operations (asking for comprehensive informations, performing audits, sensitive information disclosure, etc), leet bet is based in a model focused on outcomes, i.e., assuring the resilience of the vendor in the service provision. Starting by the coincidences in both postures:

  • We think the list of elements to consider to trust in our vendor is really right, because it is necessary to consider technical aspects, but also provider reliability.
  • We also think the phased approach for decision making that starts with the own company analysis about information / process criticality to take to the cloud. That is to say, not all travels to cloud are equal, each one has its particularities according to what is going to be taken to the cloud is right.
  • Decision trees are really useful to help to decide the type of service model (IaaS, PaaS or SaaS) and the deployment model (basically public versus private).
  • It is a right guess to consider as a positive risk the security improvement of SaaS providers, because being selling services their business, they have incentives to provide secure services (more than the cloud users).
  • Finally, we also fully agree in that the most difficult step is to find the service that better fits our company business need while minimizing the potential risk, i.e., match user and vendor risk profiles.

And, to end with this analysis, we list those aspects in which we disagree or we consider that the approach is not the correct one (to explain it, we will use power supply as simile to the service provision to resemble capacity or storage provision):

  • We do not think that it is necessary to know all the parts involved together with their physical location in the same way that we do not need to know all the parts involved in power generation and distribution. In any case, we will have to ask for assurance that third parties involved in our service provision do not pose a risk for our service conditions.
  • We think that formula of trust in vendors with tradition is simplistic, basically because this will close the doors to all new players and it will stop innovation. In fact, what we should do is to have mechanisms that help us to know if we can trust in a provider or not.
  • We neither think that vendor auditability permission is essential in the same way that we do not think in audit our power supply vendor. If what we are pursuing is assure control implementation, we should ask form independent audit by qualified staff and that these audits will be supervised by independent bodies. So, we think that security measures included in Appendix A are intrusives and unrealistics, because very few providers are going to disclosure all the information required by ISACA.

As a conclusion, we think that ISACA approach is very close to consider cloud computing as a kind of outsourcimg, when what cloud is doing is changing completely relations models and role players. In this way, we think that the approach should be the implementation of mechanisms that allows potential users, without a broad security knowledge of service and vendor, to easily know if the service offered fits the needs regarding risk profile. You can follow us on twitter.com/leet_security

You can follow us on twitter.com/leet_security

14 de diciembre de 2012