-
Using Management Center for Cisco Security Agents 4.5.1
-
Title
-
Preface
-
Product Overview
-
Management Center for Cisco Security Agents Administration
-
Configuring Groups and Managing Hosts
-
Building Policies
-
Using System Correlation Rules
-
Using Application Classes
-
Configuring Variables
-
Event Logging and Alerts
-
Generating Reports
-
Using Management Center for Cisco Security Agents Utilities
-
Using Cisco Security Agent Analysis
-
Policy Definition Guidelines
-
Third Party Product Integration
-
Cisco Security Agent Overview
-
System Components
-
Open Source License Acknowledgements
-
Table Of Contents
Configuring Policies—The Methodology
Combined General Server and Sample Web Server Policies
Policy Definition Guidelines
Overview
The policies you create on the Management Center for Cisco Security Agents should reflect a well-planned, enterprise-wide security policy. If your corporate enterprise already has security guidelines in place, the rules that form your policies should reflect those guidelines.
When you begin to configure policies, there is a common methodology you can use to successfully form the rules that will provide the security and the flexibility you require. This appendix provides a general approach you should take when creating your CSAMC policies.
This section contains the following topics.
•
Configuring Policies—The Methodology
•
Analyzing Applications
The rule modules you create as part of your policies are application-centric. The application classes, those shipped with CSAMC and the ones you configure yourself, are the key to the rules you build as part of your security policies. Understanding how those applications work is necessary for configuring rules that adequately address the needs of a secure yet unobtrusive policy for that application.
There are three specific areas to consider when determining the type of security required by the application in question. There are overall generic types of protection that stop malicious code such as System API protection, Buffer overflow protection, and Port scan detection (Network shield rule). There are application-specific types of protection you can put in place to allow the application to operate normally while insulating it from any undesired access. Then there are environment-specific types of protection that control access to the application in question and its data over various network channels. It is the latter two, application-specific and environment-specific protection requirements, that this chapter concentrates on.
When analyzing an application for the purpose of writing a policy, consider the following questions.
•
•
•
•
•
•
•
Determining the answers to these types of questions will help you target the resources you want to control as part of your policy for protecting the application.
For example, asking the questions above when analyzing how a Web server application operates would first lead you to determine which files are installed and used by the Web server application itself. What network resources are accessed and what registry keys are owned by the application? How is the Web server administered? Are html files FTP'ed to the server or is Front Page used locally on the system? These are questions targeted at producing application specific rules for a policy.
You would also note how the Web server is used and who can access it. Is it an intranet or Internet server? Does it act as a standalone server or does it access other resources? If there are forms users fill out on the Web server, does it use a backend SQL Server to store data? If so, which applications must be able to communicate with each other and what services, other than HTTP, are required for this communication? These are questions targeted at producing environment specific rules for a policy.
Ultimately, you want your policy to secure both the application and the environment it operates within.
Configuring Policies—The Methodology
Once you understand how an application works, you can begin forming a policy to protect it. There are three general areas you want to address for each resource you are protecting. By addressing the security needs of these three areas, you can configure a well-formed policy to protect the resources you are targeting.
When building a policy to protect a designated resource, refer to the following steps to help you address each resource area.
Step 1
You must prevent writing to the application executables themselves. This maintains the integrity of the executable. The only time the executable should change is if you're upgrading the application.
This type of rule would prevent a Trojan from naming itself "Netscape.exe" to disguise itself as the real Netscape executable.
Restrict access to specified data by other applications. For server policies, you'll want to protect information in certain directories on the server in question, allowing restricted access to specific files and blocking all outside access to other files.
In order to correctly formulate this rule, you must examine what other applications (if any) need to access the application data. This type of rule would protect another application from retrieving sensitive data from a server, such as credit card information or a password file.
Restrict access to sensitive application-specific registry keys. You want to allow the specific application to write to its own registry keys, but prevent all other applications from writing to those registry keys.
Step 2
Dictate what the applications in question can and cannot do. Likely, you'll want specific applications to write only to their own file types. To restrict an application, you must look at the files the application needs to read from and write to and then restrict it to only those files. This type of rule would prevent a buffer overrun from compromising a running application, and damaging other components on the system.
When applications are invoked, they often spawn other processes as part of the action they are performing. It may be desirable to place different restrictions on spawned processes. Therefore, when you analyze an application in preparation for writing rules, CSA MC gives you the option of including or excluding child processes created by the original application. You can also restrict the child processes of an application and create a rule to address only those processes.
Step 3
For example, if an application requires network connectivity, you should specify what required network services must be enabled. Components that are "network visible" are especially vulnerable to attacks. It is important to control what these network-accessible applications (and their spawned processes) can do.
General Server Policy
The General Server policy described here uses the applicable steps mentioned previously to secure common server resources. This is a generic server policy that can be applied to any server. Depending on the type of server you're protecting, you'll want to apply this General Server policy and then create an additional policy, which more specifically targets the resources you want protected, to augment this general one. Here is an overview of a General Server policy.
Note that the rules in these tables are ordered (top to bottom) according to their priority. High priority deny rules take precedence over all others. Allow rules take precedence over deny rules. This General Server policy now locks down the server machine protecting the system directory and protecting network access.
Sample Web Server Policy
Once you have a general server policy to protect basic server resources, you can write a policy that actually targets the resources used by the particular server application you want to protect. For the purposes of this example, the application is a Web server. The executable is "WEB.EXE."
This targeted server policy builds on the General-Server policy restrictions, allowing the services required for WEB.EXE to operate securely. Once we explain the components of this policy, we will combine both the General-Server and Sample Web Server policies and implement them together to provide the overall protection the Web server application requires.
Table 12-2 Sample Web Server Policy
Here is how the methodology detailed in the first section of this document was applied to the creation of this policy. The Description, appearing in italics below, given for each rule in the Web server policy table is listed here with the "methodology" step that applies to it.
Step 1
Protect Web server directories from others: Here we have denied all applications from writing to the directories that contain the Web server application executables. Protect Web server data: This rule prevents anyone from writing to html files and defacing web pages. Protect sensitive Web server keys: This would protect, for example, keys controlling user authentication settings.
Step 2
For a general purpose policy, you want to protect the system from the application in question. Therefore, you can allow the application (ex. WEB.EXE) to read all system files, but restrict writes to system files. (If you are concerned about the application reading certain system files, you can restrict reads to those files specifically, if necessary.)
Prevent WEB.EXE all file write access: This rule denies the Web server application access to all files on the system.
Let WEB.EXE write to temp files and log files: This rule allows the Web server application to write to temp and log files used by the application.
Note that restricting access to a resource should always be done in the policy that owns that resource.
Step 3
Let the WEB.EXE talk to network: This allows WEB.EXE to act as a server for the http service.
Combined General Server and Sample Web Server Policies
To fully protect the Web server, we apply our base General-Server policy and our targeted Sample Web Server policy to the agent running on the Web server system. When applied to the Web server, the combined policies work as displayed in the table below (in order of rule precedence).
Table 12-3 Combined Policies
Reference
"Vulnerable applications" defined in various rules are network-aware applications. These application types are much more vulnerable than others. They are as follows:
•
•
•
•