4. OPERATION OF TRIPWIRE At installation time - and whenever any of the monitored objects change legitimately - a HIDS must initialise its checksum-database by scanning the relevant objects. Persons in charge of computer security need to control this process tightly in order to prevent intruders making un-authorized changes to the database(s). Such initialisation thus generally takes a long time and involves cryptographically locking each monitored object and the checksum databases or worse. Because of this, manufacturers of HIDS usually construct the object-database in such a way that makes frequent updates to the checksum database unnecessary. Computer systems generally have many dynamic (frequently changing) objects which intruders want to modify - and which a HIDS thus should monitor - but their dynamic nature makes them unsuitable for the checksum technique. To overcome this problem, HIDS employ various other detection techniques: monitoring changing file-attributes, log-files that decreased in size since last checked, and a raft of other means to detect unusual events. Once a system administrator has constructed a suitable object-database - ideally with help and advice from the HIDS installation tools - and initialized the checksum-database, the HIDS has all it requires to scan the monitored objects regularly and to report on anything that may appear to have gone wrong. Reports can take the form of logs, e-mails or similar. 4.1 PROTECTING THE HIDS A HIDS will usually go to great lengths to prevent the object-database, checksum-database and its reports from any form of tampering. After all, if intruders succeed in modifying any of the objects the HIDS monitors, nothing can stop such intruders from modifying the HIDS itself - unless security administrators take appropriate precautions. Many worms and viruses will try to disable anti-virus tools, for example. Sadly, a lot of
4. OPERATION OF TRIPWIRE At installation time - and whenever any of the monitored objects change legitimately - a HIDS must initialise its checksum-database by scanning the relevant objects. Persons in charge of computer security need to control this process tightly in order to prevent intruders making un-authorized changes to the database(s). Such initialisation thus generally takes a long time and involves cryptographically locking each monitored object and the checksum databases or worse. Because of this, manufacturers of HIDS usually construct the object-database in such a way that makes frequent updates to the checksum database unnecessary. Computer systems generally have many dynamic (frequently changing) objects which intruders want to modify - and which a HIDS thus should monitor - but their dynamic nature makes them unsuitable for the checksum technique. To overcome this problem, HIDS employ various other detection techniques: monitoring changing file-attributes, log-files that decreased in size since last checked, and a raft of other means to detect unusual events. Once a system administrator has constructed a suitable object-database - ideally with help and advice from the HIDS installation tools - and initialized the checksum-database, the HIDS has all it requires to scan the monitored objects regularly and to report on anything that may appear to have gone wrong. Reports can take the form of logs, e-mails or similar. 4.1 PROTECTING THE HIDS A HIDS will usually go to great lengths to prevent the object-database, checksum-database and its reports from any form of tampering. After all, if intruders succeed in modifying any of the objects the HIDS monitors, nothing can stop such intruders from modifying the HIDS itself - unless security administrators take appropriate precautions. Many worms and viruses will try to disable anti-virus tools, for example. Sadly, a lot of
43354759-Trip-Wire.docx