• caglararli@hotmail.com
  • 05386281520

alternatives to MDE device isolation for unsupported OS versions

Çağlar Arlı      -    20 Views

alternatives to MDE device isolation for unsupported OS versions

I’ve been exploring options for device isolation within MDE. I have Windows 2008 R2, Windows 2012 (they do not support device isolation at all), Windows 2012 R2, and Windows 2016 (they DO support it, however one would first have to migrate to the Unified Agent). How to isolate these old servers?

One way of addressing this would be limiting the Network Security Group (NSG) for a particular server in Azure to accept connections only from the shared jump host we have in our environment. Is this ideal? How can I be sure that the jump host will not let badness happen once I interact with the potentially infected/compromised VM?

Was thinking about using a dedicated VNET (aka forensic) disconnected from the hub subscription, completely isolated from the rest of the network, however reading I came to the realization that moving a VM across VNETs is simply not doable (well technically it is; delete the VM, leave the OS disks intact, and recreate the VM in the new VNET), but that’s a bit of pain. It is however possible to move a VM between subnets within the same VNET.

Here’s what I was thinking to do (although have not investigated the details yet, so apologies if this doesn’t make much sense). Have an automated way of deploying Azure Bastion including the corresponding requirements such as a subnet dedicated to Bastion and have the VM in scope of a potential compromise, move to a dedicated subnet that would allow access only from the Azure Bastion subnet.

Is this common, or a feasible way of doing this?

PS. Yes, of course it would be ideal to move forward with upgrading the servers, but hey, business is business.