What do computer users hate the most? Interuptions. Whether it is a virus, spyware, web browser-based scripting (JavaScript, VBScript, and so on), or security programs
themselves, users hate popup messages that interrupt their work.
The following are some definitions you should understand:
•
CSA Query Message—Often referred to as a popup because that is what it does. CSA opens a window in the middle of your screen with a question that you must answer before proceeding. Figure 4-1 illustrates an example of this. Some messages might also include a secondary challenge—a series of letters you must enter to ensure for sensitive operations that there is a human in front of the machine (and not something just clicking Yes for you). Figure 4-2 displays an example of this.Figure 4-1 A Standard Cisco Security Agent Version 4.5 Query
Pre-Planning 57
Figure 4-2 A Standard Cisco Security Agent Version 4.5 Query with a Challenge
•
CSA Balloon Message—these are messages that appear as a little balloon above the Cisco Security Agent red flag in your taskbar. Figure 4-3 displays an example of a balloon message. They do not require any interaction and can be silenced by the user if they become annoying via the CSA menu on the user’s machine.Figure 4-3 A Standard Cisco Security Agent Version 4.5 Balloon Message
With these factors in mind, what can you do to define some metrics for how you want your users to interact with CSA?
•
You can take a simple approach and set the No User Interaction checkbox, which disables all popup messages and queries—in fact it removes the CSA flag and user interface completely from the user’s sight. CSA still operates normally; however, any query message that would have appeared to the user takes the default answer instead of giving the user a choice.This is a bit severe—make sure you understand what sort of environment you are deploying this option to, and test it well for the side effects of not giving the user any choice.
•
You can test these metrics for the number of query messages in a pilot and in various stages throughout your pilot. Poll your pilot users for feedback on the numbers of query messages they see during their daily activities to come up with changes to the CSA policy that you need to make. You can also poll users to develop a metric of what are acceptable query levels.Pre-Planning 59
This is an example of the thought process for the number of acceptable queries to see: Are three queries a day an acceptable metric for your users as an end goal? Are 20 queries a day acceptable?
•
How can users use the Don’t ask again checkbox to save time and queries in the future? You should take a look at the rules that you develop (and the policies provided by Cisco) and see what makes sense for your organization. Remember that as the CSA administrator, you can decide what answers to what questions that appear can be saved. You can also change that decision later with a simple policy change. This can be useful, especially if you make a decision based on the information you have at the time, and then later discover that you would like to change your mind and not allow users to save a particular answer to a particular query based on some new information.Many companies are able to reduce their events and queries to reasonable numbers, and this book helps you along that path, but user environments differ greatly and it is hard to recommend one number over another. You need to keep your query messages to a minimum if at all possible, so that:
•
Your users actually read what is on the screen in front of them when a query displays, and then they take appropriate action.•
Your users do not become annoyed by too many query messages and get in the habit of clicking Yes to anything that pops up on the screen (definitely a bad habit).During your project planning, remember that your CSA policies reflect your security policy. However, to successfully deploy any security package, you must make tradeoffs between security and usability.
ROI
ROI is the ultimate measure of success for a good project. This needs to be researched and typically documented to explain the reasoning behind the project.
If you are lucky and plan so well that you have extra time and money to invest in deploying CSA to all your machines, you can have a preventative measure in place before an attack happens. This is the best possible situation. However, most people come looking for security software not because they have unlimited time or resources to deploy it, but because their network and hosts have suffered a meltdown (perhaps for the second or third time) and they urgently need help.
However, help or mitigation against future attacks implies cost in manpower (people/time), capital expenses (equipment deployed—in this case, Management Center), and operating costs (software purchases, on-going time and effort, and support). Whenever cost is involved, most organizations want to have proof of a return on that investment.
In this case, several categories can be tracked to calculate a return on your investment in the purchase, deployment, and ongoing support of CSA. The following defines a set of them and gives you some examples on how to do this:
•
Cost of an incident— Define what an incident is to you and your organization. This can be something as simple as one attack or infection, or it can be the percentage of your organization that is affected by a particular security issue during a specified time.
— Do not overcomplicate things. For your organization, just figure out how much a minor versus a major incident costs you per occurrence.
Major can be defined as a certain number of hours spent by a specified number of staff members or the number of machines affected (or infected as the case may be).
Minor can be defined as everything that falls under the major threshold, but guard against including insignificant instances; for example, an employee brings a virus into the workplace, it affects only his machine, and is detected and cleaned by the antivirus. Such an incident probably does not qualify for a huge expense line or significant tracking.
— Start tracking the time spent on these incidents before you deploy CSA if at all possible. It is difficult to get numbers out of people after an incident, as they are usually exhausted and either under- or over-estimate the time actually spent.
— Track all costs associated with an incident that it is reasonable to track and track them as quickly as possible:
Did you have to take down a portion of production networking? What was the lost time (man-hours) because of this (to both those infected and not infected)?
Did you have to recover and reimage users’ workstations because of malicious code or other infections that were not cleanable through traditional methods (antivirus, cleaning programs, and so on).
Was travel required to mobilize a remote work force to address issues at remote locations?
How long were users unable to work? (This can be hard to track, but it is worth trying to estimate.)
•
Calculate the number of incidents you have in a typical year.— You do not generally gain much by measuring less than a year (such as measuring a quarter or month), because you are trying to define a general figure to work with.
Pre-Planning 61
— Separate your list of incidents based on the criteria you came up with in the preceding “Cost of an Incident” section (criteria such as cost or severity of the incident). Use the major and minor criteria examples (or your own definitions) to break the list up into those two groups. Go back as far as you can track these incidents to give yourself a good base from which to work.
If you do not have that base to work from, start the tracking methods to gather this information, so you are in the habit of collecting the appropriate information as it happens.
•
Gather the number of total machines you expect to deploy CSA to, and negotiate at least a starting point quote for what your cost of CSA will be (from the software perspective).— If you already purchased CSA, this is the easy part.
— If you have not purchased CSA, contact your account manager or reseller and get at least a ballpark number to work with.
•
Do your best to split the numbers you have from the earlier items in this list to operating expenses and capital expenses.Now that you understand what information you need to gather, you might ask yourself what you expect to gain from it.
To help you answer that question, Table 4-1 outlines a quick formula.
In this chart, we determined that a minor virus, worm, or malicious code incident typically costs 200,000 dollars. This figure is calculated from the average wages per hour across all employees typically involved in handling an incident and lost time (users, production networks, and so on) caused by the incident. The major incident that is shown in the example costs roughly 2.5 million dollars. We then track back and agree that we had four minor and two major incidents in the 2004 calendar year, and the same in 2005.
Table 4-1 Example Incident Cost Chart
Year Cost Frequency Event Cost Total Cost
2004 $200,000 minor 4 $800,000.00
$2.5 million
2005 $200,000 minor 4 $800,000.00
$2.5 million
This brings us to a rough total of approximately 5.8 million dollars spent each year in time and effort just to combat incidents that should be preventable with the help of CSA. This calculation is based on our knowledge of what CSA is capable of doing and stopping.
Although those numbers might seem enormous, think carefully about the last major virus or worm issue you had in your company, and what you lost because of it. Actually, we consider these numbers to be fairly conservative for most medium to large businesses.
So in this example case, as long as the capital and operating expenses to deploy CSA cost less than 5.8 million dollars, then you received a return on your investment.
What should you expect to see? After deploying CSA, you should hope to see most of those major events go away, and the number of minor incidents minimized. For those incidents that do occur post-CSA rollout, they should be contained to a small base of users as opposed to a large group that needs remediation. In addition, the effects of the incident on user computers should be so minimal that users can continue working.
In the preceding example, if you get rid of the major incidents and contain your issues to minor incidents in the first year, you would save five million dollars.
What about the incidentals? In a large enterprise, there is typically a limited security and operations staff available to investigate, track down, and remediate machines inflected by a virus or malicious code. We all want to have staff available to dispatch at the first sign of a security issue. However, most companies cannot afford that. On the other hand, think of the amount of time it takes just to add up to the five million dollars in the example. If you can get all that time (or most of it) back and dedicate it to working on other security issues, what is that worth, and how can you represent it as a return on this investment?
At this point, it might be useful for you to review the information covered in this section, and go back and look at some previous incidents you experienced. Try to fill in the blanks and gather information to then compare to your post-CSA deployment information. It will be invaluable in proving your case later on.