CSA 4.5 contains builtin desktop groups for Windows and Linux operating systems. The following sections examine the policies assigned to each in detail.
Windows
Windows Desktop Groups are further divided into two types. There is the Desktops—All Types group that as the name suggests is applied to all desktops, and the Desktops—
Remote or Mobile group that is used for roaming workstations or workstations used in a home office and not always connected to the corporate network. The Desktops—All Types group is associated with policies that are useful for all workstations in the organization, such as the E-mail Client—Basic Security—Windows policy. Figure 8-3 shows that the rule modules attached to that policy are the E-mail Client Module—all Security Levels, E-mail Client Module—Base Security, and the E-mail Worm Protection Module.
Figure 8-3 E-mail Modules and Policy Applied to All Windows Desktops
Notice the other policies associated to the Desktops—All Types group. Policies for document security, virus scanners, base system protection, and network filtering are also
attached. When combined, these policies give the workstation a great deal of protection from common threats you face everyday.
NOTE Remember that some modules attached to a policy might not be active depending on the system state of the machine or the actual operating system of the machine. Therefore, some of the rules attached to groups with this policy association are not enabled even though those rules are present in the combined list of rules for that group. The next chapter explores this concept in greater detail.
The followings lists describe some of the highlights and more important protections provided by these policies. The points are grouped by the action taken whenever the given event occurs.
The following are actions always denied:
• E-mail applications are not allowed to launch user-invoked applications, NT virtual DOS machines, or command shells. An event is logged if this is attempted.
• E-mail applications might not write dynamically quarantined files, and any attempt to do so is logged.
• Any application processing that recently created untrusted content (such as a recently downloaded executable) is not allowed to access the Local User Account registry keys and attempts to do so log an event.
NOTE There is a rule in place to disable any attempt by the workstation to act as a server for any TCP or UDP services; however, the rule is not enabled by default.
The following are actions always allowed:
• Any application can invoke virus scanners, and virus scanners can invoke any application.
• Installers and applications invoked by installers can read and write all files.
• Document readers, e-mail applications, and Winzip applications can read and write document and user data files.
The following are actions that cause the user to be queried:
• Any application invoking a software installer causes the user to be queried, and an event is logged. If the user is not logged in or does not respond in a timely manner, the action will be denied.
• E-mail applications attempting to access wscript, vbscript, or file system objects prompt the user for a response and log an event.
• The user is queried when any application tries to write files in virus scanner directories. An event is logged.
• Any application attempting to trap keystrokes, monitor media devices (such as microphones or video cameras), or write memory owned by other applications cause a user query and logged event.
• An NT virtual DOS machine attempting to read files from removable media causes CSA to query the user and log an event.
The following reactions are denied unless allowed by some other policy and log an event unless otherwise noted:
• MS LSASS is not allowed to invoke any applications.
• Remote clients, network servers, and suspected virus applications cannot write startup files.
• Remote clients cannot access registry keys.
• No applications can access physical memory.
The following are events and actions that are simply detected and build dynamic application classes:
• All applications invoking MS sysocmgr are added to the Installation Applications application class.
• Processes executing untrusted content is added to the Suspected Virus Applications application class if they try to communicate using protocols normally used by e-mail applications.
• All applications invoking unusual system calls are monitored.
• Antivirus events and logon events are logged to the NT event log.
• Any detected nonstandard, non IP-based protocols attempting to load trigger an event.
There is also a group with two associated policies for remote or mobile desktops. The Desktops—Remote or Mobile group has the Cisco VPN Client Policy—Windows and the IP Stack—External Network Security policies attached to it. These policies contain rule modules that are useful for allowing remote access to the network and also have more strict controls on what network services are allowed to connect to the machine.
Some of the rule highlights from this group include:
• Although the attempt to modify CSA files by Cisco Secure Desktop (an optional component of the Cisco SSL VPN client) is denied, related events are not logged.
• The Cisco VPN client can invoke VPN helper applications.
• Port scans from all hosts fail.
• The machine does not respond to echo requests.
Notice that the policies that are valuable to both types of machines are applied to both the Desktops—All Types group and the Servers—All Types group. These policies could easily be associated with the <All Windows> auto-enrollment group, and the resulting policy set would remain the same. This illustrates that you can accomplish one goal several different ways in CSA and that you can creatively use groups and policy associations.
The Windows Servers—All Types group is associated with a subset of policies that are assigned to the Windows Desktops—All Types group. Referring back to Table 8-1, you see that the resultant set of server policies does not include rules for document security, e-mail client security, or network personal firewall, as the desktops do.
Linux
The Linux desktop policies are written to afford protections for Linux systems similar to the Windows protections detailed previously. In much the same way that Windows policies protect directories such as windows\system32 and the system registry, the /etc directory is protected on Linux systems and Solaris systems. Because Linux operates differently than Windows, other application classes and variables are used in policies, but the overall enforced policy is similar.
The following are some of the main differences in policy:
• The Red Hat Network Updater utility cannot act as a client or server for TCP services.
• During a change in run levels, setting up the network interface is allowed.
• All applications are prevented from loading any modules.
• Untrusted content, suspected viruses, web browsers, and e-mail clients cannot write Redhat Package Manager (RPM) database files.
Although these are some of the differences, there are key similarities to Windows and Linux policies. In fact many rules are exactly the same, particularly Network Access Control rules. Most applications cannot write or modify files in system directories, files recently downloaded from the web are untrusted, and in most cases applications cannot accept connections as servers.
Comparing Table 8-2 to Table 8-1 shows that Windows and Linux handle policy associations the same way with respect to desktops and servers' group policy mappings.
The standard Linux desktop policy and server policy are identical except the desktop policy contains rules for IP stack security and network personal firewall.
Solaris
The manner that CSA addresses Solaris differs from the way that Windows and Linux are handled; all Solaris hosts are expected to be servers, and there are no builtin desktop
policies. This does not mean that Solaris hosts cannot be used as desktops, but simply that CSA does not have default policies for Solaris workstations. Policies for Solaris
workstations can be created and can use rule modules from Linux, and in most cases, they work fine without modification.
It should come as no surprise that the policies attached to the All Solaris group are Operating System—Base Permissions—Solaris and Application Classification. The Solaris Servers—All Types group is associated with General Application—Basic Security—
Solaris, Installation Applications—Solaris, and Operating System—Base Protections—
Solaris policies. Again, attaching all five policies to the <All Solaris> group would yield the same results as having a host that is a member of the Servers—All Types group. Table 8-3 outlines these relationships.
Another interesting point to note is that the Application Classification policy is associated with the auto-enrollment group for all three operating systems. This policy contains rule modules that target each of the operating systems.