Security Log Test
This test reports statistics relating to the Windows security log audits.
Target of the test : Any Windows host system
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the server being monitored
Configurable parameters for the test
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Successful audits: |
Indicates the number of successful audits of windows security logs. |
Number |
The detailed diagnosis of this measure, if enabled, provides the details of the successful log audits. |
Failure audits: |
Indicates the number of windows security log audits that failed. |
Number |
The detailed diagnosis of this measure, if enabled, provides the details of the failed log audits. |
Note:
The stateless alerting capability is currently available for the following tests alone, by default:
- EventLog test
- ApplicationEventLog test
- SystemEventLog test
- ApplicationEvents test
- SystemEvents test
- SecurityLog test
- Account Management Events test
If need be, you can enable the stateless alerting capability for other tests. To achieve this, follow the steps given below:
- Login to the eG manager host.
- Edit the eg_specs.ini file in the <eg_install_dir>\manager\config directory.
- Locate the test for which the Stateless Alarms flag has to be enabled.
-
Insert the entry, -statelessAlerts yes, into the test specification as depicted below:
EventLogTest::$hostName:$portNo=$hostName, -auto, -host $hostName -port $portNo -eventhost $hostIp -eventsrc all -excludedSrc none -useWmi yes -statelessAlerts yes -ddFreq 1:1 -rptName $hostName, 300
- Finally, save the file.
- If need be, you can change the status of the statelessAlerts flag by reconfiguring the test in the eG administrative interface.
Once the stateless alerting capability is enabled for a test (as discussed above), you will find that everytime the test reports a problem, the eG manager does the following:
- Closes the alarm that pre-exists for that problem;
- Sends out a normal alert indicating the closure of the old problem;
- Opens a new alarm and assigns a new alarm ID to it;
- Sends out a fresh email alert to the configured users, intimating them of the new issue.
In a redundant manager setup, the secondary manager automatically downloads the updated eg_specs.ini file from the primary manager, and determines whether the stateless alerting capability has been enabled for any of the tests reporting metrics to it. If so, everytime a threshold violation is detected by such a test, the secondary manager will perform the tasks discussed above for the problem reported by that test. Similarly, the primary manager will check whether the stateless alert flag has been switched on for any of the tests reporting to it, and if so, will automatically perform the above-mentioned tasks whenever those tests report a deviation from the norm.
Note:
- Since alerts will be closed after every measurement period, alarm escalation will no longer be relevant for tests that have statelessAlerts set to yes.
- For tests with statelessAlerts set to yes, statelessAlerts will apply for all measurements of that test (i.e., it will not be possible to only have one of the measurements with stateless alerts and others without).
- If statelessAlerts is set to yes for a test, an alarm will be opened during one measurement period (if a threshold violation happens) and will be closed prior to the next measurement period. This way, if a threshold violation happens in successive measurement periods, there will be one alarm per measurement period. This will reflect in all the corresponding places in the eG Enterprise system. For example, multiple alerts in successive measurement periods will result in multiple trouble tickets being opened (one for each measurement period). Likewise, the alarm history will also show alarms being opened during a measurement period and closed during the next measurement period.