I\u2019ve seen blog posts and forum threads bad mouthing Microsoft and Remote Desktop Protocol (RDP). Usually it\u2019s in conjunction with someone complaining that a ransomware or cryptominer variant had successfully compromised their environment through RDP. The rants are often followed by calls for everyone to dump Microsoft Windows and how \u201cMicrosoft security sucks!\u201dIt\u2019s not only boring and pedantic. It\u2019s a case of blaming the wrong culprit.Let me be clear. If you are compromised because of RDP, the problem is you or your organization. It isn\u2019t a problem with Microsoft or RDP. You don\u2019t need to put a VPN around RDP to protect it. You don\u2019t need to change default network ports or some other black magic. Just use the default security settings or implement the myriad other security defenses you should have already been using. If you\u2019re getting hacked because of RDP, you\u2019re not doing a bunch of things that any good computer security defender should be doing.Ransomware and RDPThere are many ransomware programs, like SamSam, and cryptominers, like CrySis, that attempt brute-force guessing attacks against accessible RDP services. So many companies have had their RDP services compromised that the FBI and Department of Homeland Security (DHS) have issued warnings.The warning should be, \u201cYour security sucks!\u201d It isn\u2019t like the malware programs are conducting a zero-day attack against some unpatched vulnerability. They are simply making a bare minimum of attempts to find easy-to-guess passwords on remote access accounts, most of which appear to have admin-level access.If all you did was take the defaults that Microsoft puts in place, you would be very safe. That\u2019s because by default, Microsoft only enables RDP for members of the built-in administrators group (RID 501), which requires a password that would be sufficiently long and complex enough to stop simple password guessing RDP attacks, especially when paired with an account lockout policy that only allows a few wrong guesses before locking the account. When RDP malware breaks into a computer you manage, that means you allowed the RDP-accessible account to have a very weak password and didn\u2019t have account lockout enabled.I\u2019m pretty sure that\u2019s not Microsoft\u2019s fault.Best practices to secure RDPIf you follow any of Microsoft\u2019s decades-long touted best practices for securing RDP you would be doubly protected. For instance, Microsoft has long recommended that the default administrator name be renamed and provides a group policy option to allow that. It also recommends enabling the Interactive Logon: Do Not Display the Last User Name option. If enabled, the password-guessing malware program would have no clue what username to start with to begin successful guessing, and even if it did, it would be easily stopped from guessing by account lockout.Further, Microsoft recommends enforcing the distribution and use of trusted digital certificates to any computer trying to logon to use RDP. If the remote device doesn\u2019t have the trusted digital certificate installed, it can\u2019t even begin to guess at the logon password. The best computer security practitioners even require multi-factor authentication (MFA), which RDP supports, as authentication credentials. Microsoft has been recommending and supporting these best practices for over a decade.When RDP might really be a problemThere are times when having a remote access service can truly add vulnerabilities to your system that you could not defend against using the defaults or best practices. A great example of this would be when RDP (or a service depending on it) has a known unpatched vulnerability. This happens, but it\u2019s fairly rare. In fact, as best as I know, it\u2019s only happened two or three times in the multi-decade existence of RDP, which first appeared in Windows NT 4.0.The last critical vulnerability in RDP was back in 2012. It was the real deal. It was remotely exploitable, and one malicious connection could take over the remote logon without any successful authentication. Admins patched this one pretty fast--faster than the bad guys and malware could take advantage of it. Since then, there has not been not a single critical vulnerability that could take advantage of RDP. \u00a0Let\u2019s compare that to OpenSSH (basically the open source competitor of RDP). It\u2019s had 93 vulnerabilities since 1999, including nine in the last two years. I don\u2019t hear anyone telling everyone to dump Linux and BSD because of OpenSSH vulnerabilities.Should you do more to protect RDP?It can't hurt to protect your publicly accessible RDP connections with additional VPNs, changing default TCP\/IP ports, and other protection methods.\u00a0Microsoft\u2019s best practice recommendation of requiring digital certificates is to set up a precursor VPN, but you don\u2019t need to do it.If you ensure that you have basic, acceptable password policies along with account lockout enabled (even with a high number, like 100, of bad logons accepted), you won\u2019t need the additional protections. There\u2019s a lot to worry about and fix in the computer world, and you don\u2019t need to add mitigations when you\u2019ve already fixed the problem they solve twice over.I used to be a big believer in using alternate ports, or even cooler, using port knocking (where you ping a predetermined series of ports, like a combination lock, before the firewall opens up the port you want to connect to), and other one-off defenses. You absolutely don't need to do them. They just add unneeded complexity to an already secured system.\u00a0If ransomware or a hacker successfully exploits your system or network because of RDP, you are doing many insecure, risky things that are indictive of problems far beyond just RDP. The last thing I'm going to do is blame Microsoft and RDP for a problem they aren't even close to creating--no more than I would blame Linux and OpenSSL for password guessing issues.