Step 3: Implement Management


In this phase, you use the plans from phase 2 to begin the actual implementation. In a CSA deployment, the agent installation packages are generated by the management center. You cannot begin installing agents without the CSA MC. Therefore, the first component you must deploy is the CSA management. You face four subtasks in this phase of the project:

Step 1.

Install and secure the CSA MC

Step 2.

Understand the MC

Step 3.

Configure groups

Step 4.

Configure policies

Install and Secure the CSA MC

You should have designed your management architecture in the planning phase. Procure the necessary hardware and software, but before you actually build it, make sure it can be installed in a secure manner. It is critical to secure your CSA MC as much as possible. Security management servers are appealing targets for attackers. An attacker can use a compromised security management server for all kinds of nefarious purposes.

To secure the CSA MC, make sure it is protected as many security countermeasures as possible. Chapter 2, "Signatures and Actions," describes many of these. For example, the CSA MC should at least be in a secure physical location, protected by a firewall, and have a CSA running on it.

Note

Make sure to consult the CSA MC documentation to ensure that your countermeasures don't prevent it from working. For example, the agents use certain network ports to communicate with the management center. If your firewall blocks those connections, CSA will not work properly.


As soon as the security countermeasures are ready to go, consult your architecture plan and build your CSA management solution.

The ACME project team worked with the security and server teams to securely implement the CSA MC. They attached the single server to the network they usually use for management devices because that network is protected by NIPS and a firewall. Along with the operating system and the CSA MC software, they also installed an agent. When everything was running to their satisfaction, they configured the firewall to allow agents and administrators to communicate with the MC.

Understand the MC

After you have your CSA MC (or MCs) up and running, you can begin to experiment with the interface. You will use it often throughout the project, so take some time to explore and become familiar with it. When you have a task to perform, you won't have to fumble around looking for the correct menu or button to click.

Also, make absolutely sure you are familiar with the way security rules are assigned to hosts. The CSA MC does not assign rules directly to each host because it is not efficient to manage a set of rules for each host. Instead, rules are assigned using a hierarchical structure of related "organizational units" (see Figure 9-2). You should be familiar with five basic organizational units:

  • Hosts Systems that are running agents that the CSA MC manages. Each host is a member of at least one group.

  • Groups Collections of similar hosts. For example, hosts that are all desktops might be grouped together.

  • Policies A set of rule modules that have a common purpose and depend on each other to work properly. Policies are attached to groups. A policy can be attached to more than one group, and a group can have more than one policy attached.

  • Rule modules A body of rules that perform a particular function. Rule modules are attached to policies, and a single rule module can be attached to more than one policy.

  • Rules An atomic or behavioral security control (see Chapter 6). Attached to rule modules. A rule can be attached only to a single rule module.

Figure 9-2. CSA Organizational Units


The CSA MC is preconfigured with a useful and robust set of "default" groups, policies, and rule modules. They represent "best practice" configurations, and you should use them wherever possible. Examine the defaults, so that you can determine what they do, how they are arranged, and which ones you might use. Figure 9-3 is an example of one group with its connected policies and rule modules.

Figure 9-3. CSA Groups, Policies, and Rule Modules


Configure Groups

Your next task is to configure the groups you are going to use for your hosts. There are two types of groups:

  • Policy group Used to assign policies to hosts.

  • Secondary group Has no policies attached and is used to filter reports, event logs, and alerts.

Policy Groups

Start with the policy groups. Use the relevant default policy groups wherever possible. Using the default groups saves time, and they already have the appropriate security policies attached. For example, if you are deploying agents to desktops you should use the "DesktopsAll Types" group or the "ServersAll Types" group for servers.

As a general rule, you should make copies of the default groups you plan to use. Add something to the group name, such as a ticker symbol or a company acronym to mark it as yours. For example, the "DesktopsAll Types" could be copied and renamed "ACME DesktopsAll Types." Copying and renaming the built-in groups helps you to differentiate your groups from the defaults and keeps the defaults intact in case you need them later.

ACME decided to use default policy groups and consulted its host classifications to help it decide which ones to choose. The restrictive hosts would be in more restrictive groups, although the balanced would be in fewer and more permissive groups. It made a list:

  • E-commerce web servers (restrictive) ServersAll Types, ServersIIS Web Servers, Servers Externally Deployed, SystemsMission Critical

  • Mobile laptops (balanced) DesktopsAll Types, DesktopsRemote or Mobile

  • Manufacturing desktops (permissive) DesktopsAll Types

ACME finished the task by making copies of the seven policy groups and adding "ACME" to the name so it could easily recognize them later.

Secondary Groups

After you configure your policy groups, it is a good idea to create some secondary groups. You should base the secondary groups on any combination of the following criteria that seems useful:

  • System function Examples include e-commerce applications, back office servers, corporate desktops, remote laptops, or e-mail servers

  • Business groups Examples include finance, operations, marketing, technical support, or sales

  • Geographical location Base these groups on the physical location of the hosts

Note

Hosts generally belong to more than one group. A business critical web server in Austin, Texas, for example, might belong to the Windows Server, IIS Web Server, Mission Critical Servers, and Austin Servers groups. The first two groups might be used to apply policies, while the Austin Servers group is used just to filter events and reports.


As you define and create your groups within the CSA MC, consider that each policy group represents a distinct set of hosts and, more importantly, a distinct set of policies. The number of different policy sets you have deployed directly impacts the amount of time you spend managing CSA after the deployment is completed. Using fewer policy sets results in less time spent managing CSA.

One advantage of using a large variety of policy sets allows you to define granular policies that better meet the security needs for each host. Granularity often translates into enhanced security. The cost of enhanced security is additional management burden.

Try to strike a balance between manageability and security. Use the permissive, balanced, and restrictive classifications you gave each group of hosts to help you. If a host is in the permissive category, use fewer policy groups. If it is in the restrictive category, use more.

For example, a permissive server might be a member only of the ServersAll Types group. A restrictive server might be a member of ServersAll Types, SystemsMission Critical, and ServersExternally Deployed. Each additional policy group adds additional security policies that increase the protection from attack.

ACME created a chart listing the system function, classification, relevant policy groups, business group, and geographic location for each set of hosts (see Table 9-1).

Table 9-1. ACME Host Classification Chart

System Type Group

Classification

Business Groups

Location Groups

E-commerce web servers

Restrictive

Operations

HQ

Mobile laptops

Balanced

Sales Marketing

Remote

Manufacturing desktops

Permissive

Manufacturing

HQ

DeKalb

Fort Worth


After some discussion, the team decided it didn't want to use location as a filtering or altering criteria, so it had no need to create those groups. The team created seven secondary groups:

  • ACME E-Commerce Web Servers

  • ACME Remote Laptops

  • ACME Manufacturing Desktops

  • ACME Operations

  • ACME Sales

  • ACME Marketing

  • ACME Manufacturing

Configure Policies

The last task before you deploy your first agent is to select and configure the policies that the agent enforces on your hosts. If you used the default policy groups, all of the policies you need are already configured and applied to the hosts based on their group membership. If one of your project goals is to enforce corporate security policy, you need to customize the default policy configuration slightly.

Here are some examples of corporate security policy items that would prompt CSA policy customization:

  • HIPS agent must run at all times The CSA default policies allow users to disable the agent. If your policy states that the agent must run at all times, you should change the defaults so that users cannot disable the agent.

  • Users should not use corporate resources to download music One of the default rule modules is called Music Prevention Download. Implement this module to enforce the acceptable use policy.

  • Secret company information should not leave the company The Data Theft Prevention module can be used to control the movement of secret company information.

Because ACME chose to use the default policy groups, the policies it needs are already configured and are applied to the hosts based on their group membership. The one exception was the manufacturing desktops, which needed the Music Prevention Download rule module. ACME made the change and left the rest of the policies alone.




Intrusion Prevention Fundamentals
Intrusion Prevention Fundamentals
ISBN: 1587052393
EAN: 2147483647
Year: N/A
Pages: 115

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