.NET Logging for Security
We spoke a lot 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 any 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 other 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 for applications such as healthcare or financial transactions.
Storing Security Logs
One reason most Windows developers choose to log to the Event Viewer is that it’s completely secure, as long as hackers are not able to connect to the remote machine. 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 ensure that security files can be secured even if the attacker is able to gain local access to the server. This is what makes remote logging solutions safer than storing logs on a local drive.
Another option is to store logs in an SQL Server. There are some advantages and disadvantages to storing security logs to an SQL Server. The advantage is that you can query the database for specific errors. You can also rely on the database’s security to store the data without being breached. The disadvantage is that security logs can grow the database storage requirements heavily. Ensure this is a viable decision with current storage requirements. Storage is now cheap, so it’s usually not an issue.
The final option is writing to a text log. This is the least secure of all options, because you have to ensure that 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 that 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 that contain user credentials.
You can also send logs to a remote logging solution such as Loggly. This type of option sends your logs to the cloud where you can secure them should an attacker gain access to the server.
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. We will discuss a few of the major ones that should be part of any application.
One of the most common ways hackers obtain private data is through SQL injection. As of 2014, developers can now download a library directly from Microsoft that contains an SQL parser that checks for invalid code. The library can be found here.
The following is a sample function that uses the parser to check for invalid SQL.
public bool Parse(string sql)
TSql100Parser parser = new TSql100Parser(false);
fragment = parser.Parse(new StringReader(sql), out errors);
if (errors == null)
This function takes an SQL string and uses the TSql100Parser class to check for validation. Any errors found return false. If the parser detects errors, log an event with a copy of the SQL string. This will show you if your site is under an SQL injection attack. The “errors” variable is a list that tells you the location of the parsed error. It also gives you the parser error it finds when the query string does not pass.
Windows developers have the option to verify credentials against a database or use Active Directory. Active Directory is used with internal applications, and a lookup from the database is done for external users such as customers.
Here is a quick example of checking a user’s Windows credentials for an internal application.
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, "thedomain"))
bool isValid = pc.ValidateCredentials("username", "password");
The one variant with this code is whether you want to log for successful and unsuccessful login attempts. If you log all attempts, then your security logs will grow very large. Ensure that you have a policy to clean out these logs regularly to save space. Your retention policy defines how long you want to keep them.
By logging unsuccessful attempts, you can 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.
In addition to logging authentication, also consider logging authorization changes to user permissions and groups.
For added security, you should check to see if a user’s cookies have been tampered with either through a malicious program or manually. One way to do this is to add a signature to your cookie file. If the value doesn’t match when you retrieve the cookie, you can log out the user and log an event.
The following code creates a small signature that you can append to your cookies. You then retrieve this value from your cookie and compare it each time you read a user’s cookie.
private string sign(string originalHash, byte secret)
HMACSHA1 mac = new HMACSHA1(secret);
byte hash = Encoding.UTF8.GetBytes(originalHash);
mac.TransformFinalBlock(hash, 0, hash.Length);
byte bytesHash = mac.Hash;
// Encode the hash in Base64.
string newHash = Convert.ToBase64String(bytesHash);
Should your hash not match the original string in a cookie, you log an event that could indicate cookie tampering by an attacker.
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 did the event occur? Always have a time and date stamp logged.
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.
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.
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 a number of threats. Usually, an attacker must perform a number of 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:
Any actions taken by the user either before or after the event happened.
If you have any secondary objects that users call (such as an API), log this information as well.
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.
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 and 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 here.