Can you trust your cloud provider?

“Trust is like the air we breathe-when it’s present, nobody really notices; when it’s absent, everybody notices.”

This quote from Warren Buffett is particularly relevant in today’s world of the cloud. As I explained in my previous post, whenever you use a cloud provider you are entering into a shared responsibility model where the cloud provider will be responsible for the security of the cloud and you are responsible for the security in the cloud.

However, when you are considering a cloud provider you must think carefully about trust. For example, do you trust your cloud provider not to look at your data, do you trust the effectiveness of their security controls, not just externally but including their own operations staff, and are you confident they would inform you if they suffered a breach?

With the advent of cloud computing, the barrier of entry for budding, small software companies has never been lower. As a result, we are constantly seeing new start-ups, especially in the fast-paced world of security. However, security is hard to get right and designing your software in a secure manner requires experience and skills. Unfortunately, vendors don’t always get it right. Don’t worry, this post isn’t a witch hunt against small vendors who have got it wrong. Read on and i’ll explain.

We all know that data breaches happen on an almost daily basis as they are constantly in the news. Take the most recent story last week about Verizon and the loss of data from their cloud provider’s storage services. I could go on and list many more attacks but that’s not the purpose of this article.

When considering cloud providers you need to ask yourself whether you can trust that provider. Even if you do, I belief that you should still work on the assumption that your data will be breached. Yes, you heard me correctly. No matter what controls you or your cloud provider have in in place, if you make the assumption of a data breach, it will allow you to think about your security controls and your response to any breach in a different light. If we continue with that working assumption, then we should be asking ourselves two key questions.

1)     Is my provider building secure software and platforms?

If security were easy then we wouldn’t see as many successful attacks in the news as we do. Unfortunately, even with the best intentions, cloud providers don’t always get it right. Take the recent example of the OneLogin attack last month, when, according to reports, an attacker was able to get access to some AWS keys and start exfiltrating sensitive data from the database. Should the keys with such powerful access have even been in an internet-facing location? If not, then was this a mistake or a design flaw? Is this the fault of the cloud provider or the software company? Whatever the answers to these questions, it was clearly an issue which led to a breach.

This comes back to security assurance and solid design and implementation throughout the software development lifecycle. As a security-focused company, security is something Oracle has always taken seriously. We have a well-established software security assurance framework, which, as the above link states its intention is:

“Encompassing every phase of the product development lifecycle, Oracle Software Security Assurance (OSSA) is Oracle’s methodology for building security into the design, build, testing, and maintenance of its products”

Anyone who has worked in security for any length of time knows that security isn’t a one-off event, but, is something which has to be built into your overall development lifecycle from start to finish.

This leads us to our second question.

2)     How well does my provider respond to a data breach or security issue?

Even with the best will in the world and the best QA processes, mistakes do happen, either through bugs or poor design choices. Therefore, how a company responds to any issues is of paramount importance. Since I used a cloud-based SSO provider in my previous example, why not do the same again, this time LastPass. They have been plagued by a number of security issues recently as Tavis Ormandy from Google’s Project Zero has been digging into their service. However, as a responsible cloud provider, they have been extremely responsive in responding to, and fixing the issues quickly. This is what we need and have to expect from cloud providers in this world where our data is always online and typically accessible over the internet.

For all of your cloud providers, do trust that they would notify you in the event of a data breach? Within what timescales would they notify you? As for Oracle, we document our response to security breaches and our notification policy in our Data Processing Agreement. We want customers to have the confidence that we know what we are doing and that we have built an enterprise cloud platform, providing a secure set of services underpinned by a secure platform, with all the necessary governance, policies and procedure in place to ensure that we minimize any risk but also, identify, and respond to any incidents that may occur.


Take Responsibility For Your Cloud Data Before An Attacker Does

As I have mentioned in previous blog posts, I spend a significant amount of my time talking to customers about their Cloud strategy, explaining to them about security controls they should consider when moving to Cloud, and, how Oracle addresses security within its own Cloud.

One area that still surprises me in my discussions with organizations is the common mis-conception that a Cloud Provider is solely responsible for the security of their data within the Cloud. Even before the looming threat of GDPR compliance and fines, Cloud has always been a model of shared responsibility. Gartner discussed this in a report back in April 2016. Their summary explains this concept well:

“While public cloud providers typically have strong control attestations, numerous compliance certifications and their own security features, CSPs cannot offer complete security. CISOs and security leaders must understand the scope of their responsibilities for security in the cloud.”

The way I like to explain it is that Oracle (as a Cloud Provider) is responsible for security of the cloud, whilst you, the customer, are responsible for the security in the cloud. You might think that this is just semantics but the differentiation is important. There are a couple of ways to look at this:


At a high level, you can see that whilst the Cloud Provider has some responsibilities, actually, the customer also has a significant number of areas where the control either is wholly theirs, or shared with the Cloud Provider. Even in the red area above, there is still shared responsibility. The wedge shows how this differs depending on the type of Cloud service a customer is using.


As you can see from the diagram above, the customer responsibility for security can be a significant undertaking, especially if adopting IaaS. This is often why customers will choose to adopt PaaS or SaaS offering. Whilst the higher up the ‘as-a-service’ stack you go, the less flexibility you get, you also get less responsibility for security and less to operationally manage.

One point of interest in the graphic above is that the common customer responsibilities across all three services are the data and the service configuration.

Think about it, if you subscribe to Database-as-a-Service, you will be provisioned a secure instance of database (at least in Oracle Cloud you will). For Oracle, that instance will have a number of security controls already in place and enabled by default, such as encryption at rest, SSH access with key-based authentication, configured but disabled firewall rules etc. Beyond that, Oracle will also be securing the infrastructure itself, everything from the data center, up to the instance, providing a range of technology, people, and process controls (the bits in red in the diagram). However, if, as part of the your service configuration, you decide to open up all ports on the firewall to that instance, upload you production data, and enable a powerful DBA-level account with a simple password, the chances are, your data will be compromised. I hope that illustrates why shared responsibility is so important and, as a customer, you must be clear on what you are responsible for and what the Cloud Provider is responsible for, recognizing that this will be different across IaaS, PaaS, and SaaS.

So, what does this mean for your cloud services? You need to ensure that you have sufficient controls in place to protect your cloud services. Some of these controls will be provided by the Cloud Provider, but managed by you, e.g. user management, whilst others are additional controls that you should be implementing as part of your overall security strategy. Below are three key considerations you should be thinking about.

User Management – For any cloud service you subscribe to you will have to manage the users who have access and the level of access they have. As your number of cloud services increase as well as the number of Cloud Providers you use also increases, this is re-introducing the whole problem of Identity Management (IDM), which organizations have been addressing on-premise for a long time. What makes Cloud different is that you may well be opening up services to new user bases such as customers and partners.

When looking at IDM in the cloud, it is imperative that it isn’t treated in isolation. You must ensure you have the same controls and governance over your cloud services as you do for existing, on-premise systems. This may mean extending your existing IDM to cover your cloud services, integrating a cloud-based IDM platform with your on-premise, or moving your IDM to a pure cloud IDM platform. Oracle is ideally placed to support you in all three scenarios with our most comprehensive IAM platform, combining a market-leading IAM on-premise platform, with a modern, new, cloud IAM platform. You can find more details here.

Network Access – When using a Cloud Provider, the default access is over the internet. For many customers, this is ideal as it removes technology constraints for their users accessing the services. However, in some cases, this may not be good enough. Therefore, you must carefully consider how you will integrate with your Cloud Provider. Most providers include a number of private connection options. For Oracle, there are a number of options ranging from VPNs, through to Fast Connect and MPLS connections, depending on your requirements.

User/Service Monitoring – This is not an area that is usually thought about by organizations, but with the modern, sophisticated, low and slow attacks, understanding how users are using your cloud services and building up profiles of normal vs anomalous behavior is hugely important in identifying threats. Also, understanding how a cloud service is configured and whether that configuration has changed is important. You may have done your due diligence when setting up your cloud service, e.g. Office 365, but how often do you go back and check the configuration is still secure and hasn’t change? As with IDM, user/service monitoring should not be done in isolation but should feed into your existing monitoring capabilities. I would argue that monitoring of your cloud services is actually more important that monitoring those systems buried deep behind firewalls in your internal network. Why, because typically cloud services are accessible over the internet 24x7x365. I briefly talked last time about the concept of an Identity Security Operations Center (SOC) framework, which brings cloud-optimized capabilities such as Cloud Access Security Broker (CASB) and uses it as a component, monitoring your user’s activity and service configuration and feeding into your overall monitoring platform, adding identity context along the way.

This does also raise the question as to the suitability of your monitoring platform against today’s threats and challenges. I talk to organizations who have very mature SOCs, using a multitude of tools, but they are having challenges in knitting together all of these tools or realizing the true value of their SOC as their analysts have got many different tools and consoles to use to find the real threats. Maybe it’s time to re-visit your SOC requirements and see what services like Oracle’s Security Monitoring and Analytics Cloud Service can do for you.

Above are just three key areas where I see organizations tripping up or missing capabilities today. There are, of course, plenty of other security considerations but we would be here until Christmas if I tried to list them all.