Possible Consequences of an Attack

OWASP mentions the following three attack scenarios as examples in the documentation of the Top 10:

1. The server of an open source forum software developed by a small team was compromised by a vulnerability in its own software. The attacker was able to delete the internal source code repository with the next version of the software and all forum content. Although the source code could be recovered, the lack of monitoring, logging, or alerting led to a much worse leak. As a result, the project is no longer active. Although this is a good example, why did the attacker delete the source code repository? Unless they were acting on behalf of a competitor or were simply interested in vandalism, they did not gain anything by doing so. It would make more sense (for the attacker) to install a hidden backdoor in the next version of the forum software, through which they could later compromise all servers running this software. Because nothing was monitored, this kind of manipulation would very probably have gone unnoticed.
2. An attacker scanned for users with a common password to hijack the affected user accounts. For all unaffected users, this scan only created a single failed login attempt. After a few days, the attack would be tried again with a different password, and so on. Without adequate monitoring, this attack remained undetected.
3. A large retailer in the US used an internal analysis sandbox to check attachments for malware. It detected potentially undesirable software, but no one responded to the reports. The sandbox output warnings for some time, but they were ignored. A successful attack was only noticed when suspicious card transactions were noticed by an external bank. In this case, there seemed to be a misconfiguration. Why were the suspicious attachments delivered to the users so that they could cause harm? They should have been quarantined or even deleted. Under no circumstances should they reach the recipients.

In all three cases, the attack could very probably have been fended off by good logging and monitoring – or at least stopped at an early stage.

Preventing Insufficient Logging and Monitoring

Depending on the need for data security, various measures are required. In general, you should ensure that every login and error detected by access control and server-side input validation is logged with as much user context as necessary to identify suspicious or malicious user accounts and for a sufficiently long period of time so that the data is also available for forensic analysis. Of course, data protection regulations must be observed – you cannot simply start storing all data for all eternity. Personal data, which includes not only the user ID but also the IP address used, may only be stored within the framework of legal regulations.

Also ensure that all logfiles are generated in a format that can be processed by a centralized logfile management solution and that an audit trail with integrity checks is created for valuable transactions to prevent manipulation or deletion. You can achieve this, for example, by using append-only database tables.

You can also implement effective monitoring and alerting so you can identify suspicious activities early and respond appropriately. An incident response and recovery plan can trigger predefined procedures in the event of an attack, as well.

So far, the main focus has been on monitoring the web server. This tempting target is accessible from the outside and is interesting for many attackers. However, an attacker has many more possibilities as to where and how to strike, and these attacks must also be detected and fended off as early as possible.

First Plan, Then Configure

You must choose wisely what data is relevant for logging. If too much is logged, the interesting messages are lost in the background noise. In the worst case, if available storage space is insufficient, the messages are discarded or overwritten by unimportant messages.

The opposite case should not be underestimated either: If logging is not sufficiently planned, some systems or applications might not be monitored at all, or at least not sufficiently. As a result, security-relevant events will not be identified and handled appropriately on those components of the overall system.

However, correct planning is only half the battle, because logging also requires correct configuration; otherwise, important information might not be logged at all or not sufficiently – in contradiction of company policy. Also, logs could be inconsistent or in the wrong format, which makes evaluation difficult or even impossible. Similarly, misconfiguration can cause data to be logged that should not be logged (e.g., personal data). Even if all relevant data is available, though, you could still run up against problems, such as the failure to synchronize time on all systems so that some data cannot be assigned correctly.