Prepare for destructive AD cyber-attacks

Hi. Today we're just going to give a quick introduction on how to prepare for a destructive cyber attack. Unfortunately, these are becoming more and more common. A quick recap, though, just to understand what Active Directory means to us as an organization. Basically, the services that we use, the services that we provide our customers-- websites, phone systems, door entry systems, even our manufacturing-- all rely on Active Directory. It is not just an authentication service for users, it is so much more than that. In fact, everything we do depends on it. The kind of threats that we get, well, we've had natural disasters, of course, but then we have the intentional acts from either people inside or outside our organization, trying to do something with our data or cause harm. We have the side effects from those attacks, because let's face it, the attacker really doesn't care about how they leave the environment at the end of the day. And then we've got the accidental damage. The poor admin, or somebody that's deleted something, or a rogue process that went astray, and we ended up with a bit of a mess, either corrupted data, changed data, deleted data. So talking of data, what are the targets? Well, yeah, data is one of them. But again, our services. So the attacker may be trying to do a denial of service for us, or they may be trying to compromise a service to gain access to what it holds, or simply as a stepping stone to other customers of ours as we participate in the supply chain. We may not be the target of the attacker, just a means to an end. It could be an attack against an individual. A manager or a head of an organization, someone may have a grievance against them. Or it could be simply to do as much harm as possible for an organization to stop them functioning, so an infrastructure attack. So deletions, inscriptions, corruptions, and misconfiguarations all run riot within our environment. How do we recover from that? Or how do we stop it happening? That's the first question. Well, the problem is, that if you look at all the threats and all the targets and who can do it and what they could do, it's pretty much impossible to predict everything. Therefore, we can't stop it. We can't put physical blocks in there or software blocks in there to every single thing. We also probably couldn't afford to do it even if we had the time and the ability to predict everything. So we do run through things like trying to analyze what's going on and see what's happening, work out where our vulnerabilities are, see what we can afford to do as an organization without hindering the function of the organization. But at the end of the day, we are going to have to recover. So when we're considering our recovery, we need to have certain functionality. We need to be able to do enhanced planning. The recovery process, if you do it manually or with disjointed systems, is complex. It's a 50-step process per domain to recover. So you need to be able to know what your limitations are. Have you got the people trained and skilled to do these recoveries? If not, then you need to try and negate that requirement for that specialist knowledge. You need to have clear procedures that have to stay up to date, and you need to know what's business critical. Of course, there's no point recovering every domain if half of them don't actually service any function that the business is trying to meet there and then, such as your clients or your manufacturing. But as we've said, you can't predict what people are going to do or where they're coming from or who they are, so you need flexibility to react at the time to the threat. You also need to be able to respond to your constraints, whether that's personnel or even hardware. And also, the business' demands are changing on an ongoing basis. So you have to be able to respond to those evolving demands. So giving all of that, what we offer within Quest is this flexibility and planning. But we can take you beyond that. Why just use your investment in recovery just for the time when it all goes horribly wrong? In fact, why not use it on a daily basis to get really skilled up with it and understand it? So let us look at ways that we can use the investment in recovery and the functionality that Quest provides to go beyond that just simple recoveries phase. So we've talked about recovering DCs, but hey, hang on a minute. Why don't we use some of the functionality to allow us to recover consolidate functions? Part of the problem with doing a recovery is the complexity involved in changing configurations. But Quest takes that complexity away. It automatically reconfigures. That allows you to consolidate controllers and functions safely in your environment. We can then move, of course, because we can do bare-metal or clean OS recovery. So therefore, we can allow you to recover domain controllers to new underlying hardware and get away from those poorly configured or poor performing equipment. And why not just go all the way off to Azure? Move some or all of your resources or functions to Azure. Avoid that limitation of having to have hardware on-premise. And if you're doing a recovery, we can completely automate that. So why not do that as part of your day-to-day process? So what we're talking about here is going beyond today's needs and simply meeting what is required. Reorganize and optimize, and transfer and decommission in a safe and easy way without having to worry about major configuration issues that you would have in a manual process. But actually, that begs the question, wait a minute, we want to practice this.