Avoiding a Faux-PAW: Ditching my Beloved Jump Host

by Jonathan Lent


The Information Security Office (ISO) has created a set of Minimum Security Standards (MinSec), broken down with a matrix of applicability depending on the risk classification of a given system (low, medium, or high) [1]. Of these standards for high-risk systems, one requires the use of a dedicated admin workstation for administration (also known as a Privileged Access Workstation (PAW), or Personal Bastion Host (PBH)) [2]. Unlike many of the MinSec requirements, this standard doesn’t hinge so much on a technical implementation detail; rather, it requires a simple set of technical changes (firewall rules), along with a drastic change in daily workflows for folks like me.

Before I go into why shared jump hosts can be a source of risk, it’s important to maintain an open mind and reiterate why these setups can be useful. To be clear, by “jump host”, I mean a hardened server that is used to gain access to other resources. Without going into any implementation-specific details, jump hosts are often on the short list of machines (or the sole source) that can connect to various ports on endpoints. The machine ideally would be locked down to restrict authentication access (e.g. not only a carefully scrutinized list of users, but additional tweaks requiring specific protocols for access (e.g. Kerberos, rather than password authentication)). This is indeed more secure than some of the alternatives (e.g. world or domain-wide access to individual endpoints). With proper planning these hosts can be hardened to eliminate the potential for many issues outlined below. However, the weakest link in computer security often lies with the human element, and that’s one aspect of the shared model that cannot be ignored. Continue reading “Avoiding a Faux-PAW: Ditching my Beloved Jump Host”

Migrating away from WebAuth, practical steps

Stanford University is in the process of migrating from its homegrown authentication system, WebAuth, to the widely deployed and feature-rich SAML-based authentication. This brings a lot of benefits, like better compatibility, wider application support and easy federation with other institutions.

There are multiple SAML (Security Assertion Markup Language) implementations, but this article is focuses on two of them, Shibboleth and SimpleSAMLphp.

Shibboleth is well-documented and there are Stanford UIT documentation pages with high level descriptions of how it fits into the Stanford infrastructure. In this article I will talk about the practical steps one has to take to migrate from WebAuth to Shibboleth or SimpleSAMLphp, how to set them up and what adjustments have to be made to the configuration files on the SP (Service Provider) side.

Parts of the article are a rehash of the official UIT Shibboleth documentation with some corrections and explanations of the steps pertinent to the topic of migration from WebAuth. The content is based on our client’s questions and the issues we encountered while performing these migrations for our clients. Continue reading “Migrating away from WebAuth, practical steps”