Rounding out the bottom of the list at #10 is insufficient logging & monitoring. With the recent growth of web-based applications, it is more important than ever to keep security in mind when developing or maintaining these applications.
The Open Web Application Security Project (OWASP) has a list of what they believe are the top 10 vulnerabilities in web-based applications. This blog series will be enumerating through that list, including a few additional suggestions, hopefully leading to more secure applications.
According to OWASP, an application has insufficient logging & monitoring when auditable events are “not logged, monitored, unclear, or are only locally stored; the application is unable to detect, escalate, or alert for active attacks; or penetration testing scans do not trigger alerts.”
Auditable Events and Unmonitored Logs
According to the National Institute of Standards and Technology (NIST), an audit record should contain “security event information such as successful and failed authentication attempts, file accesses, security policy changes, account changes (e.g., account creation and deletion, account privilege assignment), and use of privileges” (Kent & Souppaya, 2006). Creating logs of these events are important in detecting if there is an ongoing or past attack on your application. A rapid amount of failed authentication attempts could mean someone is trying to brute force their way into the application.
If an account that should not have certain privileges miraculously gets them it could mean the account has been compromised. As, for how often you should be monitoring your logs, the Payment Card Industry Data Security Standards Council (PCI DSS) requires that you view all security events daily (2016). While having logs created is a step in the right direction, monitoring them is just as important. Regularly checking your logs will allow you to see attacks on your application in real time and give you a chance to respond accordingly.
Unclear Logs
When logging & monitoring security events you will want to make sure that your logs are clear and easy to understand. Having obfuscated logs will only increase the time it takes to respond to an attack or in some cases lead you to believe that there is no threat in the first place. As for what your logs should contain, OWASP recommends the “Who, what, when, where” approach (2018). For “who” caused the event you will want to contain information such as the user’s identity (username, userID, etc.) and the source address (MAC, IP, cellphone tower). As for “what” the log should contain you will want the type of event, the security level, and a description. You want to know “when” the event happened so the time that the event actually occurred and when it was logged is important. Finally, you define “where” you want information such as the location in the code, application identifier/address, and geolocation.
Only Locally Storing Logs
Another problem is believing logs are not important enough to have backups. If an attacker were to break into your application, it is vital that you learn what they so that you can prevent it from happening again. Logs often contain the necessary information to find out how and when they did it. This is why it is important to store your logs in multiple locations. It is often easier to do this if you store them in a database. Storing your logs in this way makes it easier to search through them and streamlines storing them across multiple mediums. PrestoDB is an open source distributed SQL query engine that is a great option to keep in mind if you are looking to start storing logs in a database.
Application Unable to Detect, Escalate, or Alert on Attacks/potential Threats
If your logging practices meet or exceed standards, it is still important you supplement them with proper alerting thresholds and response escalation. If your application can detect an influx of security event logs, you will be able to catch attacks on your application before they become breaches. However, it is imperative that your application not only be able to detect attacks but alert on them as well. This will help automate the process of monitoring logs. It is important that the alerting thresholds are set to match your application. As users of your application grow, you want to make sure that the thresholds match with the population.
Scans Not Triggering Alerts
One of the first steps an attacker will take before trying to exploit your application is information gathering. Having a system in place to detect these scans permits you the means to stop them. The less information the attacker has on your application the better. It is very important that you perform these scans on your application regularly so that you can find and patch security holes before the attacker does. We will be covering this more in the next blog.
Conclusion
Having good log practices will not prevent someone from attacking your application. What they can do is give the necessary information to stop an ongoing attack. If they are able to break in, then your logs can give you the information needed to learn how they did it and prevent it in the future. Implementing best practices for logging is just one way to harden your application. Be sure to check out the next blog post, #9 Use Of Components With Known Vulnerabilities, which will be covering in our next installment of the Top 10 OWASP Web Based Vulnerabilities Blog Series.
At Praetorian Secure our caring and highly skilled team of security professionals offer a wide variety of services to assist in securing applications including:
- Dynamic Application Security Testing (DAST)
- Static Application Security Testing (SAST)
- Web Application Security, and more.
Contact our team today by phone at +1(855)519-7328 or find out more about our exciting cyber security service offers by clicking here.
Effective Daily Log Monitoring Special Interest Group PCI Security Standards Council. (2016, May). Information Supplement: Effective Daily Log Monitoring.
Retrieved from https://www.pcisecuritystandards.org/documents/ Effective-Daily-Log-Monitoring-Guidance.pdf?agreement=true
Kent, K., Souppaya, M. (2006, September). Guide to Computer Security Log Management.
Retrieved from https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-92.pdf
Online Web Application Security Project. (2018, May). Logging Cheat Sheet.
Retrieved from https://www.owasp.org/index.php/Logging_Cheat_Sheet
Online Web Application Security Project. (2017). The Ten Most Critical Web Application Security Risks.
Retrieved from https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf