This extensive guide to cloud security will provide you with information about the different types of cloud services, common security issues with the cloud and steps you can take to improve your cloud security posture. You can use the table of contents in the right-hand sidebar to navigate to different sections.
Introduction to cloud security
Cloud usage is fast becoming a staple in organisations. According to the UK government’s Cloud First Policy, the cloud is usually the first option for organisations that procure new IT services.
As cloud usage continues to grow, it’s increasingly important for companies to ensure that they deploy and use cloud services securely. However, this is proving challenging. Research from IDC indicates that 98% of companies experienced at least one cloud security incident in the past 18 months.
In this guide, we explain more about common cloud security risks and provide guidance on how you can improve cloud security.
To improve cloud security, though, you first have to understand what the cloud is and what the most common types of cloud services are. As such, we’ll start with a refresher of cloud concepts and products.
What is the Cloud?
Before we dive into the mechanisms of securing the cloud, let’s first cement a definition of what it is. As with much in the world of technology, the term has been used quite flexibly (and often just downright abused) by those trying to make what they are selling sound far more sophisticated than what it actually is. Due to this, depending on exactly who you ask, you may get a slightly different definition.
At the most fundamental level, however, the cloud (sometimes referred to as ‘cloud computing’ or ‘cloud services’) is just a different way of providing digital services. The physical technology and hardware that underpins cloud services are no different from what is available to consumers and other businesses. The concept, therefore, is more about service provision than it is about technology.
Characteristics of cloud computing
While the exact definition may be vague, the following characteristics are the key traits to be aware of.
Shared Responsibility – Unlike where an organisation buys and manages their own IT equipment and infrastructure (i.e., servers, networks), there will always be a ‘cloud provider’ that holds responsibility for part of the service in cloud computing.
Depending on exactly what type of cloud service is being discussed will change who (between the cloud provider and the cloud customer) is responsible for what part of the overall service. Still, at the very least, the cloud provider will always be liable for any physical hardware, networks and supporting services (e.g., power, physical building/location, air conditioning).
This isn’t actually as complex as it might sound – but it’s important to understand because cloud security is very much a shared responsibility, with the provider looking after some aspects and leaving other elements to the customer.
One analogy is to think of using cloud services like renting a car. The car rental company (the cloud service provider) ensures the vehicle is safe to drive and in good condition. The rental customer (the business using the cloud service) is responsible for driving the car safely while they rent it. In essence, the cloud service provider is responsible for securing the underlying infrastructure, while the customer is responsible for using the infrastructure correctly and securely.
Transparent Scalability – A customer of cloud services is never responsible for providing and managing the physical hardware underpinning the service (and often not responsible for much of the software either).
This means the ability to ‘scale’ the service should be relatively seamless. Want more users on your cloud HR system? Just pay for the additional licences. Want to trial a new cloud collaboration tool? That can be set up in seconds. In these scenarios, the customer does not need to be concerned about whether the underlying physical infrastructure has the necessary capacity available to facilitate their request.
On-Demand and Pay-per-Use – One of the biggest advantages of cloud computing is that there are rarely any Capital Expenditure (CAPEX) costs. Instead, services are usually all charged on a pay-per-use, or Operational Expenditure (OPEX) basis. A cloud provider absorbs its CAPEX costs and recovers it through the more flexible payment model it offers its cloud customers. This allows smaller organisations/groups – which do not yet have the finances for large IT purchases – to pay only for what they need, as they need it.
Self-Service Provisioning and Administration – While this characteristic is a bit more hit-and-miss as to how well it is implemented in different cloud services, it is still a trait that should be present. In order to allow on-demand services, pay-per-use and scalability, the cloud customer will have some ability to manage the service(s) they pay for through some form of the administration panel.
In the more mature cloud providers, the administration options are much more complex and allow customers more flexibility. With smaller/newer cloud providers, what a customer can do without having to speak to a staff member of the provider is likely to be more limited.
Resource Pooling – Cloud providers can often provide services cheaper than if an organisation were to operate the hardware/infrastructure/service themselves through pure economy of scale. Bulk purchasing of hardware allows for lower cost-per-unit, and that same consistency allows the physical management and maintenance to be relatively simpler than multiple organisations managing their own, unique infrastructure.
This scale and consistency also enable more efficient resource utilisation. Where some resources may be under-utilised, but an equivalent set of hardware nearby is being over-utilised, the cloud service may automatically reallocate some of the customers’ services to the under-utilised resources (usually entirely transparent to the customers).
Types of cloud computing services
This is, understandably, what most people unfamiliar with the cloud computing concept want to know – what does a cloud service look, feel, smell and taste like? What actually is it?
The answer is that cloud services take many different forms, and as long as they still follow the characteristics listed above, they are all still cloud services… even if they aren’t equal.
Saying this, there are three “categories” that cloud services are usually grouped into.
Infrastructure-as-a-Service (IaaS) – This is the form of cloud service(s) that offers the greatest flexibility – but flexibility also means complexity. An IaaS does not really “do” anything by itself. It allows developers and more technical users to provide basic computing components (e.g., servers, networking equipment, data storage), architect them together and configure them to whatever that individual wants them to be.
Platform-as-a-Service (PaaS) – This is usually the most complex to understand of the three. A “platform” is a pre-determined combination of computing components like servers, networking equipment, data storage, operating systems and applications and programming languages. The customer does not need to be concerned about these components. Instead, they provide a starting block upon which to build. A common example is that of a service for hosting and building a website. The “service” for running a website (computing power, data storage, a firewall and website application, such as WordPress) can be grouped together and purchased as a PaaS; but until you build your website with your content, the service which has been purchased will be a blank collection of infrastructure and some basic software.
Software-as-a-Service (SaaS) – Most people will be familiar with this category, as this is the one intended to be the simplest and quickest to use. In a SaaS service, the cloud provider takes care of everything discussed so far and provides their customers with a built application that has all (or at least most) of the functionality ready to go. A customer may need to do some minor configuration and setup for their service, but this rarely involves any complex code or a deep understanding of the underlying infrastructure.
Another way to look at cloud service types
Despite being the most commonly used model for classifying cloud services (and worth remembering), sometimes particular services do not fall quite as neatly into one of these categories as people would like.
In some situations, the definitions do not fit because the way people use computing services has changed over the years. The best example is wanting to use the on-demand nature and scalability of cloud services to run statistical analyses or mathematical processing on large data sets. This short-term usage falls somewhere between the PaaS and SaaS definitions provided above.
The other situation that causes confusion is that the larger cloud providers now offer multiple services ranging across different categories. Therefore, saying something like “Amazon Web Services is an IaaS provider” is misleading. AWS provides more services than you can shake a stick at – arguably ranging across all the categories.
Given this, it can sometimes help to look at cloud services as falling into the following alternative categories:
Cloud Hosting Environments
Groups of services, often aimed at developers or more technically comfortable individuals, provide a wide range of individual services and options that can be combined to create unique services.
Think: Amazon Web Services, Microsoft Azure and Google Cloud
Cloud-based Office Productivity Suites
Whereas cloud hosting environments will mostly consist of component services that require additional configuration and setup to achieve a meaningful, overall service, cloud-based office productivity suites are intended to be a range of applications that anyone can use ‘out of the box’.
Productivity suites can also offer the opportunity to extend functionality through integrations and automation. In line with this, the more advanced features, like Microsoft’s Power Platform for the Microsoft 365 Suite, are arguably more PaaS than SaaS.
Think: Microsoft 365 and Google Workspace.
Cloud End Services
These types of services will be what most people would think of when they hear of Software-as-a-Service. They are services and applications that are developed for specific purposes, often by companies focusing on that being their main product. They may have some functionality to integrate with other services (such as Microsoft 365), but this is not necessarily intended to be used as a package of services.
Think: Dropbox, Jira and Workday.
Steps to securing your cloud services
Having talked about what the ”cloud” is and what a “cloud service” is, the next overarching topic is… what do we mean by cloud security?
How would we go about trying to secure a cloud service? What types of assurances would we want? How do we get those assurances? And what about cloud migration security?
As we identified in the last section, not all cloud services are equal. They come in various forms, shapes and sizes. So, as you would expect, securing them is not always the same. Whilst the exact activities will vary, the considerations fall into the following categories:
- Assurances from our cloud provider
- Configuration of the cloud service
- Penetration testing cloud services/in cloud environments
- Visibility and awareness of the cloud service
Assurances from our cloud provider
When organisations operated all their IT on their own premises, the general thinking was that the company had responsibility for everything.
When you start moving your data and services into the cloud, suddenly, you have a third party that now has some responsibility for hosting, maintenance and management of any software to support the service in question.
If that cloud provider does not take proper care of the parts of the service they are responsible for, they could be the ones that harm the security of what you are paying for.
So how do you overcome this risk…?
Supplier assurance is the answer to this part of the puzzle. There is no single guarantee that a supplier is – and will always continue to be – secure in what they provide. This is about more than just the security of data. Financially, for example, a company may one day start to struggle and subsequently be unable to provide a service upon which your organisational depends for its own business.
This latter reason is why supplier due diligence has been a significant facet of contracts and outsourcing for years. Cloud services adoption only reinforces this requirement.
Your supplier assurance process should be driven by the context of the relationship and the level of risk associated with it. In our guide to supply chain cyber security, we have covered the risks relating to third parties and suppliers.
You can also gauge a lot of the information you would ask for as part of the supplier assurance process through the details some of the larger cloud providers make public – for example, Microsoft’s Trust Center and AWS’ Risk and Compliance Whitepaper.
Does using a cloud provider increase our cyber security risk?
If you assume that your organisation’s ability to provide services in a secure manner is perfect, then yes, switching to an external supplier could increase the risk. However, in practice, we know that organisations are not perfect at running secure services internally.
Often, resourcing constraints, a lack of specialist skills or hands-on experience can lead to certain tasks and responsibilities being overlooked, resulting in vulnerabilities or weaknesses appearing.
By using a cloud provider, you are attaining the resources of whole teams of specialists to undertake the day-to-day management of cloud security that your internal staff could simply not compete with.
Therefore, you have to consider the baseline of security in your organisation to determine if using a cloud provider is likely to increase or decrease the risk.
Configuration of the cloud service
If supplier assurance is how we make sure the cloud provider is covering their responsibilities, then that just leaves the duties that fall within the control of the cloud customer.
We mentioned that one of the characteristics of cloud services was self-provision and administration. There are many settings and configurations that we can set as the cloud customer.
So, how do you overcome this risk…?
Configuration reviews are the answer to this one. Or, more correctly, trying to avoid cloud misconfigurations. On the face of it, this sounds like it should be easy. Just don’t configure something poorly. Things are never that straightforward, however…
You see, the cloud provider will provide a series of settings – available through an administrative console or portal – and all a cloud customer has to do is click, select and enter the correct details for the various settings they want or don’t want. What can go wrong?!
Well, at present, Amazon Web Services has over 200 different services, and Microsoft’s Azure has over 125 services…All with their own individual settings to configure – and this doesn’t account for the fact that they also run “Marketplaces” where partners can offer even more services.
Contact us if you need help with:
It is understandable that with the sheer complexity of certain services – mixed in with the common scenario of asking staff to build and manage things they have never been appropriately trained on – accidents will happen.
Added to this, the default configurations of cloud services are usually skewed towards enabling collaboration and functionality, and not protecting the confidentiality of data. Because cloud services are accessed over the internet, standard features such as “guest access” or “unauthenticated access” can mean that anyone around the world can get access to your service (and the data contained within it) without you realising it.
Once your cloud service is hardened, the cloud service obviously become much more robust. But organisations usually focus on the collaboration features and functionality when first using a cloud service (which are far sexier than the security settings). This means things get missed, misconfigurations arise, and data breaches occur.
A good illustration of this issue is the use of AWS S3 Buckets. S3 is the AWS ‘Simple Storage Service’ and a ‘Bucket’ is a container for data saved on AWS using S3. Unprotected S3 Buckets have become a common cause of data breaches – so much so that AWS has added warnings to the S3 permissions screen, as shown in the image below.
Reports suggest that thousands of S3 Buckets have been misconfigured, making them publicly accessible to anyone on the internet – as evidenced by the SEGA Europe failure reported at the start of 2022.
It is a bit unfair to suggest that misconfigurations are just a cloud issue. Organisations have been misconfiguring their on-premises services for years too. The difference, however, is that cloud services are inherently more public and externally available. If you misconfigured something within your own internal network, your boundary controls would usually offer you some protection. That “safety net” is not there with cloud services.
(Another side note: Most cloud providers do offer some form of overarching policy controls that you can set to mitigate the chance of a “worst case, all my data is currently spewing out onto the public internet” scenario, but you have to configure those too…).
In spite of what most cloud architects and developers would have you believe, such administrative consoles and portals are not intended to be difficult to use. Cloud providers want just about anyone to be able to use cloud services (although, this doesn’t stop them from changing where all the settings are or what they look like every few months to ensure their service remains “fresh”!).
Getting someone more familiar with these cloud services to review how you have configured the service is often all that is needed to highlight areas for improvement.
Penetration testing cloud services/in cloud environments
Penetration testing and the cloud have a quirky relationship, in that the nature of the cloud service dictates the types of security testing available to the customer.
In the shared responsibility model, penetration testing aspects of the service for which the cloud provider is responsible will fall on the provider because it’s their system. Saying this, confirmation that the cloud provider carries out regular penetration testing should form part of your supplier assurance checks.
So, you will rarely be permitted to carry out penetration testing of SaaS environments, the ‘platform’ elements of PaaS or the ‘infrastructure’ elements of IaaS.
This doesn’t mean you can never penetration test. Some exceptions do exist (see: AWS Penetration Testing and Microsoft’s Penetration Testing Rules of Engagement). But these require preapproval from the cloud provider for legal (and other) reasons, so the best rule of thumb is to assume not.
You will, however, be able to test the aspects of IaaS and PaaS that are managed by the client, such as the host operating system (OS) in IaaS or the web application hosted using IaaS or PaaS. We regularly perform penetration testing of cloud environments and web apps hosted on cloud environments hosted by AWS and Azure, for example, but only the aspects which the client is responsible for.
How to ensure your cloud service is secure?
Your starting point is to consider your cloud service and identify what can be tested. Irrespective of whether there are services that can or should be penetration tested (and we can help you identify your testing options if you need help with that), it is advisable to carry our regular configuration reviews on the elements of the cloud service that are within your control.
What you can do, and we say a client should always do, is to test the secure configuration of the cloud service for the types of misconfigurations or even missed configurations referred to in the previous section.
The big cloud providers typically issue security guidance that customers can use to ‘harden’ their cloud service and the Center for Internet Security (CIS) provide configuration benchmarks for the major cloud providers, which can be followed to ensure nothing is left to chance. In some cases, you may not want to adhere to the CIS benchmark recommendation, but at least you’ll be making a considered decision rather than not knowing about potential risks.
We, therefore, suggest that you consider your cloud service, consider penetration testing options and undertake a secure cloud configuration review. Even if there is nothing to test (because the cloud provider is responsible), reviewing your cloud configurations against the best practices is good for security assurance.
Visibility and awareness of the cloud service
All the points that have been discussed above are focused on a ‘point in time’ assessment of the cloud service. In some respects, supplier assurance will also give you an indication of how the cloud provider is likely to maintain and manage the service going forwards too.
But how will you know if something starts to happen to the service? How would you know if someone starts trying to break into it to get access to your data?
You can hope that the cloud provider will alert you to this. It may be something agreed as part of their responsibilities. But will the cloud provider necessarily understand your organisation to know if something is suspicious? Does the cloud provider know that you are a UK-only company and that user logins from overseas would indicate something malicious?
You cannot assume anything regarding what a cloud provider is monitoring, and furthermore, what they would consider sending an alert to one of their customers about.
So, how do you overcome this risk…?
Logging, monitoring and alerting is the answer to this one. Previously, companies often assumed that they would have been able to detect unusual traffic coming from internally hosted services via their network monitoring and logging. When it comes to cloud-hosted services, your company does not have visibility of the networks surrounding the service, so you can’t assume you would detect malicious activity traffic that way.
Fortunately, many cloud services offer much easier logging, monitoring and alerting mechanisms than if an organisation were to host a service itself. Cloud services can often be configured to send an email to a particular mailbox upon a given detected pre-configured activity, which is much simpler and intuitive than dealing with full-on event monitoring and log analytics software.
However, whether these features are available varies a lot when you start considering end-user services, SaaS and so on… So, it is always best to understand what is and what is not possible before procuring a Cloud service.
Sources of Cloud Security Best Practice
Several expert resources are available to help organisations overcome the security risks associated with the cloud. As well as this guidance, you can also review the National Cyber Security Centre’s (“NCSC”) cloud security guidance as a starting point.
Other sources of best practice include NIST’s guidelines on security and privacy in cloud computing, NIST’s general access control guidance for cloud systems and NIST’s cloud computing standards roadmap. While these resources are definitely not light reading, they do offer in-depth insight that can inform your strategy.
Finally, we recommend the CIS benchmarks for cloud service providers, which currently cover Amazon Web Services, Microsoft Azure, Microsoft 365, Google Cloud Computing Platform, Google Workspace, Oracle Cloud Infrastructure, IBM Cloud Foundations and Alibaba Cloud.
Download guide to cloud security for free
Download a PDF version of the guide to Cloud Security:
Discuss your cloud security requirements with an expert
"*" indicates required fields