The Event Viewer feature, introduced in Security Manager 4.0, enables you to selectively monitor, view and examine events from ASA devices.
Before you can use Event Viewer to view events generated from an ASA device, you must configure the logging policies on the device to generate and transmit syslog messages.
Step 1 (Device view) Seclect the ASA device, then select Platform > Logging > Syslog > Logging Setup from the Policices selector. In the policy, select Enable Logging.
Step 2 Select Platfrom > Logging > Syslog > Syslog Servers.
Add the Security Manager server's IP address to the syslog servers table. Configure the server to use the UDP protocol. The default port, 514, is correct unless you configure a differnt port on the Tools > Security Manager Administration > Event Management Page.
Step 3 If you want to configure non-default syslog server settings, such as adding time stamps to syslog messages, changing the severity level of messages, or suppressing the generation of specific messages altogether, configure the Platform > Logging > Syslog > Server Setup policy.
After the above configuration changes have been submitted and deployed to the ASA device, you can start viewing events. To open the Event Viewer do one of the following:
- Select Tools > Event Viewer
- Click on the Event Viewer icon.
- Use the keyboard shortcut Alt+T+W
Event Viewer opens in a new window and displays the All Device Events view in the Last 10 Minutes mode.
Tips for Event Log Management (Generic tips):
Here are few fundamental tips for event log management to help you get started:
1. Use an application to do the heavy lifting for you
Unless you have a very small number of servers, you’ll find you have too many systems to effectively handle event log management by hand. The most important tip for event log management is to use an event log management application. The automation will make event log management scalable, and it will help with the remaining tips in this article.
2. Log only what you need, which is just enough to reproduce the events
Too much information is worse than not enough. It’s not uncommon to find servers configured to log so much that they cannot store more than a rolling 24 hour period worth of data. If someone wants to know on Monday morning what happened Friday night, that data has already been lost. Good event log management avoids information overload by ensuring only the relevant data is logged.
3. Aggregate, and correlate your logs
That event log management software will save you countless hours of logging on to each individual system and trying to gather all the logs manually, and then massaging them in Excel to correlate events. You want to see what happens and when it happens across all your systems, and correlating events is the way to get the big picture.
4. Review the logs regularly
Reviewing logs when you have a problem is a failing strategy. Regularly reviewing logs lets you start to recognize what is normal, so you will notice what is bad. You need to establish that baseline. Regular reviews can also help you spot issues before they become incidents, and that is one of the main reasons to do any kind of event log management at all. Otherwise, you might as well just turn off logging completely to save space.
5. Investigate anomalies
Because you are doing regular reviews as part of your event log management, you will be able to spot anomalies and get ahead of any potential issues before they become major incidents. Whether it is response times, capacity challenges, or inappropriate access attempts, early detection is key.
Scenario 2:
Problem:
We have CSM 4.4.0 SP2 patch 1 installed with no default configuration. According to cisco, CSM is under Vulnerable Products list with cisco bug ID CSCuo19265.Do I need to take any action for my CSM ?
Solution:
CSM 4.4.0 SP2 patch 1 is not vulnerable to heartbleed. No action required for this specific version of CSM.
Given below is list of CSM versions that are vulnerable:
CSM 4.5
CSM 4.5 SP0 PP1
CSM 4.5 SP0 PP2
Recommend that you restrict HTTPS access to the CSM server to the few clients that actually need access to it, until a fix has been released. That way you can at least restrict the amount of clients that could utilize this leak.
To reliably report events from contexts in multiple-context mode, Cisco Event Viewer requires an IP address for the management interface of each context." [/edit]