Unit 4
Collaborative discussion post
Read Berger. (2024) and Nyangaresi, V. O. et al. (2024) and then post your thoughts on the issues of logging for security analysis versus the issues of log-related exploits. You should support your arguments with appropriate academic references.
Logging is an important aspect of application development and infrastructure and network management. Collected information is invaluable for developing and debugging applications, improving operational performance, analysing tendencies, and optimising processes. Besides these benefits for day-to-day operations, logs also support and enhance security operations in an organisation. They allow detecting ongoing attacks by highlighting anomalies and aid in later investigations. Other possible use cases include compliance and policy monitoring or collection of data for later requests, e.g. by law enforcement (OWASP Foundation, 2025). Another important aspect is that data processors must keep logs to monitor how the information is accessed, modified, or disclosed according to the UK GDPR (Information Commissioner’s Office, 2024).
At the same time, logging functionality itself can become a target for adversaries. Log often contain large amounts of information about how the application or the infrastructure is running, and misconfiguration or oversight may lead to exposure of confidential information through logs, like described in CWE-532 Insertion of Sensitive Information into Log File (The MITRE Corporation, no date). Another example of an attack on logging software is the Log4Shell exploit that affected the commonly used library Log4j, where it was possible to execute arbitrary code on a remote server. This became possible because logging user-provided data were logged without sanitisation. It is estimated that the vulnerability affected nearly 10 % of digital assets worldwide (Hill, 2022; Berger, 2023; IBM, 2023).
So, while logging is beneficial and in most cases essential and required by law, if implemented incorrectly, carelessly, or with vulnerable components, logging functionality turns from an asset into a liability. Therefore, software developers must exercise caution and understand the nature of the data they preserve as log records. Code reviews and audits may help detect possible data disclosure via logs or missing sanitisation of user input that can later be processed by logging mechanisms.
References
Berger, A. (2023) ‘What is Log4Shell? The Log4j vulnerability explained (and what to do about it)’, Dynatrace news, 2 March. Available at: https://www.dynatrace.com/news/blog/what-is-log4shell/ (Accessed: 28 July 2025).
Hill, M. (2022) ‘The Apache Log4j vulnerabilities: A timeline’, CSO Online, 7 January. Available at: https://www.csoonline.com/article/571797/the-apache-log4j-vulnerabilities-a-timeline.html (Accessed: 3 September 2025).
IBM (2023) What is Log4Shell? Available at: https://www.ibm.com/think/topics/log4shell (Accessed: 3 September 2025).
Information Commissioner’s Office (2024) Logging. ICO. Available at: https://ico.org.uk/for-organisations/law-enforcement/guide-to-le-processing/accountability-and-governance/logging/ (Accessed: 3 September 2025).
OWASP Foundation (2025) Logging - OWASP Cheat Sheet Series. Available at: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html (Accessed: 3 September 2025).
The MITRE Corporation (no date) CWE - CWE-532: Insertion of Sensitive Information into Log File (4.17). Available at: https://cwe.mitre.org/data/definitions/532.html (Accessed: 3 September 2025).
Seminar presentation
Read Swinhoe, D., 2020. The 15 Biggest Data Breaches of the 21st Century.
Select one of the cases quoted and then complete a breach checklist as discussed in the required reading (reproduced below):
- What types of data were affected?
- What happened?
- Who was responsible?
- Were any escalation(s) stopped - how?
- Was the Business Continuity Plan instigated?
- Was the ICO notified?
- Were affected individuals notified?
- What were the social, legal and ethical implications of the decisions made?
If you had been the ISM for the organisation you selected, what mitigations would you have put in place to stop any reoccurrences?