Understanding CSA Groups

 < Day Day Up > 

The CSA product uses groups as a mechanism to simplify management. Groups enable you to place policy controls and set agent configuration parameters to a number of agents without the need to granularly apply the settings. Groups also allow for a consistent configuration to be deployed across the environment. Hosts are required to participate in at least one group from which they will inherit various settings and policy controls. The hosts are not limited to participating in a single group, however. Hosts can belong to several groups at the same time, with the various settings and policies attached to the respective groups being merged into a host-specific policy on the endpoint. You should be familiar with a few types of groups and several ways to use groups, which are discussed in this section. You learn more about hosts later in the section "Understanding CSA Hosts"

Introducing the Group Types

Before you can begin creating groups for your specific deployment, collect information about your internal security requirements and the systems that need to be protected by security agents. After you have gathered information such as operating systems, application information, and system user interaction requirements, you are ready to begin grouping agents together. Three types of groups are available for use in the CSA architecture:

  • Mandatory groups

  • Predefined groups

  • Custom groups

CAUTION

Hosts can belong to more than one group, and so they can inherit multiple policies; be aware, however, that the combined rule set will follow the rule precedence when deciding which rules override other conflicting rules when the combined rule set is put into effect on the host. Rule precedence is covered in detail in Chapter 4, "Understanding CSA Policies, Modules, and Rules."


Mandatory Groups

The mandatory groups are Windows, Solaris, and Linux. After a host enrolls with the management console upon its first successful poll, it is placed into one of these groups based on the agent install kit type. At this point, the host belongs to one of the three top-level mandatory groups and cannot be removed. Mandatory groups are the highest level of grouping within CSA and enable the security administrator to apply rules to these groups such that other more specific group policies cannot override them.

The rules and policies assigned to the mandatory groups become mandatory rules, which you will learn about in Chapter 4. An example to illustrate this concept is the need to ensure all Windows hosts protected by CSA cannot have the remote control service disabled by other attached policies inherited from nonmandatory groups. When you have a policy attached to the mandatory group that ensures the agents always have the remote control mechanism allowed, the help desk can continue to service your install base without fear of a new, more-restrictive policy blocking their access.

Remember, after a machine has registered as Windows, Solaris, or Linux, it cannot be changed without first uninstalling the current agent software and then installing a new agent of a different type. Very rarely will this is necessary, but it is worth noting.

Predefined Groups

The second type of group is known as a predefined group. In the CSA product, Cisco has predefined groups for common deployment scenarios and has already defined some baseline policies to protect these groups. Organizations can use these groups to speed product deployment. Although the predefined groups and policies are useful in initially understanding and testing/piloting the product, most customers find they need to create their own groups that better mirror their security pilot, geography, and business requirements. The groups you create to specifically suit your environment are known as custom groups and are covered in the next section. Figure 3-1 shows the predefined groups on the CSA MC server. You learn more about this type of group later in the section "Exploring Predefined Groups."

Figure 3-1. Predefined Groups


One last point to make about the group list shown in Figure 3-1 is that when a group has hosts as members, there will be an entry to the right of the Group Description field. In this example, the VMS CiscoWorks Systems group at the bottom of the screen lists "1 host," which is a clickable link to the list of hosts participating in this particular group. In summary, groups allow the CSA architecture to scale.

Custom Groups

Custom groups are groups that you manually create to suit your own deployment needs. You might want to create a custom group for many reasons, but the major reason is to lower the administrative overhead of managing the product while still maintaining a highly effective security policy. Custom groups enable you to create and maintain policies that will affect large numbers of similar hosts so that you do not have to manage hundreds or thousands of hosts individually. You may create groups to have a consistent policy. If you only manage a single policy and attach it to a group, there is less chance that any single machine s policy will differ from other machines in the network.

You need to decide how best to use custom groups in your network so that they best fit your security policy enforcement goals. Some ways to group machines include the following:

  • Function or application

  • Business or department related

  • Physical or geographic location

  • Criticality and importance to the business

Another reason to use custom groups is for manageability and reporting. By assigning certain hosts to specific groups, you can sort events specifically related to that group which may relate to a specific geographic location, department, or subnet. You may also want to place a group in Test Mode to test new policies without affecting your entire production environment.

Viewing Groups

The Groups configuration window is an option under the Systems tab of the CSA MC tool. To view all of the groups configured on the CSA MC (mandatory, predefined, and your custom-created groups), choose Systems > Group as shown in Figure 3-2.

Figure 3-2. Choosing Groups from the Navigation Bar


When you are at the Groups window, you can view the list of currently available groups by operating system. You can also remove groups by checking the check box directly in front of the group you want to remove and then clicking the Delete button at the bottom of the browser window.

Two other options at the bottom of the page enable you to create new custom groups: New and Clone. Clicking the New button enables you to create a new custom group. You can use the Clone button after choosing another group via its associated check box. The clone process inherits the other group s configuration, so you can create a new similar group with modified settings without affecting the original group s configuration. This can prove very useful for testing slightly changed policies on a controlled pilot group without affecting the mass of other hosts running the currently deployed policy attached to the original group.

The last button to discuss at the bottom of the Groups screen is the Compare button. To use the Compare button, choose two groups you want to compare by checking the associated check boxes and then click Compare. The CSA MC then presents you with a comparison view of the two groups, including such items as attached policies, polling interval, architecture, and description, as shown in Figure 3-3.

Figure 3-3. Comparing Groups


TIP

The Compare option for groups is only able to compare two groups to each other. You need to perform successive comparisons if you want to compare more than two groups to each other.


When comparing two groups, you can choose any policy attached to the group by checking the check box to detach or attach the policy to the group. Detaching a policy removes it from the group and attaching enables you to add it back to the group s active policy.

Creating a Custom Group

To create your first test group, first click New at the bottom of the Groups web page. A pop-up window then asks, "What is the target architecture?" The answer to this question depends on the purpose of your group; for illustration purposes, however, choose Windows as the target architecture. The Group Configuration page displays next. Before you finish configuring this group, notice the following points shown in Figure 3-4:

  • The group name is originally Untitled_1 This group name changes after you have renamed the group, but at this point the group has already been created. If you want to remove this newly created group, click the Delete button at the bottom of the page.

  • One rule change is pending To finalize all configuration changes and implement them into the CSA running active configuration deployed to agents, click the Generate rules link at the bottom of the page.

Figure 3-4. Creating a Custom Group Named TestGroup1


TIP

After changing any configurable settings on any CSA MC web page, you must click the Save button at the bottom of the page to commit the changes. These changes are not activated in the production agents until you generate rules, as described later in this chapter, and save the changes; otherwise, the changes are lost.


From the Group Configuration screen, you can now edit the group and all group settings. First, name this group TestGroup1. Then edit a brief description and a detailed description for this group. The Description and Detailed fields prove extremely useful when used appropriately. Place a simple description in the Description field; in the Detailed field, add information regarding who to contact about the policy and any important notes that may help troubleshooting in the future.

Below the Description field, the Target Architecture field reminds you that this is a Windows policy. The polling interval for devices in this group is set to 10 minutes. You can change the polling interval to a lower or higher number if devices in this group require checking in more or less often for configuration updates. Another option is to check the Send Polling Hint box, which turns on the UDP hint message capability new to CSA 4.5. UDP hint messages are signed UDP messages that the MC can send to the last known IP address of the agent to alert the agent of an impending configuration change or other similar request. This feature can prove useful when setting the polling interval high but still wanting to have some control over a speedy policy update when a change is necessary.

The next section of the Group Creation dialog is Rule Overrides. The various options are available upon clicking the plus sign (+) next to Rule Overrides. As shown in Figure 3-5, the rule-override options are as follows:

  • Test Mode Applying Test Mode to a group causes the agents in that group to only monitor what actions would have been taken based on the local running policy without actually enforcing the preventive actions. These monitored events are reported back to the MC as Test Mode events. Test Mode is commonly used when testing policies in an active production environment or when testing policies in nonproduction during the early phases of the CSA implementation. This mode enables the implementation team to watch the policy on end systems for possible conflicts with the system and its applications that could have impacted system usability if the agent had been in Protect Mode. Protect or Enforcement Mode is the state an agent is in when the policy is actively enforcing the actions on the end system. You learn more about Test Mode later in the section "Using Test Mode."

  • Verbose Logging Mode Verbose Logging Mode causes the hosts in the group to log all recurrences of events rather than just a single event in cases where multiple occurrences of the same event are suppressed.

  • Log Deny Actions This option causes the agents in the group to log all deny actions regardless of whether the individual rules state that logging should take place.

  • Filter User Info from Events This option prevents some personal user information from showing up in the CSA MC log so that you can be aware of what is happening in the network without overstepping your bounds as "Big Brother." This feature is valuable when you have privacy policy limitations.

Figure 3-5. Definable Group Settings


After defining the appropriate parameters for the previous options, click Save to make the changes permanent.

In addition to enabling you to define parameters for group settings, the Groups screen also provides a quick links section at the top of the page. This section contains three options:

  • Modify Host Membership Links to a page that displays which hosts belong to this group and enables you to add currently nonparticipating hosts to this group as members.

  • Modify Policy Associations Brings you to a page where you can select which policies should be attached to this group and thereby distributed to the group s members. You learn more about policies in Chapter 4.

  • View Related Events Links you to a filtered view of the event log, which only displays events generated by members of this group.

The final task in creating or modifying a group is to click Generate rules at the bottom of the Configuration page. Clicking this button takes you to a listing of the changes that need to be committed and an option to Generate, as shown in Figure 3-6. Also notice that some options have a clickable [Details] link, which you can click to view what that particular change entails. (See Figure 3-7.) You must click Generate for the CSA MC to modify the rule associations and agent kits so that they will be in effect. Figure 3-8 shows the rule-generation operation completed.

Figure 3-6. Sample Generate Rule Programs Screen


Figure 3-7. Sample Entry Details Pop-Up Window


Figure 3-8. Generating Rules


After policies are attached to this group, the associated rules display at the bottom of the Groups page.

Exploring Predefined Groups

The product installation includes many predefined groups. These groups are included to simplify a basic installation of the CSA product but may not be applicable to all environments. As a best practice, explore the predefined groups to see which you could use in your specific deployment to simplify the implementation and configuration process. So that you can better understand what a predefined group can be used for, this section looks at a few of them in detail and explores their attached policies.

The Desktops All Types Group

The Desktops-All Types group is by far one of the most used predefined groups shipped with the CSA MC. You can use this group for all of your generic hosts. It is a great place to configure policies that should be inherent on all desktops in your organization. This section looks at the generic functionality of the Desktop-All Types group as assigned by the pre-attached policies. You can change these policies and rules as needed for your own successful deployment or, alternatively, you could create your own groups for hosts that better match your deployment plan and architecture.

Initially exploring the top-level group settings, you notice a generic description for the group has been prepopulated and the 10-minute polling time is the default. The Polling Hint Message is enabled, allowing all hosts in this group to receive a hint message when a policy update is required. Another item to note is that the attached policies and the combined rules from these policies are listed, as shown in Figure 3-9. You did not see this earlier in the "Creating a Custom Group" section because when you created your custom group called TestGroup1, you had not associated any policies with that particular group at creation time.

Figure 3-9. Attached Policies and Combined Rules


To get a better understanding of what this group s policies control on the hosts, you can expand the associated policies by clicking the plus sign (+) in front of the policies listed; doing so reveals all associated modules. (See Figure 3-10.)

Figure 3-10. Expanded Policies Reveal Associated Modules


You can see in Figure 3-10 that the Default Desktops group includes several policies, which in turn include several modules. In the Combined Policy Rules block, you see every rule associated with these policies. You can navigate via the clickable links directly to each attached policy, module, and rule; however, the CSA quick links section located at the top of most CSA MC Configuration pages gives you a few other valuable viewing options. To get an easy-to-read explanation of the attached combined policy, click the Explain Rules quick link.

The Explain Rules page enables you to view in as simple terms as possible what all the rules in your combined policy mean, as shown in Figure 3-11. There are sections to this easy-to-read explanation, so you can navigate directly to the portion you want to view without having to search aimlessly.

Figure 3-11. Explain Rules Page


To add even further detail to this page while maintaining the ability to understand the policy in place, the sections are each broken down by state so that you can understand what rules will be in effect based on information such as who is logged in and whether the CSA MC is reachable.

Without going into great detail regarding the Desktop-All Types group, Explain Rules shows you that various types of rules are contained in the attached policy affecting the following:

  • How the local agent can be used

  • How the machine interacts with the network as both a client and server

  • How the local file system is used by various applications

  • What should be audited, such as logon and logoff of the machine

Other Predefined Groups

Several other predefined groups are included with the CSA MC installation and are listed on the Groups page. The groups listed on this page are sorted by operating system architecture. These groups are not necessarily included as a guide of how you should or should not implement groups in your organization but rather as basic examples and a possible launching pad to quicker deployment. Every organization should look deep into their own security policy for reasons to implement different sorts of groups, whether it is for grouping specific types of application servers, geographical locations, or purely for report and Event Monitor filtering purposes. Here is an abbreviated list of predefined groups:

  • Servers All Types

  • Desktops All Types

  • Desktops Remote

  • Servers IIS Web Servers

  • Systems Test Mode

Remember, the preceding list is just a sample of the predefined groups included during the installation process. Refer to your Groups page to see what definitions are included with the particular version of the CSA MC you installed; these predefined groups and policies will continue to be developed and mature over time. Chapter 14, "CSA MC Administration and Maintenance," describes group best practices in more detail.

Viewing and Changing Group Membership

When working with groups, you may occasionally need to change which hosts are part of that group. This change might be related to a physical relocation of the host or possibly a change in the application composition of the host. To easily edit which hosts are associated with the specific group, click the Modify Host Membership quick link from that Groups Configuration page. In Figure 3-12, you can see an example of the Modify Host Membership page associated with the TestGroup1 group. It is very easy to add or remove hosts from this group by highlighting the host or hosts and clicking Add or Remove.

Figure 3-12. Example Host Membership Modification Page


You also have the option to Bulk Transfer all members of another group to this group via either a Copy or Move option at the bottom of the page. Using a bulk transfer move function enables you to empty the current group and relocate the users to a new or preexisting group; however, using a bulk transfer copy adds the members of the current group to an additional group without removing the hosts from the original group. In this situation, these hosts participate in more than one group and, therefore, the host settings and rule base are a derivative of the combined group information in accordance with rule precedence, as you learn about in Chapter 4.

As with any change in the CSA MC, you must click Generate rules to commit the changes to the active configuration to be delivered and enforced on the agents. The agents are completely unaware of the changes until the rule generation is completed and the host successfully polls the CSA MC server for updates. Until both of the preceding events take place, the remote agents are completely unaware of any changes made centrally and continue to enforce the currently deployed policy.

Viewing Group-Associated Events

When working with an existing group and troubleshooting rules, it proves very useful to view which events have been triggered by members of that group. An easy way to view these particular events is from the Groups page under the top-level Systems menu option. From this page, you can choose Group Associated Events from the quick links navigation option. This opens a new window that displays all group-related events in the CSA MC database, as shown in Figure 3-13. From this page, you can scan for particular types of events that you may be troubleshooting and then dig deeper into their cause to see whether it was a legitimate action or a rule in need of revision. The event log is covered in detail in Chapter 8, "Monitoring CSA Events."

Figure 3-13. Group-Specific Events in the Event Log


     < Day Day Up > 


    Cisco Security Agent
    Cisco Security Agent
    ISBN: 1587052059
    EAN: 2147483647
    Year: 2005
    Pages: 145
    Authors: Chad Sullivan

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net