I’ve been getting a steady stream of client questions of the form: “We have outsourced a lot of IT admin functions – how do we limit what the vendor or outsourcer can do when they remotely connect to us?”
In the bad old days there were a lot of single server dial-in modems or modem banks to allow vendors remote console access. The security problems of modem-based access were replaced with the security problems of Internet VPN-based access. Letting vendors/outsourced IT personnel SSH to every individual server directly has huge security issues; having the remote external people VPN to the edge and have full network access is worse. Trying to segment internally or use NAT is hard and expensive.
There are host based approaches to what Ant Allan of Gartner calls “Super User Privilege Management” but that approach can be expensive and leaves open the possibility of mis-managed servers not having the SUPM agent installed and away you go. So, what has been emerging is a class of products that are network-based – essentially VPN gateways for limiting and auditing remote privileged access. These are not SSL VPNs or portals – they go beyond HTTP and support the major complex/dirty protocols that system administrators need to use, like SSH, Telnet, FTP, RDP, etc. Many of them support command line filtering to limit what console-type actions can be initiated (like preventing Telnet, for example) and support full session auditing and change logging.
It is another example of the network-based approach solving 80% of the problem with 20% of the fuss. Basically, funnel all your vendor remote access through a single access gateway and do role-based access, command line filtering for very granular access control and have full session auditing. Ant will be coming out with a research note detailing this area but some of the products we’ve seen in the emerging space are from Axeda, Cryptek ION, Rohati, Uplogix and Xceedium.
They all take slightly different approaches to the problems and use slightly different terminology. The holy grail: when you issue a trouble ticket for an administrative action, have that ticket serve to open access for a specific person to a specific machine (or set of machines) for a limited set of specific actions and to have that access removed when the ticket is closed. There are more elegant ways to do this, but most of those approaches will more talk than action for years – these technologies are in use solving problems today.
1 response so far ↓
1 Rob Lewis // Oct 30, 2008 at 9:42 am
John,
We solve this problem very easily. Our technology is a security sub-system that turns networks into distributed MLS enclaves in an otherwise discretionary environment. Fine grained access and audit control at the data file level, on a per user basis, is enforced at the kernel level.
With this technology, all one has to do is create a specific user group that includes only the vendor partner(s) and your enterprise liaison with a definitive policy about what your staff person can bring into that user group. The policies are based on users, roles and groups, or in the language of the business rules, so they are very intuitive. Rather than ACLs, a couple of rules are usually all that are required. A vendor partner can also be removed, or access privileges changed, in minutes.
Even if the vendor partner’s own systems get owned, no one can ever tunnel past that user group from outside, and if the enterprise provides a laptop with our brand of MAC, MLS security on it to access their information, that laptop will not be owned either.
Sorry if I appear to be crossing the line into “selling” in any way. I am only trying to respond to your post topic.
Leave a Comment