Use the Security Event Log

Seriously consider writing security-related events, such as those in the following list, to the Windows security event log rather than writing to your own log file.

• Result of a security decision (some action was allowed or denied)

• Change in a policy or setting that might affect the outcome of security decisions (including old and new value of a security setting)

• Change in state that might affect the outcome of security decisions (load module, start module, stop module, etc.)

• Management of application-specific user accounts (create, delete, manage groups, change password, enable, etc.)

• Application authentication (user logged in/disconnected)

• Application-specific suspicious behavior or integrity violation (this is application specific, but for example, if a Web application detects an SQL injection attempt, it might choose to log that, or an antivirus program might log that it detected a virus, etc.)

Microsoft added a new API, AuthzReportSecurityEvent, to Windows Server 2003 and Windows Vista to log such data easily. The Windows security log is Common Criteria compliant at EAL4+; and although this doesn’t guarantee Common Criteria compliance for your application, it may reduce the amount of work required to achieve Common Criteria for your application.

Windows’ authentication, authorization, and account management functions all generate appropriate audit trails in the Windows security event log. If you use these functions of Windows rather than implement your own, then auditing will be done for you. One final point, don’t flood logs with irrelevant information, just log critical data that could help administrators.