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.
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:
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.
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:
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).
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:
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):
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.