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:
Install and Secure the CSA MCYou 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 MCAfter 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:
Figure 9-2. CSA Organizational UnitsThe 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 ModulesConfigure GroupsYour next task is to configure the groups you are going to use for your hosts. There are two types of groups:
Policy GroupsStart 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:
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 GroupsAfter 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:
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).
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:
Configure PoliciesThe 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:
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. |