IT Baseline Protection Manual S 4.128 Secure operation of Lotus Notes
S 4.128 Secure operation of Lotus Notes
Initiation responsibility: Head of IT Section, IT Security Management
Implementation responsibility: Administrator
The security of a complex system must be permanently maintained in operation, especially as system changes become necessary during ongoing operations. It is therefore not sufficient to create a secure initial configuration (see S 4.116 Secure installation of Lotus Notes and S 4.117 Secure configuration of a Lotus Notes server). The security aspects outlined below must be considered during ongoing operation of a Lotus Notes system.
The security offered by the mechanisms providing access to Lotus Notes servers and databases is based on authentication of users through their Notes ID, which is stored in a file. The system security thus depends directly on the secure handling of the Notes ID file. The security concept must therefore include guidelines for handling Notes ID files (see S 2.207 Defining security guidelines for Lotus Notes). The aspects which need to be considered here are summarised in safeguard S 4.129 Secure handling of Notes ID files.
Changes in a Notes system are especially necessary when new databases are created on a server. However, newly created databases are generally not yet integrated into the existing security structures. The installation of a database should therefore not be regarded as complete until as a minimum the steps summarised in safeguard S 4.130 Security measures following the creation of a new Lotus Notes database have been implemented. The authorisation to create new databases or to generate new database replicas can be explicitly controlled through appropriate access control lists (ACLs) (see S 4.119 Instituting restrictions on access to Lotus Notes servers).
Normally the data contained in different databases will differ as to its protection requirements (see also Section 2.2 "Determination of Protection Requirements"). As well as pure access control, Lotus Notes also offers facilities for encrypting databases. If on the basis of the assessment of protection requirements it is necessary for the data in a database to be protected with encryption, then the recommendations contained in S 4.131 Encryption of Lotus Notes databases should be considered.
To obtain a clear idea of how secure a Lotus Notes system actually is, it is necessary to monitor the system. The aim of such monitoring is to discover any violations of the applicable security provisions, identify any existing security weaknesses and detect any configuration errors which could potentially result in security loopholes. The IT security concept should include a corresponding monitoring concept. Usually it is not feasible these days for complex systems like Lotus Notes to be monitored manually by individual Administrators, but monitoring must be automated, using appropriate system components or products of third party vendors. The configuration of the monitoring must be regularly adapted to the system as it changes. The recommendations regarding monitoring are summarised in S 4.132 Monitoring of a Lotus Notes system.
An important aspect of the security of a Lotus Notes system is the consistent administration of users and authorisations. The administrative concept affects the complexity of the administrative tasks that have to be carried out. Complex processes can, however, encourage the development of configuration errors. To be sure that the system really is secure, the administrative tasks should therefore be as simple as possible. The access concept should therefore be based on groups. This will significantly simplify the administration of rights of access to databases, making it less error prone. For example, a "Termination Group" could be defined as part of the group concept, into which all "deleted" users are transferred and to which all rights are explicitly refused.
Note: under version 4.x groups can only contain a certain number of users as these are stored in a corresponding field in the server document. Once the maximum field size is reached, a group no longer functions correctly. Where a group has a large number of members (e.g. all the users of a server, Termination Group etc), nesting of groups is therefore recommended.
The security settings of a server should be regularly checked.
The log files of a server should be regularly checked. This can be done manually or using tools.
Examples:
Group-based access concept
An employee moves to a different department, with the result that his access rights need to be amended.
If user-specific ACLs are used, then every database has to be modified to either remove the user from the ACL or add him to the ACL.
If group-specific ACLs are used, then the administrative task entails simply removing the user from or adding him to the relevant groups as required. The change can be made centrally to the user object.
Termination Group
An employee leaves the company. By mistake his account is not removed from a Notes group. Through this group membership, moreover, the former employee has rights enabling him to access the Notes server. However, since his Notes account has been added to the Termination Group, he cannot access the server. The reason is that the Termination Group is explicitly denied access to the server (and its databases) and denials take priority over concessions of access rights.
Additional controls:
Are the security settings on Notes servers regularly checked?
Are the log files for Notes servers regularly checked?
