|
|
Initiation responsibility: Head of IT Section, IT Security Management
Implementation responsibility: IT Security Management
Before a start can be made on the actual configuration and installation of Windows NT in a client-server network, two fundamental observations must first be made:
First of all, it must be clarified which services are to be provided by the operating system and in what context it is to be used.
This can be illustrated using a number of examples:
Extra security problems can arise as a result of the use of Peer-to-Peer functions within a Windows NT network (in this respect see also Chapter 6.3 Peer-to-Peer network). For this reason the use of Peer-to-Peer functions within Windows NT networks should be avoided. Peer-to-Peer functions should, at best, be allowed as a temporary solution in a restricted way, if, for example, WfW computers or non-networkable printers are to be integrated into the Windows NT network.
Following this, the above considerations must be translated into a security strategy.
Here it can be seen that depending on the already existing system environment and organisational structure, together with the restrictions on possible Peer-to-Peer functions that may have to be allowed for, a greater or lesser effort is necessary in the development of a suitable security strategy.
A methodical procedure is shown below which can be used to develop a comprehensive security strategy for a client-server network. However, as Windows NT can be deployed in various configurations, an individual decision should be taken for the respective characteristic as to which of the steps outlined should be applied.
Determining a security strategy for a client-server network
The security strategy must demonstrate how a client-server network for the respective organisation can be securely constructed, administrated and operated. The individual development steps of such a strategy are presented below:
1. Definition of the client-server network structure
The first step involves determining the logical structure of the client-server network, in particular the allocation of the servers and the network domains (see S 2.93 Planning of a Windows NT network). If possible, the use of Peer-to-Peer functions should be dispensed with, as these can adversely affect the security of the client-server network. Provided that this cannot be avoided, however, binding rules must be made for the use of Peer-to-Peer functions (see S 2.67 Defining a security strategy for Peer-to-Peer networks).
2. Regulation of responsibilities
A client-server network should be operated securely by a trained network administrator together with a substitute. Only these individuals should be allowed to alter security parameters in the network. For example, they are responsible for making administration rights and tools available to the relevant individuals in charge on the servers, so that the latter can allocate file and directory rights, share directories and applications required by others, configure user groups and accounts, and set system guidelines for users, access supervision and monitoring.
The responsibilities of the individual users in the client-server network are outlined under Step 11.
3. Determining name conventions
In order to facilitate the management of the client-server network, unambiguous names should be used for the computers, user groups and users.
In addition, naming conventions should be introduced for the share names of directories or printers (see S 2.67 Defining a security strategy for Peer-to-Peer networks). Should no conclusions be possible on the contents of a shared directory, appropriate pseudonyms must be used. Should a shared resource not be recognisable as such, the symbol "$" must be attached to the share name. The latter is always recommended whenever directories are shared only for the bilateral exchange of information between two users or for accessing resources which are only meant to be known to individual users.
4. Determining the rules for user accounts
Before user accounts are set up, the restrictions intended to apply to all, or a certain number, of these accounts should be stipulated. In particular, this concerns the rules for passwords and for the reaction of the system to incorrect log-in procedures. The rules laid down can be implemented with the aid of the "Policies" option of the User Manager (see S 4.48 Password protection under Windows NT).
5. Configuring groups
To facilitate administration, user accounts which need to fulfil identical requirements should be coalesced into groups. User rights such as file, directory and sharing rights as well as any additional, pre-defined functions are then assigned to these groups instead of individual user accounts. The user accounts inherit the rights and authorisations of the groups to which they belong. For example, all the staff members of a particular department can be coalesced into one group. Rights and authorisations should only be allocated to individual users in exceptional situations.
6. Determining user rights
Rights allow a user to perform certain actions on the system. They refer to the entire system, are not assigned to any special object, and can annul the authorisations to an object, as a right takes precedence over all file and directory authorisations. Whenever a user logs into an account to which the desired rights were granted either directly or via group membership, he can perform the corresponding actions. If a user does not possess the appropriate rights, Windows NT stops all attempts to carry out the actions concerned.
As already mentioned, user rights should be assigned to groups instead of individual users wherever possible.
During installation, Windows NT performs default settings which are generally adequate for secure and efficient operation. However, it is advisable to withdraw the "Shut down system" and "Local login" rights from the "Everyone" group and, if applicable, the "Local login" right from the "Guests" group (refer to S 4.50 Structured system administration under Windows NT).
7. Determining the specifications for logging
Windows NT provides very detailed capabilities for the logging of incidents relevant to security which, when used to the full, are capable of occupying the system to a large extent with auditing and consume large amounts of disk space in the process. A spectrum of incident types can be recorded which extends from system-wide incidents, such as, for example, the log-on of a user through to a user attempting to read a certain file. Both the successful and the failed attempts to perform an action can be recorded. In the configuration of the logging, however, it must be noted that an increase in logging does not necessarily also increase the security of the monitored system. Log files which are not evaluated or which, on account of their size, can only be evaluated with great effort, do not lead to improved supervision of the system sequences; on the contrary, they are ultimately useless. For these reasons, logging should be set in such a way that under normal circumstances it only records the really significant incidents (see S 4.54 Logging under Windows NT).
8. Rules concerning data storage
A specification is required as to where user data should be stored (refer to S 2.138 Structured data storage). In some cases, for example, it is advisable to store user data only on a server. This model does not permit a storage of data on local hard disks. However, it is also conceivable to store certain user data only on a local hard disk. The strategy to be employed must be ascertained in accordance with the circumstances applicable in each case. A general recommendation is not possible here.
9. Setting up project directories
In order to achieve a clean separation of user and specific project data from each other and from the programs and data of the operating system, a suitable directory structure should be established to support a project and user-based file system. Thus, for example, two main directories \Projects and \Users can be created, under which the files and directories of the projects and users are each then filed in their own sub-directories.
10. Allocating access rights
For the servers, it must be determined which directories and - if NTFS partitions are used - files should be shared for access, and which access rights should be assigned to them (refer to S 4.53 Restrictive allocation of access rights to files and directories under Windows NT). In addition, as far as the use of Peer-to-Peer functions at the level of the clients is concerned, a decision must be taken as to which directories should be shared for network access (see S 2.94 Sharing of directories under Windows NT).
The above comments also apply to the sharing of printers.
11. Responsibilities for administrators and users in the client-server network
Besides the discharging of network management tasks (see No. 2), further responsibilities must be determined. It should be laid down which responsibility the individual administrators have to assume in the client-server network. These can, for example, be responsibilities for
In a client-server network the end-users must also take on certain responsibilities, provided that they are given rights to perform administrative functions. In general, these responsibilities are restricted however to the allocation of access rights to their own files, provided that these are explicitly stipulated and not assumed by the presets of the superior directory.
12. Training
Finally it must be determined which users have to be trained on which topics. Effective operation can only begin after adequate training. In particular, the administrators must be thoroughly trained with regard to the management and security of Windows NT.
The security strategy developed in this way must be documented and communicated to the required extent to the users of the client-server network.
Additional controls:
| © Copyright
by Bundesamt für Sicherheit in der Informationstechnik |
July 1999 |