Security Settings – Event Log
A set of uncontroversial, yet helpful Group Policies which will enforce consistent settings for your three main event logs.
- Log Size
- Retention Method
- Retain Period
- Free Event Log Consolidator
- Prevent local guest groups from accessing logs
* Guy’s Top Two Event Log settings
Since NT 3.51 days the default log size has remained at a mere 512k. (kilo, not megabytes). Why not create a policy which increases all logs to at least 4,000k = 4 Mb? A small logs size risks losing data because later events overwrite early ones and so you miss valuable troubleshooting clues. What have you got to lose? Surely you can afford a relatively tiny amount of disk space.
These days more and more programs write events to the application log, so do not just increase the system log, but also remember the application and security logs.
Choose ‘Overwrite events as needed’, rather than overwrite every 7 days. By selecting this policy, coupled with increasing the log size, you will minimise missing events in the logs.
Only high security organizations need, ‘Do not Overwrite, clear logs manually’. The idea is that being very security conscious, you do not allow any event to go unrecorded. However, if you select this option, then when the logs fill up, the system grinds to a halt until an administrator clears the logs. Here is another case of the more security you have the more work for you.
Syslog messages contain useful information for troubleshooting network problems. When something goes wrong then surely there will be an error message in the syslog datagram – if only we can find that record and interpret the event.
Here is a utility to capture and analyze network messages. The Kiwi Syslog Server filters messages and creates advanced alerts. View your syslog data via web access.
If you take my advice and use the ‘Overwrite events as needed’, then you do not need these settings. Their purpose is to fine tune those who like to overwrite the logs after x days. Here is where set that value for x.
Here is an example of what I mean by a gentle and uncontroversial policy. What you can do is hide the logs from Guests who log on to the machine. My thinking is not many guests are likely to logon, even if they do they are not going to see the company secrets by viewing the system log. Only administrators can see your security logs, so even without this policy guests could not snoop there.
LEM will alert you to problems such as when a key application on a particular server is unavailable. It can also detect when services have stopped, or if there is a network latency problem. Perhaps this log and event management tool’s most interesting ability is to take corrective action, for example by restarting services, or isolating the source of a maleware attack.
Yet perhaps the killer reason why people use LEM is for its compliance capability, with a little help from you, it will ensure that your organization complies with industry standards such as CISP or FERPA. LEM is a really smart application that can make correlations between data in different logs, then use its built-in logic to take corrective action, to restart services, or thwart potential security breaches – give LEM a whirl.
Next: Restricted Groups
See more security Group Policies
If you like this page then please share it with your friends