Security issues with an append-only log in UNIX

Question

I'm going over past exam papers for a security module I'm taking at university and there is a question which I can't give a great answer for.

As a security manager in a bank you are asked to implemented an "append-only" log system in Unix for all transactions in your bank. Give five security issues you are going to address and discuss a proper countermeasure for each.

To make it more in the spirit of this site... What security issues are there when it comes to implementing append-only log files in Unix and what would countermeasures to those issues be?

Answer 1

For an authoritative answer, see your instructor.

Here are some possible security issues:

1. How will we enforce/ensure that the log can only be appended to, and no prior entries can be deleted/removed/modified?

2. Who/what will have authority to append items to the log?

3. Who/what will have authority to read the log?

4. What do we need to do to ensure that confidential information is not stored in the log, or else is adequately protected?

5. How will this stand up in court, if the logs ever need to be used as evidence in a legal dispute?

6. What information/events should I log?

7. How will we secure the information to be logged while it is in transit from the system generating the log to the system storing the log records?

8. How will we secure the log information on storage?

9. How will the log records be used? How can they be used to detect attacks/fraud/anomalies? What tools/techniques will be used to analyze the logs?

For techniques you can use to address these security issues, you might start by reading the following questions on this site (they should cover a good part of the space, and if there is anything specific missing, you can ask another more specific question separately):

• Techniques for ensuring verifiability of event log files

• WORM media types

• What data should be logged?

• Do any cloud storage system offer an append-only mode for buckets, directories, etc.?

• How can I secure my log files?

• How do I log everything a certain program is doing?

• Is it legal to log passwords from failed logins

• What's the risk if I accidently type my password into a username field (Windows logon)?

• logging requirements for PCI for web applications

Answer 2

I'll do a quick security review — note that because it's quick, it's probably far from exhaustive.

Threats

1. Removing or amending an existing log entry.
2. Rollback of the log file. (Technically a particular case of removal of old entries, but a peculiar one deserving special consideration.)
3. Insertion of spoofed entries.
4. Preventing legitimate use of the logs.
5. Unauthorized access to the logs.

Attacks, with some countermeasures

1. Illegitimate physical access to the hardware hosting the logs.

   • Physical access control.
   • Geographical redundancy (dispatch logs to multiple hosts).
   • Log all access attempts to a remote location.

2. Illegitimate remote access to the machine hosting the logs.

   • Restrict the possible methods of access to a minimum (firewall, authentication, etc.).
   • Use secure, up-to-date access control software.
   • Log all access attempts to a remote location.

3. Bypass of local security mechanisms that enforce the read-only nature of the logs.

   • Use a secure method to implement a read-only log (for example, Linux's append-only attribute).
   • Use secure software to receive and store the log entries.

4. Misuse of a legitimate administrative access to the machine hosting the logs.

   • Restrict legitimate access methods to a minimum.
   • Require multiple authorization (split keys) for physical access and any dangerous logical access.
   • Log all access attempts to a remote location.

5. Submission of malformed log messages.

   • Use secure and robust software for sending, transmitting and receiving messages.
   • Authenticate senders.
   • Use a transmission method that ensures data integrity.
   • Audit the origin of log entries that do not match the expected format.

6. Capture or subversion of logs in transit.

   • Use a transmission method that ensures data confidentiality and integrity.
   • Use a transmission method that ensure proper delivery.
   • Do not validate a transaction until the transmission of the corresponding log entry has been acknowledged.
   • Sign and encrypt each entry at its point of origin (in addition to overall integrity mechanisms).
   • Audit the origin of log entries that do not match the expected format.
   • Audit the frequency of log entries from each source.

7. Snooping on log backups.

   • Encrypt logs and their backups.

8. Capture or subversion of log archives.

   • Encrypt and sign logs and their backups.
   • Archive logs on write-only media. Make multiple copies.
   • Audit log archives regularly.

9. Subversion of the log file rotation mechanism.

   • Design a robust log file rotation mechanism.
   • Rotate logs at different times on different copies of the data.