Blog post

My cloud isn't a castle

Created:  06 Jul 2018
Updated:  06 Jul 2018
Author:  Andrew A
My cloud is not a castle

You may have noticed from my previous blogs, or the talks I’ve given, that I’m a massive advocate for the security benefits that can come with moving to a good cloud service.

And yet, as these services grow in popularity it's increasingly common to hear news stories reporting that a company or organisation has suffered a cyber breach, accidentally leaking or losing sensitive data.

These are events that we, the security community, can plan for and react to. This is true whether we're running bespoke services in-house or hosting them in the cloud.

In this blog post I want to talk about why accidental breaches are continuing to happen in the context of cloud services and suggest some measures that should make future incidents less likely. 

Own goals

Recently, we've seen a steady flow of incidents where organisations using cloud services haven't applied the security settings needed to keep their information private. The result has been, in many cases, that anyone with an internet connection can see their, often sensitive, data.

We're talking here about things like S3 buckets being unintentionally left open, sensitive data being posted to public Trello boards and web service API keys being accidentally checked into GitHub. These are just some examples of the kind of issues that can affect many different types of cloud service, including SaaS offerings.

Many of these breaches have come to light through the work of security researchers who have responsibly disclosed their findings to the affected organisations. To these noble individuals I would like to say a big thank you.

Our heads are in the cloud

So, why are these breaches happening? My theory is that some people are treating cloud services in the same way that they would an on-premise service. One that has centralised enterprise control and oversight. This leads to the assumption that, by default, they get the same control over cloud services as they would the on-premise equivalent.

To use a crude analogy, our traditional self-hosted IT can be thought of as having been built inside a Medieval castle. It was up to us to decide how many portcullises we wanted and the minimum moat width. We could change the shape of the arrow slits when we had to defend against new weapons, and we could choose when to raise and lower the drawbridge to let only the people we wanted inside.

In our heads, we’ve assumed that cloud services resemble our castle. It just happens to be a castle that’s owned by somebody else and shared by several families. In many ways that’s true, especially when you stretch the analogy to suggest that archers on the battlements come as part of the service.

Unfortunately, that way of thinking allows us to forget that many cloud services aren’t designed to directly replicate old IT. Many cloud services are intentionally designed to promote collaboration and data sharing, while still allowing us to constrain access to named organisations or individuals.

In our old on-premise model, making some data available to 'everyone' meant 'everyone within the organisation, but no-one else'. In the cloud it can mean that same thing, or by design it can mean that 'everyone on the Internet can see it'.

Whilst the cloud provider is responsible for delivering a secure platform for our data, we as data owners are still responsible for how the service is configured. This means we need to acknowledge and act on our responsibility to configure the service to only share the data that we intend to, with only the people we want to.

Finding the silver lining

We recommend that your focus should be on reducing the burden on users to make good security decisions:

  • Make it obvious to contributors that they must not submit sensitive data to services - or parts of a service - that have public sharing enabled. This ensures that anyone contributing to publicly visible services will be on the same page about what is/isn’t appropriate to post.

  • Set sharing to be 'off' by default on each of the services that you use to hold internal-only data. And – unless required – entirely disable the ability to make data public. You should continue to use cloud services to share data to named individuals who are otherwise outside your organisation in an intentional, managed and audited way.

  • Identify an individual or a small team as being responsible for your organisation’s use of each cloud service. They can make sure the service is configured as expected and act as an authoritative contact if things go wrong (don't forget to make sure this responsibility is tolerant to people leaving your organisation!). You can then get confidence in such configurations by including your organisation’s use of SaaS in your regular security audits and penetration test.
  • Reduce the desire for your people to use shadow IT. You can do this by creating organisation-wide accounts for the services that your people need or want to use. An individual signing up for services for their own use may not realise that they need to put a bit of thought and effort into the configuration. It’s very hard to audit/monitor something that you don’t know is there.
  • Avoid sharing secrets such as credentials, API keys and password reset emails in shared services, unless they are appropriately protected by the service and can only be accessed by specific authenticated users. This is described in Cloud Security Principle 2, our Secure Development and Deployment guidance.

I don’t think that any of these suggestions will be a magical sticking plaster that makes these accidental data leaks just go away. However, I am hoping that we can make the number significantly smaller.

As always, any comments gratefully received below.

 

Andrew A
Cloud Security Research Lead - NCSC

6 comments

Joel Samuel - 06 Jul 2018
A key nuance that is not discussed as much as it should be (I am not saying this article skipped this but an abstract reflection) is that both small (Trello, Atlassian, Slack) and larger (Office 365, G-Suite) associated audit and configurable 'security' characteristics to paid tiers - SSO, audit exports, ability for admins to assume-user and so on.

It is difficult to prescribe paid tiers for popular SaaS products in order to achieve security goals but it may be worth weighing in a future blog - if you posses the capability and funds, you can export audit from Trello/Slack/Atlassian/G-Suite etc into your SIEM tool(s) but this is only valuable when effective and assumes basics (as described here) are already there and the organisation is relatively mature around the same.
Andrew A - 13 Jul 2018
It’s a conversation we’ve had round the office quite a lot. There’s always going to be a push towards free/cheap versions of the products as it can be a challenge to quantify the value for money of those security features. And of course shadow-IT rarely has a budget!

However, in order to help both users and IT teams do the “right thing” from a security perspective, I agree it’ll usually be necessary to use the paid tier of a service to get the features that appropriately deal with the threat.

The other often-unsaid angle on this is that it costs the vendor to run even the free tier of the service. While it’s not always true, they may instead be making money by mining your data and use of the service. It means that someone needs to read the terms and conditions to make sure you're not handing over a license to all your data.
Simon - 08 Jul 2018
One aspect I’ve noted, which says a similar thing in a different way, is that there is a lack of defence in depth in some Cloud offerings. S3 buckets are a good example, they are one policy mistake (in a language which Amazon introduced machine learning to help spot mistakes) from leaking all their contents. They are also feature rich (Web Dav anyone?).

One way for cloud vendors to add that depth back would be simplification of products and settings, so that the products are as simple (by default) as our mental models of them, especially security settings in AWS.

One cloud vendor I used had really simple firewall model, you attached it to a server and set the ports for that server. Simple but effective. In comparison AWS security groups can be horrendous.
Andrew A - 13 Jul 2018
I agree that we should be looking for services that are both secure by default (e.g. forces MFA for all users) and is easy to configure to act the way we intend.

The “keep it simple, stupid” mentality continues to apply wherever humans are involved! However, I think there’s always going to be a balance between the SaaS services that can have simple configuration, and the cloud platforms that by design allow us to build a custom service using a wide variety of configurable components. In those latter cases I think we need to acknowledge the complexity and look for services that give us the tools to check our homework and help us abstract the impact of that underlying complexity.
Max Pritchard - 11 Jul 2018
The reduction in size of IT teams alongside the increase in technical capabilities has led to the rise in SaaS and cloud services. That, in turn, has led to the disintegration of device-based network perimeters. Defending castles has turned into defending villages, roads and towns engaged in constant commerce.

The principles of securing the new environments have not changed considerably, and castle analogies still have their place. Perhaps business just needs some help to build castles in the clouds? Use tools to visualise your cloud assets, group them, and automate the deployment of a secure starting configuration when the asset is created, regardless of who created it. Use multi-factor authentication to administrate assets.
Andrew - 16 Jul 2018
This is a very useful blog. I have already been able to cite it in a debate with some of our digital team to explain why we definitely won't be using certain cloud services in our department - an argument I'd previously been losing. Thank you for providing this and highlighting the risks of these services. They're far too share-y by default for our use!

Andy.

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No