Auditing

Auditing is an important step in effective security management. Unfortunately, many applications do not incorporate simple auditing techniques that can provide a tracking mechanism to identify security breaches. In addition to security auditing, simple auditing can operate as application monitoring to help determine what an application is doing and who did what with the application.

CAUTION

---

Those new to incorporating auditing into applications should be forewarned: Auditing can be expensive because it can utilize extensive processing and storage resources. Also, auditing is an intrusive process that, when overzealously implemented, can cripple an application's performance. The application development team must determine an appropriate level of auditing to reach a medium between governing the working application and allowing the application freedom to simply operate unencumbered.

A common way to address this concern is to emulate the designers of Windows NT. Within Windows NT, seemingly everything that can occur on a system can be audited into a Windows Event Log. However, as shipped Windows NT does not activate most auditing features by default. These features can be activated when system administrators think it is necessary. Minimal information is always recorded in the Event Log, such as System or Application Errors, or the start-up of certain application services.

One way to categorize auditing events that can be incorporated into applications is to group them by the following headings:

• Information Informational messages enable applications to pass along state knowledge, such as noting that a computers data storage has reached 750 MB. Messages can also communicate the application is functioning correctly.
• Success Incorporating success messages (for example, notifying users that an application service has successfully begun at a particular date or time) can provide reassurances to administrators as well as allow automated monitoring systems to check for successful entries.
• Warning Warning messages typically signify problems that may arise. Warning messages could alert users to unexpected events in an application. When users receive warning messages, they should perform a follow-up to determine if additional action is required to solve the problem being addressed.
• Failure If an action cannot be properly completed, the application should make a permanent record in the form of a failure message. The development team should not rely upon users to report that they have been receiving error messages, as such the application should track important client or server errors. From a security point of view, it is important to capture failure messages that result when an application reports that access to a particular system was denied. These access failures are the first line of defense against unwanted software violations. For example, 42,000 failed data requests in a one-minute period can signify a potential security breach, as well as a significant problem with the application.

Log Files

Writing text files that act as log files is a simple way to provide auditing. Text files can be written from all common programming languages, as well as through ADO and ODBC. It is recommended programming practice to allow system administrators to determine where log files are physically located. The application can request a log file directory during installation and store the location within the application's registry setting.

Event Logs

The logs created by the Windows NT event logging service are accessible from the Windows event viewer. They are separated into three different logs: a security log, a system log, and an application log. Support for these logs can be incorporated into applications to ensure that information is written into the appropriate event log. The event logs are physically located in the Windows NT Systemroot\System32\Config directory in the appevent.evt, secevent.evt, and sysevent.evt files. Server administrators should secure access to these files to prevent tampering, as well as prevent software criminals from trying to cover the tracks of their illegal system access.

Windows NT provides several interfaces for controlling auditing. As mentioned, most auditing is disabled by default, but can occur for:

• Windows NT system auditing System auditing includes user logon and logoff, object access, file and object access, use of user rights, user and group management, security policy changes, system restart and shutdown, and Process Tracking.
• File and directory auditing This type of auditing can be set to determine the success and/or failure of read, write, execute, delete, change-permission, and take-ownership actions.
• Registry auditing Auditing within the registry includes success and failure actions that query values, set values, create subkeys, enumerate subkeys, notify, create link, delete, write DAC, and read control.

CAUTION

---

An excessive amount of auditing can adversely impact system performance. For additional information on how to set auditing values, refer to Microsoft Windows NT 4.0 Security, Audit, and Control (Microsoft Press, 1998).

For ongoing monitoring of applications, the project team can build Windows NT performance counter capabilities into the application. As discussed previously, the Windows NT Performance Monitor provides excellent real-time information regarding how an application is functioning. Additional counter information specific to the application can be reported to the performance monitoring system by including the appropriate performance interfaces. For additional information on incorporating performance monitor interfaces, refer to the Microsoft Windows NT Workstation 4.0 Resource Kit (Microsoft Press, 1996).

Distributed Environments

The way Windows NT 4.0 authenticates users directly affects how the use of distributed applications should be audited. For example, with Windows NT authentication, a token gets passed only from point A to point B. When B wants to access something, B's security token is used to access C. The effect is not transitive, meaning if C trusts A, and A trusts B, C does NOT inherently trust B. (Kerberos security, on the other hand, is transitive.) To successfully build auditing into Windows NT 4.0 distributed N-tier environments, developers need to understand this underlying method of authentication.

Obviously, developers need to audit for errors. However, the following items can also be audited for:

• Success events.
• Failure events.
• Object access monitoring.
• Database access monitoring.
• Runtime diagnostics.
• Development diagnostics.
• Usage monitoring.

When developers create an audit trail for object security, they generally want to know who was trying to use the application. To determine who is using an application, the programmatic security services provided by MTS must be implemented. For example, developers could create audit objects to implement an audit trail originating from the presentation tier and ending at the data tier. MTS programmatic services also enable developers to perform more sophisticated security checks in components, rather than simply checking role membership.

Most security needs—even programmatic security—can be met by using role-based security. For example, when designing a banking application, developers may have a business rule enabling a bank teller to authorize withdrawals of up to $500 from a particular user's account, but larger withdrawals must be authorized by a manager. In this case, the Withdraw method implementation needs to take different actions depending on the caller's role. The object context methods IsSecurityEnabled and IsCallerInRole can be used to handle this procedure.

In rare instances in which role-based security is insufficient, MTS provides the ISecurityProperty interface, which can be used to access Windows NT user identities. The object context is queried to obtain an ISecurityProperty interface pointer, and then one of the following four methods is called to obtain a security identifier (SID):

• GetDirectCallerSID returns the SID of the external process that called the currently executing method.
• GetDirectCreatorSID returns the SID of the external process that created the currently executing object.
• GetOriginalCallerSID returns the SID of the base client process that initiated the sequence of calls from which the call to the current object originated.
• GetOriginalCreatorSID returns the SID of the base client process that initiated the current activity.

A SID is a Windows structure containing information about a particular user and any groups to which the user belongs. The Windows API must be used to parse a SID. The SID's information can be used to restrict access to components or to obtain information for auditing and logging. When a SID obtained from the ISecurityProperty interface is no longer needed, ReleaseSID should be called to release the SID.

SIDs are not easily accessible from Visual Basic, so MTS also provides a SecurityProperty object. The SecurityProperty object is defined in the MTS type library. A reference to the object can be obtained using the Security property of the object context, as shown in the following code example:

 Dim secProperty as SecurityProperty Set secProperty = GetObjectContext.Security 

The SecurityProperty object provides access to usernames only, not to the entire SID. Fortunately, the username is all that's generally need for auditing or logging.

Just as they can audit object security programmatically, developers can audit database security by building in parameters, such as a username, that is passed to stored procedures in the database. Later, the database can record the username in the appropriate table using an additional stored procedure or trigger.