S 4.292 Logging of VoIP events

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

When communicating using VoIP, numerous pieces of information can be logged. Usually, certain status information from the VoIP middleware needs to be logged to ensure smooth operation. Only regular evaluation of this log data makes it possible to evaluate the devices to ensure they are operating properly and to detect any attempted attacks. With the help of the logged information, it is often possible to determine the type of attack attempted and to modify the configuration accordingly as a consequence.

Careful configuration of the logging function is especially important since it is only possible to extract the relevant data from the mass of information generated using appropriate filters.

Depending on the type of event logged, it may be necessary to react quickly. The log data must be evaluated regularly for this purpose.

On the one hand, the logging functions can contribute to the ability to track the VoIP operations. On the other hand, though, it may be possible to abuse the logging functions to violate the IT security or compromise the data protection. For this reason, it must be systematically specified which mandatory information needs to be logged and how the log data will be regularly evaluated. In any case, the Data Protection Officer and the Personnel Board or Supervisory Board must also be allowed to participate in the evaluation (see also S 2.110 Data protection guidelines for logging procedures). The amount of information logged and the criteria for its evaluation should be documented and co-ordinated in the organisation. If necessary, any other committees having a say in this matter should become involved early on.

Logging the signalling information

A large amount of information can be obtained by evaluating the signalisation. The following data should be recorded on a SIP proxy, gatekeeper, or gateway:

• Who called whom?
• How long was the call?
• Did the person called pick up the telephone?
• From which network was the call made and which IP address was used?
• Which media transport protocols and codecs were negotiated?

This information can be used for cost accounting purposes or to optimise the VoIP infrastructure, for example.

Logging the media transport

By recording the logs at a suitable location in the network, it is possible under certain conditions to record the actual conversation. For calls that leave the network from a defined location, for example over a proxy, the logging information can be recorded directly at the defined location.

A proxy is often unnecessary for internal calls. It is also possible in general, though, to record the contents of a call in this case as well, for example on the end devices or routers used.

If the cryptographic key is negotiated directly by the devices taking part in the call when using an effectively encrypted media transport, then less information can be recorded at the central location.

Logging the system status information

In addition to the information mentioned above, the following information should also be logged on the VoIP middleware, if possible:

• all direct logins to the appliance or to the IT system,
• changes to the configuration,
• failed attempts to log in to the VoIP service,
• system errors,
• load,
• changes to the user administration (the creation or deletion of users, changes to the telephone numbers assigned to users, etc.),
• hardware malfunctions that could lead to the failure of an IT system,
• important system events on the IT system running the VoIP application software. Additional information on this subject can be found in the corresponding IT-Grundschutz modules for the operating system.

Central administration of the log data

It is recommended to send the log data over the network to a separate syslog server. This server is then used to collect, archive, and evaluate the log data at a central location since there are usually not enough resources available for this purpose on the VoIP appliances. In addition, this also offers the advantage that an attacker will not be able to directly change or delete any log data already transmitted when a device becomes compromised.

If the log data is transmitted to the syslog server in unencrypted form, then it is possible to listen in on the transmission route. For this reason, the log data should either only be stored on the server itself or transmitted in encrypted form over a separate network (administration network).

Time synchronisation

A correct time stamp should be applied to all log data, if possible. This is necessary to permit effective evaluation of this data, especially when analysing attempted, or successful, attacks. For this reason, a corresponding server should be installed in the internal network that provides all systems with the correct time. The time server can use the NTP service for this purpose, for example (see S 4.227 Use of a local NTP server for time synchronisation).

Review questions:

• Is there a rule governing the prompt evaluation of log data?
• Is there a rule for improving the security level based on the log evaluation?
• Is there a rule governing the definition of content and extent of the events and information to be logged?
• Do the protocols and paths for logging and administration conform to the current state of the art?
• Is there a rule governing the uniform configuration and monitoring of parameters?