Best Practices

This section examines some of the important issues involved in improving performance. Following is the list of some good practices:

Recommendation on Installation

Use a dedicated machine for CSAMC installation, and for better management and performance, use a separate machine for the Security Monitor. This also depends on the number of Agents deployed and other variables such as amount of logging turned on, etc. To support 5,000 agents, use approximately a quad processor, 2 GB of memory, and a RAID disk.

Test Mode

Test mode is used to find out what's normal for the machines in your network, and to see if you need to create any exceptions for certain applications to function correctly. However, be aware that there are performance issues with the agent installed and in testmode.

Testmode, as you know, logs all events regardless of whether logging is turned on or off. Once testmode is turned off, any rules that have logging disabled will no longer log the event. Testmode is meant for policy tuning and not for performance testing. Testmode logs more events than you will see if the agent is in protect mode.

The recommendation is this:

Step 1.	Place agent into Testmode to tune the policies to meet your security objectives.
Step 2.	Once the policies are tuned, take the agent out of Testmode and you will see a decrease in the performance impact of the agent. Furthermore, you can even turn off logging of some deny/query user rules if you do not want to see the event log messages that they generate.
Step 3.	Turn off the network shim if the machine already has some kind of firewall capability or application already installed. Just by the nature of what it does, the netshim affects performance more than other CSA components.

Disaster Recovery for CSA

Disaster Recovery is discussed under the database management section of this chapter, so it is not discussed again here. This section focuses primarily on suggestions for Disaster Recovery procedures that were described in the Database Management Troubleshooting section earlier.

There is no need for a redundancy server at another site. However, if your current company policy calls for a redundancy server at another site, the backup procedure will work just as well as wherever that backup machine is located. This is true if the agents can resolve domain name via DNS server to that new MC.

A possible recovery scenario would be to run the Backup Configuration feature once a day (or just schedule the backup to be performed), and then run an automated script that will zip up the backup files and move them to a shared drive (or move them over without zipping them up). If the original server ever goes down, then you can use any machine that meets the hardware and software requirements to restore the MC quickly. Again, the new machine must be given the same DNS name and IP address as the original StormWatch Management Console.

In addition, the Agents that belong to that MC must be able to reach it via DNS/WINS to get their configurations changed, and to send events to the MC. Because the new MC has exactly the same configuration as the original MC, downtime and recovery of the MC is kept to a minimum. It would take approximately 10-15 minutes to reinstall the MC, and another 10-15 minutes (depending on the size of the DB) to restore the original configuration from our backup. Remember that the Agents are still protecting their hosts throughout any recovery process.