You also need to restrict administrative access at the application level. This can mean that only certain individuals have administrative privileges in the app, or it can mean that administrators can only access the control surfaces from specific subnets. Data sources for the application, whether internal or external, need to be treated to the same role-based access controls as human users.

Business and operational processes will also cross the trust boundary, and several of these functions are core to why we need jump boxes. Two key processes to examine are change control (such as pushing a patch to production) and authorization (such as granting someone administrator privileges). These must be separate roles, and both must be logged and set up with alerts so that attackers’ attempts to move laterally are more difficult to execute and easier to identify.

To the greatest degree possible, segregate third-party access from critical systems. Physical access control is also crucial as well as cabling and power connections.

Step 3: Define Ingress Access Control

Now you can set up the rules for who passes through the gates. This can be tricky, especially when you think about everything just scoped in and how porous the boundary will be. Personnel, data, and requests for service will all need to traverse this boundary, so every gateway needs access control.

Authentication systems need to be segregated on either side of this trust boundary, which is easier said than done. Safely segregating permissions on the same Active Directory tree for both administrators scoped into these sensitive systems and normal everyday users is arduous. It’s easier and safer to maintain separate domains or Active Directory branches for each trust zone. For the sensitive zones, we strongly recommend stronger authentication measures, like multifactor authentication.

Step 4: Set Up and Configure Jump Workstations at the Border

The purpose of the jump boxes is to provide administrators with a low-risk proxy for managing sensitive assets, since administrators’ everyday workstations can’t be trusted. To be really low risk, jump boxes need proactive, careful configuration management.

Access control

Allow administrators to authenticate to the jump box only from a specific subnet or VPN. It is a bad idea to make the jump box visible from anywhere in the corporate environment, and it is a really bad idea to make the jump box accessible from the Internet.

Jump boxes need strong authentication, both in terms of authenticating to the jump box and authenticating through it to the assets behind it. We’ll get to this in a moment, but all authentication surfaces need to be heavily logged for compliance and audit purposes.

Authorization

It’s best to think of the jump box as a single-use machine, so limit what it can touch, see, and do:

• Network Access: Limit access for hosts and subnets to managed assets in the trusted zone. If an attacker compromises the jump box, this constrains their ability to move laterally.
• Internet Access: In a best-case scenario, do not allow the jump box to be freely accessible from the Internet. If it absolutely must have some Internet access, use allow lists to constrain which external sites it can connect to.
• Applications: Minimize the application footprint on the jump boxes. Application control policies can limit available programs and functions.
• Logging: Monitoring administrative activity at the jump box is important for situational awareness, audit preparation, and forensic capabilities. Store these logs off the jump box so that an attacker can’t wipe them.

Special Cases/Cloud Configurations

Configuration management and automation tools can help in these scenarios, particularly around complex or heavily virtualized environments. If you use a configuration management tool, be sure to employ the same standard of access control and logging as you do for the rest of the jump box infrastructure.

We have largely been talking about these systems in reference to on-premise environments, but all these principles apply for cloud environments as well. Most cloud management services offer multifactor authentication and robust logging capabilities.

Step 5: Roll-Out Policy

Roll out your jump boxes slowly and carefully. Integrate procedures around the new infrastructure into change control and operations processes, but leave existing systems in place for cover during the transition. Get feedback from stakeholders, paying particular attention not to make life too hard for administrators—they’re the boots on the ground here.

Once you have a sense of how well things are working, you can decommission the old access methods. Don’t forget to set up a recurring log review to ensure everything is as it should be.

It’s Not New or Easy but it Works

We know this isn’t easy. In fact, it is exactly the kind of interdisciplinary hydra of a problem that makes security tricky. In our experience, starting small is good—it maximizes the likelihood of success.

Jump boxes are not a new idea, but they remain important for managing hardened assets. Nobody wants to inadvertently architect the demise of their own servers! Even if the literal implementation suggested here doesn’t align with your environment, the principle of segmenting managed assets from daily workstations is crucial, particularly considering the havoc that ransomware is wreaking on organizations big and small.

But Wait, There’s More

There is a much longer, more detailed version of this article available to F5 Labs email newsletter subscribers. Sign up today. We promise we’ll only email you once a week and only about F5 Labs happenings.