INTERNATIONAL ISO/IEC STANDARD 18028-1

ISO/IEC18028-1:2006(E)public networks. Each type of remote log-in should have additional controls appropriate to the nature of theconnection type. Control examples are:— not allowing direct access to system and network software from accounts used for remote access, exceptwhere additional authentication has been provided (see Clause 13.6.3 below), and perhaps end-to-endencryption,— protecting information associated with e-mail software and directory data stored on PCs and laptops usedoutside of an organization's offices by its personnel, from unauthorized access.13.6.3 Authentication EnhancementsThe use of user id/password pairs is a simple way to authenticate users, but they can be compromised orguessed. There are other more secure ways to authenticate users, particularly remote users. Authenticationenhancements should be required when a high possibility exists that an unauthorized person may gain accessto protected and important systems. This may be, for example, because the access may be initiated usingpublic networks, or the accessing system may be out of the direct control of the organization (e.g. via alaptop).Where authentication enhancements over network connections are required (for example, by contract) orjustified by the risks, an organization should consider strengthening the person authentication process byimplementing relevant controls.Simple examples are using:— CLID, which may be thought of as the originating telephone number seen by the receiving equipment.Although CLID has some value as being the claimed ID of the calling party, it is open to spoofing andshould not be used as a proven ID without further authentication. CLID is often used as a quick identifierin the establishment of backup links (especially over ISDN) between sites,— links via modems that are disconnected when not in use, and only connected after verification of thecaller's identity.More complex, but very important, examples - particularly in the context of remote access, are:— using other means of identification to support the authentication of users, such as remotely verified tokensand smart cards (e.g. through readers attached to PCs), hand held one time pass key generation devices,and biometric based facilities,— ensuring that the token or card can only function in conjunction with the authorized user's authenticatedaccount (and preferably, that user's PC and location/access point) and, for example, any related PIN orbiometric profile.Generically this is termed strong, two factor, authentication. If tokens are used, a user is required to know aPIN which with the token enables the production of a unique authentication value. With regard to smartcards,these can be viewed as automating the use of token access. In order to be 'opened', the user should supplythe PIN to the card after inserting it into the smartcard reader. Then, whenever authentication is required bythe central or remote systems, the smartcard may be 'called' directly to 'sign' data (proving authentication)using a key embedded in the smartcard.13.6.4 Remote System IdentificationAs implied in Clause 13.6.3 above, where relevant authentication should be enhanced by verification of thesystem (and its location/access point) from which external access is made.It should be recognized that different network architectures can offer differing identification capabilities. Thus,the organization may achieve enhanced identification by choosing an appropriate network architecture. Allsecurity control capabilities of the chosen network architecture should be considered.50 © ISO/IEC 2006 - All rights reserved