Installing Management Center for Cisco Security Agents 6.0 - Quick Configuration and Deployment [Cisco Security Agent]

Table Of Contents

Quick Configuration & Deployment

Overview

Logging on to the CSA MC

Access Management Center for Cisco Security Agents

Simple View and Advanced View Modes

Visible, Hidden, and Read-only Components on CSA MC

Cisco Security Agent Policies

Piloting the Product

Running a Pilot Program

Quick Configuration and Deployment

1. Update your Licenses

2. Pick your Policies

3. Update the Agent Kits

4. Distribute and Install the Kits

5. Create Exceptions as Necessary

View Registered Hosts

Policy Tuning and Troubleshooting

Overall Guidelines

Creating Policies for Your Special Applications

Using Audit Mode

Disabling Specific Rules

Caching and Resetting Query Responses

Setting Up Exception Rules

Configuring Your Own Policies

Distributing Agent Kits Using a Third Party Tool

Setup.exe Command Switches

--autolevel

--reboot

--rebootdelay

--startagent

--disable_net

--targetdir

--mt

Command Examples

Quick Configuration & Deployment

Overview

This chapter provides the basic setup information you need to start using the Management Center for Cisco Security Agents to configure some preliminary groups and build agent kits. The goal of this chapter is to help you quickly configure and distribute Cisco Security Agent kits to hosts and have those hosts successfully register with CSA MC. Once this is accomplished you can configure some policies and distribute them to installed and registered Cisco Security Agents.

For detailed configuration information, you should refer to the User Guide.

This section contains the following topics.

•Logging on to the CSA MC

–Access Management Center for Cisco Security Agents

–Simple View and Advanced View Modes

–Visible, Hidden, and Read-only Components on CSA MC

•Cisco Security Agent Policies

•Piloting the Product

–Running a Pilot Program

•Quick Configuration and Deployment

–1. Update your Licenses

–2. Pick your Policies

–3. Update the Agent Kits

–4. Distribute and Install the Kits

–5. Create Exceptions as Necessary

•View Registered Hosts

•Policy Tuning and Troubleshooting

–Overall Guidelines

–Creating Policies for Your Special Applications

–Using Audit Mode

–Disabling Specific Rules

–Caching and Resetting Query Responses

–Setting Up Exception Rules

•Configuring Your Own Policies

•Distributing Agent Kits Using a Third Party Tool

–Setup.exe Command Switches

–Command Examples

Logging on to the CSA MC

Use the procedures in this section to access the CSA MC from a browser. After logging on you reach CSA MC's Home Page. For a description of the CSA MC interface, see "Interface Overview of Management Center for Cisco Security Agents" in Using Management Center for Cisco Security Agents.

Access Management Center for Cisco Security Agents

An initial administrator account was created as part of the CSA MC installation process. Use that administrator account to log into CSA MC.

You access CSA MC locally or remotely from a supported Web browser. No more than 12 users may be logged on to the CSA MC at the same time.

Local Access

•To access CSA MC locally on the system hosting CSA MC software, double-click the CSA MC desktop icon created during the installation.

Remote Access

•To access CSA MC from a remote location, launch a browser application and enter
https://<system hostname>.<domain> 
For example, enter https://stormcenter.cisco.com
Enter the administrator name and password created during the CSA MC installation.

Note When you login to the CSA MC system, you are presented with the CSA MC Home page. Various messages or warnings may appear in the Things to Do area. See the description of the Home Page in Using the Management Center for Cisco Security Agents for more information.

Tip Once you have logged on, look at the global command buttons in the top right corner of the Home Page. One will indicate "All OSes," "Windows," or "Unix." Click the command button to view the components relevant to the operating system you choose. Clicking Unix displays components for both Solaris and Linux operating systems.

Caution If you have not obtained a valid license from Cisco, when you login to CSA MC, you'll receive a warning informing you that your license is not valid. Any newly deployed agents will not be able to register with the unlicensed CSA MC. Refer back to Licensing Information, page 2-2 for further licensing information.

Simple View and Advanced View Modes

When you first login to CSA MC, the administrator created during the installation process has a simplified view of CSA MC. This "Simple Mode" view provides everything you need to deploy and administer the product. Default groups are pre-configured and shipped with the MC to provide out-of-the-box security policies for servers and desktops. Through the use of a wizard, you can refine the policies to match the security needs of your site and of the applications that run on your network.

For advanced users there is the "Advanced Mode" view. This view exposes all CSA MC menus and pages to administrators. This gives the administrator the ability to create or configure any component, view all possible reports, and have access to the full range of analytical and maintenance utilities. Advanced view is best for administrators who need to create customized policies for their enterprise or who want more granular control of the system.

Visible, Hidden, and Read-only Components on CSA MC

What you see on component list pages and on the Host Security page depends on your user configuration and whether or not the component is hidden or visible. What you can edit on list pages or through the Host Security page depends on your user configuration.

Some components are "hidden" by default other components are "Read-only" by default. Users are not expected to have to configure these components in a deployment that uses the groups, policies, and other components, supplied with this release.

Before you begin your pilot, view the system in Advanced Mode and, from the menu bar, navigate Maintenance > Administrators > Account Management. From the account list page, click the login ID you intend to use to manage your pilot. The details page shows the user's preferences.

Here you can configure users viewing mode, their ability to see hidden objects, and their permissions to edit read-only objects. Configure your users with the permissions they will need to conduct the pilot. See "Configuring Role Based Administration" in the Management Center for Cisco Security Agents Administration chapter of the User Guide.

From the menu bar, navigating Configuration > Host Security brings up the Host Security page. From this page you can configure groups and create agent kits. The groups and policies appear on this page because their Simple Mode Settings are set to expose the component on the page.

If there are other groups or policies you want to manage through the Host Security page, you can configure them to be displayed if your user account allows you to edit read-only components. See "Configuring Groups" and "Configuring a Policy" in the User Guide for instructions on exposing these components on the Host Security page.

Cisco Security Agent Policies

CSA MC default Cisco Security Agent kits, groups, policies, and configuration variables are designed to provide a high level of security coverage for desktops and servers. These default Cisco Security Agent kits, groups, policies, rule modules and configuration variables cannot anticipate all possible local security policy requirements specified by your organization's management, nor can they anticipate all local combinations of application usage patterns. Cisco recommends deploying agents using the default configurations and then monitoring for possible tuning to your environment.

If you are using shipped policies, you can also use shipped, pre-built agent kits. Therefore, if you're not creating your own configurations, you can simply refer to the chapters on Management Center for Cisco Security Agents Administration and Event Logging and Alerts in Using Management Center for Cisco Security Agents for information on deploying kits to end users and viewing the event log.

Note Each pre-configured rule module, policy, and group page has data in the expandable +Detailed description field explaining the item in question. Read the information in these fields to learn about the items described and to determine if the item in question meets your needs for usage.

As a jumping off point for creating your own configurations, the following sections in this manual take you through the step by step process of configuring some of the basic elements you need to initiate server/agent communications and to begin the distribution of your own policies.

Piloting the Product

Before deploying Cisco Security Agents (CSA) on a large scale, it is worthwhile to run a manageable and modest initial pilot of the product. Even in a CSA upgrade situation, a short pilot program will be beneficial.

CSA 6.0 ships with many security policies that you should be able to run in your enterprise as they are or with only minimal tuning. This tuning is best done on a small sample of systems that are representative of the whole.

Once the pilot is operating satisfactorily, with CSA protecting systems using properly tuned policies, you can turn your pilot into a larger deployment.

The following sections provide a guideline for conducting a pilot of CSA and deploying the product on a large scale.

Running a Pilot Program

Your pilot program should proceed in the following manner:

•How large should a pilot program be? Select a logical, manageable, sample of systems on which agents will be installed. A good rule of thumb is to make your pilot approximately 1% the size of what the entire deployment will be.

Details:

–If your entire deployment will be very small, be sure to pilot at least 15-20 systems.

–If your entire deployment will be very large, roll out your pilot in steps. For example, do not pilot 1,000 systems initially and all at once. Start with a smaller sample and gradually expand the pilot.

The pilot should include machines that you can access readily (either yourself or through a responsive end-user). If you will eventually be installing agents on multiple, supported operating systems, your pilot should include machines running those operating systems. Again, systems in your pilot should be representative of the whole deployment to which you intend to scale.

•How long should a pilot program run? The policies in CSA 6.0 are designed to be used as they are or with only minimal tuning. Still, deploying and tuning policies is an iterative process. Initially, you will have some event log noise to parse. You must examine the data coming in and fine tune your policies accordingly.

Although every site is different, it would not be unusual to run a pilot program for approximately one to two weeks after you feel you have tuned your policies to your satisfaction. All possible application usage should take place within the pilot time frame. It is important to note that this recommended time frame allows you to exercise applications, their deployment and usage, within an entire fiscal quarter. The idea being, every application you use and every manner is which you use it will occur during this piloting period.

Quick Configuration and Deployment

The Management Center for Cisco Security Agents (CSA MC) comes preconfigured with downloadable kits for desktop and server hosts. Here's how to get your pilot program up and running in five easy steps:

1. Update your Licenses

CSA MC comes with a few free agent licenses for servers so you can install the CSA MC and get started quickly. Before deploying agents throughout your network, you must install a more comprehensive license for desktops and servers. If you want the added protection of the Data Loss Prevention feature, you will need to upload a separate license for that.

For a procedure on how to update your licenses and to learn more about Data Loss Prevention update your licenses, see Licensing Information, page 2-2.

Note You can proceed through step 3 without loading a license, but make sure to load a license before proceeding to step 4.

If you need help getting your formal CSA MC license file(s) from Cisco, see the Product Licensing Information section of the Documentation and Licensing Overview for Management Center for Cisco Security Agents 6.0. If you need keys for a product evaluation, and you are a registered user of Cisco.com, you can go to the Cisco Product License Registration page and download the Cisco Security Agent 6.x Demo License.

2. Pick your Policies

To pick policies for your desktops, mouse-over the Configuration menu on the CSA MC and click Host Security, then follow this procedure:

Step 1 Click the "Desktops" group for the appropriate operating system. You will see a list of policies - you can click on a policy name to see a description of the policy.

Step 2 Click the checkbox for each policy you want enforced on your desktops. If you want a policy's rules to be logged but not enforced, click the policy's "Audit Mode" checkbox. If you are unsure of what to check, just keep the defaults. If you change a checkbox from its default state, press the Save button when done.

Step 3 If a policy displays a red [warning] link, click the link to show the items that require customization. Customize each item by clicking its link in the Policy Warning dialog box and editing the pop-up provided. If you customize something, press the Save button when done.

Tip If you want to take the deployment a little slower, enable one policy at a time and tune that policy before turning on the next policy. This will help you match specific outcomes with specific policies.

3. Update the Agent Kits

Policies are bundled together into downloadable, installable agent kits. If you made changes in the previous step, you must update these kits by clicking Generate rules at the bottom of your browser window, then pressing the Generate button to confirm the action. (If you didn't change anything, then you can skip this step.)

You can see a list of all your agent kits by mousing-over Systems in the menu and selecting Agent kits.

4. Distribute and Install the Kits

To see the agent kit corresponding to your desktop group's policies, go to the Host Security page and click on the appropriate Desktops group. You should see the text "Available kits for this group" followed by a link. Click the link to pop up the name of the kit, and click on this name to see the kit's details dialog box.

On this dialog, under the heading Download, there will be a URL. The URL references the executable that installs CSA with the appropriate policies. E-mail this URL to your users who should install CSA. Alternatively, you can click on the URL, save the resulting executable, then use systems-management software (like SMS) to push the executable to your endpoints for installation.

When an agent kit is downloaded and installed, the agent will register with the CSA MC, start enforcing your policies and generating events.

Once you have completed steps 1-4 for desktops, repeat them for the servers you want to protect with CSA.

5. Create Exceptions as Necessary

If CSA denies an action that you wish to allow, you can create a policy exception to permit the action.

Step 1 Open the Event Log by navigating Events > Event Log from the menu bar.

Step 2 Locate the event corresponding to the denied action in the Event Log.

Step 3 For the appropriate event, click the Wizard link to launch the exception wizard.

Step 4 Follow the steps given in the wizard to make the agent more permissive. Take the default settings offered by the wizard.

View Registered Hosts

Once you have distributed agent kits to your pilot hosts, you can see which hosts have successfully registered using any of these methods:

•In Simple or Advanced Mode, mouse-over Configuration in the menu bar and select Host Security. For a particular group, click the number of hosts in the hosts column to see which hosts have registered as a member of that group.

•In Advanced Mode, mouse-over the Systems menu and select Hosts. This takes you to the Hosts list page. On the right side of this page is a column that displays varying types of information on each host. Use the pulldown menu for this column to view hosts that are Active.

•To search for specific hosts based on more status data, use the Search option in CSA MC. Search for Hosts using available status information such as:

–Active hosts—A host is active if it polls into CSA MC at regular intervals.

–Not active hosts—A host is inactive if it has missed a certain number polling intervals or if it has not polled into the server for at least one hour.

Policy Tuning and Troubleshooting

Once you have started your CSA pilot, you may need to tune the policies to suit your needs and troubleshoot any problems that occur. Beyond creating exceptions you may need to tune rules to deny or allow user actions or prevent false positives. Tuning policies is best done using Advanced Mode.

Overall Guidelines

This section presents some overall guidelines for tuning and troubleshooting your CSA pilot. Please read through this section carefully and consider the specific needs and requirements of your pilot before moving on to actually using the techniques. Here are the most important guidelines to follow when tuning and troubleshooting policies:

•Never directly modify one of the supplied groups, policies, or rule modules unless you are using the links provided through the Home page or Host Security page. The groups, policies, rule modules provided are designed to work in your enterprise with minimal or no tuning. Using the links provided on the Home page and Host Security page will direct you to the areas that require your attention. If you need to dramatically change a group, policy, or rule module, make sure you clone and rename it first so you preserve it for use later. Modifying the supplied groups, policies, and rule modules directly makes it difficult to back out of any inadvertent mistakes.

•Policies displaying a red [warning] link on the Host Security page may need your attention. Click the warning link to display the Policy Warning dialog box. In the box you will find links to one or more items that may have already been customized but may require occasional updates. Customize each item by clicking its link in the Policy Warning dialog box and editing the pop-up provided.

•Use the supplied groups and if necessary define additional groups for each distinct desktop and server type in your network. In your pilot, you should have some participants that are using each desktop and server type so you can tune and troubleshoot all policies before deployment.

Group membership is cumulative, which can be useful in tuning and troubleshooting. For example, at the beginning of a pilot, participating hosts that are Windows desktops would be attached to the All Windows and Desktops groups. Once you are satisfied with the performance of these basic policies, you could define a new group for a specific department's applications, attach hosts to the new group, and pilot those policies.

•If you are running your pilot with policies or groups in Audit Mode, examine the event log (Events -> Event Log menu) for possible tuning and troubleshooting needs before moving to enforcement mode (also known as live mode). With the current release, you can place individual policies within a group in audit mode or a single rule module in audit mode. Therefore, as you tune and troubleshoot, you can incrementally move rule modules to enforcement mode if need be. Keep in mind when using audit mode that the area under test is completely vulnerable from a security standpoint.

•Policy tuning and troubleshooting is an iterative process. Focus on a single policy for improvement at a time and then verify that the tuning and troubleshooting techniques did what you expected before deploying the improved policy.

•Prioritize the security features you want to implement with CSA policies. You can also prioritize applications and groups. By having clear priorities and working through a single policy improvement at a time, you can manage the complexity of deploying large policy sets in large networks. For example, based on priorities, you can keep a specific rule module in audit mode while the rest of the rule modules in the policy are in live mode.

•Large policy sets can generate enormous numbers of log messages. Another advantage of piloting one policy at a time is that you can focus on the just the events the new policy has generated. Otherwise, you need to use the tools provided that help filter out extraneous information and isolate the specific policy to be improved or behavior to be studied. For example, you can log only the events that result in Deny actions or create an exception rule that stops logging a specific event to reduce the overall number of log messages. In addition, host diagnostics can be used to filter rules based on the user state (that is, the user and group) the host is in, such as only logging the behavior of the rules used by members of the Administrator group. Monitor policies can be used in clever ways to focus in on specific behavior without interrupting applications and services.

•Set up separate agent kits to support the different features of your pilot. For example, you might have some desktop kits that have all policies in audit mode, some desktop kits with a basic set of well-tested policies in live mode plus one experimental policy in audit mode, and so forth. Labelling these kits clearly will help your pilot participants download the right set of policies you want to test and give you clear feedback on areas needing improvement.

Creating Policies for Your Special Applications

Once you have distributed and piloted a generic Desktops or Servers agent kit, you are ready to create and pilot policies that address the needs of special applications you in use in your enterprise.

The Application Behavior Investigation tool allows you to understand the behavior of these special applications.

Prioritize the applications that you want to protect and begin your analysis with the highest priority application. From the menu bar, navigate Analysis -> Application Behavior Investigation > Behavior Analyses to launch the Behavior Analyses tool. Using this tool will allow you to understand the behavior of the application, craft a policy, place it in audit mode on the pilot machines, and examine the event log. Use the techniques in the rest of this section to tune/troubleshoot that application's policy, re-examine the event log, and if you are satisfied with the result, place the application's policy in live mode on the pilot machines. You repeat these steps with each application on your prioritized list.

Using Audit Mode

CSA policies can execute in live mode, where they enforce rules by denying or allowing events, or audit mode, where they indicate in the event log what the action would have been to the given event. All entries in the event log for rules in audit mode begin with the label https://<system hostname>.<domain> to make it easy to scan for events relating to rules under test. In general, you start a pilot in audit mode and gradually change over to live mode as you examine the performance of each policy. You can place an entire group, individual policies within a group, or and individual rule modules within a policy, in audit mode.

See the Rule Module Configuration chapter in Using Management Center for Cisco Security Agents and review the Using Audit Mode section for a complete discussion of how to use audit mode.

Note When running your pilot, explain to participants the difference between audit mode and live mode, clearly label whether agent kits are for audit mode or live mode, and tell participants which kits to download and use during various phases of the pilot.

Audit mode is not intended to be used indefinitely because the area under test is completely vulnerable from a security standpoint. Groups and rule modules in audit mode should move to live mode in a timely fashion. Once the pilot is over, you need to carefully control which hosts if any are in audit mode. You can remove the audit mode kits to ensure they do not get downloaded during deployment and periodically monitor hosts involved in the audit to ensure that all pilot participants have migrated to live mode agent kits. You want to avoid the situation where a security hole exists after deployment because some groups or rule modules were inadvertently left in audit mode.

Disabling Specific Rules

When you examine the event log with the Events -> Event Log menu, the description of each event references the rule number. If you find a consistent pattern of false positives with the same specific rule number, you can disable that rule if desired. There are two different approaches to disabling rules:

•You can disable the rule temporarily. At a later time, you can go back and modify the rule, set up a query with a cached response, or set up an exception rule.

•You can disable the rule permanently if the rule protects a resource that you don't need protected as part of your security policy.

The easiest way to disable a rule is by clicking on the rule number at the bottom of the event description in the event log. On the rule page, you click on the Enabled checkbox to uncheck it and disable the rule. Once you generate the rules, this rule will be disabled.

Caching and Resetting Query Responses

Rules can be configured with enforcement actions of allow, deny, terminate, or query the user. In some cases, there are rules that already query the user but do so repeatedly instead of caching the user's response to make it persistent. In other cases, there are rules that are generating a mix of false positives and valid enforcements in the event log and need to be modified so they query the user and cache the user's response for the false positives.

You set up a query and cache the answer with different CSA MC menus:

•To set up a query, you display the rule you wish to modify by clicking on the rule number in the event log. You then select Query User from the action popup menu.

•To cache the response for a query, select the Configuration -> Variables -> Query Settings menu option, and then select the desired query from the page. Then, click on the Enable "don't ask again" option checkbox if it is not already checked. When users receive the query and indicate they don't want to be asked this query again, their answer is cached.

Note One trade-off of setting up a cached query response is that users can answer the query inappropriately and then the inappropriate response becomes persistent. After setting up a cached query response, review the event log to make sure users are responding appropriately to the query. If some users give inappropriate responses, you can reset their agents and then give the users more information about responding to the query.

If a user has responded to a query inappropriately and the response is being cached, you can reset the user's cache by doing the following:

1. Select the Systems -> Hosts menu option.

2. Click on the <hostname>.

3. Click the Reset Cisco Security Agent link in the Tasks menu.

Setting Up Exception Rules

In some cases, you need two or more different rules to completely specify the desired actions to a specific event. For example, you could have one rule that denies all applications from writing to the //blizzard/webdocs directory and another rule that allows the WebGuru application with authenticated user webmaster to write to the //blizzard/webdocs directory. The second rule allowing write access for WebGuru is considered an exception rule because it overrides a small part of the overall deny rule for the //blizzard/webdocs/ directory. The MC manipulates the precedence of exception rules so that they are evaluated before the rules that they override.

Although you can create exception rules with the MC rule pages, the easiest way to create exception rules is using the Event Management Wizard from the event log. The wizard tailors its behavior to the event from which you launch it. You can use the wizard to create two general types of exception rules:

•Exception rules that under certain conditions allow an event that was denied

•Exception rules that stop logging similar events

To launch the wizard:

1. Select Events -> Event Log.

2. Click on the Wizard link at the bottom of the desired event's description.

The wizard asks you questions about the following:

•Whether the exception rule applies to the user/state conditions of the triggering rule or the user/state conditions of the specific event where you launched the wizard. If you want the exception to apply to all users, you typically want the user/state conditions of the triggering rule (the default). If you want to create an exception rule only for the user specified in the event, you need to explicitly select the specific user state conditions radio button

•Whether the description of the proposed exception rule looks correct. Keep in mind that if you need to make some small changes to the rule, such as the applications specified, you can do so later. After the wizard finishes, you can still modify the exception rule further before saving it.

•Whether you want to put this new exception rule in a separate exception rule module (the default) or modify the rule module that triggered the event. In most cases, you want to put this in a separate exception rule module so you can preserve the supplied rule modules.

•Whether you want the exception rule based on the application specified in the event or whether you want to base it on a new application class.

After you click Finish in the wizard, the MC displays the new exception rule. At this point, you should do the following:

1. Change the Description field to an appropriate name.

2. Examine the details in the when box. If necessary, you can change these details to expand or narrow the conditions for the exception.

3. Click the Save button.

Configuring Your Own Policies

Creating a complete custom set of policies requires a team of network security experts who have assembled a detailed list of security features and studied the many supplied rule modules. The experts use the Behavior Analyses tool to thoroughly study the applications for which they will write rules. Then, the experts will craft custom policies by selecting the desired rule modules and rules. With this custom approach, consider conducting a small pilot of a few systems in a test lab and then expanding to a larger and more thorough pilot.

To create a set of custom policies these are the tasks you need to complete after you have assessed your application's vulnerabilities and decided on your security needs:

Step 1 Familiarize yourself with the CSA MC user interface in Advanced Mode. See the chapter on Management Center for Cisco Security Agents Administration in Using Management Center for Cisco Security Agents (this is also referred to as the User Guide) for more information.

Step 2 Select an existing rule module or create your own. See the chapter on Rule Module Configuration in the User Guide for more information.

Step 3 Add existing rules to the rule modules or create your own rules and add them to the rule module.

Step 4 Create a policy and associate rule modules with the policy. See the chapter on Building Policies in the User Guide for more information.

Step 5 Associate the policy with a group you create or an existing group that you select. See the chapter on Configuring Groups and Managing Hosts in the User Guide for more information.

Step 6 Create an agent kit to distribute the policy. See Configuring Groups and Managing Hosts in the User Guide for more information.

Step 7 Monitor events created by the new policy, then tune and configure the policy. See the chapter on Event Logging and Alerts in the User Guide and Policy Tuning and Troubleshooting.

Distributing Agent Kits Using a Third Party Tool

Agent kits can be distributed using third party software distribution tools. After the agent has been downloaded and installed it will attempt to register with the CSA MC.

Note The agent kit is a self-extracting executable file that contains several files (16 total) such as cab files, hdr, and setup files. In order to distribute agent kits using a third party software distribution tool, you must first extract the files manually from the agent kit and then run a script or a command from a command shell applying certain switches. The switches are referenced AFTER the extracted setup.exe.

This distribution methodology is for Windows agents only.

Step 1 Download the agent kit from CSA MC.

Step 2 Extract the files in the agent kit. If the agent kit is named CSA-Desktops-setup-abc123.exe, run this command from a command prompt:

https://stormcenter.cisco.com

This will extract all the files to the directory

C:\{D933754D-B870-45b7-BFAA-1BDD2A7D4B80}

Step 3 Connect to the directory {D933754D-B870-45b7-BFAA-1BDD2A7D4B80}:

AuditMode:

Step 4 Run the extracted setup.exe with the necessary parameters for mass deployment.

This command is run as a local user:

c:\>CSA-Desktops-setup-abc123.exe -x

Notice the use of f2 in the next example. This will allow you to specify where the Installshield log directory will be written, just in case it cannot write to the drive where the setup.exe is located. This is useful if you are installing over a network:

c:\>cd {D933754D-B870-45b7-BFAA-1BDD2A7D4B80}

Setup.exe Command Switches

The following are the switches for the agent setup.exe in versions 5.0.0.x and later

--autolevel

--autolevel switches define the amount of user interaction with the installation.

--autolevel=1 no questions are asked. The default actions are taken.

--autolevel=2 no warnings are displayed

--autolevel=3 suppresses all warnings and error messages

--autolevel=4 which makes the install completely silent (not even the message saying "Installing CSA" is displayed)

--reboot

--reboot=0 The agent install finishes silently and the host is not rebooted.

--reboot=1 The agent reboots automatically at the end of the install. (This is the default.)

--rebootdelay

--rebootdelay=x Specifies in seconds what the reboot delay is if reboot=1.

Note If this parameter is missing and you set the machine to reboot (reboot=1), the default is 300 seconds (five minutes).

--startagent

This switch is applicable only if reboot=0.

startagent=0 The agent is not started after the installation is finished.

startagent=1 This agent is started after the installation is finished. This is the default setting.

Warning The agent will provide NO security until the agent service is MANUALLY started or the machine is rebooted.

--disable_net

This switch is used to suspend agent security and prevent further connections to and from the machine.

--disable_net=0 We do not prevent network connections.

--disable_net=1 We do prevent any network connections. This is the default setting.

Warning During an upgrade, the agent service is stopped. If this switch is set to 0, the machine is unprotected during the time of the upgrade.

--targetdir

This switch allows you to install the agent to a directory of your choice)

setup.exe /s --targetdir=f:\installfolder\ --disable_net=0 --reboot=0<path>

setup.exe /s --targetdir=c:\Path\To\Directory

Note The <path> should NOT have quotes, even if the path contains spaces.

If the path does not exist, the installation will create it. Also, if the path is invalid (invalid driver letter or encrypted directory, for example), the installation aborts.

The default path, if no command line targetdir is specified, is

setup.exe /s /f2"c:\setup.log" --autolevel=3 --reboot=0 --nshim=1 --startagent=0

--mt

This switch is used to uninstall CSA

--mt=removeall

for example:

--targetdir=

Command Examples

Example 3-1 Install silently, no errors displayed, reboot at the end of install

<PROGRAMFILES>\Cisco

The reboot=1 will show the 5 minute countdown prior to reboot - this box cannot be suppressed at this time)

Example 3-2 Install silently, do not log errors, force a reboot after 10 seconds

C:\{D933754D-B870-45b7-BFAA-1BDD2A7D4B80}>setup.exe --mt=removeall

Example 3-3 Silent installation, install on f:\targetfolder, do not disable the NIC and do not reboot:

setup.exe /s --autolevel=3 --reboot=1

Example 3-4 Silent uninstallation, no user interaction

setup.exe /s --autolevel=3 --reboot=1 --rebootdelay=10

You will then need to reboot eventually, there is no forced reboot.

Example 3-5 Silent uninstallation from the Installshield Installation Information folder:

Change directories to:

setup.exe /s --autolevel=3 --targetdir=f:\installfolder\ --disable_net=0 --reboot=0

Then run:

setup.exe /s /f1"%PROGRAMFILES%\InstallShield Installation Information\{DE499746-67B9-11D4-97CE-0050DA10E5AE}\setup.iss" --mt=removeall --autolevel=4

Example 3-6 Drive independent uninstallation

If you do NOT want the uninstall to be drive dependent, then you can wildcard the program files"

*:\Program Files\InstallShield Installation Information\{DE499746-67B9-11D4-97CE-0050DA10E5AE}

	Installing Management Center for Cisco Security Agents 6.0
	Quick Configuration and Deployment
Installing Management Center for Cisco Security Agents 6.0 Preface Preparing to Install Installing the Management Center for Cisco Security Agents Quick Configuration and Deployment Cisco Security Agent Installation and Overview Open Source License Acknowledgements and Third Party Copyrights	Download this chapter Quick Configuration and Deployment Download the complete book Installing Management Center for Cisco Security Agents 6.0 (PDF - 3 MB) Table Of Contents Quick Configuration & Deployment Overview Logging on to the CSA MC Access Management Center for Cisco Security Agents Simple View and Advanced View Modes Visible, Hidden, and Read-only Components on CSA MC Cisco Security Agent Policies Piloting the Product Running a Pilot Program Quick Configuration and Deployment 1. Update your Licenses 2. Pick your Policies 3. Update the Agent Kits 4. Distribute and Install the Kits 5. Create Exceptions as Necessary View Registered Hosts Policy Tuning and Troubleshooting Overall Guidelines Creating Policies for Your Special Applications Using Audit Mode Disabling Specific Rules Caching and Resetting Query Responses Setting Up Exception Rules Configuring Your Own Policies Distributing Agent Kits Using a Third Party Tool Setup.exe Command Switches --autolevel --reboot --rebootdelay --startagent --disable_net --targetdir --mt Command Examples Quick Configuration & Deployment Overview This chapter provides the basic setup information you need to start using the Management Center for Cisco Security Agents to configure some preliminary groups and build agent kits. The goal of this chapter is to help you quickly configure and distribute Cisco Security Agent kits to hosts and have those hosts successfully register with CSA MC. Once this is accomplished you can configure some policies and distribute them to installed and registered Cisco Security Agents. For detailed configuration information, you should refer to the User Guide. This section contains the following topics. •Logging on to the CSA MC –Access Management Center for Cisco Security Agents –Simple View and Advanced View Modes –Visible, Hidden, and Read-only Components on CSA MC •Cisco Security Agent Policies •Piloting the Product –Running a Pilot Program •Quick Configuration and Deployment –1. Update your Licenses –2. Pick your Policies –3. Update the Agent Kits –4. Distribute and Install the Kits –5. Create Exceptions as Necessary •View Registered Hosts •Policy Tuning and Troubleshooting –Overall Guidelines –Creating Policies for Your Special Applications –Using Audit Mode –Disabling Specific Rules –Caching and Resetting Query Responses –Setting Up Exception Rules •Configuring Your Own Policies •Distributing Agent Kits Using a Third Party Tool –Setup.exe Command Switches –Command Examples Logging on to the CSA MC Use the procedures in this section to access the CSA MC from a browser. After logging on you reach CSA MC's Home Page. For a description of the CSA MC interface, see "Interface Overview of Management Center for Cisco Security Agents" in Using Management Center for Cisco Security Agents. Access Management Center for Cisco Security Agents An initial administrator account was created as part of the CSA MC installation process. Use that administrator account to log into CSA MC. You access CSA MC locally or remotely from a supported Web browser. No more than 12 users may be logged on to the CSA MC at the same time. Local Access •To access CSA MC locally on the system hosting CSA MC software, double-click the CSA MC desktop icon created during the installation. Remote Access •To access CSA MC from a remote location, launch a browser application and enter `https://<system hostname>.<domain>` For example, enter `https://stormcenter.cisco.com` Enter the administrator name and password created during the CSA MC installation. Note When you login to the CSA MC system, you are presented with the CSA MC Home page. Various messages or warnings may appear in the Things to Do area. See the description of the Home Page in Using the Management Center for Cisco Security Agents for more information. Tip Once you have logged on, look at the global command buttons in the top right corner of the Home Page. One will indicate "All OSes," "Windows," or "Unix." Click the command button to view the components relevant to the operating system you choose. Clicking Unix displays components for both Solaris and Linux operating systems. Caution If you have not obtained a valid license from Cisco, when you login to CSA MC, you'll receive a warning informing you that your license is not valid. Any newly deployed agents will not be able to register with the unlicensed CSA MC. Refer back to Licensing Information, page 2-2 for further licensing information. Simple View and Advanced View Modes When you first login to CSA MC, the administrator created during the installation process has a simplified view of CSA MC. This "Simple Mode" view provides everything you need to deploy and administer the product. Default groups are pre-configured and shipped with the MC to provide out-of-the-box security policies for servers and desktops. Through the use of a wizard, you can refine the policies to match the security needs of your site and of the applications that run on your network. For advanced users there is the "Advanced Mode" view. This view exposes all CSA MC menus and pages to administrators. This gives the administrator the ability to create or configure any component, view all possible reports, and have access to the full range of analytical and maintenance utilities. Advanced view is best for administrators who need to create customized policies for their enterprise or who want more granular control of the system. Visible, Hidden, and Read-only Components on CSA MC What you see on component list pages and on the Host Security page depends on your user configuration and whether or not the component is hidden or visible. What you can edit on list pages or through the Host Security page depends on your user configuration. Some components are "hidden" by default other components are "Read-only" by default. Users are not expected to have to configure these components in a deployment that uses the groups, policies, and other components, supplied with this release. Before you begin your pilot, view the system in Advanced Mode and, from the menu bar, navigate Maintenance > Administrators > Account Management. From the account list page, click the login ID you intend to use to manage your pilot. The details page shows the user's preferences. Here you can configure users viewing mode, their ability to see hidden objects, and their permissions to edit read-only objects. Configure your users with the permissions they will need to conduct the pilot. See "Configuring Role Based Administration" in the Management Center for Cisco Security Agents Administration chapter of the User Guide. From the menu bar, navigating Configuration > Host Security brings up the Host Security page. From this page you can configure groups and create agent kits. The groups and policies appear on this page because their Simple Mode Settings are set to expose the component on the page. If there are other groups or policies you want to manage through the Host Security page, you can configure them to be displayed if your user account allows you to edit read-only components. See "Configuring Groups" and "Configuring a Policy" in the User Guide for instructions on exposing these components on the Host Security page. Cisco Security Agent Policies CSA MC default Cisco Security Agent kits, groups, policies, and configuration variables are designed to provide a high level of security coverage for desktops and servers. These default Cisco Security Agent kits, groups, policies, rule modules and configuration variables cannot anticipate all possible local security policy requirements specified by your organization's management, nor can they anticipate all local combinations of application usage patterns. Cisco recommends deploying agents using the default configurations and then monitoring for possible tuning to your environment. If you are using shipped policies, you can also use shipped, pre-built agent kits. Therefore, if you're not creating your own configurations, you can simply refer to the chapters on Management Center for Cisco Security Agents Administration and Event Logging and Alerts in Using Management Center for Cisco Security Agents for information on deploying kits to end users and viewing the event log. Note Each pre-configured rule module, policy, and group page has data in the expandable +Detailed description field explaining the item in question. Read the information in these fields to learn about the items described and to determine if the item in question meets your needs for usage. As a jumping off point for creating your own configurations, the following sections in this manual take you through the step by step process of configuring some of the basic elements you need to initiate server/agent communications and to begin the distribution of your own policies. Piloting the Product Before deploying Cisco Security Agents (CSA) on a large scale, it is worthwhile to run a manageable and modest initial pilot of the product. Even in a CSA upgrade situation, a short pilot program will be beneficial. CSA 6.0 ships with many security policies that you should be able to run in your enterprise as they are or with only minimal tuning. This tuning is best done on a small sample of systems that are representative of the whole. Once the pilot is operating satisfactorily, with CSA protecting systems using properly tuned policies, you can turn your pilot into a larger deployment. The following sections provide a guideline for conducting a pilot of CSA and deploying the product on a large scale. Running a Pilot Program Your pilot program should proceed in the following manner: •How large should a pilot program be? Select a logical, manageable, sample of systems on which agents will be installed. A good rule of thumb is to make your pilot approximately 1% the size of what the entire deployment will be. Details: –If your entire deployment will be very small, be sure to pilot at least 15-20 systems. –If your entire deployment will be very large, roll out your pilot in steps. For example, do not pilot 1,000 systems initially and all at once. Start with a smaller sample and gradually expand the pilot. The pilot should include machines that you can access readily (either yourself or through a responsive end-user). If you will eventually be installing agents on multiple, supported operating systems, your pilot should include machines running those operating systems. Again, systems in your pilot should be representative of the whole deployment to which you intend to scale. •How long should a pilot program run? The policies in CSA 6.0 are designed to be used as they are or with only minimal tuning. Still, deploying and tuning policies is an iterative process. Initially, you will have some event log noise to parse. You must examine the data coming in and fine tune your policies accordingly. Although every site is different, it would not be unusual to run a pilot program for approximately one to two weeks after you feel you have tuned your policies to your satisfaction. All possible application usage should take place within the pilot time frame. It is important to note that this recommended time frame allows you to exercise applications, their deployment and usage, within an entire fiscal quarter. The idea being, every application you use and every manner is which you use it will occur during this piloting period. Quick Configuration and Deployment The Management Center for Cisco Security Agents (CSA MC) comes preconfigured with downloadable kits for desktop and server hosts. Here's how to get your pilot program up and running in five easy steps: 1. Update your Licenses CSA MC comes with a few free agent licenses for servers so you can install the CSA MC and get started quickly. Before deploying agents throughout your network, you must install a more comprehensive license for desktops and servers. If you want the added protection of the Data Loss Prevention feature, you will need to upload a separate license for that. For a procedure on how to update your licenses and to learn more about Data Loss Prevention update your licenses, see Licensing Information, page 2-2. Note You can proceed through step 3 without loading a license, but make sure to load a license before proceeding to step 4. If you need help getting your formal CSA MC license file(s) from Cisco, see the Product Licensing Information section of the Documentation and Licensing Overview for Management Center for Cisco Security Agents 6.0. If you need keys for a product evaluation, and you are a registered user of Cisco.com, you can go to the Cisco Product License Registration page and download the Cisco Security Agent 6.x Demo License. 2. Pick your Policies To pick policies for your desktops, mouse-over the Configuration menu on the CSA MC and click Host Security, then follow this procedure: Step 1 Click the "Desktops" group for the appropriate operating system. You will see a list of policies - you can click on a policy name to see a description of the policy. Step 2 Click the checkbox for each policy you want enforced on your desktops. If you want a policy's rules to be logged but not enforced, click the policy's "Audit Mode" checkbox. If you are unsure of what to check, just keep the defaults. If you change a checkbox from its default state, press the Save button when done. Step 3 If a policy displays a red [warning] link, click the link to show the items that require customization. Customize each item by clicking its link in the Policy Warning dialog box and editing the pop-up provided. If you customize something, press the Save button when done. Tip If you want to take the deployment a little slower, enable one policy at a time and tune that policy before turning on the next policy. This will help you match specific outcomes with specific policies. 3. Update the Agent Kits Policies are bundled together into downloadable, installable agent kits. If you made changes in the previous step, you must update these kits by clicking Generate rules at the bottom of your browser window, then pressing the Generate button to confirm the action. (If you didn't change anything, then you can skip this step.) You can see a list of all your agent kits by mousing-over Systems in the menu and selecting Agent kits. 4. Distribute and Install the Kits To see the agent kit corresponding to your desktop group's policies, go to the Host Security page and click on the appropriate Desktops group. You should see the text "Available kits for this group" followed by a link. Click the link to pop up the name of the kit, and click on this name to see the kit's details dialog box. On this dialog, under the heading Download, there will be a URL. The URL references the executable that installs CSA with the appropriate policies. E-mail this URL to your users who should install CSA. Alternatively, you can click on the URL, save the resulting executable, then use systems-management software (like SMS) to push the executable to your endpoints for installation. When an agent kit is downloaded and installed, the agent will register with the CSA MC, start enforcing your policies and generating events. Once you have completed steps 1-4 for desktops, repeat them for the servers you want to protect with CSA. 5. Create Exceptions as Necessary If CSA denies an action that you wish to allow, you can create a policy exception to permit the action. Step 1 Open the Event Log by navigating Events > Event Log from the menu bar. Step 2 Locate the event corresponding to the denied action in the Event Log. Step 3 For the appropriate event, click the Wizard link to launch the exception wizard. Step 4 Follow the steps given in the wizard to make the agent more permissive. Take the default settings offered by the wizard. View Registered Hosts Once you have distributed agent kits to your pilot hosts, you can see which hosts have successfully registered using any of these methods: •In Simple or Advanced Mode, mouse-over Configuration in the menu bar and select Host Security. For a particular group, click the number of hosts in the hosts column to see which hosts have registered as a member of that group. •In Advanced Mode, mouse-over the Systems menu and select Hosts. This takes you to the Hosts list page. On the right side of this page is a column that displays varying types of information on each host. Use the pulldown menu for this column to view hosts that are Active. •To search for specific hosts based on more status data, use the Search option in CSA MC. Search for Hosts using available status information such as: –Active hosts—A host is active if it polls into CSA MC at regular intervals. –Not active hosts—A host is inactive if it has missed a certain number polling intervals or if it has not polled into the server for at least one hour. Policy Tuning and Troubleshooting Once you have started your CSA pilot, you may need to tune the policies to suit your needs and troubleshoot any problems that occur. Beyond creating exceptions you may need to tune rules to deny or allow user actions or prevent false positives. Tuning policies is best done using Advanced Mode. Overall Guidelines This section presents some overall guidelines for tuning and troubleshooting your CSA pilot. Please read through this section carefully and consider the specific needs and requirements of your pilot before moving on to actually using the techniques. Here are the most important guidelines to follow when tuning and troubleshooting policies: •Never directly modify one of the supplied groups, policies, or rule modules unless you are using the links provided through the Home page or Host Security page. The groups, policies, rule modules provided are designed to work in your enterprise with minimal or no tuning. Using the links provided on the Home page and Host Security page will direct you to the areas that require your attention. If you need to dramatically change a group, policy, or rule module, make sure you clone and rename it first so you preserve it for use later. Modifying the supplied groups, policies, and rule modules directly makes it difficult to back out of any inadvertent mistakes. •Policies displaying a red [warning] link on the Host Security page may need your attention. Click the warning link to display the Policy Warning dialog box. In the box you will find links to one or more items that may have already been customized but may require occasional updates. Customize each item by clicking its link in the Policy Warning dialog box and editing the pop-up provided. •Use the supplied groups and if necessary define additional groups for each distinct desktop and server type in your network. In your pilot, you should have some participants that are using each desktop and server type so you can tune and troubleshoot all policies before deployment. Group membership is cumulative, which can be useful in tuning and troubleshooting. For example, at the beginning of a pilot, participating hosts that are Windows desktops would be attached to the All Windows and Desktops groups. Once you are satisfied with the performance of these basic policies, you could define a new group for a specific department's applications, attach hosts to the new group, and pilot those policies. •If you are running your pilot with policies or groups in Audit Mode, examine the event log (Events -> Event Log menu) for possible tuning and troubleshooting needs before moving to enforcement mode (also known as live mode). With the current release, you can place individual policies within a group in audit mode or a single rule module in audit mode. Therefore, as you tune and troubleshoot, you can incrementally move rule modules to enforcement mode if need be. Keep in mind when using audit mode that the area under test is completely vulnerable from a security standpoint. •Policy tuning and troubleshooting is an iterative process. Focus on a single policy for improvement at a time and then verify that the tuning and troubleshooting techniques did what you expected before deploying the improved policy. •Prioritize the security features you want to implement with CSA policies. You can also prioritize applications and groups. By having clear priorities and working through a single policy improvement at a time, you can manage the complexity of deploying large policy sets in large networks. For example, based on priorities, you can keep a specific rule module in audit mode while the rest of the rule modules in the policy are in live mode. •Large policy sets can generate enormous numbers of log messages. Another advantage of piloting one policy at a time is that you can focus on the just the events the new policy has generated. Otherwise, you need to use the tools provided that help filter out extraneous information and isolate the specific policy to be improved or behavior to be studied. For example, you can log only the events that result in Deny actions or create an exception rule that stops logging a specific event to reduce the overall number of log messages. In addition, host diagnostics can be used to filter rules based on the user state (that is, the user and group) the host is in, such as only logging the behavior of the rules used by members of the Administrator group. Monitor policies can be used in clever ways to focus in on specific behavior without interrupting applications and services. •Set up separate agent kits to support the different features of your pilot. For example, you might have some desktop kits that have all policies in audit mode, some desktop kits with a basic set of well-tested policies in live mode plus one experimental policy in audit mode, and so forth. Labelling these kits clearly will help your pilot participants download the right set of policies you want to test and give you clear feedback on areas needing improvement. Creating Policies for Your Special Applications Once you have distributed and piloted a generic Desktops or Servers agent kit, you are ready to create and pilot policies that address the needs of special applications you in use in your enterprise. The Application Behavior Investigation tool allows you to understand the behavior of these special applications. Prioritize the applications that you want to protect and begin your analysis with the highest priority application. From the menu bar, navigate Analysis -> Application Behavior Investigation > Behavior Analyses to launch the Behavior Analyses tool. Using this tool will allow you to understand the behavior of the application, craft a policy, place it in audit mode on the pilot machines, and examine the event log. Use the techniques in the rest of this section to tune/troubleshoot that application's policy, re-examine the event log, and if you are satisfied with the result, place the application's policy in live mode on the pilot machines. You repeat these steps with each application on your prioritized list. Using Audit Mode CSA policies can execute in live mode, where they enforce rules by denying or allowing events, or audit mode, where they indicate in the event log what the action would have been to the given event. All entries in the event log for rules in audit mode begin with the label `https://<system hostname>.<domain>` to make it easy to scan for events relating to rules under test. In general, you start a pilot in audit mode and gradually change over to live mode as you examine the performance of each policy. You can place an entire group, individual policies within a group, or and individual rule modules within a policy, in audit mode. See the Rule Module Configuration chapter in Using Management Center for Cisco Security Agents and review the Using Audit Mode section for a complete discussion of how to use audit mode. Note When running your pilot, explain to participants the difference between audit mode and live mode, clearly label whether agent kits are for audit mode or live mode, and tell participants which kits to download and use during various phases of the pilot. Audit mode is not intended to be used indefinitely because the area under test is completely vulnerable from a security standpoint. Groups and rule modules in audit mode should move to live mode in a timely fashion. Once the pilot is over, you need to carefully control which hosts if any are in audit mode. You can remove the audit mode kits to ensure they do not get downloaded during deployment and periodically monitor hosts involved in the audit to ensure that all pilot participants have migrated to live mode agent kits. You want to avoid the situation where a security hole exists after deployment because some groups or rule modules were inadvertently left in audit mode. Disabling Specific Rules When you examine the event log with the Events -> Event Log menu, the description of each event references the rule number. If you find a consistent pattern of false positives with the same specific rule number, you can disable that rule if desired. There are two different approaches to disabling rules: •You can disable the rule temporarily. At a later time, you can go back and modify the rule, set up a query with a cached response, or set up an exception rule. •You can disable the rule permanently if the rule protects a resource that you don't need protected as part of your security policy. The easiest way to disable a rule is by clicking on the rule number at the bottom of the event description in the event log. On the rule page, you click on the Enabled checkbox to uncheck it and disable the rule. Once you generate the rules, this rule will be disabled. Caching and Resetting Query Responses Rules can be configured with enforcement actions of allow, deny, terminate, or query the user. In some cases, there are rules that already query the user but do so repeatedly instead of caching the user's response to make it persistent. In other cases, there are rules that are generating a mix of false positives and valid enforcements in the event log and need to be modified so they query the user and cache the user's response for the false positives. You set up a query and cache the answer with different CSA MC menus: •To set up a query, you display the rule you wish to modify by clicking on the rule number in the event log. You then select Query User from the action popup menu. •To cache the response for a query, select the Configuration -> Variables -> Query Settings menu option, and then select the desired query from the page. Then, click on the Enable "don't ask again" option checkbox if it is not already checked. When users receive the query and indicate they don't want to be asked this query again, their answer is cached. Note One trade-off of setting up a cached query response is that users can answer the query inappropriately and then the inappropriate response becomes persistent. After setting up a cached query response, review the event log to make sure users are responding appropriately to the query. If some users give inappropriate responses, you can reset their agents and then give the users more information about responding to the query. If a user has responded to a query inappropriately and the response is being cached, you can reset the user's cache by doing the following: 1. Select the Systems -> Hosts menu option. 2. Click on the <hostname>. 3. Click the Reset Cisco Security Agent link in the Tasks menu. Setting Up Exception Rules In some cases, you need two or more different rules to completely specify the desired actions to a specific event. For example, you could have one rule that denies all applications from writing to the //blizzard/webdocs directory and another rule that allows the WebGuru application with authenticated user webmaster to write to the //blizzard/webdocs directory. The second rule allowing write access for WebGuru is considered an exception rule because it overrides a small part of the overall deny rule for the //blizzard/webdocs/ directory. The MC manipulates the precedence of exception rules so that they are evaluated before the rules that they override. Although you can create exception rules with the MC rule pages, the easiest way to create exception rules is using the Event Management Wizard from the event log. The wizard tailors its behavior to the event from which you launch it. You can use the wizard to create two general types of exception rules: •Exception rules that under certain conditions allow an event that was denied •Exception rules that stop logging similar events To launch the wizard: 1. Select Events -> Event Log. 2. Click on the Wizard link at the bottom of the desired event's description. The wizard asks you questions about the following: •Whether the exception rule applies to the user/state conditions of the triggering rule or the user/state conditions of the specific event where you launched the wizard. If you want the exception to apply to all users, you typically want the user/state conditions of the triggering rule (the default). If you want to create an exception rule only for the user specified in the event, you need to explicitly select the specific user state conditions radio button •Whether the description of the proposed exception rule looks correct. Keep in mind that if you need to make some small changes to the rule, such as the applications specified, you can do so later. After the wizard finishes, you can still modify the exception rule further before saving it. •Whether you want to put this new exception rule in a separate exception rule module (the default) or modify the rule module that triggered the event. In most cases, you want to put this in a separate exception rule module so you can preserve the supplied rule modules. •Whether you want the exception rule based on the application specified in the event or whether you want to base it on a new application class. After you click Finish in the wizard, the MC displays the new exception rule. At this point, you should do the following: 1. Change the Description field to an appropriate name. 2. Examine the details in the when box. If necessary, you can change these details to expand or narrow the conditions for the exception. 3. Click the Save button. Configuring Your Own Policies Creating a complete custom set of policies requires a team of network security experts who have assembled a detailed list of security features and studied the many supplied rule modules. The experts use the Behavior Analyses tool to thoroughly study the applications for which they will write rules. Then, the experts will craft custom policies by selecting the desired rule modules and rules. With this custom approach, consider conducting a small pilot of a few systems in a test lab and then expanding to a larger and more thorough pilot. To create a set of custom policies these are the tasks you need to complete after you have assessed your application's vulnerabilities and decided on your security needs: Step 1 Familiarize yourself with the CSA MC user interface in Advanced Mode. See the chapter on Management Center for Cisco Security Agents Administration in Using Management Center for Cisco Security Agents (this is also referred to as the User Guide) for more information. Step 2 Select an existing rule module or create your own. See the chapter on Rule Module Configuration in the User Guide for more information. Step 3 Add existing rules to the rule modules or create your own rules and add them to the rule module. Step 4 Create a policy and associate rule modules with the policy. See the chapter on Building Policies in the User Guide for more information. Step 5 Associate the policy with a group you create or an existing group that you select. See the chapter on Configuring Groups and Managing Hosts in the User Guide for more information. Step 6 Create an agent kit to distribute the policy. See Configuring Groups and Managing Hosts in the User Guide for more information. Step 7 Monitor events created by the new policy, then tune and configure the policy. See the chapter on Event Logging and Alerts in the User Guide and Policy Tuning and Troubleshooting. Distributing Agent Kits Using a Third Party Tool Agent kits can be distributed using third party software distribution tools. After the agent has been downloaded and installed it will attempt to register with the CSA MC. Note The agent kit is a self-extracting executable file that contains several files (16 total) such as cab files, hdr, and setup files. In order to distribute agent kits using a third party software distribution tool, you must first extract the files manually from the agent kit and then run a script or a command from a command shell applying certain switches. The switches are referenced AFTER the extracted setup.exe. This distribution methodology is for Windows agents only. Step 1 Download the agent kit from CSA MC. Step 2 Extract the files in the agent kit. If the agent kit is named CSA-Desktops-setup-abc123.exe, run this command from a command prompt: `https://stormcenter.cisco.com` This will extract all the files to the directory C:\{D933754D-B870-45b7-BFAA-1BDD2A7D4B80} Step 3 Connect to the directory {D933754D-B870-45b7-BFAA-1BDD2A7D4B80}: `AuditMode:` Step 4 Run the extracted setup.exe with the necessary parameters for mass deployment. This command is run as a local user: `c:\>CSA-Desktops-setup-abc123.exe -x` Notice the use of f2 in the next example. This will allow you to specify where the Installshield log directory will be written, just in case it cannot write to the drive where the setup.exe is located. This is useful if you are installing over a network: `c:\>cd {D933754D-B870-45b7-BFAA-1BDD2A7D4B80}` Setup.exe Command Switches The following are the switches for the agent setup.exe in versions 5.0.0.x and later --autolevel --autolevel switches define the amount of user interaction with the installation. --autolevel=1 no questions are asked. The default actions are taken. --autolevel=2 no warnings are displayed --autolevel=3 suppresses all warnings and error messages --autolevel=4 which makes the install completely silent (not even the message saying "Installing CSA" is displayed) --reboot --reboot=0 The agent install finishes silently and the host is not rebooted. --reboot=1 The agent reboots automatically at the end of the install. (This is the default.) --rebootdelay --rebootdelay=x Specifies in seconds what the reboot delay is if reboot=1. Note If this parameter is missing and you set the machine to reboot (reboot=1), the default is 300 seconds (five minutes). --startagent This switch is applicable only if reboot=0. startagent=0 The agent is not started after the installation is finished. startagent=1 This agent is started after the installation is finished. This is the default setting. Warning The agent will provide NO security until the agent service is MANUALLY started or the machine is rebooted. --disable_net This switch is used to suspend agent security and prevent further connections to and from the machine. --disable_net=0 We do not prevent network connections. --disable_net=1 We do prevent any network connections. This is the default setting. Warning During an upgrade, the agent service is stopped. If this switch is set to 0, the machine is unprotected during the time of the upgrade. --targetdir This switch allows you to install the agent to a directory of your choice) `setup.exe /s --targetdir=f:\installfolder\ --disable_net=0 --reboot=0`<path> setup.exe /s --targetdir=c:\Path\To\Directory Note The <path> should NOT have quotes, even if the path contains spaces. If the path does not exist, the installation will create it. Also, if the path is invalid (invalid driver letter or encrypted directory, for example), the installation aborts. The default path, if no command line targetdir is specified, is `setup.exe /s /f2"c:\setup.log" --autolevel=3 --reboot=0 --nshim=1 --startagent=0` --mt This switch is used to uninstall CSA --mt=removeall for example: `--targetdir=` Command Examples Example 3-1 Install silently, no errors displayed, reboot at the end of install `<PROGRAMFILES>\Cisco` The reboot=1 will show the 5 minute countdown prior to reboot - this box cannot be suppressed at this time) Example 3-2 Install silently, do not log errors, force a reboot after 10 seconds `C:\{D933754D-B870-45b7-BFAA-1BDD2A7D4B80}>setup.exe --mt=removeall` Example 3-3 Silent installation, install on f:\targetfolder, do not disable the NIC and do not reboot: `setup.exe /s --autolevel=3 --reboot=1` Example 3-4 Silent uninstallation, no user interaction `setup.exe /s --autolevel=3 --reboot=1 --rebootdelay=10` You will then need to reboot eventually, there is no forced reboot. Example 3-5 Silent uninstallation from the Installshield Installation Information folder: Change directories to: `setup.exe /s --autolevel=3 --targetdir=f:\installfolder\ --disable_net=0 --reboot=0` Then run: `setup.exe /s /f1"%PROGRAMFILES%\InstallShield Installation Information\{DE499746-67B9-11D4-97CE-0050DA10E5AE}\setup.iss" --mt=removeall --autolevel=4` Example 3-6 Drive independent uninstallation If you do NOT want the uninstall to be drive dependent, then you can wildcard the program files" `*:\Program Files\InstallShield Installation Information\{DE499746-67B9-11D4-97CE-0050DA10E5AE}`
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.