We're going to talk about whether your Microsoft Cloud could be deleted.

We all know there's been a huge growth in the take-up of Microsoft 365, particularly in financial services. I think something like three-quarters of financial services firms, certainly in the UK and Europe, use Microsoft 365, particularly for email.

Now, it's really easy to access and deploy, and as we've heard, the growth has been exponential. But on the flip side, is it not, at the same time, potentially very easy to delete or turn off? So, I'm interested in talking a little bit today about some of those risks.

It is a question that we do get asked: could my entire Microsoft environment get deleted? So, let's kick off with that big question. What would it entail for someone's Microsoft environment to be deleted?

The deletion process

The answer is yes, it can be deleted. Microsoft 365 and Microsoft Azure can be deleted just as easily as things are spun up. They can be spun down and destroyed.

The process to delete—and this isn't a guide—involves a series of steps.

The first thing would be to delete every user, which is as simple as going and selecting or pressing the delete button, if you have the permissions. Now, there are some protections that Microsoft puts in place. For example, if you delete a mailbox, it's not actually deleted until 30 days have gone by. So, even if you delete everybody's mailboxes and emails in one go, you can still come back from that; you've got 30 days. But let's say the 30 days have elapsed, and no one has noticed for some reason.

The other thing you'd need to do is everything in Azure, which is where all your servers and databases might be. This one is a bit trickier because not all services in Azure are the same. Some have this kind of protection, particularly around files. Depending on what type of storage you're using, you might also have the option to recover after 30 days.

But for things such as servers, if you click delete on that, it really is down to raising a support request to Microsoft and asking if they still have that VM somewhere. They do kind of just disappear into the Microsoft ether and are very difficult to recover. So you would have to delete everything out of your Microsoft Azure, which would take some time, but again, it's relatively simple to do: you select the thing and you press delete, or you select all of them and you press delete.

So, if you've managed to get rid of all your servers and all your mailboxes, you would also want to detach yourself from the partner (i.e., us in that case), so we couldn't have access to stop it. And in order to do that, you need to supply a credit card. Microsoft doesn't allow you to effectively stop paying in Microsoft 365; there has to be some payment on file. So you'd either have to detach or supply your own credit card information.

Even when we get to this stage, where there's kind of nothing going on inside the Microsoft 365 environment, and you press the final delete button, Microsoft still keeps hold of the container or the tenant in your environment for something like 90 days or potentially 180 days. So you could still kind of recover that element of it.

So, yes, you can delete your Microsoft Cloud environment, but there are a number of steps that you have to go through and some level of protection is built in. But these are not things that you should rely on. Well, certainly that one about the credit card—the fact that Microsoft isn't going to allow you to ever not be able to know who they're billing—actually kind of indirectly acts as a protection, but you shouldn't rely on that. You can imagine a scenario where a hacker is looking to delete it, but they actually ultimately have to put in a credit card themselves.

Recovery and what you get back

Okay, fine. Let's move on, then, to let's say the tenant has been deleted and you want to get it back. You said there's a period of time you've got, and you can go to Microsoft. That's correct. What could you get back? And going back to you talking about removing these services first, what position are you going to find yourself in if you ask for it to be restored?

It's not a backup. You can't go to Microsoft and say, "My Microsoft Cloud's been deleted; I want it back from Friday." It's just not how it works. What you get basically are the settings you had in Microsoft 365, just with nothing in it. Then you have to rely on any backups you might have to be able to restore into that. But yeah, it's not much.

Privileges and protection for administrator accounts

So you need to have some really significant or high-level privileges in order to perform these activities. So, which accounts have the keys to the kingdom to be able to do these types of activities?

This is the Global Administrator account. It is the super all-powerful account or role that you can have in a Microsoft 365 environment. It gives you access to everything to do everything. You can have one or many of these Global Administrator accounts, but these are the accounts that you really do not want an attacker to get hold of. There are other privileged accounts, but these are very special accounts in the Microsoft Cloud that do allow you to do things like shut down or close off your Microsoft tenant.

You need to protect these accounts, and they should only be used under very specific scenarios. So, how does Microsoft recommend you protect and secure these accounts? There is a Microsoft way, as ever, for doing things, and it is important because it's based on their experience and what they see.

Their approach is that a Global Admin account should really not be assigned to anyone to use unless they need to do specific tasks that only a Global Administrator can do. An example is the concept of these "break glass" accounts, which are typically Global Administrators, and they are used when you can't use any other level of privilege or permission, or something goes wrong inside the Microsoft Cloud.

Oddly, although there is some method to this madness, they recommend that you don't have multi-factor authentication (MFA) on one or more of these Global Administrator accounts. Everyone's been ingrained with the idea that you need to have MFA, but the reasoning is that if something went wrong with your MFA, then you could still get in. So you need an extremely long password, basically, with these accounts.

But the ultimate aim is not to use Global Administrators; to use one other permission that enables you to go off and do what you need to do. And even then, those permissions should be used really sparingly.

Administering multiple client environments

So, let's talk a little bit about our world. We work with independent financial service firms. They're not huge organisations, so they are obviously looking to outsource the administration of their Microsoft Cloud environment. We are the designated administrators. We have access to the break glass. But we also have access to many clients. What additional risks or challenges does that present, and how do we address those additional challenges of having to administer multiple environments securely?

If you are an enterprise organisation, you typically only have one Microsoft Cloud environment, which may have one or more Global Administrator accounts. Whereas we have multiple Microsoft Cloud environments for each of our clients. So we have many Global Administrators across all those. So, those really are a target.

We have to take extra care and need to put in even additional layers of controls and processes in order to make sure that our access remains safe and controlled, versus maybe a different type of organisation that's only taking care of one thing.

We look to use technology such as Privileged Access Management (PAM). That's a very common one to control who can access that environment, to give them permissions to do whatever tasks they need to do, rather than giving them broad-range permissions or Global Administrator access. So, limiting what people have access to, providing them access only when they need to, and having that complete audit trail and log outside of the Microsoft Cloud around what somebody's done or is doing.

Mitigating risks from high-profile breaches

There have been quite a number of high-profile security breaches recently that have revolved around or used administration accounts, as far as I understand. So, how would that type of approach you just talked about mitigate the risks that we've seen recently with these high-profile breaches?

What we typically find is that someone breaks in at a kind of a lower level. They're not breaking in at the administrator level. They're going in at a typical user at the ground-floor level, and then they're able to get in enough where they can find maybe a password in a file somewhere, and they've got access to that file, and that takes them up a level—privilege escalation.

So, there are a number of things that you can do there to control that. It's really about when you have these privileged accounts in the environment, when they're not in use, they shouldn't have any permissions to do anything. Those permissions to do some form of administration in your Microsoft Cloud environment should only be granted when they are required by an authorised person.

There are lots of controls that you can put in place to prevent that, or at least reduce the likelihood of that account being compromised. But these are not things that are kind of ticked and turned on by default. They do require a lot of setup. Sometimes they require third-party tools to make it even stronger or hardened. But it is something that you have to set up and not something that's enabled by default.

Advice for clients on managed service providers

If you put yourselves in the shoes of a client who is using a managed service provider (MSP) to look after their Microsoft Cloud, and you want to try and understand whether they're doing that securely, what kind of advice would you give them? What kind of questions do they really need to ask? What are the red flags or alarm bells that would go off if you were to ask the right questions?

There are a few things here.

• First, I'd ask them how they currently administer your environment, and they should be able to produce some form of documentation.

• The types of things in those documents want to be looking for are the roles where maybe you've got a help desk who have certain permissions, and a more senior technician has a different level of permissions—an access matrix, if you like—that kind of demonstrates they've thought about or are doing this more granularly than just one account, one administrator.

• Another is to ask them about the Global Administrator account: Who's logging into it? Who has access to log in to it? How many people signed into it in the last 30 days, and what were they doing? If they can't answer any of those questions, I'd be seriously worried, or if there is significant use of that Global Administrator access, I would be worried.

• They should also be able to demonstrate that they are using the type of tools that we'd expect in this scenario, like Privileged Identity Management (PIM) and Privileged Access Management (PAM). You want to be looking for PIM and PAM. Those types of tools effectively enable this controlled level of access and being able to audit.