Apparatus and method for protecting against data tampering in an audit subsystem

[0002] 1. Technical Field

[0003] The present invention relates to an improved data processing system and, in particular, to a method and apparatus for managing audit logs in a data processing system. Still more particularly, the present invention provides a method and apparatus for creating and verifying audit logs in a relational database without compromising the ability to detect data tampering in a data processing system.

[0004] 2. Description of Related Art

[0005] Audit logs have long been used to keep permanent records of events. The audit log can be used at some future date to reconstruct events that happened in the past. This reconstruction might be required for legal, accounting, or security purposes or for recovery after a disaster.

[0006] Audit logs are more useful if the entries can be authenticated in some way. In paper systems, the physical log itself enforces this authentication. However, modern audit logs are often kept in digital files within a computer system. Such computer audit logs differ from paper documents in that they can be more easily modified undetectably. For example, it is easy to add, delete, or modify individual entries within an audit log in a computer system in such a way that the changes will go undetected. In fact, many computer hackers who break into computer systems take specific actions to modify the audit logs to erase all traces of their actions.

[0007] Computer security manufacturers have responded to this threat in several ways. One is to force the audit log to be continuously printed out on paper. Variants of this technique involve writing the audit log to a non-erasable medium, such as a CD-ROM. Another approach uses conventional computer security techniques to guard the audit log files. Such techniques include hiding and encrypting the log files or requiring special permissions to write to them. These techniques work well in some applications—most notably when the audit log is stored on a shared computer and the malicious person trying to modify the audit log does not have full permissions on that computer—but are not without their disadvantages. For example, clever hackers can often figure out ways around the computer security techniques and make changes to the audit log.

[0008] A common implementation approach for audit subsystems is to store audit records in a flat file. Such solutions are limited in terms of scalability, transaction support, sophisticated query capabilities, and recovery. Furthermore, they are not amenable to supporting on-line integrity checking or on-line archiving.

[0009] Therefore, it would be advantageous to have an improved method and apparatus for protecting against data tampering of audit logs.

[0010] The present invention solves the problems associated with the prior art by storing audit records in a relational database comprising a primary audit log table, auxiliary tables, and a system table. Audit record level protection is achieved by including an integrity column in every audit record and by assigning a unique identifier, such as a serial number, to each audit record. System level protection is achieved by maintaining serial number range and integrity information in the system table. The present invention provides for detection of unauthorized row modification, deletion, or insertion, and incorporates extra measures to protect against administrator attacks. Using the serial number range in the system table, a snapshot may be taken of the audit log to enable integrity checking and audit log archiving without having to suspend or bring down the audit subsystem.

[0011] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0012] FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented;

[0013] FIG. 2 is a block diagram of a data processing system that may be implemented as a server in accordance with a preferred embodiment of the present invention;

[0014] FIG. 3 is a block diagram illustrating a data processing system in which the present invention may be implemented;

[0015] FIG. 4 is a client/server view of an exemplary audit subsystem of the present invention;

[0016] FIG. 5 illustrates a database schema in accordance with a preferred embodiment of the present invention;

[0017] FIG. 6 is a flowchart, which illustrates an audit server or audit tool startup process in accordance with a preferred embodiment of the present invention;

[0018] FIG. 7 is a flowchart, which illustrates an audit record creation process in accordance with a preferred embodiment of the present invention;

[0019] FIG. 8 is a flowchart, which illustrates an integrity check utility in accordance with a preferred embodiment of the present invention;

[0020] FIG. 9 is an audit record checking utility in accordance with a preferred embodiment of the present invention; and

[0021] FIG. 10 is an extraneous record checking utility in accordance with a preferred embodiment of the present invention.

[0022] With reference now to the figures, FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented. Distributed data processing system 100 is a network of computers in which the present invention may be implemented. Distributed data processing system 100 contains a network 102, which is the medium used to provide communications links between various devices and computers connected together within distributed data processing system 100. Network 102 may include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone connections.

[0023] In the depicted example, a server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 also are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. For purposes of this application, a network computer is any computer, coupled to a network, which receives a program or other application from another computer coupled to the network. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. The example illustrated in FIG. 1 also includes a server 114 connected to network 102 and a storage unit 116 connected to server 114.

[0024] Distributed data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, distributed data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for the present invention.

[0025] Referring to FIG. 2, a block diagram of a data processing system that may be implemented as a server, such as server 104 in FIG. 1, is depicted in accordance with a preferred embodiment of the present invention. Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 connected to system bus 206. Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.

[0026] Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108-112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in boards.

[0027] Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.

[0028] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 2 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

[0029] The data processing system depicted in FIG. 2 may be, for example, an IBM RISC/System 6000 system, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system.

[0030] An operating system runs on processor 202 and is used to coordinate and provide control of various components within data processing system 200 in FIG. 2.

[0031] The operating system may be a commercially available operating system, such as Windows 2000, which is available from Microsoft Corporation. An object oriented programming system such as Java may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 200. “Java” is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard disk drive 232, and may be loaded into main memory 209 for execution by processor 202.

[0032] With reference now to FIG. 3, a block diagram illustrating a data processing system in which the present invention may be implemented. Data processing system 300 is an example of a client computer. Data processing system 300 employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor 302 and main memory 304 are connected to PCI local bus 306 through PCI bridge 308. PCI bridge 308 also may include an integrated memory controller and cache memory for processor 302. Additional connections to PCI local bus 306 may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter 310, SCSI host bus adapter 312, and expansion bus interface 314 are connected to PCI local bus 306 by direct component connection. In contrast, audio adapter 316, graphics adapter 318, and audio/video adapter 319 are connected to PCI local bus 306 by add-in boards inserted into expansion slots. Expansion bus interface 314 provides a connection for a keyboard and mouse adapter 320, modem 322, and additional memory 324. Small computer system interface (SCSI) host bus adapter 312 provides a connection for hard disk drive 326, tape drive 328, and CD-ROM drive 330. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

[0033] An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in FIG. 3. The operating system may be a commercially available operating system, such as Windows 2000, which is available from Microsoft Corporation. An object oriented programming system such as Java may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 300. “Java” is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard disk drive 326, and may be loaded into main memory 304 for execution by processor 302.

[0034] Those of ordinary skill in the art will appreciate that the hardware in FIG. 3 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash ROM (or equivalent nonvolatile memory) or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIG. 3. Also, the processes of the present invention may be applied to a multiprocessor data processing system.

[0035] For example, data processing system 300, if optionally configured as a network computer, may not include SCSI host bus adapter 312, hard disk drive 326, tape drive 328, and CD-ROM 330, as noted by dotted line 332 in FIG. 3 denoting optional inclusion. In that case, the computer, to be properly called a client computer, must include some type of network communication interface, such as LAN adapter 310, modem 322, or the like. As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system 300 comprises some type of network communication interface. As a further example, data processing system 300 may be a Personal Digital Assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.

[0036] The depicted example in FIG. 3 and above-described examples are not meant to imply architectural limitations. For example, data processing system 300 also may be a notebook computer or hand held computer in addition to taking the form of a PDA. Data processing system 300 also may be a kiosk or a Web appliance.

[0037] With reference now to FIG. 4, a client/server view of an audit subsystem is shown in accordance with a preferred embodiment of the present invention. The audit subsystem 400 includes audit clients 402, 404 connected to audit servers 406, 412. Audit clients 402, 404 are controlled by audit client software and audit servers 406, 412 are controlled by audit server software. In a preferred embodiment, the audit client software and audit server software is written in an objected-oriented programming language, such as Java. However, the software may be written in any known programming language.

[0038] Audit server 406 is connected to keystore 408 and database 410. Similarly, audit server 412 is connected to keystore 414 and database 416. A keystore represents a collection of keys and certificates.

[0039] Audit clients 402, 404 may be embodied on client computers within a network, such as clients 108-112 in FIG. 1. Audit servers 406, 412 may each be embodied on a network server, such as server 104 in FIG. 1. It will be understood that audit subsystem 400 may comprise any number of audit clients and any number of audit servers. Each client 402, 404 and each server 406, 412 may reside in a separate computer. Alternatively, a client and server, such as client 402 and server 406, may reside in a single computer. It will also be understood that the connectivity between clients and servers may be modified within the scope of the present invention. For example, audit client 404 may only be connected to audit server 412.

[0040] Audit clients 402, 404 monitor for events and send the events to audit servers 406, 412. The audit servers collect the events into the audit database. The audit servers also include utilities for ensuring the integrity of the audit database, as will be described below.

[0041] Audit database 410 includes a primary audit log table 420, a system table 422, and auxiliary tables 424. According to a preferred embodiment of the present invention, audit database 410 is a relational database, such as Database 2 (DB2) from IBM Corporation. A relational database is a database in which relationships between files are created by comparing data and by using indexes, which are built and maintained on key fields used for matching.

[0042] Each record in the audit log table has an integrity column, which is computed as the message authentication code (MAC) over the rest of the columns. A MAC is an authentication tag or checksum derived by application of an authentication scheme, together with a secret key, to a message. MACs are computed and verified with the same key. MACs can be categorized as (1) unconditionally secure, (2) hash function-based, (3) stream cipher-based, or (4) block cipher-based. Audit record modifications are detected by comparing the integrity column with a recomputed MAC over the remaining columns.

[0043] A keystore 414 is provided to store integrity information, such as keys or passwords, including the MAC key and any other keys or passwords related to integrity, and MAC values. Only the audit server and audit tools are able to compute MAC values, since they are the only code modules that have access to the keystore. The keystore checks that the calling code is trusted code and denies access to the contents of the keystore if the calling code is not trusted.

[0044] Examples of commonly used MACs include cipher block chaining message authentication code (CBC-MAC) and HMAC (short for “keyed-Hashing for Message Authentication”). CBC-MAC is a widely used U.S. and international standard. In CBC-MAC, the message blocks are encrypted using DES cipher block chaining and the final block in the ciphertext is output as the checksum. HMAC uses a key or keys in conjunction with a hash function to produce a checksum that is appended to the message.

[0045] Each record also has a unique serial number that increases monotonically with each new audit record. The serial number is used in aiding detection of row deletions and additions. After invoking a query to scan the audit records, a row deletion may be detected when a gap is encountered in the serial number sequence. Since the records are queried in ascending order and the serial numbers increase monotonically, a hole would occur if the serial number of the current audit record and the previous serial number plus one are not equal.

[0046] The system table 422 maintains the serial number of the first record in the audit log table (First_SN) and the serial number that will be assigned to the next audit record (Next_SN). When an audit record is inserted into the audit log table, the Next_SN value in the system table is updated and the audit record is inserted in the same transaction, so that the serial number range in the system table is always consistent with the set of current audit records. Any row whose serial number is outside the range of First_SN to Next_SN minus one is considered to be an extraneous record. A query of the audit log table for records outside the range may be invoked to isolate extraneous records for recording in an error log.

[0047] The system table also contains the integrity value of the auxiliary tables in the audit database. Similar to an audit record in the audit log table, the system table contains its own integrity column, which is computed as a MAC over the other columns. The integrity of the system table may be verified by recomputing the system table MAC and comparing it with the integrity column of the system table. The integrity of all the auxiliary tables may be verified by recomputing their respective MACs and comparing them with their corresponding values in the system table.

[0048] If all data were maintained in the database, a database administrator who is not authorized as an auditor could make modifications to the audit database without such changes being detectable. Such an attack may occur if (1) the database administrator gains access to the MAC key or (2) the database administrator mounts a database restore attack in which a restore operation is performed after some set of records have been inserted in the audit log.

[0049] To protect against the first type of attack, the MAC key is protected in a keystore, such as keystores 408, 414. The MAC key is triple data encryption standard (triple-DES) encrypted under a DES key derived from a password known by an individual acting as an auditor. This password is required to log into the keystore and subsequently gain access to any of the content of the keystore.

[0050] In addition, when a program attempts to access the contents of the keystore via the keystore application program interfaces (APIs), the keystore API logic authenticates the calling code. If the calling code is not trusted code, the APIs return failure codes and no access to data is granted. These techniques make it very difficult for an administrator, or any user for that matter, to gain access to the contents of the keystore.

[0051] To protect against the second type of attack, the first serial number, next serial number, and integrity columns from the system table are written to the keystore. Before verifying the integrity of the system table, the system table's integrity value, the first serial number, and the last serial number are compared with the corresponding values in the keystore file. If the next serial number in the system table is less than that in the keystore, then it is assumed that a database restore has been completed.

[0052] The above described technique for protection against DBA restore attacks is effective assuming that the DBA and the owner of the keystore file, typically an auditor, are not the same individual. If an enterprise defines a DBA role that is distinct from the auditor role, undetected tampering of the audit log via a restore attack is only possible if an individual acting as a DBA were to collude with an individual acting as an auditor.

[0053] With reference now to FIG. 5, a database schema is depicted in accordance with a preferred embodiment of the present invention. Database Schema 500 includes system table 510, audit log table 530, and auxiliary tables, particularly event type table 540 and authorized entity table 550. The system table 510 maintains the serial number of the first record in the audit log table (First_SN) and the serial number that will be assigned to the next audit record (Next_SN). The system table also contains the integrity value of other auxiliary tables in the audit database, particularly the event type table MAC and the authorized entity table MAC. The system table also contains its own integrity column, the system table MAC, which is computed as a MAC over the other columns. System table 510 may be embodied as system table 422 in FIG. 4.

[0054] The system table MAC is stored in keystore 520. The keystore also contains the MAC key to protect against a DBA attack. The first serial number (First_SN) and the next serial number (Next_SN) in the audit log table are also stored in the keystore. The keystore also stores database credentials. Keystore 520 may be embodied as one of keystores 408, 414 in FIG. 4.

[0055] Audit log table 530 includes a row for each event. The columns of audit log table 530 include serial number (SN), event type (ET), and authorized entity (AE). Each record in the audit log table also has an integrity column, which is computed as the MAC over the rest of the columns. The serial number column is populated with the Next_SN value from the system table when the audit record is created. The event type column is populated with an event type identification (ID) and the authorized entity column is populated with an authorized entity ID. In the example shown in FIG. 5, the audit record with SN equal to ten has an event type of ET₁and an authorized entity of AE₂. The event type ID and the authorized entity ID are associated with an event type and distinguished name of the authorized entity, respectively, using lookup tables 540, 550, as discussed further below. Audit log table 530 may be embodied as audit log table 420 in FIG. 4.

[0056] Event type table 540 and authorized entity table 550 are examples of auxiliary tables that may be embodied in auxiliary tables 424 in FIG. 4. Each record in event type table 540 associates an event type ID with an event type. In the example shown in FIG. 5, event type ID ET₁is associated with a “Certificate Generation” event. Event type ID ET₂is associated with a “Certificate Revoke” event. Each record in authorized entity table 550 associates an authorized entity ID with distinguished name of an authorized entity. In the example shown in FIG. 5, authorized entity ID AE₁is associated with distinguished name DN₁. Authorized entity ID AE₂is associated with distinguished name DN₂. Therefore, the audit record in audit log table 530 with a SN equal to ten is a “Certificate Generation” event and the authorized entity is DN₂.

[0057] The database schema shown in FIG. 5 illustrates the advantages of the present invention discussed above. The audit log table 530 in conjunction with system table 510 protects against record insertion, deletion, and modification by use of the serial numbers and integrity column. The system table maintains the integrity of the auxiliary tables and stores the range of serial numbers of the audit records to allow an integrity check to be performed on-line. The keystore 520 protects against DBA attacks by storing the system table integrity value, the MAC key, and database credentials needed to access the audit database.

[0058] Those of ordinary skill in the art will appreciate that the structure of database schema 500 may vary depending on the implementation. The database may include fewer or, more likely, more tables and columns within the tables. For example, audit log table 530 may include additional columns each of which has an associated auxiliary table.

[0059] With reference now to FIG. 6, a flowchart of an audit server or audit tool startup process is depicted in accordance with a preferred embodiment of the present invention. The process begins and reads a password from a startup command (step 602). The process allows the user to log into the keystore (step 604) and a determination is made as to whether authorization is successful (step 606). If authorization is not successful, the process exits with a failure (608) and the process ends.

[0060] If authorization is successful in step 606, the process proceeds to read database credentials from the keystore (step 610), record the MAC key from the keystore (step 612), and obfuscate the MAC key in memory (step 614). The process then attempts to connect to the database using the database credentials (step 616) and a determination is made as to whether the connection is successful (step 618). If connection is not successful, the process exits (step 620) and ends. If connection is successful in step 618, the process continues normal processing (step 622).

[0061] With reference now to FIG. 7, a flowchart of an audit record creation process is depicted in accordance with a preferred embodiment of the present invention. The audit record creation process begins following the startup sequence as shown in FIG. 6, gets the next audit event (step 702), and makes a determination as to whether the event is valid (step 704). If the event is a not a valid event, the client is notified and the process returns to step 702 to get the next record.

[0062] If the event is a valid event in step 704, the process creates an audit record structure in memory (step 706) and gets the Next_SN value from the system table (step 708). This locks the system table because of the database isolation level (COMMIT_READ) and blocks the archive utility. Thereafter, the process assigns Next_SN (step 710) and other required information (step 712) to the audit record in memory. Next, the process computes the audit record MAC (step 714), inserts the audit record into the database, and makes a determination as to whether the insertion is successful (step 718). If the insertion is not successful, the transaction is rolled back to the state before the process received the event (step 720) and the process returns to step 702 to get the next audit event and the audit client is notified of the failure.

[0063] If the insertion is successful in step 718, the system table is updated so that (1) Next_SN=Next_SN+1, and (2) the system MAC is recomputed (step 722). A determination is made as to whether the system table update is successful (step 724). If the system table update is not successful, the transaction is rolled back (step 720) and the process returns to step 702 to get the next audit event and the audit client is notified of the failure.

[0064] If the system table update is successful in step 724, the keystore is updated with First_SN, Next_SN, and system MAC values from the system table (step 726). A determination is made as to whether the keystore update is successful (step 728). If the keystore update is not successful, the transaction is rolled back (step 720) and the process returns to step 702 to get the next audit event and the audit client is notified of the failure. If the keystore update is successful, the process commits the transaction (step 730) and returns to step 702 to get the next audit event.

[0065] With reference now to FIG. 8, an integrity check utility process is depicted in accordance with a preferred embodiment of the present invention. The process begins following the startup sequence shown in FIG. 6, sets database isolation level to committed read (step 802) and reads the system table into memory (step 804). The row is locked because of database isolation level and inserts are blocked. The process then reads keystore information (step 806) and performs a rollback to unlock the system table (step 808). The rollback to unlock the system table unblocks inserts.

[0066] Thereafter, the process compares First_SN, Next_SN, and system MAC values of the system table in memory with the keystore information in memory (step 810). A determination is made as to whether the values are equal (step 812). If the values are not equal, the process logs the error (step 814) and verifies the system MAC in memory (step 816). If the values are equal in step 812, the process proceeds directly to step 816 to verify the system MAC in memory.

[0067] A determination is made as to whether the system MAC in memory is verified (step 818) by recomputing the MAC using the MAC key and comparing the recomputed value with the value read from the system table. If the system MAC is not verified, the process logs the error (step 820) and verifies the MACs of all auxiliary tables (step 822). If the system MAC is verified in step 818, the process proceeds directly to step 822 to verify the MACs of all auxiliary tables.

[0068] A determination is made as to whether the MACs of all the auxiliary tables are verified (step 824) by recomputing the auxiliary table MACs using the MAC key and comparing the recomputed value with the values read from the system table. If the MAC of any of the auxiliary tables is not verified, the process logs the error (step 826) and executes an audit record check process (step 828). If the MACs of all the auxiliary tables are verified in step 824, the process proceeds directly to step 828 to execute the audit record check process. The detailed operation of the audit record check process according to a preferred embodiment of the present invention will be described in more detail below with respect to FIG. 9. After the process executes the audit record check process, results are printed (step 830) and the process ends.

[0069] With reference now to FIG. 9, an audit record checking utility process is shown in accordance with a preferred embodiment of the present invention. The process begins, sets database isolation level to TRANSACTION_READ_COMMITTED (step 902). This isolation level releases the shared lock on the current row when the next record is read, so that a large number of records is not locked. Next, the process queries the audit log table for records between First_SN and Next_SN−1 (step 904). The process then sets a variable Current_SN to be equal to First_SN and Previous_SN to be equal to First_SN−1 (step 906). Thereafter, the process fetches the next record from the query results (step 908). A determination is made as to whether the record is available (910).

[0070] If the record is available, the value of Current_SN is set to be equal to the serial number from the fetched record. The process verifies the MAC for the record (step 912). A determination is made as to whether the MAC is verified (step 914) by recomputing the MAC using the MAC key and comparing the recomputed value with the value read from the integrity column. If the MAC is not verified, the process determines that the record has been modified and logs an error for corrupted record (step 916) and then determines whether Current_SN is equal to Previous_SN+1 (step 918). If the MAC is verified in step 914, the process proceeds directly to step 918.

[0071] If Current_SN is not equal to Previous_SN+1 in step 918, the process has found a gap in the serial numbers and logs an error for deleted records (step 920). The process then sets Previous_SN to be equal to Current_SN (step 922) and returns to step 908 to fetch the next record. If Current_SN is equal to Previous_SN+1, then no gap is found and the process sets Previous_SN to be equal to Current_SN (step 922) and returns to step 908 to fetch the next record.

[0072] With reference again to step 910, if the record is not available, a determination is made as to whether Current_SN is less than Next_SN−1 (step 924). If Current_SN is less than Next_SN−1, then the process determines that the record to be fetched is in the range of event records that are supposed to be in the audit log table. Therefore, since the record is not available, the record is missing and the process logs an error for missing records at the end of the log (step 926), executes a check extraneous records process (step 928), and ends.

[0073] If records have been deleted, the audit record checking utility will detect this because of gaps in the audit record serial numbers. The issue is that the audit record checking utility will detect this every time without a capability whereby an auditor running the tool can “patch” the audit log so that previously reported deleted records will not be reported again. In a preferred embodiment, the auditor may insert dummy records using the audit record checking utility. The inserted dummy records would be MAC'd liked other records and would have appropriate content to enable the auditor to get a later report on deleted records. At the same time, since the serial number gaps would be closed, the audit record checking utility would only report recent deletions or those for which the auditor has not patched in dummy records.

[0074] If Current_SN is not less than Next_SN−1 in step 924, then the process determines that the end of the log has been reached. Thus, the process proceeds directly to step 928 to execute a check extraneous records process and ends. The detailed operation of the check extraneous records process according to a preferred embodiment of the present invention will be described in more detail below with respect to FIG. 10.

[0075] The above described design for system level protection exploits the fact that each audit record has a unique serial number that increases monotonically. The first serial number and the next serial number are maintained in the system table. By maintaining these values in a separate table, it is possible to take a snapshot of the audit database at any given time.

[0076] The integrity check utility takes a snapshot of the audit log based upon the serial number range in the system table and performs an integrity check on the records using the previously described process. The system table is locked in shared mode for the duration of the read and released immediately. This allows the audit subsystem to continue inserting rows while the integrity check utility is executing.

[0077] With reference now to FIG. 10, an extraneous record checking utility process is shown in accordance with a preferred embodiment of the present invention. The process begins and queries the audit log table for records outside the First_SN to Next_SN−1 range (step 1002). A determination is made as to whether records outside the range are available (step 1004). If records outside the range are available, the process fetches each record and logs the serial number as an extraneous record (step 1006). Next, the process ends. If records outside the range are not available in step 1004, the process ends.

[0078] If the integrity check fails due to row modification, deletion, or insertion, the offending rows must be reported and an authorized administrator, typically an auditor, must be given an opportunity to inspect these rows. Once an administrator has taken action on the offending rows, they must be marked as having been inspected; otherwise, the integrity check utility will continue to report integrity failures. In a preferred embodiment of the present invention, the set of offending serial number ranges is stored in a separate table. The MAC of this table is stored in the system table. This MAC is protected under the system level MAC, so that data tampering of the “inspected” serial number ranges will be detected. In an alternate embodiment, the serial number ranges may be stored in the keystore.

[0079] Since the audit records are never deleted by any application, the audit log table can grow significantly over time. Audit records generated five years ago may no longer be required to be online. For this purpose, the audit subsystem provides a mechanism to archive and purge audit records. The records are archived to files and signed using an audit signing key. Archived records can be brought online for viewing purposes. Online archiving is accomplished using the snapshot mechanism described above allowing archival of records to be done at the same time new audit records are being inserted into the audit log.

[0080] The present invention provides an improved method and apparatus for protecting against data tampering of audit logs. Audit records are stored in a table in a relational database. Each record is assigned a unique serial number, which increases monotonically. The serial number is used in aiding the detection of row deletions and additions. Record modification is detected by computing a message authentication code over each record to verify the integrity of the record. The present invention protects against database administrator attacks by the use of a keystore.

[0081] It will be apparent to those of ordinary skill in the art that modifications may be made to the above described embodiments within the scope of the present invention. For example, while the audit records are described as being stored in a database table and having a unique, monotonically increasing serial number, the audit records may be stored in another data structure. The audit records may also be assigned some other identifier that maintains the order of the records. For instance, each record may be assigned a pointer to the next audit record in sequence. As another example of modifications that may be made to the embodiments described herein, the MAC value for each audit record may be computed over a smaller subset of columns (e.g., every other column), rather than the remaining columns in each record.

[0082] It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.

[0083] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.