Answer yes if your organisation stores all recorded logs on dedicated servers that are logically separate from your production systems, and hardened.
What is the control?
In order to protect logs from being altered or deleted, they should be stored on a separate dedicated system. This means that if a system is compromised, the attacker will have access to that system’s local logs, but not those stored remotely on the separate logging system.
Why should I have it?
While local logging is useful to troubleshoot functional issues, the problem with using local logs for security reasons is that if a system is ever compromised there is no guarantee that the logs on that system have not also been compromised. In fact, it’s common practice for attackers to modify or delete logs to cover their tracks.
By having all systems forward their event logs in real time to a separate dedicated system such as a SIEM (which can be hardened and secured to a very high standard since it has no other function) we ensure that a system’s logs cannot be tampered with in the advent that system is compromised.
This has the additional benefit of storing all logs in a centralised location. This means not just an easier way to access and manage logs from across the entire environment but also allows you, like in the case of SIEM (Security Incident and Event Management) platforms, to perform useful correlation between those logs to detect and investigate potential incidents.
Your logging policy should dictate that your logs be stored on a centralised log platform. This system should be classified with your highest level of sensitivity and hardened and patched accordingly.
Ensure that the process of sending logs to the centralised server does not involve any mechanism where the submitting system can access the server or in any way overwrite any of the submitted logs.
There are numerous consultancies or individual consultants that will be able to assist in crafting the correct security architecture in a way that meets your business and technical requirements.
If you would like to contribute to this article or provide feedback, please email knowledge@riskledger.com. Contributors will be recognised on our contributors page.