How logging and monitoring prevent damage to an application and its users
You’ve probably heard of the OWASP top ten or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of top ten vulnerabilities that threaten APIs, called the OWASP API top ten. The current API top ten are Broken Object Level Authorization, ****Broken User Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring. Today, let’s talk about the last vulnerability on the list: Insufficient Logging & Monitoring.
So far in our API security series, we’ve talked about measures that you can take to prevent malicious attacks against your API. For instance, we talked about Broken User Authentication and how you can implement authentication properly on API systems.
But what happens after an attacker finds a way to exploit your application or API?
After an attacker gains initial access to your system, they will start to utilize that initial foothold to explore and exploit the network. They might look for for more vulnerabilities that they can exploit on the machine, perform recon to discover other machines on the system, exploit new vulnerabilities they found on the system, establish persistent access to the system, or move across the network to steal data from other machines, and so on.
Cyber attacks do not happen within a few hours or even a few days. Attackers often need time to explore the network and construct suitable strategies to fully exploit the system and steal the data it contains. The longer an attacker is able to access the system without detection, the more likely the attacker would find a way exploit the system, steal data, and cause extensive damage to the application and its users. That’s why it’s essential to have a logging and monitoring system capable of detecting malicious activity as soon as possible.
Many organizations only conduct infrastructure logging like logging network events and server logins, and lack API or application specific monitoring infrastructure. If this is you, this means that you do not have insight into the malicious activities going on in your network. You need an API logging system that would be responsible for monitoring for abnormal API usage. You can log events such as input validation failures, authentication and authorization success and failures, application errors, and any other API events that deals with sensitive functionality like payment, account settings, and so on. Over time, you will be able to understand what normal usage of the API looks like, and detect suspicious activity that could be an attack.
That brings us to the second part of the equation. Once you set up logging and monitoring, make sure that you have an effective alert system in place in case of a security incident. After all, a monitoring system is only useful if its results could be delivered in time and to the right people. This way, your team can resolve the incident as soon as possible and limit the damage to your systems.
And that wraps up our our series about the OWASP API top ten! Which one of the OWASP API top ten do you see the most in your work? What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.
Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.