Many organizations choose to allow direct access to systems via Remote Desktop Protocol (RDP) from untrusted networks.  This presents a number of inherent risks, which opens the system up for direct exploitation via the RDP protocol.  With the recent announcement of MS12-020, we are reminded of this risk: it has been reported to Microsoft that vulnerabilities exist within RDP that may allow an attacker to send a sequence of specially crafted packets to gain the ability to remotely execute code on the system in question.

Let’s take a quick step back here and talk a bit about risks posed by exposing services.  Software is written (generally) by people and people make mistakes.  Therefore one should assume that allowing direct access to any service from an untrusted (or even trusted) network poses some risk.  The key here is making sure the benefits of allowing this access outweigh the risks posed by allowing the access (a formal risk assessment can help here).  Of course, one can also (and should) put processes in place to help further mitigate the risk, if possible.  In this specific example, you may have a legitimate business reason for directly exposing RDP to the Internet that outweighs the risk of allowing that direct access and that’s OK.  Hopefully you have systems (IDS, logging, FIM, etc) in place to help you figure out if something malicious is going on…but just because there is risk in exposing RDP to the world doesn’t mean that you should stop doing it if your company absolutely needs direct RDP access to do business.

One must always remember that the function of IT Security within an organization is to support the organization in their ability to do business.  From a purely technical security standpoint, is directly exposing RDP to untrusted networks a good idea?  No.  Should one present a case for requiring an additional layer of security (i.e VPN) prior to accessing an RDP connection?  Absolutely.  However, the same could be said for basically any network service – albeit less complex ones could be argued to have less risk of compromise due to the lack of complexity.  Either way, understanding that exposed services (yes, even VPN fits in this category) poses some risk is a good first step.

So where do you go from here?  First – patch your systems.  Once a vulnerability (like MS12-020) is publicly exposed, the likelihood of exploitation increases dramatically.  Second – understand that exposing network services poses some risk and take steps to determine whether the services need to be exposed.  Third – if a service needs to be exposed, assume that it is exploitable and put some layers of protection in place (proxies, VPN, IDS, logging, SEIM, etc) to help you mitigate some of the risk posed by the exposure.  Finally – continue to work side by side with the business to help promote a clear understanding of what risks presently exist and work together to come up with solutions to allow the business to continue to operate while accepting only the minimal amount of risk possible.

Oh yes – and did I mention that you should patch?