ASP.NET 2.0 Security Guidelines - Auditing and Logging

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan


Contents

Use Health Monitoring to Log and Audit Events

ASP.NET version 2.0 introduces a health monitoring feature that you should use to log and audit events. By default, health monitoring is enabled for ASP.NET version 2.0 applications and all Web infrastructure error events (inheriting from System.Web.Management.WebErrorEvent) and all audit failure events (inheriting from System.Web.Management.WebFailureAuditEvent) are written to the event log. The default configuration is defined in the <healthMonitoring> element in the machine-level Web.config file. To audit additional security related events, you create custom event types by deriving from one of the built-in types.

The health monitoring feature has built-in providers that allow you to log events in an e-mail message (SimpleMailWebEventProvider, TemplatedMailWebEventProvider), to SQL Server (SqlWebEventProvider), to the event log (EventLogWebEventProvider), as ASP.NET trace output (TraceWebEventProvider), or to the Windows Management Instrumentation (WMI) Web event provider (WMIWebEventProvider). You can configure health monitoring in the machine or application Web.config file to modify the events that are logged and the way in which they are logged.

For more information, see How To: Use Health Monitoring in ASP.NET 2.0.


Instrument for User Management Events

Instrument your application and monitor user management events such as password resets, password changes, account lockout, user registration, and authentication events. Doing this helps you to detect and react to potentially suspicious behavior. It also enables you to gather operations data; for example, to track who is accessing your application and when user account passwords need to be reset.

By default, ASP.NET health monitoring records all WebFailureAuditEvents, which ASP.NET raises when user authentication fails in forms authentication with the membership system. ASP.NET also raises a WebFailureAuditEvent when authorization is not granted to a resource protected by file authorization and URL authorization.

For more information about auditing password changes and account lockout events, see How To: Instrument ASP.NET 2.0 Applications for Security.


Instrument for Unusual Activity

Instrument your application and monitor events that might indicate unusual or suspicious activity. This enables you to detect and react to potential problems as early as possible. Unusual activity might be indicated by:

  • Replays of old authentication tickets.
  • To many login attempts over a specific period of time.
  • Replays of old authentication tickets automatically raise an ExpiredTicketFailure event. To raise an event for too many login attempts, if you are using the membership system and the Login controls, you can write an event handler for the LoginError event of the Login control. In the handler, call Membership.GetUser(Login1.UserName).IsLockedOut to determine if there have been too many login attempts for the user. You can then raise a custom event to indicate that the account has been locked out.

For more information about auditing password changes and account lockout events, see How To: Instrument ASP.NET 2.0 Applications for Security.


Instrument for Significant Business Operations

Use ASP.NET health monitoring to track significant business operations. For example, instrument your application to record access to particularly sensitive methods and business logic. To do this, create a custom event class that inherits from System.Web.Management.WebSuccessAuditEvent or System.Web.Management.WebFailureAuditEvent and raise that event in the appropriate methods. For more information see How To: Instrument ASP.NET 2.0 Applications for Security.


Consider Using an Application-specific Event Source

By default, the EventLogWebEventProvider writes to the application event log by using an event source named "ASP.NET xxxxxx", where xxxxxx is the .NET Framework version number. This is not configurable. If you want events generated by the ASP.NET health monitoring feature to use an application-specific event source, you must create a custom event provider (inherit from EventLogWebEventProvider) and override the ProcessEvent method to write to the event log (by calling EventLog.Write) using the desired event source.

When using a custom event source, you need to create the event source at installation time when administrator privileges are available. If you are unable to create new event sources at installation time, and you are in deployment, the administrator should manually create new event source entry beneath the following registry key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<LogName>

Note You should not grant write permission to the ASP.NET process account (or any impersonated account if your application uses impersonation) on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\ registry key. If you allow write access to this key and the account is compromised, the attacker can modify any log-related setting, including access control to the log, for any log on the system.


Protect Audit and Log Files

Protect audit and log files using Windows ACLs and restrict access to the log files. If you log events to SQL Server or to some custom event sink, use appropriate access controls to limit access to the event data. For example, grant write access to the account or accounts used by your application, grant full control to administrators, and read-only access to operators.

This makes it more difficult for attackers to tamper with log files to cover their tracks. Minimize the number of individuals who can manipulate the log files. Authorize access only to highly trusted accounts such as administrators.

Personal tools