Auditing and Logging

  • Article

patterns & practices Developer Center

It is important to audit and log activity across the tiers of your application in order to detect suspicious activity. Using logs frequently provides early indications of a full-blown attack and can help you address the threat of repudiation, where users deny their actions. Log files may be required in legal proceedings to prove the wrongdoing of individuals. Generally, auditing is considered most authoritative if the audits are generated at the precise time of resource access and by the same routines that access the resource.

Use the following guidelines when implementing auditing and logging in WCF applications:

  • Use WCF auditing to audit your service
  • If non-repudiation is important, consider setting the SuppressAuditFailure property to false
  • Use message logging for debugging purposes
  • Instrument for user management events
  • Instrument for significant business operations
  • Protect log files from unauthorized access
  • Do not log sensitive information
  • Protect information in log files
  • Use a Custom Trace Listener only when message filtering is needed

Each of these guidelines is described in the following sections.

Use WCF auditing to audit your service

Use the auditing feature in WCF to audit your service. WCF service auditing can allow you to detect an attack that has occurred or is in progress. In addition, auditing can help you debug security-related problems. For example, if an error in the configuration of the authorization or checking policy accidentally denies access to an authorized user, you can discover and isolate the cause of this error by examining the auditing events in the event log.

Configure your application to use the WCF auditing feature to log security events for success, failure, or both. The events are written to the Windows system event log, and you can view and examine them in the Event Viewer.

The following configuration snippet shows how to configure your WCF service to use auditing:

<configuration>
  <system.serviceModel>
    <behaviors>
      <behavior>
        <serviceSecurityAudit
             auditLogLocation="Application"
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Failure"
             messageAuthenticationAuditLevel=
                         "SuccessOrFailure" /> 
      </behavior>
    </behaviors>
  </system.serviceModel>
</configuration>

Additional Resources

If non-repudiation is important, consider setting the SuppressAuditFailure property to false

If non-repudiation is important, consider setting the SuppressAuditFailure property to false. This setting will cause an exception to be thrown whenever an audit failure occurs. By default, your WCF service will ignore audit failures and allow the service to continue running. By setting SuppressAuditFailure to false, an exception can be thrown and handled by your WCF service.

// configuration snippet 
<configuration>
  <system.serviceModel>
    <behaviors>
      <behavior>
        <serviceSecurityAudit
            auditLogLocation="Application"
            suppressAuditFailure="false"
            serviceAuthorizationAuditLevel="Failure"
            messageAuthenticationAuditLevel=
                        "SuccessOrFailure" /> 
      </behavior>
    </behaviors>
  </system.serviceModel>
</configuration>

Use message logging for debugging purposes

Message logging can be used to diagnosed application errors and performance problems. Message logging is not turned on by default, because logging is an expensive operation that can consume disk space and processing time. Turn on message logging by setting attributes on the <messagelogging> element in your configuration file and adding a trace listener to log the events to a file.

Note

Important: Make sure that you limit the number of messages that are written to disk for a particular service, as disk space could be a limiting factor. When the message limit is reached, a trace at the Information level is produced and all message-logging activities stop.

The following configuration code enables message logging by creating a ServiceModelMessageLoggingListener and System.ServiceModel.MessageLogging source:

…
<configuration>
<system.diagnostics>
  <sources>
   <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
    <listeners>
     <add type="System.Diagnostics.DefaultTraceListener" name="Default">
      <filter type="" />
     </add>
     <add name="ServiceModelMessageLoggingListener">
      <filter type="" />
     </add>
    </listeners>
   </source>
  </sources>
  <sharedListeners>
   <add initializeData="c:\inetpub\wwwroot\WCFService\web_messages.svclog"
    type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
    <filter type="" />
   </add> 
  </sharedListeners>
</system.diagnostics>
</configuration>
…
…
<system.serviceModel>
  <diagnostics>
   <messageLogging logEntireMessage="false" logMalformedMessages="true"
    logMessagesAtServiceLevel="false" logMessagesAtTransportLevel="true" />
  </diagnostics>
…

Additional Resources

Instrument for user management events

Use ASP.NET health monitoring to instrument your application and monitor user management events around authentication and authorization. This instrumentation can help you 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.

The following steps show how to instrument your application for user management events:

  1. Create a custom user management Web event by creating a class library and then creating a class that inherits from WebAuditEvent.
  2. Configure your WCF service for health monitoring.
  3. Instrument the WCF service by raising the custom event in a service contract.
  4. Verify the service events in the event log after calling the service method from a test client.

Additional Resources

Instrument for significant business operations

Use ASP.NET health monitoring to instrument your application to track access to sensitive operations. This level of instrumentation can help you detect and react to potentially suspicious behavior. It also enables you to gather operations data; for example, to track what important business operations are being carried out and by whom, etc. For instance, you could track usage of methods that relate to financial transactions or access to sensitive data.

The following steps show how to instrument your application with health monitoring:

  1. Create a class library and then create a class that inherits from WebSuccessAuditEvent that displays some business information, such as bank account transactions.
  2. Configure your WCF service for health monitoring.
  3. Instrument the WCF service by raising the custom event in a service contract.
  4. Verify the service events in the event log after calling the service method from a test client.

Additional Resources

Protect log files from unauthorized access

Restrict access to log files and SQL Server records in order to make it more difficult for attackers to tamper with log files and cover their tracks.

Minimize the number of individuals who can manipulate the log files. Authorize access only to highly trusted accounts such as administrators.

Restrict access to audit and log files by using Windows ACLs. 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 grant read-only access to operators.

Do not log sensitive information

Do not log sensitive user or application data to your log files. Permissions on log files are often different from permissions on sensitive data in your data store and operations that access it. The presence of sensitive data in your logs could allow users to gain access to information to which they would not otherwise have access.

Sensitive data includes, but is not limited to:

  • Personally identifiable information (PII). This is data that either contains personally identifiable information or can be used to derive personally identifiable information that should not be shared with users. Examples of personally identifiable information include credit card numbers and social security numbers.
  • User sensitive information. This is information provided by a user that they would not want shared with other users of the application. This can include user credentials, preferences, or application usage information.
  • Application sensitive information. This is information that comes from a trusted source that is not designed to be shared with users. Application sensitive information can include connection strings and service account credentials.

Additional Resources

Protect information in log files

Protect the information in your log files because it may provide important insight into the internal workings of your application.

The following tips can help you prevent the contents of a log file from being exposed unintentionally:

  • Ensure that the log files are protected by access control lists (ACLs) both in Web-hosted and self-hosted scenarios.
  • Choose a file extension that cannot be easily served using a Web request. For example, the .xml file extension is not a safe choice. You can check the IIS administration guide to see a list of extensions that can be served.
  • Specify an absolute path for the log file location, which should be outside of the Web host vroot public directory to prevent it from being accessed by an external party using a Web browser.

By default, when using message logging, keys and PII (username, password, etc.) and application-specific headers (such as query string) and body information(such as a credit card number) are not logged in traces and logged messages.

Additional Resources

Use a custom trace listener to filter sensitive application data in messages

Use a custom trace listener only when you need a message filter for filtering application-specific personally identifiable information (PII) elements from messages before logging. Using a custom trace listener with additional options gives you more control over the messages to be logged.

Adding a custom trace listener on the message logging trace source is a privilege that should be restricted to the administrator. This is because malicious custom listeners can be configured to send messages remotely, which leads to disclosure of sensitive information. In addition, if you configure a custom listener to send messages on the network (for example, to a remote database), you should enforce proper access control on the message logs in the remote machine.

The following code example demonstrates a custom listener configuration:

<system.diagnostics>
   <sources>
     <source name="System.ServiceModel.MessageLogging">
           <listeners>
             <add name="MyListener" 
                    type="YourCustomListener"
                    initializeData="c:\logs\messages.svclog"
                    maxDiskSpace="1000"/>
           </listeners>
     </source>
   </sources>
</system.diagnostics>

Additional Resources