The 4 Most Common Cloud Security Blunders - And How to Avoid Them

It's hard to miss the almost weekly security-themed headlines when something has gone drastically wrong. These can lead to company data being compromised, stolen and, in extreme cases, ransomed or resold. The causes behind security breaches are frequently traced back to human error when managing cloud resources - leaving a storage container insecure, careless handling of database credentials or poorly configured access controls. A recent report by IBM estimates the average cost of a data breach for an organisation to be in the region of USD 4.45M, with immeasurable damage to an organisation's perception. Cloud misconfiguration is ranked as a prominent initial vector for data breaches, closely grouped with stolen or compromised credentials.

Human error resulting in cloud misconfiguration is inherently challenging to guard against, so companies turn to different types of tooling to help identify issues and mitigate risks. This is sometimes handled by a centralised function or team who enforces processes and ensures tools and best practices are applied. This may even involve third parties to provide bleeding-edge security know-how. As noted in the IBM report, only 1 in 3 breaches are identified by an organisation's internal team or tooling, suggesting that an in-house team is helpful but still insufficient by itself.

It's easy to understand how, even with the best intentions, people can make ultimately fatal mistakes when working with cloud technologies. Each app being managed might have different configurations with different dependencies and underlying requirements. The challenge is further compounded with multiple environments typically in use - development, testing, staging and production environments with other data sets to contend with. Furthermore, different cloud vendors might be used, with different terminology and technologies on offer - public, private and even on-premises cloud infrastructure. Notably, citing the IBM report, the most significant percentage of breaches, 39%, involved data stored across multiple environments, followed by public cloud usage.

Cloud vendors and associated service providers try to mitigate issues in a number of ways, such as encouraging a “just enough” approach to access and roles, providing sensible, secure defaults for configuration or providing automated scanning and analysis services to identify code and configuration issues early on. While these undoubtedly have prevented data loss, the responsibility lies with development teams and DevOps roles to maintain integrity while avoiding data breaches and human error creeping in. 

A commonly prescribed and best practice approach is to work with the assumption that data will be breached and thus always stored using sufficiently strong encryption. While this is a sensible practice for an organisation seeking to reassure users after a breach, it needs more confidence in the organisation's infrastructure and development prowess.

The Divio platform is conceived with security by default, meaning taking an opinionated approach to what the platform allows and removing as much of the “attack surface” as possible. Where cloud vendors provide a vast amount of flexibility in what can be configured and depend upon a shared security model, Divio puts cloud infrastructure on the rails. 

Security issues can manifest across the cloud, primarily through underlying and interconnected services. With cloud vendors offering hundreds of services, small misconfigurations can easily creep in to break the chain of trust.

Here are our top four picks for the most common problems we encounter.

1. Cloud storage that is inadvertently exposed

A far too common security blunder is misconfigured data buckets used by an application, or even users, to store and share data. Most applications require some form of permanent storage for meta and application data. For example, storing files that a user might upload through an application. Granting sufficient access that allows the application access but prevents the data from being made accessible to the public is ripe for human error to creep in.

Diagnosing an insecure data bucket is often unclear - the application works and behaves as intended, but the consequences are silent and severe. Implementing sufficient logging and log management to examine who has access needs to be coupled with regular auditing is an obvious mitigation step. Still, as an organisation's structure changes, it can be easily neglected and fall by the wayside.

Divio addresses cloud storage by mandating best practices - providing a decentralised storage network environment variable that apps must use. This allows the underlying cloud vendor infrastructure to be abstracted away and gives the app developer confidence they can depend on the variable they are automatically provisioned. Users of the Divio platform cannot accidentally misconfigure cloud storage, and the secure-by-default model cannot be broken.

2. Misunderstanding or neglecting the Shared Responsibility Model

The Shared Responsibility Model is a widely used concept amongst cloud vendors that defines who is responsible for keeping data and infrastructure safe and secure. It is intended to make it clear to customers where responsibilities start and stop.

While the model differs slightly between vendors, a common misconception is to overly assume that a cloud vendor is responsible entirely for ensuring security practices are applied and maintained. This can create a dangerous sense of overconfidence, assuming the cloud vendor is taking care of all security topics, and is especially difficult to assert across an organisation that might be in a constant state of change. 

The Divio approach is defined more clearly by abstracting away the configuration of the cloud vendor infrastructure. Developers have responsibility over the behaviour of an application deployed on the Divio platform - ensuring it behaves as it should and uses the resources that the Divio platform provides, while Divio manages and provides secure infrastructure - regardless of the cloud vendor being orchestrated underneath.

3. Inadequate access management control

Databases form the backbone of most apps, potentially storing sensitive information and representing the most appealing target for data breaches through access and management oversights. 

Keeping databases and the data they hold secure is typically more nuanced than federating who can access the data and touches upon broader concerns - the backups of the data and how they are stored and accessed, how data is moved between replicated databases or insufficient offline encryption.

Best-made intentions for access controls are often tempting to compromise upon, especially during development, to gain quick insight into unexpected app behaviour. Access can be easily granted and forgotten, and legacy settings can be carried across from development or test environments into a production database configuration.

The Divio platform implements a firm stance on database access and configuration. A database is automatically provisioned for your app through the Divio Control Panel, and following best practices, access is granted to an app through an environment variable. Divio federates access to the database and the application, preventing direct access in all cases.

Divio offers an alternative approach that allows a database to be easily copied between cloud and local environments through the included developer tools. Alternatively, a remote connection can be made to a limited cloned cloud environment that facilitates fault finding and troubleshooting. 

The opinionated approach to access management aims to achieve a nuanced balance: - databases are never exposed whilst fault finding and development are not impeded.

4. Shadow IT 

Shadow IT, or simply unauthorised services, is a problem that cloud infrastructure is particularly susceptible to. It refers to technical users creating and running unfettered services, which can lead to sprawling cloud infrastructure, security blind spots and large uncontrollable bills. This is a complicated problem to retrospectively address when services might already be in production and used in various apps.

Organisations typically try to find a balance between providing flexible working arrangements and governing access to services through implementing roles and access rights with a dedicated DevOps function.

Determining user roles and suitable access rights usually represents an ongoing, time-consuming process, adjusting according to needs, new projects and new requirements. Most notably, this area is ripe for human error, granting a user or process too many capabilities making it possible to expose data or break best practices accidentally.

Not having infrastructure on demand for development teams introduces bottlenecks and frustration, slowing development and release velocity.

The Divio approach is dramatically different to what the underlying cloud vendors offer and takes a simplified and opinionated approach. Instead of providing users with granular access controls, the Divio platform works in the other direction by giving the app permissions depending on the pre-configured resources it depends upon. Granular controls are abstracted into simple and easy-to-understand roles.

Three user types are available:

• Regular user: is given access per project.

• Admin: has access to all apps within an organisation.

• Owner: governs an organisation, adding admins or regular users accordingly.

This makes it very easy for an organisation or the owner of the organisation to get an overview of what projects are being run and where they originate from. Developers can work on apps, deploying new versions on-demand without compromising on security through misconfiguration of the cloud infrastructure.

Delegate security to a platform with award-winning support

Cloud storage, shared responsibility, access management and shadow IT are just a few of the considerations that can have a major business impact when not well understood. 

The Divio platform adopts a lot of responsibility by being an orchestration platform for underlying cloud vendors and effectively acts as a virtual best-in-class DevOps team. 

In order to meet the needs of organisations that depend upon Divio and place trust in the platform, the Divio platform is compliant with ISO 27001, amongst other standards.

ISO 27001 is an internationally recognised standard for Information Security Management Systems and is an important tool that enables organisations to adhere to secure processes and implement important controls in a structured and verifiable way. 

By offering an opinionated approach to building and safely deploying apps, a best-practices approach to security and being rigorously verified against ISO 27001, the Divio platform can address common pitfalls in cloud security.

On top of ISO 27001 certification, Divio provides award-winning support that puts engineers and hands-on developers on the front line, directly connecting users to cloud competence. Eliminating the more usual stepped escalation-based support structure means response times are dramatically reduced and a more personal approach to solving issues together.

If you want to learn more about the shared security model of your current infrastructure or are simply looking for a way to work worry-free, get in touch with us.

Stay informed! Join our LinkedIn and X/Twitter community to access exclusive insights and be the first to know about our latest blog posts.