Event Log

When you write event-logging code, consider the threats of tampering and information disclosure. For example, can an attacker retrieve sensitive data by accessing the event logs? Can an attacker cover tracks by deleting the logs or erasing particular records?

Direct access to the event logs using system administration tools such as the Event Viewer is restricted by Windows security. Your main concern should be to ensure that the event logging code you write cannot be used by a malicious user for unauthorizedaccess to the event log.

To prevent the disclosure of sensitive data, do not log it in the first place. For example, do not log account credentials. Also, your code cannot be exploited to read existing records or to delete event logs if all it does is write new records using EventLog.WriteEvent . The main threat to address in this instance is how to prevent a malicious caller from calling your code a million or so times in an attempt to force a log file cycle to overwrite previous log entries to cover tracks. The best way of approaching this problem is to use an out-of- band mechanism, for example, by using Windows instrumentation to alert operators as soon as the event log approaches its threshold.

Finally, you can use code access security and the EventLogPermission to put specific constraints on what your code can do when it accesses the event log. For example, if you write code that only needs to read records from the event log it should be constrained with an EventLogPermissin that only supports browse access. For more information about how to constrain event logging code, see "Event Log" in Chapter 8, "Code Access Security in Practice."