- Why Write Custom Policies?
- Preparing for the CSA Tuning Process
- Best Practices for Tuning
- Sample Custom Policies
- Using Dynamic Application Classes
- Forensics
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using Dynamic Application Classes
Dynamic application classes are a key component in the CSA architecture. Learning to use these effectively allows you to complete complex tasks using a limited number of rules rather than a great number of static rules. After you understand how to use this type of control, you will use it often and continue to become a more effective and efficient CSA administrator.
An example of dynamic application classes follows. The example tunes an item many corporations use to simplify their environments. Many companies use mass deployment software distribution products to install software, software updates, and patches to their systems automatically. Because the software deployment mechanism is trusted, no CSA administrator wants to tune the policy for every software installation and update. Instead, you can build a rule module that makes use of a dynamic application class to provide the capabilities needed to all the installers that are started by the trusted deployment mechanism.
For this example, assume the software distribution mechanism is named AUTO-INSTALLER.EXE and is pre-installed on every system. The following steps walk you through a high-level approach that enables you to create your own policy that allows your enterprise software distribution system to function.
- Create an application class named AUTO-INSTALLER.EXE that includes your application as shown in Figure 9-12.
Figure 9-12 AUTO-INSTALLER.EXE Application Class
- Create another application class named Processes Started by AUTO-INSTALLER.EXE and Children.
- This is a dynamic application class that includes processes started by AUTO-INSTALLER.EXE and their child processes as well. You select only When Dynamically Defined by Policy Rules to make this a dynamic application class. Do not select This process and all its descendants. You can see the configuration of this in Figure 9-13.
Figure 9-13 Dynamic Application Class
- This is a dynamic application class that includes processes started by AUTO-INSTALLER.EXE and their child processes as well. You select only When Dynamically Defined by Policy Rules to make this a dynamic application class. Do not select This process and all its descendants. You can see the configuration of this in Figure 9-13.
- Create a policy named Installation Policy and a rule module named Installation Rule Module that you can associate to the policy.
- Create the following rules in the rule module.
-
Add an Application Control rule that has an action of Add New Process to Application Class and select Our Dynamic Application Class from the dropdown list. Select the Allow checkbox to list the type of matching action. Select AUTO-INSTALLER.EXE and Processes Started by AUTO-INSTALLER.EXE and Children as the application classes to monitor. Finally, select All applications under attempt to run. This is shown in Figure 9-14.
Figure 9-14 Tagging Child Processes
This rule can be interpreted as, "When AUTO-INSTALLER.EXE, processes started by AUTO-INSTALLER.EXE, and all subsequent processes start any allowed application, add the new process (as a child) to the dynamic application class."
If you turn on logging for this rule, you can see the process tree of who starts whom. You might not want to do this in a production environment due to the load it can create on the CSA MC, but it can be useful at times.
-
Clone the Application Control Rule described previously by selecting the rule from the rule module and pressing the Copy button to copy a clone to the same rule module. Edit the new rule and change the action associated to the new rule to Allow and also the description as shown in Figure 9-15.
Figure 9-15 Allow the Installers to Execute Applications
This rule allows the installation program and any software package, patch, or update to start any programs required to complete the installation. This also allows the installer to start the patches and other installers in the first place.
- Add a File Access Control rule to allow AUTO-INSTALLER.EXE and the contents of the dynamic application class to Read File, Write File, and Write Directory on all files. This allows the installer to write to all locations required, which includes writing DLLs and services. It is important to test your installers before allowing your mass distribution system to install the software. Remember, you assume that anything installed by your installation and distribution program is trusted 100 percent. This rule is displayed in Figure 9-16.
Figure 9-16 Allow the Installers to Write Files
- Add a Registry Access Control rule to allow the same two application classes to write to all registry locations.
- Add a System API Control rule that allows whatever temporary security controls you want to provide to the installers. Common installer System API rule violations could include: trapping keystrokes, accessing memory of other applications, injecting code into other applications, and accessing functions in data or stack.
-
)
)
)
)
)
Remember, this policy does not weaken the entire system, but just provides these specific installation applications the temporary rights they need to complete an installation without causing the CSA administrator the headache of providing updated policy every time a new installation occurs. The key to everything in the previous example is the dynamic application class and the amount of intelligence and control it provides you. Mastering this concept ensures a successful deployment. The list of rules we added, as seen in Figure 9-17, might not be a complete configuration for every installation application on the market, but should provide you a start in creating your own policy.
)
Figure 9-17 List of Rules from the Installation Policy