What is different about Cloud Security?

Dec 2018

Develop a cloud security strategy? I am always puzzled when I face with open questions with the word strategy involved. Strategy, by definition, is the plan of actions to achieve long term goals. In the case of an enterprise, these goals are naturally driven by the business context; vision, priorities, opportunities, risks. etc. Cloud is just another way of sourcing technology infrastructure and application services. Clearly, choices are more versatile than ever and bring opportunities to the enterprise for agility, resiliency and economy (if only you do it right). Business strategy should drive the choices for the cloud, not the other way around, and Cyber Security (as an IT function) just need to follow the service model, i.e., protect the components you control, and get warranties from the provider for the components outside your control. So, what is different about cloud security?

Let me tell first; I will argue that cloud security is not much different, and it shouldn't be. I also assume that cloud providers are external to the enterprise, as this is the most common case. The utility type service model abstracts internal complexities of services, and it is now the providers' problem to deal with internal risks and costs. Though, accountability still lies with the consumer enterprise and cyber security functions need assurances for that reason, similar to the traditional practice of supplier management (not exactly same though). Further challenges come with the shared responsibility model of the cloud as the consumer enterprise still controls some (or many) components of the service and this is often overlooked in the transformation journey.

I suggest working cloud security within two domains. The assurance domain contains activities to build trust that the provider is able to protect the layers and components they control. These are due diligence exercises to attest good security practice is followed by the provider and obtain service warranties accordingly. The technology domain contains deployment and operation of functional security services for the cloud. All of these should be integrated with core IT services of the enterprise as cyber security objectives are common (e.g. defend, detect, respond). There are just a few areas that need particular attention for cloud environments and I listed them as below.

Assurance Domain

Vendor Maturity has always been an issue for traditional cyber security functions, and has become a well developed practice accordingly as part of procurement activities. I have seen elaborate control assessments for supplier security assurance and it might have worked well in the past in the context of supplier & buyer relationships. Service contracts were used to be great vehicles to enforce controls, at costs of cumbersome and lengthy negotiation processes. This is no longer viable for enterprises that make cloud choices for agility. Service contracts for public cloud are usually non-negotiable anyway, otherwise the degree of control over contract terms is very limited. A modern approach would be considering the industry accepted view that tier-1 cloud service providers (the big three you can name easily) are secure in terms of protecting the components under their control. For others, security assurance and risk can be formulated based on other factors, such as independent certifications (e.g. ISO27001 or CSA STAR) or thru well-established partner relationships.

Shared Responsibility Model clarifies the responsible parties for the composing layers and components of services. It is often a misconception for cloud services that all technical management responsibilities are transferred to the provider. A good approach is to identify and describe service components and activities under your control and plan & integrate security services accordingly. The service components controlled by the provider will also need to be identified and described, however they should be abstracted as much as possible, as the complex interactions inside are now the provider's problem and we just need to seek service warranties instead (e.g. security SLAs/metrics).

Regulatory & Legislative Requirements are binding constraints for many enterprises. Cloud providers are well aware of this fact and are usually cooperative to meet these requirements. Regulators also have recognised cloud models and assign responsibilities to providers so that they carry out due diligence for security (and privacy). Nevertheless, accountability cannot be transferred to providers and therefore it is imperative to build and develop cloud governance, risk management and compliance practices within core IT of the enterprise.

Technology Domain

New Perimeters are the reality of the cloud and the digital era. As enterprises desire to collaborate more with partners and customers, they create many multi-directional information flows and service interactions. This brought the debate that there is no perimeter for information and systems, and new concepts emerged accordingly, such as "boundaryless information flow", "identity as the new perimeter", etc. I insist perimeters still apply but just in a different way than the traditional data centre network perimeter. If we consider cyber security is all about protecting information and systems, we definitely need perimeter controls, wherever our information and systems are hosted. Cloud technologies offer a variety of solutions for that; including traditional tools for segregation (e.g. micro-perimeters, boundary firewalls) and contemporary techniques for threat defences (e.g. AI, machine learning). They just need to be architected as per the new definition of cloud security domains and trust relationships.

Visibility and Control of information and systems in the cloud is probably the top concern for cyber security functions of the core IT organisation. This can be overcome by simply building the security control layer for the cloud. Cloud Access Security Broker (CASB) technologies are evolving rapidly to facilitate controlling multiple cloud services centrally. CASBs provide visibility into user activities and deploy security policies. They are able to help compliance with security standards, such as enforcing data-centric security policies based on data classification. CASB technologies are also evolving to deliver a set of border (perimeter) protection services, such as, firewalls, malware protection and data loss prevention. The fundamental issue here is not just to architect and deploy a technology solution that makes cyber security yet another silo, but also to integrate that with operational functions and processes of the core IT organisation. This is not a technical challenge at all as CASBs provide integration points (APIs) to facilitate integration with the enterprise security infrastructure.

Data Protection is essential as data is a critical business asset to be protected. Cloud providers offer native technologies for data protection (e.g. encryption, tokenisation, access control, automated rules for data transfer & storage, etc.), and they are just usual candidates for building blocks of the integrated security architecture. A good approach however is to deploy these services transparent to the cloud. This allows full control of data, regardless of its location, in the cloud or on-premise, and facilitates portability across cloud providers. CASB technologies are good candidates to deliver data protection services as discussed above. Though, technology tools are just one piece of the solution and it is crucial to architect and deploy an integrated operating process within core IT so that security services can be delivered efficiently and effectively.

What is all that about?

I notice many cloud adopters have assumed the provider would protect services end-to-end, many others have tried to build a "new IT" dedicated to cloud management -as their core IT has been bulky, slow and expensive. While new realities of the digital era compel essential changes to core IT, separating cloud IT will not help much as this will create new organisational silos. It is best to fix core IT with new learnings from cloud and DevOps/agile concepts, and integrate all together as "one-IT" with outward focus to the business of the enterprise.

You might recall that I referred to (enterprise) architecture several times for solutions. The benefit I see from architecture is twofold. First, it builds and presents the holistic view of all tools and processes composing the business value-stream of the enterprise. Second, it manages complexity by presenting the right level-of-detail to stakeholders (i.e. abstraction). A modern architecture discipline is a great helper for successful cloud transformation journeys as solution patterns and abstracted views suit the cloud utility model well, while holistic views organise and coordinate effective integration of all tools and processes within "one-IT", all working in harmony to deliver the unified mission of the enterprise.