S 6.67 Use of detection measures for security incidents

Initiation responsibility: IT Security Officer

Implementation responsibility: IT Security Officer

It is also essential to detect security incidents in addition to preventing them. There are a number of security-related irregularities that can be detected automatically, and therefore early, using the corresponding technical aids. These detection measures usually increase the reliability of the detection and drastically reduce the time between the occurrence and the detection of an irregularity. However, the response capabilities and response time gained come in conjunction with the additional time and effort required for their implementation and monitoring, which should be estimated in advance. Such detection measures are practically indispensable in cases where a damage event has the potential to cause a great deal of damage, and possibly even personal injury.

The following are examples of such technical detection measures:

• intruder and fire detection systems (see S 1.18 Intruder and fire detection devices),
• remote malfunction indicators (see S 1.31 Remote indication of malfunctions),
• computer virus scanners (see S 2.164 Selection of a suitable virus protection program),
• intrusion detection and intrusion response systems (see S 5.71 Intrusion detection and intrusion response systems),
• cryptographic checksums (see S 4.34 Using encryption, checksums, or digital signatures),
• use of a real-time security monitor for z/OS systems to enable fast detection of security violations,
• use of a centralised log file analyses to detect any attacks to IT systems.

Not all security incidents can be detected quickly using technical safeguards alone. In many cases, additional organisational safeguards also need to be implemented. The reliability of technical detection measures generally depends on how up-to-date they are and how well they have been adapted to the actual conditions. The reliability of organisational detection measures is highly dependent on the reliability of the people assigned to implement them, but also on the extent to which the measures can actually be implemented in ongoing operations. The suitability of all detection measures must be checked regularly.

Typical examples of detection measures that are partially or entirely of an organisational nature include the following:

• obtaining information on security gaps (see S 2.35 Obtaining information on security weaknesses of the system),
• regular security checks of selected IT systems (see S 4.93 Regular integrity checking, S 5.8 Regular security checks of the network, and S 5.141 Regular security checks of WLANs, for example),
• regular evaluation of log files (see S 2.64 Checking the log files, S 4.5 Logging for telecommunication systems, S 4.25 Use of logging in Unix systems, S 4.47 Logging of security gateway activities, and S 5.9 Logging at the server, for example),
• evaluation of SMF data records in z/OS (see S 2.291 Security reporting and security audits under z/OS). Information from the SMF records can be used for batch reports or as a data source for real-time security monitors, which in turn can control a central control console. Such central consoles are offered by various manufacturers in connection with automation products.

An overview of the detection measures used should be available.

The security incidents detected should be registered as incidents immediately so that they can be clearly documented from the time of their initial detection until their resolution. For this reason, the systems in which this information will be recorded must be specified. In addition, the service desk must know which information needs to be recorded when a security incident is reported (provided that it is possible to determine from the report if the incident is actually a security incident).

Review questions:

• Is an overview of the detection measures used available?
• Is the suitability of the detection measures used checked regularly?
• Is it ensured that irregularities in log files are detected and reported?
• Does incident management know which information it needs to record when a security incident is initially reported?
• Is it ensured that the security incidents detected are registered as incidents, and has it been specified which systems should be used to record this information?