.NET Logging for Security

.NET Logging for Security

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.

Purpose of Security Logs

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.

Storing Security Logs

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.

Logging Specific Security Events

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.

Login Events

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.

SQL Validation Logging

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.

Other Types of Security Logs

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.

Attributes to Log

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? When did the event occur? Always have a time and date stamp logged.
• Where? Most organizations have several applications. Logs should include the application where the event occurred and the server the application is hosted. Think of a web farm where there are ten web servers. Although these servers should be set up the same, mistakes happen where one is patched and another is not. This can lead to errors occurring on one server but not on the others.
• Who? Log user information with security events. This is imperative for root cause should a breach happen. It's also a requirement when working with specific regulatory guidelines such as HIPAA.
• What? Always log an event and any information that helps a researcher review what was happening when the event occurred. This is probably one of the most challenging attributes to log because an attacker could be performing several threats. Usually, an attacker must perform several attacks that throw errors before success. For this reason, logging errors can help you identify the type of attack and how the attacker was able to breach the system.

Miscellaneous Attributes to Log

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:

• Actions: Any actions taken by the user either before or after the event happened
• Objects: If you have any secondary objects that users call (such as an API), log this information as well
• Headers: HTTP headers and status codes for cloud applications
• User Attributes: We mentioned logging the user account, but you can also log the user's authorization access or attributes that distinguish if the user should or should not have access to a particular file or section of the application
• Reason for Declined Access: If the user is declined access, state the reason, such as not enough access rights, wrong password, or even if the database denies access

Data you should never include in standard logging include:

• Regulated Personally Identifiable Information (PII) such as health information or credit card numbers
• Source code from the application
• Passwords
• Sensitive organization information such as intellectual property or data directly from the application that could compromise the integrity of the organization
• Encryption keys or hashes

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