Browse Prior Art Database

Efficient Gathering of Computer Audit Data Before and During Attack Disclosure Number: IPCOM000028538D
Original Publication Date: 2004-May-19
Included in the Prior Art Database: 2004-May-19
Document File: 2 page(s) / 45K

Publishing Venue



An idea is disclosed, which allows to keep a very high amount of detailed log data of a computer system not only from the time after an attack, but also from some time before the attack. In the physical security/video surveillance world, it is possible today in products that video cameras can write their stream into a local buffer, reflushing after x minutes. In case of an alarm of another sensor (like a door opening etc), the system can tell the camera to keep this data plus some more minutes after the event and send it to the server, where the video snippet will be associated with the alarm - thereby capturing data during the alarm/intrusion. Obviously it is especially important that one also keeps data from before the alarm until after the alarm. A similar solution is disclosed here for the area of computer security: An extensive amount of logging/auditing could be enabled continuously on the computer system, but data will be only kept for x minutes (in memory, or a round-robin file etc), thereby reducing memory and resource consumption. Then, when an alarm from an intrusion detection sensor tells the central server that the host was the target of an attack, the system contacts the host (via a secured channel) and gathers immediately the existing audit information in the buffer from before until after the alarm for analysis and forensics. Optionally, logging behaviour could be changed to allow for more extensive, or remote instead of local, logging on the attacked machine. These audit data can be attached to the security alarm and serve for detailed analysis of the intrusion (attempt). To keep e.g. the process and I/O activity during the attack (starting before the attack) for analysis greatly helps with the understanding of the results of the attack (especially, if it was successful or not, what was changed by the attacker etc).

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Efficient Gathering of Computer Audit Data Before and During Attack

Meaningful, reliable audit/log traces useful for forensic analysis in computer security

are basically a necessity for any security analysis, but can quickly get very large (e.g. in the order of 100Mb/hour, see [1]), adding a significant performance hit onto computer systems. Therefore in practice only a low level of audit data is gathered, which is not allowing a detailed forensic analysis in case of an intrusion (attempt). in case of a successful intrusion on a computer system, the attacker can in most

cases change audit/log traces, thereby making an analysis of the intrusion very hard resp. destroying the evidence and consequences and repercussions of an intrusion.

Current solutions: usually in security conscious organizations a compromise is taken: a manageable size of log data (restricted in detail and number of machines - see e.g. [1], [2]) is taken to a central server (to avoid tampering of an attacker) and stored for a time, which allows for discovery of a intrusion (attempt) and analysis of the logs, before removal of the log data. alternatively, cryptographic methods are used to make available logs tamper resistent and destroying of log data at least detectable [3]

This compromise is unsatisfactory from a intrusion detection standpoint for security & forensic analysis, therefore an additional solution is proposed here.

In normal operation, the monitored computing systems (1) keep extensive audit logs locally (2) or remotely by sending log data to a central logging server (3), but to keep log files manageable, data is only kept for a very limited time, say x minutes (where x is in the order of about 10 minutes, which should correspond to the worst case reaction time of the deployed intrusion detection system...