API10:2019 Insufficient Logging & Monitoring
|Threat agents/attack vectors||Security weakness||Impacts|
|This vulnerability can not be exploited in its own right but what it does is help any potential attacker stay unnoticed. Depending on how much of the logging and monitoring is insufficient, the attacker can either stay unnoticed for longer or even not be noticed at all.||Should anything happen on our system that needs investigation, we have no way of doing so if our logging and monitoring are insufficient and we probably would not even know we'd have something to investigate because of the insufficient monitoring.||If we do not implement sufficient logging and monitoring, attackers are free to take their time and investigate the situation before they strike and even after striking, we would have no way of either knowing or following up on the attack.|
What is Insufficient Logging & Monitoring?
The title already says a lot but this vulnerability is a bit more complexity than it was at first sight, of course the API is vulnerable if it does not create any log entries or when the log level is set incorrectly but we should not neglect to also check whether or not the contents of the log messages are what is expected and that they contain enough detail.
A second aspect that is a bit harder to control is the log integrity, for example a malicious user might insert a special character that when written to the log breaks it. This is known as log injection and it could nullify all the logging efforts made.
When we finally have a clear plan of what to log, when and on what environment we need to ensure we are monitoring these logs, failure to do so would result in a massive decrease in the efficiency of our logging efforts.
Monitor everything, not just the logs but make you monitor the APIs and the infrastructure as well.
How does Insufficient Logging & Monitoring affect business?
The impact from a business perspective can be seen in several aspects. To start with confidantiality since often logs contain personal information that the victin would rather not share with the world. You really want to protect the logs from any attackers as this can have a severe impact.
For that same reason we should ensure that any data that goes into the logs is sanitised to the same level of scrutiny as other vulnerability types like XSS for example. A log pollution attack can nullify our attempts to log proper, sanitised and sufficient data.
In any case if we do not have sufficient logging and an attack does happen, we have no real way of tracing the call.
Though it may be important to log things, we should not go overboard as every log entry has a cost to it in the form of resources, this is why it's so important to pick exactly the right amount of logging. If you log too much or don't put rate limiting on logging endpoints an attacker could perform a DoS attack by consuming all the resources the server has to log their calls.
Lastely, should an external audit ever happen, we would have no way of proving our true intentions due to missing audit trails.
Example Attack Scenarios
A log entry might be in CSV form, if the attacker knows this, they might insert a malicious character such as a comma character ( ,) which the CSV log will interpret as a new column thus breaking the code and the logs. Especially if the logs are being monitored since this might break the monitoring tool as well which is expecting a certain format but it will have lines with too many columns.
name,lastname,email test,test,firstname.lastname@example.org test2,test2,email@example.com test3,te,st3,firstname.lastname@example.org
A second example would be an attacker gaining access to a system and being able to get customers data for 9 years without alerting any of the monitoring tools. What's really scary is this happened a while ago (https://healthitsecurity.com/news/insurer-dominion-national-reports-server-hack-that-began-august-2010).
Preventive measures against Insufficient Logging & Monitoring?
- We should log any authetication calls and at a minimum failed calls. This can be a 403 forbidden status code but also any input validation.
- How we log is also partially decided by the log management systems since the logs we create should be able to be consumed by said systems. The formats of our logs should match the expected format for the management solution.
- Log should be treated with the utmost respect towards peoples privacy in mind, they should be kept safe and stranspoted safe.
- Logging is needed but we should also set up a 24/7 monitoring system that monitors our logs, infrastructure and API endpoints. We should get an alert from this system if a breach occurs.
- Security Information and Event Management (SIEM) systems can be used to aggregate logs from all components of the API technology stack and the virtual hosts.
- The catch an attacker earlier, set up custom dashboards and alerting fit for your environment.
Insufficient Logging & Monitoring may not seem to be impactful at first but like with any issue type, if we look under the hood there is much more to be found. If there is not sufficient logging an attacker can roam freely and take their time and even if there was enough logging, that is no guarantee that there will also be monitoring to watch those logs. Given the severity of this type and what it can do though, it would not be wise to ignore logging and monitoring until the last minute and to bake it into the designs of the software that's created.