S 6.102 Procedures in the event of WLAN security incidents

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, User

If the WLAN does not respond as intended (e.g. the WLAN is unavailable for a long period of time, access to network resources is impossible, or the network performance is reduced for a long period of time), this may be caused by a security incident. This can be brought about by an attacker, faulty configurations, or system errors.

In this case, users should take the following items into consideration:

• They should save the results of their work, terminate the WLAN connection, and disable the WLAN interface on their client.
• If error messages are displayed or the client does not respond normally, the users should document the response as precisely as possible. Likewise, the user should also document what he/she was doing before and during the security incident. This allows the administrators to quickly limit the number of possible reasons for the incident and promptly initiate countermeasures.
• The administrators must be informed by the users using a suitable escalation level (e.g. user help desk). It must be ensured in this case that the ability of the administrators to do their work is not significantly impaired by the notification process.

The administrators should initiate appropriate countermeasures when a security incident occurs. Examples of possible actions include:

• switching off access points
• blocking communication on the connection point between the distribution system and the LAN / internet
• shutting down the servers (web servers, control servers in the production environment, and such like)
• deactivating the WLAN interface of the WLAN client
• checking the configurations of the access points
• saving all files that could provide clues as to the type and cause of the problem encountered (for example, if there really was an attack and how the attacker was able to penetrate the system), i.e. in particular, backing up all relevant log files.
• restoring the original configuration data if necessary (see S 6.52 Regular backup of configuration data of active network components)
• informing the users with a request to check their work areas for any irregularities.

If access points have been stolen, specific security safeguards must be taken, for example:

• changing all cryptographic keys used, meaning the PSKs when using WPA-PSK or WPA2-PSK, for example
• changing the configuration on the RADIUS servers to exclude the stolen access point (IP, name, RADIUS client, shared secret, IPSec)

The possible consequences of events critical to security must be examined. Finally, all safeguards necessary to make it impossible to use stolen devices to gain access to the network of the organisation must be implemented. If a WLAN client is stolen, the client certificates must also be blocked if a certificate-based authentication method is used.

Review questions:

• Have the corresponding escalation levels been defined for security incidents?
• Have the employees responsible for handling QLAN security incidents been appointed?
• Have behavioural rules and safeguards been defined for security incidents in the WLAN?