In most organizations, network and system records pile up somewhere. As long as the disk does not fill up and the service keeps running, the matter is considered closed. Yet when a record is actually needed, the real questions are different: whose is this record, how do you show that nobody tampered with it, and can you really bring it back when you need it?
This article breaks record keeping into three questions. It contains no legal assessment; how records are handled in any given process is a separate matter.
1. Whose record is it? (Identify)
A log line often carries an address and a time. But an address alone does not tell you a person or a device. The same address may have been given to different devices during the day.
Identification means being able to link a record to the user or device at that moment. The questions to ask are:
- Are address assignment records kept as well, or is there only a traffic record?
- Can the time in the record be compared with the time of the address assignment?
- On guest or shared networks, is there a step that identifies the user?
If you try to build this link afterwards, it is usually incomplete. It is more robust when the identity information is produced together with the record, at the time of the record.
2. The record has not changed: how do you show it? (Prove)
The sentence “the records are on the server” does not show that the records have not changed. Someone with access to the file can change the content, knowingly or by mistake, and the change may go unnoticed.
The common way to show integrity has two parts:
- Digest (hash): A short fingerprint of the record file is produced with an algorithm such as SHA-256. If a single character in the file changes, the fingerprint changes.
- Timestamp: A trusted third party signs that this fingerprint existed before a certain moment. RFC 3161 is a standard defined for this purpose.
Together they say: “This record has been standing in this form since this moment.” How often the sealing is done also matters; the longer the interval, the longer the period left unsealed.
3. Can the record come back? (Test)
A record whose integrity has been proven also has to be within your reach. Whether the archive can be exported, whether the compressed file opens and whether the seals can be verified again can only be seen by trying. Cases where a record assumed to be in the backup cannot be read are mostly noticed at the moment of need.
That is why testing should not be a one-off but periodic, and if possible should not depend on a person remembering it. An automatic test turns the sentence “our archive is sound” from an assumption into an observed result.
A three-question checklist
- Can we link every record to a user or device at the time of the record?
- Can we show with a digest and a trusted timestamp that the records have not changed?
- Do we regularly try that the archive can be opened and verified?
If you cannot answer “yes” to all three, this is not an alarm; it is a list of areas to improve.
How does LogKeeper Pro handle these three steps?
LogKeeper Pro is the log management software developed by 7 Tepe, and its message follows the order in this article: Identify · Prove · Test.
- Identify: It identifies whose record it is.
- Prove: It shows record integrity by sealing with a timestamp and a digest.
- Test: When an off-site copy target is defined, it tests periodically and automatically whether the restore works.
The product installs on your existing server. You can contact us for details, a demo and a quote.
Also on this topic: Firewall logs and Turkish Law No. 5651: where to start?
Do you want to show whose your records are, that they have not changed and that they can come back? See the LogKeeper Pro page: LogKeeper Pro
