Protect AD Backups from Malware Infection

[MUSIC PLAYING] Welcome. This is "Quest Unscripted," a vlog series on trending topics and Quest solutions related to Active Directory, Office 365-- oh, and don't forget, Azure AD. You're here because you have questions. We're here because we have answers, I think. We will address questions we've received from customers experiencing the same challenges as you, all with the goal of helping you confidently move, manage, and secure your Microsoft environment. We call the show "Quest Unscripted" because, except for this intro, nothing we say is scripted or rehearsed. And we're pretty sure you'll notice that right away. Hey, Brian. Hey, Bryan. How are you? Good. First question for you-- Yeah? Is secure storage and immutable storage the same? No, actually it's not. So secure storage, for us, is simply a place to store backups that cannot be reached from the network. So we essentially have firewalled a server to the point where it's air gapped. Air gapped-- why? Why are we doing this? Well, because the ransomware guys are getting really, really smart. There's a vendor that touts itself as a ransomware proof solution that one of my clients recently had, and the attackers simply learned how to get administrative access to that system. And before they dropped ransomware, they went in and deleted all the backups-- not a very good thing. So-- Yeah, it's becoming more and more common nowadays. So-- Yeah. With that said, can you describe how we're doing and what we're doing with secure storage to protect our AD backups? Sure. Absolutely. So the first big thing to know is that secure storage is a secure storage location. And implementation is important at that, but the real thing is that, when those backups are stored, the only way for you to pull them back out is to gain physical access to the server that you set up as secure storage. So why don't I show you on some slides here. And when you're saying physical access-- so somebody has to physically go to the server or get access, console-level access, to that server to extract it off? Yes. And we'll talk about some of those details, because those are good questions. So here is my example. I've got my RMAD server and my RMAD console, and then I have a server I want to use for secure storage. So you identify that server first. And then you tell the RMAD console, and it creates-- well, here, I'll step through a couple of slides here. But it creates this agent that's specific for the server you're going to make your secure storage server. And then you deploy that agent and install it. And the agent sets up a TLS encrypted port. Sorry, I think I tapped twice-- sets up a TLS encrypted port back at the-- back into itself, so that the console is able to talk. And we use a high-level port. You can pick what you want. I think we use 48001 by default, but you can pick whatever port you want. And then we encrypt that traffic with TLS using a mutually shared key. Now, the commands that are issued here cannot do anything more-- and I'll talk about the details there. They can't do anything to manipulate the backups that are on the box. But as soon as this connection is established, the server gets hardened. So you write, but you can't read. Is that right? Yes, essentially. Yeah, not quite. No, I'm going to take that back, not quite. The secure storage server allows you to read data back out, but the commands that you issue are not allowed to manipulate the backups that are already stored here. And so we'll walk through those details, Brian. It'll make more sense. So again, only that high-level TLS port is available. Everything else is gone-- no remote desktop, no remote procedure calls. You can't even ping this box, so ICMP is completely shut down. And we kick off any SMB protocols. We actually disable them so that, even if the firewall were to drop, SMB is not enabled on this box. And you can't create a share or access a share. I'm just assuming this is not a member of the domain whatsoever, right? Yeah, that's not smart to make it a member of the domain. Agreed. Any little bit that you open the door is bad, in our opinion. But the nice thing is you can have as many secure storage servers as you want. So here, I've got two data centers. And you can see I've got one in each data center. When backups are made, what happens is the RMAD console starts the backup. You can see the commands go to the backup agents. The agents then what they've always done. They store those backups. They create them, and they store them in what I like to call tier one storage. So that could be on the RMAD server. That could be on some share closer to the DCs. It could be on the DCs themselves. It doesn't really matter where that is, as long as it's an SMB share and we can reach them from secure storage. And then as soon as those backups are done, the console notifies the storage agents and says, hey, you've got a new backup. Go get it. And so the storage agent then reaches out and pulls that backup in. So you don't have to have the firewall drop to do that. I'm reaching a share that's open on tier one. And I can pull that backup in and then I store it. Now, storage is done by a number of days, not by a number of copies. And again, the commands that you can issue-- I think I'll just move forward a slide. Those commands that you can issue in this secure notification-- they can only tell the storage agent, hey, you've got a new backup. Go get it. Retention is taken care of by a set of PowerShell cmdlets that you can only run when you are physically logged into the server. So physical console access is really the only way to manipulate things, once the server has been hardened. Now, I should prompt you with a question, Brian. A lot of customers ask, well, can this be a VM? I'd hope not. A lot of different VM attacks-- was a VMware vCenter attack last week were remote code execution. So I think, technically, yes. Advisable? No. Right. You're exactly right. Yeah, we don't recommend this as a physical server, or a VM server. We recommend it is a physical server with its own storage, not SAN-attached and certainly not NAS-attached storage. The backups that are on there-- another question I get asked is, does it encrypt those backups? Well, our backup process encrypts backups. So if you want your backups encrypted, do it when they're created. And then when they're stored on tier one, they'll be encrypted. And that way, when they're going across the wire, they will remain encrypted. They're encrypted, because they're encrypted at rest. And there's two types of backups we make, Brian. And I haven't talked about these details in this deck. But our Active Directory backups-- the agent will actually create the backup file on the server, on the DC. Yeah. And then it will encrypt it and compress it. And then it will copy it over the wire. So it's encrypted going over the wire, because it was encrypted at rest. Bare metal backups are a little different. We use Windows Server Backup. And so if you decide to encrypt the backups for bare metal, even if your DCs are not encrypted, we enable BitLocker on the VHDX file that we're creating. So that makes the backup agent is encrypting that data as it sends it over the wire. And then we take the decryption keys, and we encrypt those with the password that you give in Recovery Manager. And so then we ship those over, and we store them in another partition in the same disk backup. So, Bryan, you said BMR-- So everything on the wire is encrypted. I know we can do BMR, but you don't have to do BMR, right? No, and we don't really recommend BMR, unless you kind of have to. Now, as far as secure storage, I'm assuming since we're just really storing data, it doesn't really mean much processing power, do we? No, two to four CPUs, two to four gigs of RAM is probably plenty. It doesn't need to be a big beefy box, as far as that. It does have a check integrity feature. And so I think I can show that in another video. But with check integrity, it will actually check some of the files on the secure storage server, and then compare them to the checksum of the file when it was created, and make sure they match. So while secure storage isn't an immutable storage, I think it can help you on your cyber resilience and with a standard attack, because you can't necessarily see where we're storing the different data to begin with? Is that a good summary, Bryan? Yeah, it is a good assumption. So what we want this server to become on your network is a ghost. We want it to be seen by nothing, and it responds to nothing. So if you are in a large data center, hopefully you remembered where you installed this server, so you can go physically access it later. All right. Thank you, Bryan. Appreciate it. All right. Cheers.