Tech Tidbit – Your Battle – Deny Lateral Movement vs. Momentum

I constantly harp on denying the bad guys access to your network, and if they are inside already, denying lateral movement.  At the last Tech Talk, I mentioned that I am watching many of the Paladin Sentinel Monitoring sites just RDP into all the servers with the true Domain Admin Administrator ID - just like we did 15 years ago.

The Tech Talk attendees admitted that it is hard to stop these bad habits because "it is the way we have done it forever" and "it is so easy to do it this way".   In other words, you are compromising potential security because of momentum.   It is simply too hard to break through nearly two decades of bad habits into a more secure operating model.

You do need to fix these bad habits.

Best practice today is to use Remote Server Access Tools (RSAT) and delegation as much as possible either from your secure desktop or from a secure management server vs. randomly RDPing around to accomplish the tasks you legitimately need to do.

For the remainder of my Tidbit, I am going to talk about limiting RDP inside your networks to help you better control access to your servers.

If a bad guy gets in and sets up shop, your RDP client (MSTSC.EXE) is going to be their first "go-to" tool to see how far they can get to infect your servers and steal data.  We need to deny them that access to bottle them up and deny them visibility to anything until we can kill them.

Here are a few things to remember:

• VNC is like having no security at all.  A hacker can shred that password and move through your network at will.  If you use VNC, you must remove it from your network ASAP.
• Turning off RDP is a good start, but if you turn it off and then "turn it on when needed", it is going to get left on.  Time and time again I see people "forgot" to turn RDP off again.  Plus it is a pain to turn it on and off and it slows down our work to do it. We need something more reliable to limit Remote Access.
• You can programmatically allow RDP connections only from "secure" locations such as the tech office machines to limit the exposure to RDP.  That is a good start.  Plus it is free to do.  However, if a tech's workstation got infected, then you still have given away the network.
• Many of you own Microsoft Endpoint Configuration Manager aka SCCM.  That means you own the two-way SCCM remote control client.   Best practice says that using an alternative "RDP like" client that uses different credentials is ideal.  If you own SCCM, consider using that client and turn off RDP everywhere.  Remember the SCCM Console can be installed independently of the SCCM server for more convenient access.
• You can purchase an alternative RDP type client.   Dameware from Solarwinds is used by many schools and is pretty good.   You could then shutdown RDP and use the out of band, alternative credentials, RDP access client to do what you need to be done.
• Finally, you can add MFA to all your server RDP sessions as well as your tech workstations.  Cisco DUO works great at this.   If I RDP to a DUO MFA configured server or workstation, I am challenged for the DUO MFA code.  I can even configure it not to ask for the code but just to instantly prompt my phone to ask the Y/N DUO access question (like GMAIL does on your phone).   Furthermore, I can configure it to have MFA on RDP and local logins or just RDP.  And I can tell DUO to protect against attempts to go into Safe Mode to get underneath my security.   It takes about 5 minutes a device to configure DUO MFA and no reboots are required.   It is tied to your AD users that are DUO authorized so any DUO assigned user can access it.   All the GPO access rules are also still in place on top of MFA.  DUO is sold by the user so the more places you can implement MFA the more secure you are and the easier it is to justify the money for the MFA license.

The DUO MFA RDP denies unauthorized lateral movement while not being a hardship to your techs or users or a tremendous time-waster in getting everyone's work done.  Plus there is no manual process to remember to undo or redo.

The bad guys then would get hung up on the MFA challenge trying to remote into any server or MFA protected workstation (which is hopefully all the tech machines and all your servers).

If you haven't already done so, you need to decide on a secure, internal remote access plan and make a commitment to shut down the RDP attack vector on your network.

Give us a call.  We are happy to help.