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 then be sold for profit, application developers should be more conscientious about logging security events. These events should be logged for both internal and external users, as even insider threats pose a problem for security teams. This section will discuss logging for security purposes.
Application error logs are used by developers to fix bugs. Security logs are needed for the security team. What makes security logs difficult is that developers don’t always think like hackers. They create defaults and handling that sometimes makes it easy for hackers to trick the application into giving higher privileges or dump important data to the screen. When this occurs, there are very few signs that alert the administrators. However, logs can help stop the situation.
There are intrusion detection systems that 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 happened, so you can 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 completely 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 important that developers think like hackers to avoid common mistakes that 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 is able to 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 very 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 it’s inherently protected by Windows local policies. When developers create custom logs, they (and the administrator) might not place the proper security on them, which can create a security hole on 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 any 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 are typically secured by SSL for security in transit. Vendor’s like SolarWinds provide ISO 27001, SSAE16 SOC-1 Type II, and SOC-2 Type II certifications for organizations with strict compliance requirements.
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 for you to determine how best to securely log.
Secure logging should provide visibility into failed and successful logging attempts. By looking for failed attempts, you can also detect attacks such as brute-force login 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 the audit log for your application, and should be reflected in your log for visibility, postmortem analysis, and real-time threat detections.
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 securing cookies in .NET.
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 basic 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 includes:
With the right 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 right logging, risk response team, and procedures in place. However, the time it takes and the extra logging are critical for secure cloud applications.
Also, check out the Guide to Troubleshoot Windows System Logs for Security Issues.