Some customers have configured their sensor to check hourly for new updates.
For others once a day is enough.
The sensor allows you to configure the check based on a time interval, or based on specific days and times of the week.
Here are some things to consider:
1) We have seen errors when the update time is set exactly on the hour. Most people have used a basic configuration where the check is made on the hour. With most of these sensors using NTP they are in sync and all try to contact cisco.com at once. This can sometimes lead to connection problems.
So a recommendation would be to schedule it at an odd time like 13 minutes past the hour. Fewer sensors will be contacting cisco.com at that time, and you will be less likely to experience connection issues.
2) On lower end sensors (like the IDS-4215, and AIM-IPS), then signature update can take some time to install. During this time packets will not be monitored (for an inline sensor the packets may pass through unanalyzed if ByPass is set to auto).
You might consider scheduling the update at a time when your network is less congested and less chance of an attack getting past while the sensor is being updated.
3) Signature Updates vary in how often they are delivered. If no major vulnerabilities are discovered, then the updates generally release between every 1 to 2 weeks. However, the discovery of major vulnerabilities can cause the update to be released within a day to even within a few hours of the discovery.
As more is found out about the vulnerability it can even be common for updates to be released within a single day of each other.
Then there are even the few rare cases where more than 1 update may be released within a single day.
It is because of these rare cases that I've mentioned that some customers have chosen to have their sensors check on an hourly basis.
4) There are times when a signature update could add signatures with false positives. If you are running an inline sensor, then it is possible these new signatures could cause the denying of legitimate traffic. The signature team tried very hard to not have this happen, but they can't check for every possible traffic patterns and so they do sometimes happen.
For this reason you may want to schedule the updates to happen when you have somebody working who can handle the situation should it happen.
Large enterprise businesses have 24X7 monitoring and so are ready for this should it happen at any time of the day.
Smaller businesses may only have staff available during normal business hours. In which case you may want to schedule updates to happen only during normal business hours to be sure you have personnal on hand to deal with any issue that might arise.
5) You might even consider combining the cisco.com auto update feature along with the auto update from your own server.
Both types of auto update can be configured on the same sensor.
You might consider configuring the cisco.com auto update to happen during business hours for normal usage.
But also configure the auto update to your own server to check every hour.
So for example:
Normally you could setup your sensor to only check cisco.com during the morning on Mon - Fri when you have people in the office.
BUT you have your sensors to check your local server every hour.
Normally your sensor won't update at other times because you haven't placed anything on your local server.
BUT when an emergency update goes out and you need the sensors updated as soon as possible outside of the standard update times. Then you manually download the update from cisco.com and place it on your own local server. Then within an hour all of your sensors will have downloaded and begun installation of the update.
These are just some thoughts to consider.
Hopefully others on the forum will share their thoughts and experiences.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...