Most recent

You want to grant your partners access to corporate resources – Now what?

By Eitan Bremler

If you work in either of the following teams IT/security/networks/applications/MFT in an organization which has business partners, then you probably heard the request - “we need to grant partner x access to our systems/apps/services, because otherwise we can’t do business with them…”

Sounds familiar? Well, the need is of course obvious, as the world becomes much more digital and global, we need to start opening up our network and internal applications to the outside world much more than in the past…whether it’s providing FTP/S access, VPN/SSL VPN access, reverse-proxy access, etc.

But with great cooperation and openness to the world, comes a high level of risk. Each one of the above access options, have benefits but also major faults:

  • FTP/S and SFTP – the beauty of an FTP/S or SFTP server is the simplicity in its deployment and usage by either internal or external users. All you need to do is place a file transfer server in your DMZ and have partners with the right credentials access it. This is exactly the problem! Placing a file transfer server in the DMZ is inviting hackers to easily “see” and attack it. Hackers can use it as a jump point to the network via the open firewall port, authentication options are limited, SSL keys are held in the DMZ unprotected, and more.
  • VPN / SSL VPN – the use of VPN offers high security by utilizing certificates or other authentication mechanism. However, the problems start when you provide partners with VPN access – first, it’s complicated to manage as distribution of certificates to 3rd party partners is required, moreover there is no support for ad hoc access. VPN gateways were originally designed to grant network access rather than application access. Which means that if you wish to grant a partner with access to a specific application (who would want a partner roaming around their network) using VPN, in most cases you will need to isolate the application in a specific network segment. Also SSL VPN gateways naturally store SSL certificates, usually in the DMZ, making them prime targets to SSL based attacks, like the latest Cisco WebVPN vulnerability.
  • Reverse Proxy access – reverse-proxies are the simplest means of allowing external parties to access internal applications, their benefits stem from the fact that they are simple to deploy and they offer a wide range of security options (from simple session breaking, to high end application security capabilities). However they pose quite serious security concerns - hackers can easily “see” and attack them using various SSL/SSH based attacks or OS based vulnerabilities, they store SSL keys in the DMZ unprotected, they require opening ports in the firewall, and more.
  • RDP (Remote Desktop) – remote desktop access is used when we want to allow remote/external access to a specific machine within the network. This access can be granted to organization employees or 3rd party partners, however in both cases in most cases the basic requirement is the use of a VPN connection over which the RDP protocol will flow. And here we get back to the downsides of using VPN which I discussed above.

Now that I bashed the common external access solutions, you’re probably thinking, “so where is he leading with this? What is he saying? ”

I’m saying we need a new way of allowing secure external access to our services. A SOLUTION which can offer true secure access to internal applications and machines, while:

  • Offering robust authentication options for both registered (internal, external, partners) and ad hoc users (AD, SAML, certs, OTP, etc)
  • Removing the need to distribute certificates for partners
  • Perform SSL decryption in a secure zone, while removing any SSL keys from the DMZ
  • Ensuring we don’t deploy any DMZ components which can be hacked and utilized to access the network
  • Removing the need to open ports in the firewall, thus preventing port and OS scanning attack vectors
  • Prevent access to the network but only allow access to a specific application/service
  • Supporting RDP services over HTTPS (i.e. RDH5), allowing to both secure RDP and scan the traffic

The bottom line is that you need a new type of application proxy, one which ensure only legitimate traffic arrives to the relevant application (and not the network) after it has been thoroughly scanned.

If this new concept is of interest, I recommend checking out our RSAccess solution.


Eitan Bremler

All posts