.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 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.

Purpose of Security Logs

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.

Storing Security Logs

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.

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 for you to determine how best to securely log.

Login Events

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.

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 securing cookies in .NET.

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 basic 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 on. Think of a web farm where there are 10 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 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 certain regulatory guidelines such as HIPAA.
• What?
  Always log an event and any information that helps a researcher review what was happening when the event happened. This is probably one of the most difficult attributes to log because an attacker could be performing several threats. Usually, an attacker must perform several attacks that throw errors before he is successful. 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 includes:

• 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 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.