The OWASP Top 10 is an open-source project that lists the ten most critical security risks to web applications. By addressing these issues, an organization can greatly improve the security of their software applications. Unfortunately, many developers aren't familiar with the list, or don't have a thorough understanding of the vulnerabilities and how to prevent them. In this series, I'm going to break down each of the vulnerabilities on the list, explain what each one is, how to identify it in your projects, and how to prevent it.

Insufficient Logging and Monitoring

What is it?

This vulnerability stems from an application not logging important events as they take place. A lack of logging within an application, or not properly monitoring and responding to application logs, can allow an attack to continue when it could have been caught and terminated had proper controls been in place. It also makes it difficult to reconstruct the events of an attack so that vulnerabilities can be identified and addressed. Most applications do some level of logging, but it's important to understand what should be logged, where those logs should be stored, how they should be monitored, and how the security team should respond to suspected attacks.

How can you identify it?

Identifying this type of vulnerability isn't as easy as looking for a specific line in the code. This vulnerability actually occurs due to a lack of code. Because of this, it may be difficult to understand where your application stands with regards to your security logging.

The first step is to determine what logging is currently present within your application. There may be other purposes for your logging activity, such as debugging or for data analytics. Identify where logging is taking place within your application and what it's being used for.

Next, you'll need to determine where the data is being logged. Is there a log file stored on the same machine that's running the application? Is there a central logging system where multiple applications are logging information? Are security logs being stored along side debugging or analytics logs? Is the log data being stored in a cloud service, such as AWS CloudWatch, that monitors your entire account?

Finally, you need to determine how the logged data is being monitored and acted on. Is the data being fed into an intrusion detection system? Are there rules in place to trigger alerts for suspicious activity? Are there plans in place for responding to these alerts?

If you've determined that you are logging security data, you will need to ensure that the data being logged is sufficient to identify an attempted attack. This can be difficult if you don't have data from a previous attack available to review. If you're not sure if you're logging the correct data, OWASP suggests that reviewing the log files following a penetration test is a good way to determine how thorough your logging is. The logs should show the tester's scanning and attack attempts, and should provide enough information to determine the actions they took within the system, and the data they were able to access.

If your application is not logging security data, or the logs don't provide enough data to identify and track an attacker, then you need to add additional logging to your application.

How can you prevent it?

Reducing this risk is a matter of ensuring that you are collecting data related to security functions within your application, that the data collected is monitored for potential attacks, and that proper alerting is in place. Here are some guidelines for implementing proper logging:

1. Identify what events and data should be logged.

First, you'll need to determine which events need to be monitored. This will include things like login attempts, login failures, attempts to access restricted pages, input validation failures, modification of application data, etc. Once you've identified the events to be logged, you need to determine what data should be logged with it. You'll want to include a timestamp in all logs, and if you're logging from multiple applications or services, you'll want to ensure that the timestamps are synced across services. You should also log some type of identifying information, such as the IP address or the user id. You may also want to include a severity level based on the type of activity being logged. For example, a successful login may be logged as a low severity event, where a failed login attempt will be logged as a high severity event. You should avoid storing sensitive data in your log records, such as passwords, credit card numbers, or social security numbers, etc. Additionally, log data should be considered untrusted, and should be properly sanitized to prevent log injections or log forging. This is by no means an exhaustive list. The events that need to be logged, and the data recorded, will be determined by your organization's specific needs. Whatever data you choose to log, make sure it's in a common format that can be parsed by monitoring tools.

2. Determine where log data will be stored.

If possible security logs should be sent to a central location separate from the device running the application. If the application is deployed in a cloud environment, use the cloud provider's logging services. In either case, the log storage needs to have strict security controls in place to prevent tampering with or deleting log records. They should also be stored in a manner that allows them to easily be digested by a monitoring tool. You'll also need to determine a retention policy for your log data. The amount of time logs are kept may be determined by law, if you're in a regulated industry, or it may be a matter of corporate policy. Either way, the retention period should be sufficient to allow forensic analysis of the records should an attack take place.

3. Determine how logs will be monitored.

Once you've decided which events to log, and where they'll be stored, you have to decide how these logs will be monitored. There are numerous third-party and open-source options available for log monitoring. If you're using a cloud provider, their logging service will most likely have built-in monitoring and alerting available. Depending on the monitoring tool being used, there may be automated actions that can be configured to help stop attacks when suspicious activity is detected. If you're using one of these tools, you'll need to determine the thresholds that should be set, and the actions that should be taken, ie. invalidating session tokens or locking a user's account.

4. Set up alerts for suspicious activity and respond appropriately.

While logs are valuable for determining what happened in the aftermath of an attack, their real value lies in the ability to detect and respond to attacks in real time. Setting up appropriate alerts for specific events allows your security team to monitor activity and take immediate action to protect your data. You'll need to determine which types of events, and at what threshold, these alerts should be triggered. You should also have an incident response plan in place for dealing with security breeches. Guidance for developing an effective incident response plan can be found in the NIST Computer Incident Response Handling Guide.

Thorough logging and monitoring are essential to the security of your applications. This information is crucial for identifying and stopping attacks against your systems. With proper logging in place, you can identify suspicious activity before an intruder has a chance to access your sensitive data or gain a foothold on your system.

References

OWASP Top 10 Project: 10. Insufficient Logging and Monitoring
OWASP Proactive Controls
OWASP Logging Cheat Sheet
NIST Computer Incident Response Handling Guide