When organizations consider outsourcing applications or processes to cloud providers, there are many areas to evaluate carefully. Security is always near, or at the top of the list. Of the many facets of security to evaluate when selecting cloud providers, asking for disclosure of relationships to other cloud providers or third parties of interest is one not to forget. Let’s examine a simple scenario where this could impact your ability to meet compliance and/or regulatory requirements.
It is not uncommon for cloud providers to utilize the services of other cloud providers. Sometimes these relationships are not easy to see, but it is perhaps even more difficult to imagine their potential impacts. A simple example would be a Software-as-a-Service provider that uses another cloud provider for e-mail service. Why not? It’s becoming more common place and accepted. Unsuspecting corporate customer believes that a simple agreement to enable opportunistic, if not mandatory TLS for all e-mail communications between them and the cloud provider mitigates any concerns around unauthorized disclosure of message content. However, with another party providing e-mail service, it’s not quite so simple, is it? Especially if you weren’t aware of the transitive relationship!
The following diagram shows the risks associated with an assumption that a protected communications pathway between you and the SaaS provider is uninterrupted.
If the SaaS application generates or report, a log file, or anything else with sensitive information that can be sent by e-mail, then that transport actually terminates at the e-mail provider, and then another encrypted transport is established to you, the corporate customer. The SaaS provider’s point of origin may be an internal e-mail gateway, or the application may simply act as an SMTP client (in which case, you need to ensure that its communication with the e-mail provider is encrypted). Regardless, your content is unencrypted, temporarily stored, and then transmitted to you over a new encrypted transport. In such a case, the only means of solving the problem is to either ensure sensitive information, in any form, is not transported by e-mail, or, that the content is encrypted prior to transmission.
This only illustrates how important it is to think through the architecture of a proposed solution without making assumptions — in short, follow the bouncing ball! Ask lots of relevant questions specific to the engagement, and don’t rush your due diligence process because of outside pressure or a shortened timeline. Non-disclosure agreements or marketing materials do not form the basis for security — only well thought out architectures followed by impeccable implementation can get you there. Don’t settle for anything less!