|
|
All security policies and configurations are accomplished using the CSA MC. These policies are associated with specific hosts and groups of hosts. All configurations are stored on the management server and deployed to the agents via the management server.
All communications between the CSA MC and the server are secured using Secure Sockets Layer (SSL) protocol. Similarly, communications between the CSA agent and the server database are secured using SSL.
The web-based user interface is accessed securely using SSL from any machine on the network that can connect to the management server. The web-based interface is used to deploy policies from CSA MC to all the agents across the network.
SSL protocol is also needed for the agents to periodically update the policy; therefore the network must not restrict SSL traffic on port 443. This is especially important if CSA agents are located on remote network segments that are isolated via firewalls.
The CSA MC binds with the server database which holds all the policies. All CSA endpoint agents must register with CSA MC to receive the policy. The CSA MC validates the host and deploys the respective policy pertaining to that host or group of hosts.
After the CSA agent on the local system receives the policy, it starts monitoring the system proactively and takes dynamic actions as necessary.
At regular intervals (configurable), the CSA agent polls the CSA MC for policy updates. It also sends triggered event alerts to the CSA MC global event manager.
No configuration is required on the CSA agent. All configurations are completed on the server via the CSA MC and deployed to the CSA agent. CSA agent will have only basic viewing capabilities.
In the CSA architecture, hosts are the endpoint systems that require protection. A host is any system that has installed the CSA agent kit from the CSA MC and has registered with CSA MC. The host can be a desktop computer, a laptop, or even a server. These endpoints are referred to as hosts within the CSA MC configuration. As mentioned earlier, every host on the network has to register with CSA MC to receive policy updates. The status of the host can be monitored by CSA MC.
Figures 21-6 through 21-8 show a few sample screenshots for managing a host that is using the CSA MC.
Note
The sample screenshots of CSA MC shown previously and in the next few sections are taken from the Cisco "Using Management Center for Cisco Security Agents 5.2" documentation pages. For more details and further information on deploying CSA using CSA MC, refer to http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_book09186a008080732b.html.
There is no specific configuration required to configure the host settings within the CSA MC. As mentioned earlier, hosts register dynamically with the CSA MC and inherit group membership and policy settings transparently upon successful registration. Default policies are available for implementation out of the box.
To view the details of a particular host that has registered with the CSA MC, choose Systems, Hosts. Figure 21-8 shows a sample screenshot of the host detail page for a host named biohazard with complete host details. Several types of information can be viewed from the Host Detail Page, for example:
Host Name and Description: Displays the system name of the CSA endpoint and a brief description of the host.
Host Identification: Displays the CSA product version, the host IP address, a numeric ID associated to this host within the CSA MC database, registration details, host operating system details, and whether the Cisco Trust Agent (CTA) is installed and the associated posture state currently assigned to this agent. (This feature is part of the Network Admission Control [NAC] of the Cisco Self-Defending Network solution.)
Host Status: Displays events triggered by the host, software and policy version, the time since the policy was last updated, and a detailed status and diagnostics link.
Host Settings: Displays various items such as the polling interval, test mode, learn mode, logging mode, deny actions, filtering user information, and whether application deployment investigation is enabled.
Group Membership and Policy Inheritance Table: Displays group membership, details of which groups the host is a member of, the policies assigned to the groups, and the modules within the policies.
Combined Policy Rules Table: Displays a complete list of all the rules running on the host as combined from all associated groups, policies, and modules.
Every endpoint system (host) requires a CSA agent to be installed on the system. This is done via the agent kit, which is an executable installation file generated by the CSA MC for the endpoint host system. By definition, an agent kit is the CSA agent installation executable file that is installed on the endpoint system.
Agent kits can be downloaded from the CSA MC directly via the SSL-protected web page. Alternatively, the file can be transported via other media (such as a USB key or copying it across the network) and executed manually from the local system. Another alternative is to develop scripted and automated installation procedures using software installation systems.
After the agent kit is installed on the system, the host registers to the CSA MC and pulls the appropriate policies and group settings accordingly. Agent kits are associated to groups, which have appropriate policies attached to them. When a host downloads the agent kit, it dynamically associates the host to the corresponding group with the preconfigured knowledge and enforces the associated policies of that group.
CSA MC has several built-in preconfigured agent kits available. Several default kits exist, such as kits for generic desktops, generic servers, and application servers.
Additionally, a custom agent kit can also be created by using the CSA MC. This gives you greater flexibility to define customized options to deploy to the host. Before creating a custom agent kit, other related parameters must be configured, such as initial modules, policies, and rules that the agent must use.
Figure 21-9 shows a sample screenshot from the CSA MC that was used to create an agent kit for IIS web servers.
When the Make Kit button at the bottom of the page is submitted on the page shown in Figure 21-9, the kit is created, and the CSA MC produces a distribution kit for the host. The CSA MC will display a unique URL for each corresponding kit. This URL needs to be distributed to all the endpoint hosts for which the kit was created. This URL information can be sent to users via e-mail. When users receive this URL, they access the URL by using a web browser to download and install the kit. This is the most effective and recommended method for agent kit distribution.
Figure 21-10 shows a sample screenshot from the CSA MC of an agent kit URL page for IIS web servers created earlier. This URL can be distributed to all the IIS servers to be downloaded and installed on any IIS web server that needs CSA protection.
Alternatively, the default system URL for the CSA MC server can be distributed to the users. This URL lists all the available kits on the server, and users can choose the corresponding kit for their host or server and download and install it accordingly. This gives the users empowerment to make their own decisions as to which kit to download. The URL for the CSA MC is https://<system name>/csamc52/kits.
Note
The CSA MC URL may vary depending on the CSA MC Version number. In the previous example, it is Version 5.2, hence the URL has /csamc52/. If the version is 4.5, it will be /csamc45/.
Groups are logical collections of hosts. The concept is similar to Windows Active Directory Groups or any other user database system.
Grouping host systems provides the following advantages:
Policy consistency through applying the same set of policies on multiple hosts across the network
The capability to apply alternative mechanisms and event set parameters based on group configurations
A test mode feature to validate policies on groups of hosts before they are actively enforced on production systems
Hosts can be grouped on logical similarities and can be bound together on any common criteria that meet the security policy requirements; for example:
Hosts, such as web servers, can be grouped according to system function. Specific policies can be created corresponding to the web server requirements.
Hosts can be grouped according to business units, such as sales, finance, operations, and marketing. Specific policies can be created and crafted to meet the requirements of business functions and each business unit's individual needs.
Hosts can be grouped according to geographical or topological location.
Hosts can be grouped according to their importance within an organization. For example, you can group mission-critical systems into a common group so that you can apply critical alert-level configurations to the group.
CSA Group simplifies configuration management by associating policy controls and other parameters into group settings. When a user is associated with the group, the host will inherit all the parameters configured within the group. The group also ensures consistency across the entire CSA deployment. All hosts have uniform settings when associated to the same group.
This scalable approach of grouping hosts allows large-scale CSA deployments to be deployed with great ease and reduced complexity.
Hosts can be members of one or more groups and will inherit all the settings merged into the host-specific policy setting from each group.
Another important advantage of having groups is that it makes creating the agent kits easier. The group parameter is the only element required to build agent kits.
CSA MC has several built-in predefined groups (in addition to the mandatory groups) that can be used according to the requirement.
Additionally, custom groups can be created using the CSA MC. This gives flexibility to define user-defined customized group options. Before creating a custom group, several parameters must be gathered, such as operating system, application information, and system user requirements to be configured for the group.
Figure 21-11 shows a sample screenshot from the CSA MC for the group setting page for the IIS web servers.
Typically, groups in CSA MC can be divided into three categories:
Mandatory groups
Predefined groups
Custom groups
By default, CSA MC provides three auto-enrollment mandatory groups:
All Windows
All Solaris
All Linux
One of these three mandatory groups will be associated to each endpoint host according to its OS architecture upon registration. For example, when Windows-based hosts are registered to the CSA MC, they are automatically enrolled in the "All Windows" group in addition to any other groups that are mapped to this host. Hosts cannot be removed from the mandatory groups.
Mandatory groups enforce some of the compulsory security policies to prevent critical service from being inadvertently disturbed. For example, a mandatory policy can dictate that a user cannot disable DNS or DHCP service.
Caution
Hosts can belong to one or more groups and inherit multiple policies from these groups. However, the combined rule set will follow the rule precedence process when deciding which rules to override, if a rule conflict occurs.
After the agent kit is installed on the endpoint system, the CSA is ready to monitor the system. As mentioned earlier, to run the CSA agent software, no configuration is required on the endpoint. Optionally, as the administrator, you can provide end users with an advanced user interface that allows them to control the security settings and to use other added features.
To open the CSA agent user interface (UI), double-click the CSA agent icon in the system tray. (Locate a Red Flag icon in the system tray that denotes the CSA agent.) The options available in the agent UI depend upon the options selected in the Agent UI control page that governs the agent control rules in this context, as shown in Figure 21-12.
Figure 21-12 shows a sample screenshot from the CSA MC for the Agent User Interface control setting page.
Figure 21-13 shows a sample screenshot from an endpoint host system showing the CSA Agent user interface.
As shown in Figure 21-13, the Agent User Interface displays various status information of the endpoint host, for example:
The hostname of the machine on which this agent is installed.
The date and time the agent registered with CSA MC.
The date and time the agent last downloaded data from CSA MC.
Update information informing the user whether a software version update is available for his agent.
Display of the NAC posture result for the agent, if the Cisco Trust Agent (CTA) is installed. For example, the display can state the status as Healthy, Quarantine, or Infected.
When the user clicks the Poll button, it forces the agent to poll the CSA MC immediately, rather than waiting for the configured time interval to trigger a poll. This way, the agent receives any rule changes right away.
Optionally, the CSA MC for the Agent User Interface control setting page can be configured to enable the Local Firewall and File Protection feature. The local firewall settings on the endpoint allow users to manually control which applications have access permissions on their systems and define what those permissions are.
Note that these firewall settings and permissions that indicate whether the application can access the network are assigned locally by the agent by a dynamic query method via a pop-up dialog box. These permissions can also be assigned during a learning mode period.
Figure 21-14 shows a sample screenshot from an endpoint host system that shows the Local Firewall setting in the CSA Agent user interface.
Caution
Note that this feature is intended for interactive systems, as opposed to servers that should be managed only by a central policy. If this feature is present, users must select the Enable check box to turn on firewall settings.
As discussed in previous sections, each group is associated with a security policy that drives specific actions.
Policy is a collection of rule modules, and a rule module is a collection of multiple rules. The rule module acts as the container for rules, whereas the policy serves as the unit of attachment to groups. Rules provide control access to system resources. These resources can either be a system resource or a network resource.
Multiple rule modules can be attached to a single policy, and multiple policies can be attached to a single group. The rules enforce policy control actions to allow or deny specific actions. Different types of rules in a rule module can coexist, and consequently different types of rules within one policy can also exist.
CSA MC allows the creation of several types of policies in addition to the default built-in policies. An example of the three mandatory policies (Windows, Solaris, and Linux) is presented earlier in this chapter.
In principle, policies must reflect a well-planned security framework and be driven by the fundamental guidelines of the corporate security policy. Appropriate time and effort should be expended before charting these policies, because they provide network and application access to the systems.
Policies, rule modules, and rules are the enforcement tools in the CSA architecture.
Tip
For more details on building policies, refer to the following Cisco documentation URL: http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_chapter09186a00808139c0.html
For more details on rule modules and rule types, refer to the following Cisco documentation URLs: http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_chapter09186a00808074a0.html
Several other parameters are required to be configured when you are using CSA MC to complete the CSA deployment. For example, configure global correlation parameters, application classes, variables, logging and alerts, and other parameters.
Refer to the following Cisco documentation for further details to implement CSA in greater depth and additional configuration parameters: http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_configuration_guide_book09186a008080732b.html.
|
|