Organisations start to address the subtleties of securing 'as a service' propositions
According to a recent Verizon report, 94% of companies expect more than a quarter of their workloads to be in the cloud within two years. The enterprise is moving to a cloud model of IT service consumption and delivery for a variety of reasons: IT organisations can become more responsive to business requirements by scaling up on demand, operations are refocused toward the company’s core competence – which is typically not building data centres, and the long term costs can be more than 65% less than traditional IT models.
As we celebrate the tenth anniversary of cloud titan Amazon Web Services, it’s important to reflect on what the market has learned about security in the first decade of cloud computing and what enterprises must consider while beginning their journey to the cloud.
When considering a move to the cloud, it’s vital to remember that there are fundamentally different security models involved when adopting shared software as a service (SaaS) offerings compared to infrastructure as a service (IaaS). While people tend to lump these two classes of services together as public, data ownership, encryption management, and service access are wildly different between these two varieties of cloud services:
While SaaS services are typically easier to consume than IaaS services because you don’t have to manage the application layer, they’re also less secure than the more DIY-oriented approach that you have with IaaS deployments. It’s important to consider that these architectural differences are fundamental to the way third parties may try to access your data, and there are some very famous cases where cloud security is not one-size-fits-all. There are various areas which need to be addressed.
As the now-famous FBI vs. Apple case is provoking a global debate around the challenges of end-to-end security – both good and bad – it is a good lesson in source-based encryption. The case highlighted how user-generated security keys can create significant barriers to data access while simultaneously launching one of the most public government-sponsored hacking campaigns of all time.
In the above case, Apple completely complied with the government’s request for any of the San Bernadino shooter’s data that was managed by its iCloud SaaS service – and it could do so because it also owned the customer’s data. Similar cases have surfaced all around the world, where national interests are not as aligned, such as Microsoft vs. the US Government. What is becoming increasingly clear is that unless you’re the service and data owner, a third party SaaS provider can be leaned upon in ways you may not have prepared for and ways you’re less able to protect yourself from.
Aggregating the information of or about many organisations within one system has always been a critical shortcoming of public and private cloud IT systems. There is a direct, linear correlation between the amount of users of a public cloud SaaS service and its appeal to hackers – where the largest services can often deliver the best data payload to hackers. Over the last two years there have been countless examples of high-value hacking events from the U.S. Office of Personnel Management, to Target, Sony and more.
As a reaction to this surge in security breaches, security managers and CISO’s are advising that organisations segregate their data sets, minimise the volume of any one high target asset and create secure, encrypted tenants around users to the greatest level of granularity as possible. Businesses, such as private equity firm The Carlyle Group, have been working with CTERA to adopt best practices to ensure security is approached correctly. The firm has worked to encrypt each of its offices with a unique key and explains its approach in a video here.
Here are some best practices as you consider moving your data to the cloud.
- Own your keys, and generate your keys: Third party encryption key generation is an additional level of vulnerability that isn’t appropriate for today’s secure organisations.
- Make your cloud private: Virtual private clouds (VPCs) have achieved the same level of security as private data centres and have always been able to deliver. For this reason, organisations can now go all-in on their cloud agenda without compromising on application or data security.
- Compartmentalise your users, divisions and data to minimise the thread radius of any security compromise: Scalable systems that create unique encryption keys and data isolation around cloud tenants can ensure that in the event of any breach, the breach is contained to that user, application or segmented data set.
By taking on board these best practices, you can avoid issues that are being uncovered in the high profile cases and address the cloud security challenge.
- » Redis Labs further changes licensing terms – to make developers happy and keep big cloud vendors at bay
- » Understanding Kubernetes today: Misconceptions, challenges and opportunities
- » IBM focuses on second chapter of cloud story at Think – hybrid and open but secure
- » How to tackle the multi-cloud security challenge
- » Do cryptographic keys belong in the cloud?