We spoke a great deal about logging for error exceptions and handling, but what we haven't mentioned yet is logging for security. As the web continues to offer more opportunities for hackers to obtain data that can be sold for profit, application developers should be more conscientious about logging security events. These events should be logged for internal and external users, as insider threats also pose a problem for security teams. This section will discuss logging for security purposes.
Developers use application error logs to fix bugs. Security logs are needed for the security team. Security logs are difficult because developers don't always think like hackers. They create defaults and handling that sometimes make it easy for hackers to trick the application into giving higher privileges or dump important data to the screen. When this occurs, few signs alert the administrators. However, logs can help stop the situation.
There are intrusion detection systems designed to help with the process, but developers can create their own logging events. For instance, a malformed SQL statement sent to a form should first be validated. Since malformed SQL will fail validation, the developer can then trigger a logging event that records to event viewer or another logging system.
There are several other reasons for logging security events. You can establish a baseline for your application to detect unusual behavior patterns from both external and internal users. They give you audit trails, should you determine a security breach occurred, allowing you to review user activity. It's also a part of compliance and audit requirements for applications in healthcare or finance sectors.
One reason most Windows developers choose to log to the event viewer is it's utterly secure if a hacker is not able to connect to the remote machine or access the remote management console.
The developer doesn't need to worry much about security with Event Viewer. However, it's still crucial developers think like hackers to avoid common mistakes which can make it easy to breach an application. Since Event Viewer logs can be sent to a central repository, you can help ensure compromising data can be secured even if the attacker can gain local access to the server. If you must log locally and are concerned about security, opt for the Event Viewer. Otherwise, use a remote logging facility.
The final option is writing to a text log. This is the least secure of all options, because you must help ensure the files are secure. Because it takes an extra step for security, it's generally the least favorite for most developers. Event Viewer also logs to a file, but Windows local policies inherently protect it. When developers create custom logs, they (and the administrator) might not place the proper security on them, creating a security hole in the system.
One item to note with security logs is they should be kept separately from main application error logs. Security logs contain sensitive information that shouldn't be available to users except administrators. Basic application logs also require security, but they can be viewed by developers and IT employees. Keeping security logs extremely private cuts down on insider threats, especially with logs containing user credentials.
You can also send logs to a remote logging solution such as SolarWinds® Loggly®. This type of option sends your logs to the cloud, where you can secure them should an attacker gain access to the server. Communication between your application and a remote logging solution is typically secured by SSL for security in transit.
Once you decide what you will log and where you will log, you can start logging events. There are numerous types of security events you can log. Let's cover the big three to give you a launching point to determine how best to log securely.
Secure logging should provide visibility into failed and successful logging attempts. You can also detect attacks such as brute-force login attempts by looking for failed attempts.
You also want to know when a successful login was made, so you should log events made by outside attempts to log in. Additionally, by logging successful attacks, you can detect insider threats or suspicious login behavior. It also helps to log the time and IP address for audit trails.
Aside from logging authentication, also consider logging authorization changes to user permissions and groups. This should be part of your application's audit log and reflected in your log for visibility, postmortem analysis, and real-time threat detection.
Use the TSQL100Parser library from Microsoft to validate your SQL if you're using SQL Server®. Always validate your inputs. Log all failures and all successes.
Cookie tampering – To protect against cookie tampering, avoid using client-side cookies. Enable HTTP cookies where possible, enforce SSL for cookies, encrypt your cookie values, and enforce domain rules for your cookies. For more information, check out this guide on cookie security by OWASP.
Some applications require a higher level of logging for audit trails. For instance, you might want to log events where the application connects to the network to download a file. You can also log events when a user is added to the application or when personal identifiable information (PII) is accessed. In healthcare, audit trails to PII are required. Each time the user's information is retrieved, the person who retrieved the data, time, date, and IP address must be logged in the system.
We mentioned a few attributes such as time, date, IP, and (sometimes) user credentials. To create a proper audit trail, you need a few essential attributes with your logs.
When, where, who, and what are the four main attributes to log, but you can also log extra information to better identify an attack and even a bug in your application.
Some other attributes you should consider logging:
Data you should never include in standard logging include:
With the proper security logging in place, you can stop an attack much quicker and before it becomes a critical data breach. You'll need to work with administrators and developers to put the proper logging, risk response team, and procedures in place. However, the time it takes and the extra logging is critical for secure cloud applications.
The OWASP guide provides a comprehensive list of attributes you should log based on the requirements. Also, check out the Guide to Troubleshoot Windows System Logs for Security Issues.
Last updated: 2022