Security is a Holistic Proposition

Gorka Sadowski

Subscribe to Gorka Sadowski: eMailAlertsEmail Alerts
Get Gorka Sadowski: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Daisy Chaining Clouds, how transitive is Trust?

So we talked about some of the challenges - and hence opportunities - faced by Cloud Providers.  Last time we talked about Trust, and how important Trust is for business relationships.

Trust is already difficult in pretty straightforward environments, but in the context of Clouds, it can become very fuzzy...   Read on.

Clouds: Providers, Clients, Partners and Competitors... all at the same time!

We could imagine a world where there are so many cloud providers, so many interconnections between them and so many trust relationships that end-client duties are performed by different cloud providers based on the time of the day, the type and complexity of the task or any other criteria.

This means that a Cloud Provider can be both provider and client.

We could even envision that some Cloud Providers can be both partners as well as competitors. In fact, it is not uncommon for business entities to collaborate on some projects and compete on others. So are these Cloud Providers friendly partners or are they enemies?

In the following diagram, Client A1 uses B1 and B2 as a SaaS Software as a Service provider.  B1 uses C1 and C2 as PaaS Platform as a Service provider. And C1 uses D1 and D2 as IaaS Infrastructure as a Service provider.

Client A1 and Client A2 are competitors.  Cloud Providers B1 and C2 also are competitors, although C2 provides service to B1.

How would it be possible for all of these entities to collaborate despite requirements for secrecy in a climate of suspicion?


Figure 4 - The layered structure of subcontracting within Cloud Providers.

Inter-Layer Relationship

In the figure below we can see a logical diagram of a Cloud Provider (Layer N) and its interactions to neighboring layers, layers N-1 and N+1.


Figure 5 - High-level view on the operations of a Cloud Provider

At any layer within this hierarchical view, a provider (Layer N) accepts requests for a specific service to be rendered, either from an end-client or from another Cloud Provider.

The Layer N uses internal computing resources to perform this service (Local Processing, Processes A-F), and can even subcontract some or all of the required computing resources to a layer below (Layer N+1).  In this case, it requests to Layer N+1 a service to be performed. Upon receiving the result back from the subcontracting (N+1) layer, and combining it with its own processing, it will finally deliver the final result to the originally requesting Layer (N-1).

Please trust me.

If you (Layer N) trust your provider (your Layer N+1), who trusts its provider (your Layer N+2), do you trust your Layer N+2 also?

Not necessarily...

Trust is transitive in nature, but the more degrees of separation, the more trust relationships fade away.

And although there is implicit trust between you and your Layer N+2, explicit trust would be better. Why exactly does your provider (your Layer N+ 1) trust its provider (your Layer N+2)? And are these reasons shareable?  If your Layer N+2 gives your Layer N+1 permission to share these reasons with you, and if for you these reasons are sufficient, then you just went from implicit trust to explicit trust.

You can now decide to trust or not trust your Layer N+2, it is an informed decision that you are making.

So, in this environment, what is the information that needs to be exchanged between these different layers to enable effective collaboration while protecting trade secrets from potential competitors?

Verifiable reports based on actual logs.

Sure, it is not easy to define what reports will be required to build confidence and foster trust while protecting intellectual property and trade secrets.  These reports need to describe and demonstrate usage and performance of computing subsystems, yet should not go so deep that it becomes obvious to understand precisely how these computing subtasks are defined.

There is a difference between the actual raw logs that are collected and managed, with the higher-level view of the reports.

Logs will allow for a very precise understanding and visibility into the "how", and higher-level reports will provide the level of transparency required for Trust, SLA, usage and performance measurement.

Next time we'll look at some Critical Success Factors required as basis for Log Management solutions.

More Stories By Gorka Sadowski

Gorka is a natural born entrepreneur with a deep understanding of Technology, IT Security and how these create value in the Marketplace. He is today offering innovative European startups the opportunity to benefit from the Silicon Valley ecosystem accelerators. Gorka spent the last 20 years initiating, building and growing businesses that provide technology solutions to the Industry. From General Manager Spain, Italy and Portugal for LogLogic, defining Next Generation Log Management and Security Forensics, to Director Unisys France, bringing Cloud Security service offerings to the market, from Director of Emerging Technologies at NetScreen, defining Next Generation Firewall, to Director of Performance Engineering at INS, removing WAN and Internet bottlenecks, Gorka has always been involved in innovative Technology and IT Security solutions, creating successful Business Units within established Groups and helping launch breakthrough startups such as KOLA Kids OnLine America, a social network for safe computing for children, SourceFire, a leading network security solution provider, or Ibixis, a boutique European business accelerator.