Browse Prior Art Database

Automatic seamless admission to support personnel during maintenance mode, while denying that access, during normal system operation

IP.com Disclosure Number: IPCOM000129865D
Original Publication Date: 2005-Oct-07
Included in the Prior Art Database: 2005-Oct-07
Document File: 2 page(s) / 42K

Publishing Venue

IBM

Abstract

Described here is an automatic back-door method that allows support personnel access to a system in case of a support incident, yet denies support personnel access to the system under normal operation of the system.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Automatic seamless admission to support personnel during maintenance mode, while denying that access, during normal system operation

Although vendors strive to provide customer support based on pre-package dump information to be analyzed off line, it is also very beneficial and sometimes essential for support personnel to login to a customer's machine to debug a problem on-line. Customers in general are not too keen to allow free access to their systems for business reasons and, of course, because of security concerns. To answer such conflicting requirements, the vendor may let the customer decide when to let the vendor in for support purposes. Once the customer gives his approval, the support personnel must use some kind of secured access method, such as a password or, better yet, a Challenge/Response (since a fixed password might be too much of an exposure). The effectiveness of the password or Challenge/Response method depends on the health of the system at hand. For example, the customer's problem might be such that the password subsystem or the Challenge/Response is also not working, for instance because the customer has changed the password and forgotten it. It would be helpful, even necessary to have a backup method or plan to try, in any case, to login into the customer's system. Described here is an automatic back-door method that allows support personnel access to the system in case of a support incident, yet denies support personnel access to the system under normal operation of the system.

    It is assumed that there is a mechanism for a given cluster of nodes to agree/exchange their public/private keys (regardless whether it is a software technique or a hardware technique). The expectation is that the keys generated through that mechanism are unique to the cluster at hand, so neither an intruder nor support personnel (turned bad/hacker) can break in . This controlled/"closed" environment provides customers the level of security they want during the normal mode of operation and protects their data. The hidden assumption is that when crisis hits and the customer needs help from support, he will be willing to let the support personnel login to debug/fix the problem as quickly as possible.

    The "normal" method of allowing access to support personnel can be through a one-time password and/or a response/challenge interface, which can be enabled/disabled by the customer. Going through the paperwork to allow access to support personnel might take too long (especially if the crisis strikes at night and the customer is not around even to notice the incident, although the system has). Also, if for some reason the password method fails (for example, because the password has been ch...