Protecting Logs

One more point is easily overlooked: the need to protect the logged data. Some systems or applications do log personal information (e.g., usernames, IP or email addresses, etc.). You need to protect these logfiles just as well as the stored or processed data itself; otherwise, although an attacker might not be able to sniff out the well-protected primary data, he could access the information because the logging data is transmitted and stored without encryption.

Protection of confidentiality and integrity also is necessary for all other logged data, even if the data does not contain sensitive information. In this case, the logs themselves are data worthy of protection: If an attacker can manipulate or delete the logs, they can mask their attack.

Logging Requirements

When it comes to logging requirements, creating a security policy takes top priority. Before the IT manager can begin the implementation, they need to know who logs what, how, and where. The policy lays down the essential requirements:

• Define a person responsible for logging and determine what should (and may) be logged.
• List the existing logging functions and define a location for storing the logs.
• Ensure that the logging complies with all legal frameworks.
• Synchronize the system time of all logging systems and applications and use the same time and date format for all logfiles.

Finally, you need to evaluate the acquired information and respond to security-related incidents. This step can be endangered by inadequate qualifications of the responsible persons, missing or inadequate logging, or faulty administration of the detection systems used – thus, the importance of creating a security policy as the first requirement, this time to ensure the detection of security-related incidents.

To react quickly and effectively to detected attacks, a predefined and proven procedure for handling security incidents is required. As always, the first step is to determine who has to do what and when. A test of these processes is also very important, because in an emergency, the detected security incident, usually an attack but sometimes only a misconfiguration, must be resolved as quickly as possible.

Additionally, evidence for the forensic investigation must be secured, or at least not destroyed. Once the incident is resolved, the IT manager must investigate how it happened, what happened, and what the consequences of the attack are. In contrast to most other building blocks, you do not have to create a security policy first, but rather a policy with the initial response to be taken. At an early stage it is also advisable to consider whether your own forensic team or a service provider should carry out the forensic investigation.

Conclusions

To react appropriately to security-related incidents, whether targeted attacks, standard malware, or a misconfiguration, the IT manager must have a plan that the IT team follows in the event of an incident. These incidents must be detected in the first place, which is only possible with suitable and continuously evaluated logs. Deficiencies in logging or monitoring lead to attacks not being detected at all or being detected only when it is too late, which is why insufficient logging and monitoring has quite rightly found its way into the current OWASP Top 10.