The Inverted Cloud of Operability

It may be argued that the genesis of the cloud actually evolved from the early concept of the outsourcing model, where organizations sought to place their operations in the hands of suppliers who did technology—eventually evolving into the dynamic/elastic offering we see today as the cloud, or as I see it, the “Inverted Operational Environment”—but why inverted? Well, consider the definition of the word:

• To turn upside down
• To reverse in position, order, direction or relationship
• To turn or change to the opposite or contrary, as in nature, bearing or effect
• To invert a process
• To turn inward or back upon itself
• To turn inside out

In the context of this article I am focusing on two elements from the above list: 1) to reverse in position, order, direction or relationship, and 2) to turn inside out, insofar as the placement of all, or some elements of the technological support are being reversed against, what has been the operational norm of internal hosting; and that what has been accepted as an operational model based behind the logical-perimeter walls of the company, now being supported by an external actor in the guise of a cloud provider.

The benefit of a well-selected cloud provider is that they focus on delivering technology, maintaining currency in skills, and do tend to run optimized and well protected infrastructures. Please note that I have used the term well-selected cloud provider. However, the obtuse to this position is, as I have observed in some companies who did not exercise the required level of due diligence at the time of contracting out their operations into the hands of, what may be referred to as cheap-and-cheerful providers, only to realize their mistake when things go wrong.

When establishing a relationship with any external provider, in particular cloud, it is important to identify the areas of criticality which support the company. For example, is the selected provider aware of the policies, standards and guides to which the contracting company wishes them to adhere to? Another area which tends to get missed is that of incident response, with plug in from internal-to-external, establishing joined-up-thinking and cross-enterprise protocols and communications, which may be invoked when encountering cyber-adversity.

It is also essential when engaging the selected provider that there is an agreement around what the actual technological internals look like when it comes to segregation, platforms and the type of storage. It is at this juncture that it is also well advised to agree that no logical lock-ins are in place that could impact any future migrations if the provider is to be swapped out.

We then look to the governance and compliance challenges which must be addressed to ensure that the data objects that are being migrated out are in complete accord with the mandated obligations. For example, consider the financial institution that did not apply the required depth of due diligence at time of establishing their new partnership, further compounded by the lack of clarification around the profile of storage, resulting in PCI DSS data being sent to a multi-shared insecure jump server located within the cloud provider’s premises, leaving the bank exposed to a serious PCI breach situation.

We then come to all of the other elements which should be at the forefront of the operational mind-set, ranging from monitoring, service reviews, and of course, where applicable, escrow agreements. It is here in an ISACA webinar on 20 April we will explore the topic of the cloud and will dig deep into some of the operational and management challenges that should be considered prior to going live with any such external migrations.

John Walker, CEO, HEXFORENSICS LTD

[ISACA Now Blog]