I'm curious as to just how secure the Windows event log is, and exactly what security measures it uses.
Does it include any defenses against tampering - for example, does it use digital signatures or hash chaining?
While ACLs are indeed the main way that the event log is secured, it does implement some other security features.
When the event log is cleared from the event viewer, a new event is added which contains the username of the user that cleared it.
Windows also keeps event log files open while the operating system is running, locking the files in such a way that they can only be written to by the event log process. It is however possible for tools to inject malicious code into the event log process to circumvent this. One such tool is WinZapper, though you do need Administrator access, and I haven't played with this since Windows XP - so no idea if it still works on Windows 7.
It is sensible to ship your logs to a remote, hardened server. A number of free tools, such as Snare, support forwarding Windows logs to a syslog server. Most SIM/SIEM tools also support this either by using locally installed agents to push logs to the remote server, or by the remote server pulling logs from source systems over WMI (less scalable way). You can also use the Windows Event Collector.
Windows' Event Log is only as secure as the system it is running on. Because accounts on the system read, write and modify the events, anyone compromising the machine, or anyone with admin privileges, can modify the events. Technically, only LSASS is supposed to be able to write, but history can tell you how Sasser and other worms rendered this useless.
Personally, the only possible defense I can think of against tampering would be to use remote logging, e.g. eventlog-to-syslog. This allows ANY and ALL entries to be stored remotely. The only method someone can use to bypass anything would be AFTER the fact. Meaning, there would ALWAYS be the initial instance of a log that can never be changed. If an attacker DID manager to start tampering with logs, they would have to do some heavy duty programming to intercept system calls prior to it being written (via LSASS) to hide their tracks.
Even so (managing to tamper with logs), the only mechanism they'd (the attacker(s)) would be able to do, to go BACK and hide/modify their entries, would be to also compromise the syslog server
EDITED at 3:42PM EST for clarity on my initial answer...
From the onset, you have to look at how Windows is storing anything with regards to EventLog. It is done at the application, session, presentation, transport layers. This is ALL done on the machine itself. Every single instance is written locally. THIS is the problem period. For ANYONE who would have access to reading, writing, opening, they'd have the capability (not ability unless they're an admin) to read and write files.
Think about that for a moment. If I am on a machine with these privileges, there is little to stop me from modifying. Even if you tried to log what I am doing, I can modify these logs. In fact timestomp (counterforensics program) does just that mangles MACE times. The ONLY mechanism to prohibit this, would be to send the logs OFF the machine. There is no mechanism I know of that will STOP someone local on the machine from gaining the ABILITY to modify eventlog data. This is because reads, and writes are done on the machine itself. There is the possibility that a) an update can break things b) a user with escalated privileges can delete, and or modify data.
Remote logging makes more sense because the logs (events) aren't stored, written, modified locally. Someone would have to get into the logging machine to manipulate (modify, erase) entries. The only other mechanism (local checksumming, etc) will ALWAYS get trumped because there always needs to be a superuser (admin, root, etc). Malware authors, virus writers, malicious attackers tend to modify event entries most of the times. This should be evident that not much can be done on a local level.
As for "tamper proof," Manage Engine claims they can do this. However, they do are doing it remotely.