Readers of classic science fiction will likely recognize the reference to Robert Heinlein’s 1950s novel. In this futuristic tale, the characters must use a tunnel between Earth and an unfamiliar (and inhospitable) planet in order to take a survival test. The novel has insights that can be applied to modern security requirements regarding the use of SSH and RDP—the subject of today’s blog.

Let’s start with SSH, which is well-known as both a protocol and a client because it enables SecOps teams to securely control and monitor remote computers. However, SSH has more to offer; for example, it can be used to route local network traffic to a remote destination, or it can even be used to securely transfer files—and it is as simple to use as a UNIX file copy command.

RDP is similarly powerful. For average users, RDP is useful for desktop sharing. It is, however, quite mature (nearly 20 years old!). Not only does RDP permit desktop sharing and remote control, it also allows for file transfer, drive mapping, and even printer access—and all through an encrypted tunnel. This proprietary Microsoft protocol has been built into Microsoft Windows operating systems since XP, but Microsoft permits third-party vendors to use this universal standard.

Why is this relevant? As end-to-end encrypted tunnels, SSH and RDP bypass many perimeter security controls, and often, these protocols are opportunistically established between endpoints and third parties—with no regulation. Enterprises that access third-party systems using these protocols should create a workflow that ensures these protocols are regulated and keeps data confidential, unmodified, and readily available. This is not trivial, but necessary if organizations wish to reduce their threat surface area.

Authentication, Authorization, and Accounting + Virtual Jump Box

One approach is to break the workflow into two parts: managing access and isolating the data. This approach requires a separate jump box (also known as a jump host, jump server or even SAW—secure admin workstation), and ideally, the jump box would be implemented as a virtual machine to speed provisioning. The jump box would be equipped with the security controls required for data scanning and secure internal user access, isolation from internal shared resources, and limit access to only the third-party system. Think of the jump box as a safe location that holds all of the tools required for evaluating data prior to allowing it into a network.

Let’s walk through this. Imagine you’re an employee at Company ABC and you require access to data on a third-party system—data that your team may want to purchase for recurring use, for instance. You will need to evaluate this system before making a purchasing decision, so you ask your IT team to obtain connection information (destination IP, tunnel information, SSH-key, credentials, etc.). The following could then occur:

1. The IT team provisions a new jump box on your company’s internal network.
2. The IT team sets routing and access rules and login information.
3. You SSH/RDP into the jump box from your local workstation and open a connection to the remote third party.
4. You evaluate the data on the third-party system, or you pull it down to your local machine (jump box) to evaluate it internally.

If you like what you see, the IT team marks the jump box as a semi-permanent resource and coordinates times for its use. If the business relationship terminates at a later date, the jump box and its policies can be decommissioned and even deleted after a time period that aligns with the company’s security policy. This workflow is illustrated below:

Best practices include:

• Provision jump boxes behind perimeter firewalls. The firewalls should be configured to accept outbound SSH/RDP/SQL from each jump box based on the company security policy.
• Maintain access control—use directory services to permit access, limit access to internal network only, incorporate time constraints, etc.
• Implement jump boxes as virtual machines for rapid provisioning. The jump box gold image should contain only those tools essential for evaluating data and providing protection.
• Do not map drive shares to internal corporate resources on jump boxes, since this will require that new data be stored locally if it is to be scanned.
• Install local security tools on jump boxes as outlined by the organization’s security policies, such as host-based intrusion prevention, file integrity monitoring, system management, and anti-malware.
• Disable file sharing if RDP is being used to access the jump box.
• Where possible, enforce SSH key-based authentication, rather than passwords.
• If you are the third party receiving these connections, you will notice that these best practices align closely with your configuration requirements. At a minimum, set up authentication and isolation using VLANs to reduce the opportunity for access into your internal network.

While initially SSH and RDP protocols may not be considered threat vectors, they can introduce risk. The workflow discussed adds some complexity but it also enables an adaptive approach that leverages the strengths of multiple teams and permits rapid provisioning, secure access, and simplified decommissioning.

The primary focus of SecOps teams today is to protect users as they navigate through the “deep space” that is the Internet. A modern SecOps professional may not necessarily relate to the term “survivalist,” but I don’t think it’s that much of a stretch in today’s digital ecosystem.

The mission of the NSS Labs enterprise architecture research group (EARG) is to work with enterprises to solve security architecture and product challenges. We provide research and advisory services that are objective, accurate, reliable, and actionable. Our data comes from NSS Labs test results, first-hand experience in the lab, and interaction with our enterprise clients.