‘Jump boxes’ and SAWs improve security, if you set them up right

A jump box is a secure computer that all admins first connect to before launching any administrative task or use as an origination point to connect to other servers or untrusted environments. Over the last few years, with malicious hackers and malware infesting nearly every enterprise network at will, security admins have been looking for a way to decrease the ability of hackers or their malware creations to steal admin credentials and take over an environment and the concept of a traditional “jump box” has morphed into an even more comprehensive and locked-down “secure admin workstation” (or SAW).

A SAW is a computer the admin must originate from before performing any administrative task or connecting to any other administered server or network. Although related, they are used at different points (the SAW is always the first computer). Both can be used to make your environment significantly more secure. You should be using one or both, and if you’re not, you need to get busy.

The central tenet for highly-secured computers

The central tenet behind both jump boxes and SAWs is that they are highly-secured computers never used for non-administrative tasks. The vast majority of computer security risk in most environments comes from administrators using the same computers for performing the highest risk activities (e.g., using email, internet browsing, office productivity apps, etc.), and possibly being compromised, and then performing administrative tasks with administrative credentials on high-risk computer systems and networks.

Even an admin remotely visiting another user’s regular computer system that performs high risk activities is a risk. If the system he is visiting is exploited, the admin’s originating session could get exploited or his admin credentials stolen. Jump boxes and SAWs must be configured so that they are both less likely to be exploited and also must be restricted in what they are allowed to visit. Only by having both controls enforced can they provide much needed security.

As a 30-year computer security consultant, I can tell you that organizations consistently and reliably using one or both of these approaches have far less risk than those that do not.

Enhanced security

Here are the protective measures you should take for jump boxes and SAWs.

Use the latest OS and application versions

Every software program gets more secure with every release, so it goes without saying that your jump boxes and SAWs should only contain the latest versions of all installed and used software, including the operating system. They should have critical security patches applied within days, not weeks. New operating system versions should also be applied in a timely manner, although in practice some companies try merely to stay only one version at most behind the latest offered by the vendor (called an “n-1” strategy). N-1 isn’t as risky if you keep up with all the latest critical security patches.

Network- and host-restricted

It is extremely important that jump boxes and SAWs are not allowed to connect to just anyplace. At the very least, they should not be allowed to connect to the internet and anything from the internet should not be allowed to connect to them. (More on this below.) Almost as important, is that they not be allowed to connect to regular end-user workstations. You don’t want them connecting to a relatively unprotected computer, picking up an exploit, and then going on to do administrative things on mission-critical resources, taking maliciousness along for the ride.

Conversely, you don’t want every computer in your environment able to connect to your most secure boxes. SAWs should not have any inbound connections at all. Jump boxes should have none or be limited, or only allowed by exception, a connection from another trusted computer. You can enforce connection allows and denies using firewalls, IPSEC, VPNs, or other connection limiting mechanisms, such as NetBIOS computer enforcement, VLANs, proxies, or 802.1x network enforcement. The mechanism you use to accomplish it doesn’t matter as much as that you prevent most default connectivity. Every node denial is a decrease in risk.

The best shops prevent elevated admins, like domain admins or enterprise admins in Microsoft Active Directory environments, from connecting to anything other than domain controllers or the few servers to which they absolutely have to connect for install or configuration duties (i.e., Exchange servers, Active Directory Certificate Services installs, etc.). This significantly lessens the possibility that a very elevated credential will be stolen.

No browsing the internet

Access to or from the internet is the make or break option as to whether you take your jump box or SAW security seriously. If you allow unfettered access to the internet from a jump box or SAW, you really shouldn’t implement them. It’s the biggest requirement for reducing risk. Some shops allow a very limited number of connections to pre-approved internet sites. As long as these allowed web sites are kept very limited (say fewer than 10 sites) and are mostly vendor software download locations, this is acceptable. If the allowed list starts growing into the dozens of exceptions and includes sites not directly sponsored by a particular vendor, the risk starts to increase. Many hackers love to compromise otherwise trusted third party or social media sites, in what are known as “watering hole” attacks. The admin visits a trusted web site they’ve used for years, only to unknowingly download and use a trojaned program or tool.

Note: Remember that simply restricting port 80 or 443 traffic is not enough. Blocking connections to and from the internet means blocking all port traffic and not just internet browsing.

Security hardened

Jump boxes and SAWs should have strong computer security controls applied, far stricter than would normally be applied in the regular environment. Most computer security recommendations are created in a way to enforce a moderate amount of security while at the same time being unlikely to cause any operational issues. It is difficult to apply strong security controls across a broad range of computers without causing operational issues, so most computer security baselines stop short of being highly secure. You want highly secure configurations used on jump boxes and SAWs. Some vendors offer specialized, high-security configurations, although most of the time you’ll need to create your own customized security setting. These high-security settings should be easy to apply and re-apply, and should be reapplied on a frequent basis (no less than several times a day).

Applications locked down

Almost as critical as blocking internet access is blocking any non-pre-approved applications. Many jump box and SAW implementers use application control programs in “whitelisting” mode, but the nearly same thing can be enforced by not allowing admins to be local administrators of their own boxes. The whitelisting option isn’t nearly as strong, because many applications can be installed locally without needing to be local administrator. And many hacker tools can be run as scripts, so you need to make sure scripts are also locked down.

In many real-world implementations, this lock down step was the most controversial and time consuming. Admins just want to admin, and that means installing what they need when they need it, including downloading and installing new things on-the-fly as-needed. Allowing new applications to be installed, at will, is just asking for trouble. I can tell you from experience, that once you allow admins any leeway in installing new programs, without a thorough security review, you’ll end up with jump boxes and SAWs that look remarkably like every other computer in your environment, including having email and office productivity apps installed. It’s a good way to get hacker tools and programs installed that you never intended.

Note: When possible, install and use lower risk admin choices. For example, in the Microsoft Windows world, most admins love to use Remote Desktop Protocol (RDP) to connect to remote servers and computers. While this works fine in emulating a remote computer’s desktop environment, it is among the higher risk operations an admin can do. Instead, when possible, use lower risk tools, like PowerShell, MMC consoles, and scripts. Use tools that make exploitation opportunities less likely.

Strong authentication

Something stronger than regular passwords (e.g., smartcards, key fobs, multi-factor authentication) should be required to log on to a jump box or SAW. It not only makes it more difficult for a bad guy to log onto a jump box or SAW, but makes it almost impossible for an admin to be phished out of their logon credentials by a fake email or web site.

If you use regular passwords, they should be long and complex (15 characters or more). Try to require smartcards or other two-factor authentication methods for all elevated users. If you’re managing multiple environments (that is, different forests), make sure logon credentials are not shared among environments. If you use smartcards, key fobs, or other two-factor authentication, make sure those aren’t shared, either. Yes, it’ll be harder to administrate multiple environments. But if you share that stuff, why have different environments in the first place?

Implement anti-credential theft features

Most enterprise hackers try to steal admin credentials (e.g., pass-the-hash attacks, token re-use, etc.) and re-use them to gain access to mission-critical resources. It’s so popular, that it is the rare case when an enterprise hacker doesn’t steal admin credentials. Accordingly, some OS vendors have responded by implementing new anti-credential theft features. Unfortunately, most of the new functionality might cause operational issues with some applications and environments, and for that reason they don’t enable them by default. Test them, and if they don’t cause critical operational issue, implement them across your entire environment, if possible. If not, implement them on the jump boxes and SAWs.

Zero admin

Nothing makes a hacker madder than when no one is using admin credentials to steal from. Today’s most secure environments are doing away with the traditional, highly-elevated admins and are instead moving to a “zero admin” model, where no admin has all-mighty permissions and privileges. With this model, there are no (or as few as possible) permanent highly-elevated admins. Elevated groups are empty or near-empty. Instead, admins check out the bare amount of privileges and permissions needed (“just enough”) for only as long as they need them (“just in time”). So you end up with no admin having god-like access to all things in the environment all the time, and on top of that they run what limited credentials they do have on highly-locked down computers (i.e., the jump boxes and SAWs), which can only connect to and from a very limited set of computers. All-in-all, it’s a very tough place for a malicious hacker to end up. Thankfully.

Strong auditing

And just in case someone does do something rogue (we can always have a malicious admin), make sure auditing is comprehensive and frequently pulled to out-of-band log management tools for analysis and alerting.

Depending on your environment, tools, policies, and risk tolerances, there are more things you can do to secure your admin boxes. No matter what you decide to do, your jump boxes and SAWs should be among the most secured and audited computers in your environment.

Jump box vs. secure admin workstation

Jump boxes and SAWs are both highly secure computers for completely admin tasks or using as jumping off points to other computers and networks. Where they differ is in their location and physical implementation. Jump boxes are normally centrally located “servers” to which remote admins connect to begin their administrative duties. SAWs are individual, dedicated computers used by each admin for only their admin duties.

From a theoretical and practical viewpoint, SAWs are the more secure option. The SAW begins from a place of high safety. A jump box may be connected to from a very risky and highly insecure computer to begin with. The way most environments implement jump boxes, the original connecting computer can easily be full of undetected malware or hackers that then ride along for all the additional admin connections. A SAW is a statement that the entire administrative pathway, from the root, is going to be highly secured. Accordingly, the SAW takes more resources to pull off because every admin has one, versus a shared resource that everyone connects to.

Originally, SAWs were implemented by having admins have two computers: one for their normal processing, and one for admin tasks only. This has evolved, in most places that use them, into a single computer, where one of the two “computers” runs as a virtual machine on the other. The most trustworthy model is where the admin computer is the physical desktop and the non-admin, “everything goes” desktop runs as a virtual machine on top of it. You can run the trust model the other way, and it is probably operationally easier to do so, but for better security you want the most trustworthy computer hosting the less secure session. Using virtual machines allows admins to pop back and forth using a few keystrokes, and that’s hard for anyone to complain about.

If a few keystrokes, to switch between admin and non-admin instances is too bothersome, many companies use privilege management software to control which applications on a single computer can run administratively or not. Although not as secure as running two different computers or two different desktop sessions, it is a workable trade-off for many environments.

A growing popular middle-ground between running two different computer sessions and sharing a single desktop (with those inherent risks) is to run a single, more secure OS dedicate to keeping applications separate, so that picking up your email doesn’t allow a bad guy to learn your admin password. Joanna Rutkowski’s QubesOS is answering this call, and you can expect more vendors to follow. Qubes is a hypervisor-enabled desktop system with a focus on security isolation. It can run other operating systems and applications, each within its own virtual machine instance, appearing co-mingled on a single GUI desktop. All the admin user is doing is clicking on icons and running commands, without having to worry about security bleed-over between two environments.

Jump boxes are not dead

SAWs are preferred over jump boxes, but jump boxes are great solutions for particular scenarios. For example, the highest security possible can be gained by having SAW-using admins connect to centralized jump servers for all admin tasks. That way all the admin connections can be constrained to fewer origination points, making it easier for event monitors to see unauthorized admin attempts. Jump boxes are also great places for crossing security domains or forcing remote admins to VPN into before going on to further connect to a network. I also see companies placing application-specific admin tools on app-specific jump boxes instead of allowing them to be installed on admins’ individual SAWs.

Jump in a little or require SAWs everywhere. No matter what you do, implementing jump boxes and SAWs can only strengthen your environment.