Manual GRC is Out, Modern GRC is In

Still burning time with manual GRC tasks? Drata automates evidence collection, saving you thousands of hours while ensuring compliance. Its risk management maps and monitors new risks in real-time, enabling quick remediation before they impact your business—all in one platform. See the Drata Difference

The Security Challenge of Bring Your Own Cloud

The bring your own device (BYOD) approach has had a fundamental impact on workplace IT, with users incorporating a variety of their own devices into the enterprise IT stack and in turn, expanding what IT and cybersecurity teams need to support and secure. However, BYO has not stopped at hardware, with bring your own cloud (BYOC) also now commonplace and creating a security challenge for many.

Bring your own cloud (BYOC) is a term that is, in fact, used to refer to two different concepts. One is arguably highly insecure, absolutely undesirable and to be avoided at all costs. The other is merely likely to be insecure, tricky to justify and a potentially untenable concept for a cybersecurity team.

While the focus of this article is the first of these two BYOC concepts, let us explain briefly what the second one is all about. Imagine a scenario where instead of simply renting an application that has been built and is being hosted by a service provider, you open up a part of your cloud setup (either in one of the public cloud providers’ worlds or on your private cloud) and they deploy their software and manage it for you on your systems. Note that this is more than just a remote maintenance contract on the application itself: we are talking about the vendor directly managing the underlying operating system, maybe the virtual hardware … a concept with plenty of security considerations and concerns in its own right.

Cloud in the Shadows

The more concerning form of BYOC, as one eloquent author puts it: “typically refers to a scenario in which individuals use their personal or departmentally licensed cloud computing services without information technology approval for specific tasks or missions”. Those of you with the words “Shadow IT” coming to mind, you are absolutely right: BYOC is shadow IT in the cloud, and carries with it all of the inherent risks and challenges associated any other BYO technology approach, along with some bespoke issues. Incidentally, when the definition mentions that this occurs without information technology approval, this really means “without IT approval or awareness”.

Imagine taking on a new, legitimate, properly planned and approved cloud service. What does the cybersecurity team specify as minimum security requirements? Multi-factor authentication, for sure. Single-sign-on (SSO) against an Entra ID directory is highly desirable. Restricting access to just the organization’s internet-facing IP address ranges is useful too. Let’s look at these three before moving on to bigger things.

Managing Authentication

Implementing MFA is fairly straightforward, but only if whoever sets up the BYOC is tech-savvy and knows enough to realize that they should turn it on. The other two elements are harder, though. For IP address restrictions, this is often easy to enable, but it does rely on the implementer knowing what IP addresses need to be permitted. A simple lookup on a “what’s my IP” web site isn’t sufficient, because if you’re lucky it will only show you the primary address of your internet connection (and not the addresses of any secondary links that might be used in a failover scenario); the organization might be using a SaaS-based proxy service and the IP address shown will be nothing to do with your physical network at all. As for SSO, setting that up will usually require the involvement of a sysadmin, which by definition won’t happen if the BYOC instance is happening outside of the purview of IT.

Ensuring Compliance

Robust authentication is already a security issue for BYOC and is quickly followed by policy compliance.

It is important to quash the notion that we have to work in line with policies and controls “because management say so”. Policies exist as a result of risk assessments; risk assessments exist because risks exist and have been identified. We follow policies because doing so – assuming the policies are well-developed – brings the likelihood and potential impact of cyber attack within the organization’s risk appetite.

There is also a special type of policy: the unwritten common sense ones that govern that must operate within the law and regulation. No in-house policy can legitimately say we can play fast and loose with people’s personal data, because laws like GDPR – which override anything we might write – say you cannot.

What policies are we likely to see broken with BYOC, then? Data protection infractions are sure to be towards the top of the list. Add to that cross-border controls, questions about data controllers versus processors, issues with sensitive data such as health information, lack of control over retention periods and the security applied to the data in the cloud are sufficient to concern any compliance team.

What else? Backups for sure – there is no way an illicit cloud setup will have backups configured correctly (or, for that matter, at all). There will be no segregation of duties regarding operating the service, because the people setting it up may well be completely unaware of the concept. If your policy is to have a password management system, the chances of it being used for the admin logins of BYOC systems is little at best, non-existent at worst.

Appropriate access management will be non-existent, particularly disabling or removing users when people leave the company. This is where you hope the services were set up with MFA … but actually you don’t, because it will make absolutely no difference if someone leaves and the MFA application is on their personal smartphone, not their company one.

Then we have change management. Although many BYOC systems will hold non-critical data, it is statistically likely that more than zero will hold mission-critical data. This means that control over how the systems operate is critical, particularly when something changes. Poor change management is the cause of so many operational issues – and can, put simply, result in customers receiving wrong information, products or advice.

Managing Cost and Capability

Capacity management is a huge concern with BYOC, too – again as a direct result of how BYOC exists. In order to fly under the corporate radar, it is common for BYOC installations to be entry-level, inexpensive versions of the SaaS solution they sit on, so they can fit on an expense claim rather than hitting the IT budget … or even the free demo version. Typically, the time between setup and hitting the capacity limit is just slightly longer than the time taken for everyone to forget the limit exists (or, often, the time taken for the person who set it up to leave).

Confidentiality agreements with the service provider are really easy in a BYOC setup, because it’s just a case of clicking “Accept” on the terms and conditions and moving right along. That covers the rest of the contractual element, so without proper supplier evaluation, who knows what legal horrors the organization is being exposed to? Also, what about a pre-production instance of the platform that can be used for trying out new configuration or rules on anonymized data? This is also highly unlikely to be present.

We referred to BYOC a few paragraphs ago as “highly insecure, absolutely undesirable and to be avoided at all costs”. That avoidance is far from simple. You need strict controls over finances, so that even the small charges slipping onto corporate credit cards or expense claims are getting spotted and tracked back. Use a web filter that errs on the side of “block unless explicitly permitted”. Subscribe to services (there are many) that detect when your corporate usernames are being used for SaaS services. Reinforce, repeatedly, the policy that says unapproved systems are not permitted: maybe offer an amnesty for people to own up to their BYOC use, with a genuine threat of severe sanctions for anyone who doesn’t own up but gets discovered later.

BYOC installations generally exist because whoever sets them up means well and was usually seeking a solution to a problem. It’s rare for BYOC to be implemented for deliberately negative or malicious reasons – they spring up because of some perception that they help people achieve tasks that company systems can’t do, or to do things faster.

The problem, however, is that BYOC raises the risk of becoming Bring Your Own Cyberattack.