Guest

Cisco Security Agent

Cisco Security Agent Version 6.0.1 Deployment Guide

  • Viewing Options

  • PDF (5.1 MB)
  • Feedback

1 Executive Study

Deployment of Cisco ® Security Agent requires an understanding of an organization's corporate security policy and business requirements and of how Cisco Security Agent's host security policies can be applied to meet these requirements.

1.1 Purpose

Welcome to the Cisco Security Agent Version 6.0.1 Deployment Guide. This deployment guide should enable the reader to deploy Cisco Security Agent.

1.2 Background

Deployment of Cisco Security Agent in the past has been a challenge, requiring the implementer to address deployment considerations, make policy decisions, and perform tuning. This guide helps the implementer meet these challenges and deploy Cisco Security Agent. The reader should have knowledge of the fundamentals of Cisco Security Agent, such as how to create groups, policies, rule modules, and rules and perform cloning. Please refer to the Using Management Center for Cisco Security Agents 6.0.1 Users Guide for more information http://www.cisco.com/en/US/docs/security/csa/csa601/user_guide/CSAMC_UserGuide.html.

2 Choosing the Management Center for Cisco Security Agents Installation

Choosing the Management Center for Cisco Security Agents architecture is crucial to deploying Cisco Security Agent. The Management Center for Cisco Security Agents can be installed in a single-, two-, or three-tier environment. Please refer to the Management Center for Cisco Security Agents Hardware Installation Guide for more information: http://www.cisco.com/en/US/docs/security/csa/csa601/install_guide/CSAMC_InstallGuide.html.

2.1 Single-Tier Architecture

The Management Center for Cisco Security Agents and the SQL database are installed on the same server. By default, the Management Center for Cisco Security Agents ships with SQL Server Express, a desktop version of Microsoft SQL, which is limited to a 4-GB database. If you have more than 1000 users, you should install the full version of Microsoft SQL server 2005. Further, event if you have fewer than 1000 users but your policies require auditing or you require long-term storage of events, you may want to install the full version of Microsoft SQL 2005 if you think that your database may exceed 4 GB.
Make sure you back up your database to protect against catastrophic failure; you can build a server with the same host name and restore the database.
A single-tier, single server, Management Center for Cisco Security Agents can scale from one to 20,000 agents

2.1.1 Hardware Configurations

1. Single processor Pentium 4 (3 GHz+) with 2 GB RAM

2. Dual processor Xeon (2.5 GHz+) with 4 GB RAM

3. Quad processor Xeon (2.5 GHz+) with 8 GB RAM

4. Eight-way Xeon (2.5 GHz+) with 8 GB RAM

The following list shows the approximate number of agents you can deploy with each server configuration installed on one of four hardware configurations.

Hardware Configuration

Number of Agents

Hardware Configuration 1

2,500

Hardware Configuration 2

5,000

Hardware Configuration 3

10,000

Hardware Configuration 4

20,000

For detailed installation instructions, please see the Management Center for Cisco Security Agents Installation Guide: http://www.cisco.com/en/US/docs/security/csa/csa601/install_guide/CSAMC_InstallGuide.html.

2.2 Two-Tier Architecture

The Management Center for Cisco Security Agents is separate from the Microsoft SQL 2005 database. The SQL back-end is installed first, and the CSAMC 6.0.1 database is then created as outlined in the Management Center for Cisco Security Agents Hardware Installation Guide: http://www.cisco.com/en/US/docs/security/csa/csa601/install_guide/CSAMC_InstallGuide.html.
In the event of a catastrophic Management Center for Cisco Security Agents failure, you can build another Management Center for Cisco Security Agents with the same host and connect to the back-end database.
A two-tier Management Center for Cisco Security Agents uses one server to handle both the polling and configuration requests, and a second server for the back-end database. This architecture scales from one to 75,000 agents.

2.2.1 Hardware Configurations

1. Single processor Pentium 4 (3 GHz+) with 2 GB RAM

2. Dual processor Xeon (2.5 GHz+) with 4 GB RAM

3. Quad processor Xeon (2.5 GHz+) with 8 GB RAM

4. Eight-way Xeon (2.5 GHz+) with 8 GB RAM

The following list shows the approximate number of agents you can deploy with each server configuration installed on one of four hardware configurations.

Hardware Configuration

Number of Agents

Hardware Configuration 1

7,500

Hardware Configuration 2

15,000

Hardware Configuration 3

30,000

Hardware Configuration 4

75,000

For detailed installation instructions, please see the Management Center for Cisco Security Agents Installation Guide: http://www.cisco.com/en/US/docs/security/csa/csa601/install_guide/CSAMC_InstallGuide.html.

2.3 Three-Tier Architecture

The functions of the Management Center for Cisco Security Agents are split between two servers: the polling server and the configuration server. The Cisco Security Agents will poll, register, and send updates to the polling server. The configuration server is used for Cisco Security Agent administrative tasks.
High availability is supported through the use of Cisco CSS 11000 Series Content Services Switches. (Please see the high-availability white paper for details.)

2.3.1 Hardware Configurations

1. Single processor Pentium 4 (3 GHz+) with 2 GB RAM

2. Dual processor Xeon (2.5 GHz+) with 4 GB RAM

3. Quad processor Xeon (2.5 GHz+) with 8 GB RAM

4. Eight-way Xeon (2.5 GHz+) with 8 GB RAM

Hardware Configuration

Number of Agents

Hardware Configuration 1

10,000

Hardware Configuration 2

20,000

Hardware Configuration 3

50,000

Hardware Configuration 4

100,000

For detailed installation instructions, please see the Management Center for Cisco Security Agents Installation Guide: http://www.cisco.com/en/US/docs/security/csa/csa601/install_guide/CSAMC_InstallGuide.html.

3 Initial Pre-Deployment Questions

Asking questions at the beginning and knowing what to expect from Cisco Security Agent's host security policies can save you deployment time. Listed here are some common deployment considerations that should be addressed with the customer before deploying Cisco Security Agent.

3.1 General Considerations for Desktops and Servers

Some fundamental questions are:

• What Cisco Security Agent host security policies should be used to meet the customer's business requirements, compliance requirements, etc.?

• What are the expected behaviors for these policies and what are the default behaviors?

Desktop installations are different than server installations.
For desktops:

• Do not allow end users to install software; allow only certain groups to do so.

• Customize quarantine so that there are no end-user messages.

• Do not allow end users to disable Cisco Security Agent security settings; allow only certain groups to do so.

• Do not allow end users to change security settings; allow only certain groups to do so.

• Do not allow end users to enter queries; allow only certain groups to do so.

• Implement Cisco Security Agent in stealth mode.

• Deploy zero-day policies globally to all groups.

For all servers:

• Determine how many servers are generic (not sure of what applications are running), application based, internal, and in the DMZ.

• Do not allow no rule queries or notifications for servers.

• Deploy zero-day policies globally to all servers.

For application-based servers:

• Deploy application-based policies (such as web server policies) locally to groups.

• Assign network lockdown policy.

Note: Application-based policies will contain the ports used by the application; the network lockdown rule will help ensure that only the application has access to its associated ports.

3.2 General Considerations for Data Loss Prevention

You should meet with the customer to discuss the corporate data security policy. You should understand Cisco Security Agent's data loss prevention (DLP) policy and determine whether the customer's data security requirements match. See the discussion of Cisco Security Agent policy for details.
Cisco Security Agent's DLP policy protects against:

Data leakage: Protects against data misuse and inadvertent data loss

Data theft: Protects against malicious threats targeted at sensitive information

Note: Use Cisco Security Agent's DLP policy with Cisco Security Agent's host security policies for the highest protection. These desktop host security policies include AV-Behavior-Based Desktop, Audit System Integrity, Anti-Spyware, Anti-Rootkit, Quarantined Compromised Applications, Quarantined Compromised Hosts, and Centrally Managed Firewall policies).

• Loss of data in motion: Requires mobile users to establish a VPN connection before accessing sensitive information

End users are notified when they are noncompliant and are asked to provide business justification for being noncompliant.
You will also commonly create a corporate data security policy that addresses these questions.

• What is the customer's sensitive information?

– Does the customer need to protect credit card numbers, social security numbers, text strings, etc.?

– Does the customer need to protect specific server applications and files?

• Where is this sensitive information stored?

– Does this sensitive information reside globally on all servers or is it specific to a selected group of servers?

– Does this sensitive information reside globally on all desktops or is it specific to a selected group of desktops?

– What specific directories and file types are used to store this sensitive information?

– What precautions are being taken to protect this sensitive information?

• What applications have access to this information?

– Do certain or all applications have access to this data?

– What precautions are being taken to protect authorized applications?

• Who has access to this information?

– Do all users have access to this information or only specific groups?

• Can this information be removed locally, while on or off the corporate LAN?

– Can this information be copied to removable media?

– Can this information be burned to CD?

– Is this information accessible from removable media?

– Can this information be printed?

– Can this information be copied and pasted into other applications?

• Does the customer have a corporate data security policy for remote users?

• Where is this information going?

– Can this information be sent over web mail?

– Can this information be sent using peer-to-peer (P2P) communication, FTP, or instant messaging or through some other unauthorized channel?

– Is this information sent to specific servers within the intranet?

• What precautions is the customer taking to protect the application and data?

3.3 General Considerations for Integrated Anti-Virus Solution

Cisco Security Agent uses Integrated ClamAV and is controlled by assigning the antivirus-signature-based policies at the group level:

• Integrated ClamAV is available on Microsoft Windows platforms only; it is not required for zero-day protection.

• The Management Center for Cisco Security Agents needs to obtain signature updates from the ClamAV server (db.local.clamav.net) and should be reachable over HTTP either directly or through a proxy server.

• Remove other antivirus solutions. (Note: If other antivirus solutions are not removed, they may interpret the signature base main.cvd and daily.cvd files as infected and quarantine them.)

• The Management Center for Cisco Security Agents may obtain signature updates from the ClamAV server several times a day.

• Agent requests occur every 24 hours and cannot be customized.

• If agent requests from the Management Center for Cisco Security Agents remain unanswered for 48 hours, the agent will try to go to the ClamAV server for antivirus updates.

• You can set weekly or monthly scans.

• If Cisco Virtual Network Computing (VNC) or other remote applications are used, these may trigger false positives in potentially unwanted application (PUA) signatures.

• You can specify whether you want end-user notifications to appear when infected files are found and quarantined.

• Files in quarantine can be restored locally. If files remain in quarantine for 60 days and no action is taken, the file will be deleted.

4 Deployment Strategies

The deployment strategies discussed here cover common Cisco Security Agent desktop and server scenarios.

4.1 Desktop Deployments

1. Define your grouping structure.

2. Define policies.

Host security desktop policies generally used for Cisco Security Agent desktop deployment include:

• AV-Behavior-Based Desktop

• Audit System Integrity

• Anti-Spyware

• Anti-Rootkit

• Quarantined Compromised Applications

• Quarantined Compromised Hosts

• Centrally Managed Firewalls Desktop (may or may not be used)

Cisco Security Agent host security desktop policies are normally assigned globally across all groups. You may have acceptable-usage policies, such as "Block writing all files to USB devices," which can be assigned locally to the group.

Clone each of the original rule modules from the chosen default policies, such as AV-Behavior-Based Desktop policy.

Incorporate the name of your organization into the name of the rule module (for example, you would name a cloned rule module such as "Desktop Removable Media" as "OrganizationA_Desktop Removable Media").

Create a new policy incorporating the name of the organization like this: "name of organization_AV- Behavior-Based Desktop."

Assign the newly created associated rule modules to the policy.

The original default policies and associated rule modules remain unaffected.

3. Assign the newly created policies to your group.

4. Turn on audit mode.

5. Enable the polling hint.

6. Create an associated agent kit and deploy it to end users. In the first week of your Cisco Security Agent deployment, you should deploy this kit to 25 to 50 users in various groups. You can manually deploy these agents to the hosts and tune for legitimate applications. (Please see the discussion of tuning for details.)

7. After your groups and policies are tuned, you can clone your groups and name them "Production" (for instance, Production_Group_A).

8. You can manually move hosts from your audit group into your production group.

Note: This is only one method of deploying Cisco Security Agent; other methods of deploying Cisco Security Agent may be used.

4.1.1 Do Not Allow End Users to Install Software-Allow Only Certain Groups

End users are not allowed to install software based on the corporate security policy; IT administrators or other certain groups are allowed to do so.
The AV-Behavior-Based polices contain the following rule modules that control the installation of software:

• Security-User Running Untrusted Installation Application

• Security-Desktop Running Removable Media Installation Application

• Security-Web and Email Untrusted Installation (Medium and High)

By default, end users are prompted to enter their business justification when installing software.
Clone these rule modules: one for end users and one for legitimate groups who are allowed to install software. When cloning these rule modules, apply the appropriate user-state rules.
Change the query rules to "deny" in the rule modules that apply to all end users (Table 1).
The query rules can be left in place in the rule module that applies to groups allowed to install applications. These rules can also be changed to "allow" and "log."
Create associated policies for the rule modules and assign them to their respective groups.

Table 1. Policies, Rule Modules, and Rules for Denying End-User Software Installation Pending

Policy

Rule Module

Rule

Change (Pending Customer Policy)

AV-Behavior-Based Desktop

Security-User Running Untrusted Installation Application

First-time execution of untrusted applications by user writes installation-related keys.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

First-time execution of untrusted applications by user writes execution script file.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Security-Web and Email Running Untrusted Application (Medium

Microsoft Windows desktop invokes untrusted and first-time applications (not shells or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Email, web, and instant messaging applications (not desktop or antivirus) invoke first-time applications (not untrusted, shells, or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Email, web, and instant messaging applications (not desktop) invoke untrusted and first-time applications (not Shells or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Notify: Email, web, and instant messaging applications (not desktop) invoke shells and configuration applications.

Log to Management Center for Cisco Security Agents, or disable, or customize notification.

Security-Web and Email Running Untrusted Application (High)

Microsoft Windows desktop invokes untrusted and first-time applications (not shells or configuration applications).

Change "query" to "deny."

Email, web, and instant messaging applications (not desktop or antivirus) invoke first-time applications (not untrusted, shells, or configuration applications).

Change "query" to "deny."

Notify: Email, web, and instant messaging applications (not desktop) invoke shells and configuration applications.

Log to Management Center for Cisco Security Agents, or disable pending, or customize notification.

Notify: Email, web, and instant messaging applications (not desktop) invoke untrusted and first-time applications (not shells or configuration applications).

Log to Management Center for Cisco Security Agents, or disable pending, or customize notification.

4.1.2 Do Not Query End Users (Does Not Apply to DLP Policies)

End users should not be queried based on the corporate security policy. The policies and rule modules that require customization are:

• AV-Behavior-Based Desktop policy and associated rule modules:

– Invoking Network Configuration Applications

– Invoking System Configuration Applications

– Modify Another Process

– Network Worm Client

– Security-Client Application Security

– Security-Multiple Restrictions (see Section 4.1.3, "Customize Quarantine for No End-User Interaction")

– Security-Multiple Violations (Medium Restrictions) (see Section 4.1.3, "Customize Quarantine for No End-User Interaction")

• Anti-Spyware policy and associated rule module:

– Spyware and Trojan

• Anti-Rootkit policy and associated rule module:

– Security -Rootkit Lockdown

Do not make any change to the untrusted-classification rule modules and set and dynamic application rules. First-time executables will be learned for three days in audit mode; the executables must be installed.
Clone these rule modules: one for end users, and one for legitimate groups that are allowed queries. When cloning these rule modules, apply the appropriate user-state rules.
Change the query rules to "deny" in the rule module that applies to all end users (Table 2).
The query rules can be left in place in the rule module that applies to groups allowed queries. These rules can also be changed to "allow" and "log."
Create associated policies for the rule modules and assign them to their respective groups.

Table 2. Policies, Rule Modules, and Rules for Cisco Security Agent Host Security Zero-Day Policies that Result in End-User Queries

Policy

Rule Module

Rule

Change

AV-Behavior-Based Desktop

Invoking Network Configuration Applications

Command shell and applications interpreting untrusted file (not launching) invoke network configuration applications.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Invoking System Configuration Applications

Command shell and applications interpreting untrusted file (not launching) invoke system configuration applications.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Modify Another Process

Untrusted applications (not white list applications) inject code into all applications through AppInit dynamic link libraries (DLLs).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Network Worm Client

Untrusted applications and interpreters (not email or white list applications) access email objects.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Security-Client Application Security

Web browser, peer-to-peer, and active Internet clients access system functions from a buffer.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Applications that read untrusted data documents or multimedia applications access system functions from a buffer.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Applications that experience a buffer overflow invoke all applications (not shells or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Document reader and multimedia applications invoke first-time execution of applications (not shells or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Security-Spyware and Trojans

Untrusted applications (not web browsers, white list, or <suspect virus>) write Internet Explorer Content tab and root certificates (phishing).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Untrusted applications (not web browsers, white list, or <suspect virus>) write Internet Explorer Search, homepage, General tab, and shell command (hijacking).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Untrusted applications (not Microsoft rundll32, white list, or <Suspected Virus>) write to desktop and wallpaper (spyware).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Untrusted applications (not web browsers, white list, or <suspected virus>) write browser configuration and helper objects (spyware).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

All applications download and invoke Active X controls.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Notify: All applications (not white list) access security account manager.

Disable notification.

Security Rootkit Lockdown

All applications client servers for TCP and User Datagram Protocol (UDP) services have remote addresses.

Log to Management Center for Cisco Security Agents.

4.1.3 Customize Quarantine for No End-User Interaction

End users should not be queried or receive notifications when files are quarantined based on the corporate security policy. This rule may not be applicable to certain groups (Table 3).
Both AV-Signature-Based and AV-Behavior-Based policies quarantine applications. AV-Signature-Based policies quarantine files based on signatures. AV-Behavior-Based policies quarantine an application if the application's processes violate multiple policies. The application will be tagged as <Excessive. Behavior> and quarantined. The end user will be prompted to terminate the application and notified of excessive policy violations by default.
Change the query rules to "deny" in the rule module that applies to all end users (Table 3). The query rules can be left in place in the rule module that applies to groups allowed to terminate the application and receive queries.
Create associated policies for the rule modules and assign them to their respective groups.

Table 3. AV-Behavior-Based Desktop Policy and Rule Modules Applicable to Quarantine

Policy

Rule Module

Rule

Change (Pending Customer Policy)

AV-Behavior-Based

Security-Multiple Violations (Medium Restrictions)

Processes in two or more (or excessive) violation classes (not white list) occur in client email, TFTP, IRC, NETBIOS, and CIFs.

Change "query" to "deny" and log.

Processes in three or more (or excessive) violation classes (not white list) occur in client, server, TCP, and UDP.

 

Processes in three or more (or excessive) violation classes (not white list) invoke all applications (not
Dr Watson).

 

Security-Multiple Restrictions

All applications invoke <Suspected Virus Applications> and are untrusted (not white list).

Log all to Management Center for Cisco Security Agents.

Notify: All applications invoke <Suspected Virus Applications> and are untrusted (not white list).

Log all to Management Center for Cisco Security Agents, or customize notification, or disable.

Notify: Processes in two or more (or excessive) violation classes (not white list) occur in client, server, TCP, and UDP.

Log all to Management Center for Cisco Security Agents, or customize notification, or disable.

4.1.4 Prevent End Users from Disabling Cisco Security Agent Security-Allow Only Certain Groups

End users should not be able to disable Cisco Security Agent's security settings based on their corporate security policies. You can allow only certain groups to disable these settings.
Clone the Base-CSA Services UI Control rule module and add the appropriate user-state rules for groups that are allowed to disable Cisco Security Agent Security (Figure 1).
If you keep the default setting, the end user will be queried and the action will be logged to the Management Center for Cisco Security Agents. This setting can be changed to "allow" and "log."

Figure 1. Cloned Rule Module for Allowed Users Who Can Disable Security

Create the policy for the Microsoft Windows groups and users who are allowed to disable Cisco Security Agent's security settings.
The following screens illustrate the steps.

1. Set the user-state rule for allowed users. In this case, jeppich is the allowed user.

2. In the All Windows group, expand the "Base-CSA Service and client UI control" policy tab. The "Base-CSA client UI control" and Base-CSA service control" rule modules are globally applied to all the groups.

3. Select the "Base-CSA service control" rule module.

4. Change the action of the "All applications disable the agent security" rule to "deny."

5. Change the user state to include all end users, but not the groups allowed to disable Cisco Security Agent's security levels. Here, the user state includes all users, but not jeppich.

4.1.5 Prevent End Users from Selecting Cisco Security Agent Security Levels-Allow Only Certain Groups

End users should not be able to change security settings based on their corporate security policy. You can allow only certain groups to change these settings.
Clone the "Base-CSA client UI control" rule module and add the appropriate user-state rule to apply to all users who are allowed to select various Cisco Security Agent security levels (Figure 2).
You can keep the default settings, allowing the user to use the slide bar to change security levels.

Figure 2. Cloned Rule Module Allowing Appropriate Microsoft Windows Groups and Users to Adjust Cisco Security Agent's Security Levels

Create a policy for this group and assign the rule module to this group. The following screens show the steps.

1. Define the user-state rule, allowing jeppich to modify the security levels.

2. In the All Windows group, expand the "Base-CSA Service and Client UI control" policy tab.

The "CSA client UI control" and "CSA service control" rule modules globally affect all the groups.

3. Select the "Base-CSA client UI control" rule module and change the rule as shown in the following screen.

4. For the rule module, create a user state that is applicable to all end users, but not for allowable groups who can change security levels.

The user-state rule applies the rule to everyone except jeppich.

4.1.6 Deploy Stealth Mode

End users should not be able to see the agent UI based on corporate security policy, while certain groups will be allowed to see the agent UI.
Clone the "Base-CSA client UI control" rule module and add the appropriate user-state rule to apply it to all users who are allowed to see the agent UI (Figure 3).
Keep the default settings.

Figure 3. Cloned Rule Module Allowing Appropriate Windows Groups and Users for Non-Stealth Mode

Create a policy for this group and assign the rule module to this group. The following screens show the steps.

1. Define the user-state rule, allowing jeppich to operate in non-stealth mode.

2. In the All Windows group, expand the "Base-CSA Service and client UI control" policy tab.

The "Base-CSA client UI and Base-CSA service control" rule modules globally affect all the groups.

3. Uncheck all the settings and leave "Allow user to reset agent UI default settings" enabled.

4. Change the user state to make this rule applicable to everyone except those Microsoft Windows groups and users that are able to operate in non-stealth mode.

Note: The "Base-CSA client GUI and service control" rule module must be removed from the AV-Behavior-Based, AV-Signature-Based, and Anti-Spyware, Centrally Managed, and User-Managed Firewall Desktop policies.

4.2 Server Deployments

Follow these steps for server deployments:

1. Define your grouping structure by function (Organization_A_Web Servers, Organization_A_File Servers, etc.).

2. Define policies.

Use the following Cisco Security Agent host security server policies for generic server application-based deployments:

• AV-Behavior-Based Servers

– Anti-Rootkit

– Quarantined Compromised Applications

– Quarantined Compromised Hosts

– Audit System Integrity

• Cisco Security Agent host security server application-based policies

– Sample-Application Web Servers

If you have servers in the DMZ, such as web servers, you can apply your server-based application policies and apply the network rule module in a policy to lock down your application-based servers.

• Additional rule modules that ship with Cisco Security Agent 6.0 that you may find applicable

– Sample-Microsoft Failover Cluster

– Sample-File Integrity

– Sample-File Server

– Sample-Domain Controller

3. Create your groups based on server function: web servers, SQL servers, etc.

4. Assign your zero-day policies globally across all servers.

5. Assign your application-based server policies locally to the appropriate function-based server groups (for example, assign Sample-Web Server policies only to the Web Server group).

6. Change all query rules (default deny rules) to deny rules in the rule modules (Table 4).

7. Enable all notification rules to log to the Management Center for Cisco Security Agents, if used. You may decide not to use notification rules as part of your deployment.

Table 4. AV-Behavior-Based Servers Policy and Rule Modules that Have Query (Default Deny) Rules

Policy

Rule Module

Rule

Change

AV-Behavior-Based Servers

Security-Client Application Security

Web browser, peer-to-peer, and active Internet clients access system functions from a buffer.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Applications that read untrusted data document or multimedia applications access system functions from a buffer.

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Applications that experience a buffer overflow invoke all applications (not shells or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Document reader and multimedia applications invoke first-time execution of applications (not shells or configuration applications).

Change "query" to "deny."

Log to Management Center for Cisco Security Agents.

Security-Web and Email Clients Deny Running All Applications

Email, web, and instant messaging applications (not desktop) invoke all applications.

Log to Management Center for Cisco Security Agents (may have to have to change from high-priority deny rules to deny rules).

Notify: Email, web, and instant messaging applications (not desktop) invoke all applications.

Log to Management Center for Cisco Security Agents.

5 Tuning

5.1 White List

Applications on the white list are trusted and allowed to run; however, if they commit a severe violation, they are immediately restricted.
If a trusted application requires four or five exceptions when you use the wizard, you may want to assign this application to the white list. Applications on the white list are exempt from the Anti-Rootkit policy, as defined by the Security-Rootkits rule module.
Applications on the white list are still protected from network- and data-based attacks, as defined by the Security- Client Security rule module. This rule module belongs to the AV-Behavior-Based Desktop policy.
The administrator-defined white list contains applications such as Internet Explorer, instant messaging, and other applications that have been subjected to these types of attacks in the past and are now protected.

Note: Do not remove these applications from the administratively defined white list.

The @whitelist token is defined as any file on the global Application Trust Level page that is referred to the white list.
Applications placed on the white list may also conflict with high-priority deny rules that are defined in the Quarantined Applications rule module. This rule module belongs to the Quarantined Compromised Applications policy. You can create exceptions by adding the "Administrator defined-White List Applications" class to the "but not in any of the following" selected application classes.

5.1.1 Implementing a White List

Follow these steps to implement a white list:

1. Clone the "Administrator defined-White List Applications" class.

2. Use the cloned white list to add changes directly.

Note: The applications added here are independent of the applications defined in the application trust levels, which are defined by the @whitelist token.

3. From the Management Center for Cisco Security Agents, choose Search > Application Classes > Replace.

4. Replace all references to the administratively defined white list with references to your cloned white list.

5. Click OK.

You should see the following screen.

5.2 Grey List

Applications on the grey list can be considered malicious. These applications will still trigger rules enforced by the AV-Behavior-Based policy. Applications placed on the grey list will be denied incoming server connections as defined by the "Untrusted applications (not white list), server for TCP and UDP services" rule. This rule is contained in the Security-Distributed Firewall-All Networks rule module. This rule module is assigned to the Centrally Managed Firewall Desktop policy.
Applications can also be added directly to the "Administrator defined-grey List Applications" class. The @grey list token is defined as any file on the global Applications Trust Level page that is referred to the grey list.

5.2.1 Implementing a Grey List

Follow these steps to implement a grey list:

1. Clone the "Administrator defined-Grey List Applications" class.

2. Use the cloned grey list to add changes directly.

Note: These applications are independent of the applications defined in the application trust levels, which are defined by the @greylist token.

3. From the Management Center for Cisco Security Agents, choose Search > Application Classes > Replace > "Administrator defined-Grey List Applications" with your cloned application grey list.

4. Click OK and then generate the rules twice.

5.3 Black List

Applications on the black list are considered malicious and can be non-recommended applications within the organization. These applications will not be allowed to invoke other applications, all inbound and outbound processes will be denied, and processes running will be terminated.
You can also add these applications directly to the "Administrator defined-Black List Applications" class.
The rule module assigned to prevent black-listed applications from accessing system resources is the Security-Black List Lockdown module. This rule module is assigned to the AV-Behavior-Based Desktop policy and Quarantined Compromised Applications policy.
The @blacklist token is defined as any file on the global Application Trust Level page that is referred to the black list.

5.3.1 Implementing a Black List

Follow these steps to implement a black list:

1. Clone the "Administratively defined-Black List Applications class.

2. Use the cloned black list to add changes directly.

Note: These applications are independent of the applications defined in the application trust levels, which are defined by the @blacklist token.

3. From the Management Center for Cisco Security Agents, choose Search > Application Classes > Replace > "Administrator defined-Black List Applications" with your cloned application black list.

4. Click OK and generate the rules twice.

5.4 Using the Wizard

You can use the wizard to tune system API rules; query, deny, terminate process, and set rules; and place these exceptions in the Configuration > Exceptions view of the Management Center for Cisco Security Agents. Modifications can be made only through this view.
Use of the wizard adds an Exceptions rule module to the associated policy that contains the exception (Figure 4).

Figure 4. Exceptions Rule Module

Here are some best practices and tips:

• Make exceptions on a daily basis. Clone the associated rule module and make edits directly to the rule module.

• Create a policy called Exceptions and assign the cloned rule module to this policy.

• Depending on the exceptions, Exceptions may constitute a policy that can be applied globally.

• In the event that you receive too many monitor rules, determine whether these policies are warranted; you may want to create exceptions, such as allow rules.

• You can also suppress these rules and purge all the events associated with a rule. The Audit Security policy will generate monitor alerts, checking for first-time executables and monitoring suspicious behavior.

• When creating exceptions, you can use \**\ to replace literals in file sets. For example, instead of \documents and settings\Administrator\local settings, use \documents and settings \**\local settings. The \**\ wildcard means any characters enclosed in quotation marks.

• Use @windows, @system, and other tokens when possible.

5.5 Creating Exceptions for Symantec Rootkits

You can use the white list to create exceptions for rootkits. You can also use the wizard to create exceptions.
Antivirus solutions such as those from Symantec and Trend tend to violate the Anti-Rootkit host security policy, and if the Quarantined Compromised Hosts policy is assigned, the host will be isolated from the rest of the network.
Reset the Cisco Security Agent to allow the host to communicate with the network. You can perform this task locally by choosing Programs > Cisco > Cisco Security Agents > Reset. You can also perform this task remotely from the Management Center for Cisco Security Agents by choosing Systems, selecting the desired host, choosing Hosts > Reset, and then selecting System State (Figure 5).

Figure 5. Resetting Cisco Security Agent to Allow Host to Communicate with Network

The following example steps through the process of creating exceptions for Symantec.
Symantec rules are displayed in the Management Center for Cisco Security Agents.
The Anti-Rootkit policy works in conjunction with the Quarantine Compromised Hosts (QCH) policy. When a rootkit is detected and set as untrusted, the QCH policy will isolate that system from the rest of the network.
You can use the wizard as shown here.
Click Finish to create the exception and set the rootkit attribute value to "unchanged."
If you see repeated events, you can go back into the event and include * in the hashes.
After the exception is created, you will no longer see the associated monitor rules.

5.6 Creating Exceptions Using the Pilot Tuning for Desktops Rule Module

Clone this rule module.
Create an Exceptions policy and assign the rule module to this policy.
You can initially apply this policy globally to the groups.
Depending on the rule exceptions, this policy may constitute an application-based policy or a named policy.
Editing these rules directly will be quicker than using the wizard.

5.7 Creating Exceptions Using the Pilot Tuning for Servers Rule Module

Clone this rule module.
Create an Exceptions policy and assign the rule module to this policy.
You can initially apply this policy globally to the groups.
Depending on the rule exceptions, this policy may constitute an application-based policy or a named policy.
Editing these rules directly will be quicker than using the wizard.

5.8 Creating Exceptions Using the Sample-Backup and Inventory Rule Module

Clone this rule module, create a policy named Backup Inventory, and assign this policy to your groups globally.
This rule module provides Short Message Service (SMS) and other software distribution access to system resources (Figure 6).

Figure 6. Creating an Exception to Allow Access to System Resources

5.9 Creating Exceptions Manually

Create a rule module manually and assign a policy; then assign to your groups, locally or globally.

6 Policies

This section discusses Cisco Security Agent 6.0 zero-day policy design.
Unknown applications or untrusted code will fall into unique dynamic applications classes (Figure 7) as defined by their associated security rule modules contained in the AV-Behavior-Based Desktop policy:

Security-Policy Violation-Access or Modify System Configuration: Detect and control applications that access or modify the system configuration.

Security-Policy Violation-Access or Modify System Security: Detect and control applications that access or modify system security.

Security-Policy Violation-Buffer Overflow: Detect and control applications that may have experienced a buffer overflow.

Security-Policy Violation-Modify Another Process: Detect and control applications that modify another process.

Security-Policy Violation-Monitor User Input: Detect applications that monitor user input.

Security-Policy Violation-Network Worm Client: Detect and control applications that may be network worm clients.

Security-Policy Violation-Network Worm Protocols: Detect and control applications that access suspect network protocols.

Security-Policy Violation-Starting a Network Configuration Application: Detect and control applications that invoke network configuration applications.

Security-Policy Violation-Starting a System Configuration Application: Detect and control applications that invoke command shell or system configuration applications.

The unknown application's behavior may be prevented based on the rules contained in the associated rule module. If the application's process falls into two or more of the dynamic policy violation application classes, the application will be tagged as <Virus: Excessive. Behavior>. This application will be added to the built-in <Suspected Virus> application class, terminated, and quarantined as defined by the following rule modules:

Security-Multiple Violations (Medium Security): Restrict processes with multiple policy violations when the security level is set to Medium.

Security-Multiple Violations: Restrict processes with multiple policy violations as well as black-listed applications.

Security-Quarantined Applications: Quarantine applications.

After a file is quarantined, the Security-Quarantined Applications policy will prevent the file from being accessed by the system. Both Security-Multiple Violation rule modules belong to the AV-Behavior-Based Desktop policy. The Security-Quarantined Applications rule module belongs to the Quarantined Applications policy.
After the file is quarantined, it will be displayed by the local user interface agent under Quarantine Files. The file can be deleted or restored. If no action is taken, the file will be automatically deleted after 60 days.

Figure 7. Dynamic Application Classes

7 Deployment Tips

Use these tips when deploying Cisco Security Agent:

• Enable the Admin view by default to view and edit read-only objects.

– Login into the Management Center for Cisco Security Agents and choose Maintenance > Administrators > Account Management > admin and enable all settings under Advanced Mode.

• Enable logging of rules to the Management Center for Cisco Security Agents, to tune the policies. By default, certain rules in the rule modules are not logged to the Management Center for Cisco Security Agents.

– You still can view these events centrally from the Cisco Security Agent Management Console. Perform a search on rule ID for the local rule. This search will take you to the rule within the policy.

– You can obtain the Rule ID locally, from the Event Type tab on the Cisco Security Agent user interface. The rule ID appears in brackets (for example, [1702]).

– Do not enable logging for set and dynamic application rules or in the Untrusted Content Classification rule module.

The following example shows an event, with rule ID 1702.
Search from the Management Center for Cisco Security Agents based on rule ID 1702.
The search returns the event.
Rule 1702 belongs to the Management Center for Cisco Security Agents (CSA MC) Application Security rule module.

8 Integrated ClamAV

The signature-based antivirus function protects the endpoint by identifying infected files. After files are identified, Cisco Security Agent tags these files as infected and then the AV-Signature-Based policy quarantines these files. After these files are quarantined, they can be deleted manually, or restored. Quarantined files remain in quarantine for 60 days and then are deleted automatically if no action is taken.
Integrated ClamAV is supported on Microsoft Windows platforms only.

Note: Cisco Security Agent installs a signature database on the host. This database is used in identifying infected files. If other antivirus applications are installed on the host, they likely will interpret these signature database files as infected and quarantine them. To avoid conflicts, it is strongly recommended that users uninstall other antivirus applications when using the Cisco Security Agent antivirus feature.

8.1 How Signatures Are Updated

For signature-based antivirus protection, the Management Center for Cisco Security Agents maintains a cached version of the ClamAV signature files and acts as a proxy server when a signature update is requested by an agent.
Agent requests for signature file updates prompt the Management Center for Cisco Security Agents to obtain and provide virus definitions. When agents request updated virus signature files from the Management Center for Cisco Security Agents, the management center compares the time stamp of the signature files on the ClamAV server with its cached version of the file. If the time stamp of the files on the ClamAV server matches the copy of the signature files cached on the Management Center for Cisco Security Agents, the management center provides the agent with the signature updates from its own cache. If the Management Center for Cisco Security Agents' cached version is out of date, the management center passes the agent's request directly to the ClamAV server and then caches the new version of the signature files when they are returned.

Note: For the Management Center for Cisco Security Agents to obtain signature updates from ClamAV server (db.local.clamav.net), the server should be reachable over HTTP either directly or through a proxy server. You can configure this server through the Management Center for Cisco Security Agents homepage; you can also change the proxy settings.

Configure an HTTP proxy server from the Management Center for Cisco Security Agents homepage (Figure 8).

Figure 8. Configuring an HTTP Proxy Server from the Management Center for Cisco Security Agents Homepage

The virus signature database on the Management Center for Cisco Security Agents includes two files:

Main signature file (main.cvd): This is the main signature file that is stored on the Management Center for Cisco Security Agents and downloaded to every agent. This file is updated with every new release of ClamAV.

Daily updates file (daily.cvd): This is the database of updated signatures. It is stored on the Management Center for Cisco Security Agents and downloaded to every agent. This file is updated several times a day and stores the latest virus definitions.

On the Management Center for Cisco Security Agents, the virus signature database files are stored here:

• Program Files\Cisco\CSA MC\CSAMC60\bin\WebServer\htdocs\clamav

On the agent, the virus signature database files are stored here:

• \Program Files\Cisco\CSAgent\dclass\csa-av

An agent contacts the Management Center for Cisco Security Agents for signature updates as a result of these events:

Scheduled request for antivirus updates: An agent contacts the Management Center for Cisco Security Agents every 24 to 25 hours for updated virus definitions.

Forced antivirus updates from a host: Users can force an antivirus update from the AntiVirus screen of the Cisco Security Agent interface.

Forced antivirus update for a group: Management Center for Cisco Security Agents administrators can force an antivirus update for a group from the group's properties page.

If the Cisco Security Agent is a standalone system, or if the agent cannot reach the Management Center for Cisco Security Agents for two days, the agent will try to communicate directly with the Internet server, http://db.local.clamav.net, to get signature updates directly from ClamAV.

8.2 Signature-Based Scanning for Viruses

For signature-based antivirus protection, the goal of virus scanning is to determine whether a file is infected or clean. Infected files are tagged with the name of the virus that infects them. Clean files receive an empty tag. After the files are tagged, rules in the antivirus policy protect the host from the infected files. (See Section 8.3, "Antivirus Tagging," for more information).
Cisco Security Agent scans for viruses using these methods:

• Background scan

• Scan of files when accessed

• On-demand scan

Note: These scans do not change a file's modification date.

8.2.1 Background Scan

Administrators can schedule weekly or monthly background scans of all hosts that use the default AV-Signature-Based server or desktop policy provided with this Cisco Security Agent Release 6.0. These policies contain rules that specify which files are scanned during a background scan. By default, files on fixed local drives are scanned during an antivirus background scan (Figure 9).
Background scans happen slowly, at a controlled pace, so they do not to affect the user experience.

Figure 9. Background Scan

8.2.2 On-Access Scan

Scanning for infected files occurs when files are opened. Scan-on-open triggers a scan on the file before it can be used in any way. The application opening the file to be scanned is held until the scan completes, so applications could be locked until Cisco Security Agent has finished scanning the file.
The Security-ClamAV-Classification Module (on Open) rule module controls how files are scanned when opened:

• Antivirus background scans read or write all files on fixed drives.

• All applications read or write untrusted files and file scan in progress.

• CMD, NTVDM, RUNDLL, or NON-MS schist read or write untrusted directories.

• All applications read or write untrusted directories and file scan in progress.

• All applications invoke untrusted applications.

• All applications invoke first-time application execution.

• CMD, NTVDM, RUNDLL, or NON-MS svchost read or write untrusted files.

Scanning for infected files also occurs when the file is modified and closed for writing. Scan-on-close triggers a scan on the file after the file has been closed by the application. The typical targets of virus infections are files that are written to disk through the browser or other network applications. The application closing the file is not held until the scan completes.
The Security-ClamAV-Classification Module (on Close) rule module controls how files are scanned when closed:

• Applications reading an untrusted file write files on fixed drive.

• Active network applications or email clients write all files on fixed hard drives.

• Untrusted applications (not white list) write all files on fixed hard drives.

• First-time application executable writes all files on fixed drives.

• Remote clients write all files on fixed drives.

• All applications write all virus files.

Note: Files over 3 MB in size are scanned slowly and separately from other accessed files. This behavior allows the scanner to keep up with on-access scan requests.

The Security-ClamAV-Security Module controls the quarantining of infected files, helping ensure that these files are isolated from the rest of the system.

• Under no circumstances should all applications (not desktop) read or write all files matching malware virus signatures.

• Under no circumstances should all applications (desktop) read or write all files matching malware signatures (not in recycle bin).

• Under no circumstances should all applications invoke applications matching malware virus signatures.

• If a module loads after startup, file content matching malware virus signatures is denied.

• After all applications have been scanned and the virus scan matches a malware virus signature, end users will be notified, and the notification event is logged to the Management Center for Cisco Security Agents.

• End users are also notified when desktop shell applications read or write all files matching malware virus signatures. This notification is not logged back to the Management Center for Cisco Security Agents.

• All applications that invoke applications matching potentially unwanted application virus signatures are monitored.

• If a module loads after system startup, file content matching all virus signatures is monitored.

• Any application that reads a file classified as a virus during system startup is monitored.

8.2.3 On-Demand Scan

If a host is protected by AV-Signature-Based policy for desktops or servers, the AntiVirus pane will be visible to the user in the agent user interface. Users start on-demand scans from that screen.
An on-demand scan examines all files on fixed local drives, including archive files such as .zip files and mail files, such as .pst files. On-demand scans do not scan files based on rules in a policy.
Open the AntiVirus screen of the agent interface to perform an on-demand scan. Users can view the procedure in the agent user interface help by clicking the AntiVirus task and clicking the help icon associated with that screen.

8.3 Antivirus Tagging

Content files receive antivirus tags when virus signatures are found in them. Applications receive antivirus tags when they take some action that is considered suspicious, dangerous, or malicious.

8.3.1 Signature-Based Antivirus Tagging

After a file is scanned, it acquires a tag. After a file has been tagged, rules protect the host from the file based on the file's tag. If a file is infected, it is tagged with the name of the virus that infects it. For example, if a file has been scanned and it is infected with the CodeRed worm, it is tagged <Virus:Worm.CodeRed>. If a file has been scanned and it is not infected, the file receives an empty tag: " ".
If a file has not yet been scanned, it has no tag. While a file is being scanned, it gets a temporary tag: <CSA_SCAN_IN_PROGRESS>. If a file cannot be scanned, it is tagged <CSA_UNSCANNABLE>. An encrypted file is an example of an unscannable file.
There is also a <CSA_SCAN_NOT_ATTEMPTED> tag. Files could receive this tag if the file scanner is not ready to scan a file or if the file scanner does not have permission to open a file, for example. If a file is tagged with <CSA_SCAN_NOT_ATTEMPTED>, the file scanner will make additional attempts to scan the file. A file has the <CSA_SCAN_NOT_ATTEMPTED> tag only during the scanning transaction. After the attempted scan, the <CSA_SCAN_NOT_ATTEMPTED> tag is removed from the file.
When Cisco Security Agent scans files, the file scanner checks to see whether a file has an existing tag. If the file has an existing tag and if the file has not been modified since the previous scan, the existing tag is still considered valid, and the file is not rescanned.
Clean files-those with empty tags-lose their tags when the file scanner is shut down. This would happen, for example, if the host is rebooted. After a file loses its clean tag, it will be subject to scanning again in the future.
If a file is found to have a virus, it will be listed on the "Quarantined files" tab of the AntiVirus screen in the agent user interface. Users then have the option of restoring their access to quarantined files.

8.4 Quarantined Files

Files and applications are quarantined if they receive a signature-based or behavior-based antivirus tag. Quarantined files remain in place and are rendered inert by the rules that govern quarantined files; they are not moved to a special directory.
Users see quarantined files on the "Quarantined files" tab of the AntiVirus screen of the agent's user interface. Through that interface, users can remove files from the quarantine list by restoring them, and users can requarantine a file that they restored. Users can also delete quarantined files.
Quarantined files are automatically deleted from the user's system after 60 days, with the following conditions:

• Automatic deletion applies only to files found to have a signature-based virus.

• Files found to have behavior-based viruses will not be automatically deleted; they remain in the quarantine state.

• Applications identified as potentially unwanted applications (PUAs) are not automatically deleted; they remain in the quarantine state. These applications are not malicious by themselves but can be used in a malicious or unwanted context. See http://www.clamav.org/support/faq/ for more information about applications labeled PUA.

• The file is not used by another user or application for 60 days.

• The file's status remains in quarantine for 60 days. For example, if a file is quarantined, restored, and then moved back to quarantine, the 60-day timer is reset when the file returns to the quarantined state.

After a quarantined file is deleted, an event is sent to the Management Center for Cisco Security Agents.
Warning: Because quarantined files are restrained by antivirus rules, if security on the agent is turned off, the infected files become uncontrolled. They can be read, modified, or executed.
Caution: If the agent is reset, all files in the "Quarantined files" and "Restored files" lists are removed.
ClamAV is integrated with Cisco Security Agent and is enabled by assigning the AV-Signature-Based policy to a host's group.
You can set scheduled background scans from the Host Scanning Tasks menu. Background scans can be scheduled once a month. This operation is designed to take into account whatever processes are available at the time of scanning.

8.5 Creating Antivirus Exemptions

Antivirus exemptions can be created in the following ways:

• Use the Event Wizard to remove files containing false positives from quarantine.

Click Finish to complete the process. The exceptions appear in the AntiVirus Exemptions view.

• Use the AntiVirus Exemptions view. The filename and virus name are required. These will appear in AntiVirus Exemptions view in the Management Center for Cisco Security Agents event log and the local antivirus quarantine screen.

• Use the associated ClamAV file sets. (You will clone these file sets as part of the Cisco Security Agent deployment.)

– File Content-Virus-All signatures: File classified by ClamAV as matching a malware or PUA signature

– File Content-Virus-Malware signatures: File classified by ClamAV as matching a malware signature

– File Content-Virus-Malware signatures (not in Recycle Bin): File classified by ClamAV as matching a malware signature

– File Content-Virus-Potentially unwanted applications: File classified by ClamAV as matching a PUA signature

When ClamAV detects an infected file, as the file is a false positive regardless if it is PUA, add the filename to the "File Content-Virus-All signatures" and "File Content-Virus-Malware signatures (not in Recycle Bin) file sets.
False PUA filenames can be entered directly in the "File Content-Virus-Potentially unwanted application" file set.

• Applications can be excluded from scanning.

Create file access control rules by selecting Set and Virus Scan on Open and specifying "Not Required" for the application when accessing certain files or all files.
Create another file access control list (FACL) by selecting Set and Virus Scan on Close and specifying "Not Required" for the same application.
Use the c:\program files\cisco\csagent\dclass\dclog.txt log file to view the files that are accessible by the excluded application. If the delay time for the scanned file is greater than a few seconds, you can create a file set for this detail.

Note: If you create exceptions directly using file sets and legitimate files are still being quarantined, you can exclude the applications from scanning.

8.6 Deploying the Integrated Cisco Security Agent Antivirus Feature

1. Clone AV-Signature-Based policy, rule modules, and common virus file sets used.

Clone the rule modules under the AV-Signature-Based policy.

Give each the name of the organization and rule module: for example, give the name Security - ClamAV - Classification Module (on Open) to ACME - Security - ClamAV - Class Module (on Open).

Create the organization antivirus policy: for example, ACME - AV-Signature-Based policy).

Assign the associated rule modules to this policy and then assign the policy to the group.

Clone the following file sets:

• File Content-Virus-All signatures

• File Content-Virus-Malware signatures

• File Content-Virus-Malware signatures (not in Recycle Bin)

• File Content-Virus-Potentially unwanted applications

Assign these variables to the associated rules in the cloned Security-ClamAV Security module.

Assign the "File Content-Virus-All signatures" file set to the associated rules in the cloned Security-ClamAV Classification <on Close> rule module.

2. Assign the organization antivirus policy to the group.

3. Configure an HTTP proxy on the Management Center for Cisco Security Agents.

Configure an HTTP proxy server on the Management Center for Cisco Security Agents to forward the antivirus requests to the ClamAV mirror site.

4. Schedule antivirus background scans.

Configure the antivirus background scan by choosing Systems > Host Tasks > Host Scanning. This scan can also be configured and disabled at the group level.

5. Tune antivirus exceptions (PUA, etc.).

Add exceptions for PUAs for remote management applications such as Cisco Virtual Network Computing (VNC). Use the cloned file set variable "$File Content-Virus-Potentially unwanted applications" to add the application.

If an application is hanging during the scan, create an application class to be used in the File Access Control rule; select Set and Virus Scan (on Open) and specify "Not Required" when the application reads or writes to all files. You can also make this exception specific to files.

Use c:\program files\cisco\csagent\dclass\dclog.txt file to view the delay time for the file in question. If the delay time is noticeable, create a file set an add this detail to the FACL rule created to exempt applications from scanning.

9 Data Loss Prevention

Data on network endpoints is increasingly subject to internal policies and external regulations concerning proprietary and confidential information. The process of data classification assists network data security by helping track the existence of sensitive data, its location in the enterprise, how that data is being accessed, and how it must be protected to meet legal and regulatory requirements.
Cisco Security Agent's new data loss prevention (DLP) feature includes these capabilities:

• Classification and tagging of a file based on the result of a content scan or the file's location on the host system (scanning tags)

• Classification and tagging of a file based on what applications attempt to read it or write to it (static tags)

• User notification when users are working with content that is considered sensitive; raising awareness of the presence of sensitive data will help prevent accidental data loss (notifications and justifications).

The DLP feature enables Cisco Security Agent to tag files based on file content, including specific characters or phrases. Cisco Security Agent also provides optimized pattern matching for credit card numbers and social security numbers, which are especially sensitive and subject to government regulatory control.
Identification of sensitive data and control over sensitive data can be customized in the Management Center for Cisco Security Agents to assist in the implementation of DLP controls for use of data in compliance with your organization's policies.

9.1 Scanning Data Tags and Static Data Tags

Two types of data tags are used: scanning data tags and static data tags.
Scanning data tags can be assigned to files based on the file's contents, such as credit card numbers, social security numbers, and text-matching patterns.
Static data tags can be assigned to a file based on the applications that use that file, for files with contents that you know contains sensitive data. For example, you may have critical applications and certain files containing sensitive information. You can classify and tag this sensitive information as containing proprietary information. This approach is handy for critical server-based applications that contain sensitive information for which no scanning is required.

9.2 Scanning Data Tags

A scanning data tag is assigned to a file if Cisco Security Agent has scanned the contents of the file and matched the pattern and number of occurrences found in the file as defined by the Management Center for Cisco Security Agents Configuration > Global Settings > Data Classification view.
Scanning data tags can represent any string of characters. (See Section 9.3, "Text-Matching Search Patterns," for more information.)
The built-in scanning data tags are defined by preconfigured patterns that are used to find social security numbers and credit card numbers. Cisco Security Agent uses a special number-scanning algorithm to identify these numbers in files while, at the same time, differentiating them from other large numbers. For example, Cisco Security Agent can, with a high degree of accuracy, distinguish between a file containing nine-digit part numbers and a file containing social security numbers.
If more than one type of pattern is found in a file, the file is tagged with more than one scanning tag.
After a file has received a scanning data tag, Cisco Security Agent's DLP policy rule modules and rules govern the ways that users are allowed to interact with that file. Users are notified if they are found to be noncompliant according to their corporate data security policy. Users can also provide business justification reasons for being noncompliant. Making users aware of the kinds of files they access helps prevent accidental data loss.
Cisco Security Agent provides these built-in data scanning tags by default:

<credit_card>: The <credit_card> tag uses @credit_card, which is a number-scanning search pattern built into Cisco Security Agent. The @credit_card search pattern is optimized to identify patterns of valid credit card numbers used by major credit card issuers (Figure 10).

<Proprietary Information>: The <Proprietary Information> tag is assigned to a file if Cisco Security Agent matches the exact phrase "Company Confidential" or "Internal Use Only" a certain number of times, in a scanned file. However, before files can be tagged with the <Proprietary Information> tag, your Cisco Security Agent administrator needs to edit the pattern to make sure it is appropriate for your enterprise and then enable the tag.

• <SSN>: The <SSN> tag uses @ssn, which is a number-scanning search pattern built into Cisco Security Agent. The @ssn search pattern is optimized to identify patterns of valid social security numbers issued by the United States federal government. An <SSN> tag is assigned to scanned data if Cisco Security Agent finds valid social security numbers in the data.

<Regulatory Controlled>: The <Regulatory Controlled> tag is assigned to files in which the @credit_card or @ssn pattern is found. A <Regulatory Controlled> tag is assigned to scanned data if Cisco Security Agent finds valid credit card numbers or social security numbers in the data.

Figure 10. Using the <credit_card> Tag

9.2.1 Text-Matching Search Patterns

Text-matching patterns can contain any strings of characters or numbers specified by the administrator.

Note: In general, long text-matching patterns usually are more effective than short patterns. Searching for long text-matching patterns prevents Cisco Security Agent from assigning content tags to files that you did not expect or intend to match. For example, if you search for the pattern "Company confidential. For internal use only," Cisco Security Agent is more likely to find and tag files that are truly confidential than if your pattern is only the word "confidential."

These are the syntax requirements for character-matching search patterns:

• Cisco Security Agent's string searches support English and languages other than English whose character sets can be represented by 2-byte UNICODE text encoding. (Currently, this requirement excludes Asian and Semitic languages.) It also support accented Latin, Greek, and Cyrillic characters, as long as each letter and its accents are included in a single 2-byte character.

Note: To match strings with accented characters, the string must be entered twice using both the combined encoding and the precomposed encoding UNICODE formats.

• Text-matching patterns are not case sensitive. For example, the pattern "cisco" will match "Cisco" and "cisco".

• A text-matching pattern can be no more than 256 characters long including wildcards. For example, the pattern "confidential*" is 13 characters long.

• The smallest text-matching pattern you can search for, not including wildcards, is two characters long.

• A text-matching pattern, by default, can match only a whole word or phrase, and not part of a word. Therefore, a pattern such as "confidential" will not match the word "nonconfidential" in a file.

• Wildcards, represented by the * character, can be used to match prefixes and suffixes of a word as well as character strings in between other strings. Here are some other examples:

– The pattern "*confidential" matches "nonconfidential".

– The pattern "confidential*" matches "confidentiality".

– The pattern "*confidential*" matches "nonconfidentiality".

– The pattern "confidential" does not match "nonconfidential", "confidentiality", or "nonconfidentiality".

• If multiple words are specified and they are included on the same line in the Patterns field, they must appear in the same order in the target file to be considered a match. If words are entered on separate lines, the presence in the file of any of the lines in the Patterns field, in any order, is considered a match.

• A wildcard can be used in the middle of a string with more than one word. In this case, the wildcard breaks the pattern into three parts: the string before the wildcard, the wildcard, and the string after the wildcard.

• Cisco Security Agent will match the pattern "Cisco*confidential" to a string that begins with "Cisco", ends with "confidential", and has no more than 50 characters in between "Cisco" and "confidential". For example, "Cisco*confidential" will match "Cisco Security Agent-Company Confidential" because "Security Agent-Company " is only 26 characters long.

• Numeric strings are matched like alphabetic strings. The whole string in the Patterns field must be matched exactly in the file to record a match. If a line in the Patterns field contains more than one number, that entire string must be present in the target file to make a match. Wildcards can be used to match longer strings of numbers.

• Though wildcards can be used to match strings of numbers, if you use wildcards, you may end up matching other alphanumeric strings that you did not expect or intend to match with your string. Entering exact strings of numbers in the Patterns field will produce the most accurate results. These are examples of using wildcards with numbers:

– The pattern 9785551234 will match only 9785551234.

– The pattern 5551234 will not match 9785551234.

– The pattern *5551234 will match PART5551234.

– The pattern *8555123* will match 1234978555123ABCD.

– The pattern 978* will match 9785551234 as well as many other alphanumeric string that you may not have intended to match.

9.2.2 Performing an On-Demand DLP Scan

An on-demand DLP scan searches fixed drives on the host for files with data scanning tags. For an on-demand DLP scan to work, you need to have the DLP feature enabled. On-demand scans do not change a file's modification date.

• Log on to the Management Center for Cisco Security Agents as a user with configure or deploy privileges and switch to Advanced mode.

• From the Systems menu, choose Hosts.

• Click the link for the host on which you want to start an immediate scan.

• At the end of the DL full-scan schedule row, click View DL Scan Results.

• In the Scanning dialog box, click DL Scan Results if the tab is not open already.

• Click Scan Now.

A polling hint is sent to the host. After the host receives the polling hint, the on-demand scan begins automatically. If the host does not receive the polling hint, the scan will begin the next time the host polls.

• While the scan is in progress, you can click Get Results to receive the information gathered so far. After you click Get Results, the agent on the host will forward the information it has collected the next time the agent polls.

When the on-demand scan is complete, the agent automatically sends the results to the Management Center for Cisco Security Agents.
The DL Scan Results page periodically refreshes the information it has. Upon refresh, the latest information forwarded from the agent is displayed on the page.

9.2.3 Performing a Background DLP Scan

You can configure background DLP scans from the Cisco Security Agent Management Console by choosing Systems > Host Tasks > Host Scanning Tasks. Background scans be scheduled to run on weekly or monthly at a specified time of day (Figure 11).

Figure 11. Scheduling a Background DLP Scan

9.3 Static Data Tags

You can assign a static data tag to a file if a particular application accesses the file. You define the rules based on the organization's data security policy.
Static data tagging can be useful if, for example, you have a specialized application. Perhaps your enterprise is a hospital and you know in advance that any file that your specialized application reads falls under HIPAA guidelines. There is a <HIPAA Controlled> static data tag that you can apply to the file.
This type of tagging method can also be useful when a file type cannot be scanned for a text-matching pattern, as in the case of an audio file or graphics file.
You can check whether static tags have been defined and are in use by the Cisco Security Agent's DLP policy (Figure 12).

Figure 12. Checking for Static Tags

9.3.1 Using Static Tags

The example discussed here refers to the CSA Static Applications 127 rule module, which was manually created.
Excel is defined as a critical business application, and the sensitive information is defined as john.xls as contained in the $Static DLP Sensitive Information variable. When Excel opens and modifies the file and closes the file, this instance will be classified and tagged as containing <Sarbanes Oxley Content>. The enforced rules in the associated rule modules will refer to this data as containing <Sarbanes Oxley Content>.
A FACL rule is used to assign to the data classification tag <Sarbanes Oxley Content>, using the Set Data Classification attribute.
The corporate data security policy states that under no circumstances should Sarbanes-Oxley information be read from or copied to network shares. This FACL rule specifies this objective and is interpreted as to mean that under no circumstances should applications reading Sarbanes-Oxley information be allowed to read from or write to network shares.
The variable $Unauthorized Network Shares contains the tag <Sarbanes Oxley Content>.
A user not in compliance receives a notification. This notification is triggered by the high-priority deny rule.
Figure 13 shows the CSA Static Applications 127 rule module, where the static tags are defined.

Figure 13. CSA Static Applications 127 Rule Module

Figure 14 shows the rule module in which sensitive information is not allowed to write to network shares as defined by the rule module.

Figure 14. Rule Module in Which Sensitive Information Is Not Allowed to Write to Network Shares

9.4 Default Cisco Security Agent Policy

The default DLP Cisco Security Agent policy contains the associated rule modules, with descriptions of the rule modules (Figure 15).

Figure 15. Default DLP Cisco Security Agent Policy Rule Modules

Security-Data Loss-Classification Module on <Open> controls background DLP scans (Figure 16).

Figure 16. Security-Data Loss-Classification Module on <Open>

Security-Data Loss-Classification Module on <Close> controls scans when files are modified and closed for written access (Figure 17). Files are scanned in this manner when:

• Any application writes to a tagged file

• Email, web, and instant messaging applications write to their normal format

• Applications that read tagged files, shares, USB, CD, editors, Microsoft Office, Adobe Acrobat, Winzip, and remote clients write to any file, except email, web pages, database files, and executables

Figure 17. Security-Data Loss-Classification Module on <Close>

Security-Data Loss-Classification Module (process) classifies applications and data files to populate the application classes relevant to data loss:

• Applications reading from removable media

• Applications reading from network drives

• Applications reading regulatory data, reading proprietary data, reading a tagged file, accessing tagged files, and accessing sensitive clipboard contents

Security-Data Loss-Data in Motion prevents unauthorized network transfers of sensitive information when regulatory or proprietary data is present. The following rules are enforced by this rule module (Figure 18):

• Deny all applications for client-server processes for TCP/IP services over impromptu wireless.

• Deny all applications (except email, Microsoft Windows core applications, applications launching, and Cisco applications) for clients for TCP and UDP with external addresses.

• Deny instant messaging and P2P applications for client-server processes for TCP and UDP with external addresses.

• Deny remote clients reading from and writing to regulatory information.

• Deny all applications; write all files to network shares.

Figure 18. Security-Data Loss-Data in Motion

Security-Data Loss-Prevent Leakage prevents and monitors common methods of data leakage when regulatory or proprietary data is present (Figure 19). The following rules are enforced by this rule module:

• Deny instant messaging and P2P applications access to sensitive information; this restriction includes network access and clipboard access.

• Monitor information being transmitted to CD burners and USB devices, printers and spool queues, external IP addresses, and network shares.

• Set quality of service (QoS) for high-priority bits for network applications that read sensitive information.

Figure 19. Security-Data Loss-Prevent Leakage

Security-Data Loss-Prevent Leakage by User provides user notifications to users who are noncompliant with corporate data security policies when regulatory or proprietary data is present (Figure 20).

Figure 20. Security-Data Loss-Prevent Leakage by User

Security-Data Loss-Prevent Theft prevents malicious access to sensitive information from untrusted applications, remote access, and network applications when regulatory or proprietary data is present (Figure 21). The following rules are enforced by this rule module:

• Deny untrusted applications (not white list or email) for client-server processes for TCP and UDP with external addresses.

• Deny untrusted applications (not white list or email) reading and writing regulatory or proprietary data and dump files.

• Deny active network applications experiencing a buffer overflow (not launching) and reading and writing regulatory or proprietary data.

• Notify users when untrusted applications (not white list or email) client-server for TCP and UDP with external addresses.

Figure 21. Security-Data Loss-Prevent Theft

9.5 Deploying DLP

Decide whether you are using scanning or static tags, or both, for defining and classifying sensitive information.

• Scanning tags require a separate Cisco Security Agent DLP license based on the number of desktops and can be used on Windows desktops only.

• Static tags can be used on both desktops and servers.

• Additional rules can be added to protect sensitive applications and data locally.

• Static tags can be directly defined and classified in the rule module.

If you decide to use the Cisco Security Agent DLP policy:

• Clone the rule modules from the default policies.

Note: If you are using static tags, do not clone the Security-Data Loss-Classification Module (on Open) or Security-Data-Loss-Classification Module (on Close) policies

• Create new DLP policy and assign the cloned rules modules to this DLP policy.

• Clone or create the scanning tags; leave the pattern count at 30 if you are using scanning tags.

• Clone or create the associated file sets and assign your tagged data.

Create content file sets for the cloned regulatory and proprietary tags to refer to:

– File Content-(cloned) Regulatory Data

– File Content-(cloned) Proprietary Data

Create other content file sets for the cloned regulatory and proprietary tags:

– File Content-(Cloned) Regulatory Data on Removable Media

– File Content-(Cloned) Regulatory Data in CD-Burning Folders

– File Content-(Cloned) Regulatory Data on Network Shares

– File Content-(Cloned) Proprietary Data on Removable Media

– File Content-(Cloned) Proprietary Data in CD-Burning folders

– File Content-(Cloned) Proprietary Data on Network Shares

• Replace the description of the rules for the File Content - Regulatory and File Content- Proprietary file sets with your cloned file sets.

• Replace "Applications reading Regulatory data" and "Applications reading Proprietary data" with "Applications reading `Cloned' Regulatory Data" and "Applications reading `Cloned' Proprietary Data."

• In some cases, you may have to create dynamic application rules to create "Applications reading `Cloned' Regulatory Data."

Table 5 describes the cloned rule modules.

Table 5. Cloned Rule Modules

Cloned Rule Module

Rule Description and Rule

Modify Rule Description To

Add Cloned File Sets or Modify Rule

Create or Select Dynamic Application Class

Security-Data Classification (Process)

Add to Applications reading Regulatory Data, Data Scan matches Regulatory Data

(Scan Event Log)

Add to Applications reading Regulatory Data, Data Scan matches "Cloned" Regulatory Data

Add cloned regulatory file content set

Remove original regulatory content file set

Create dynamic application class

Add process to application class

"Applications reading `Cloned' Regulatory data"

Add to Applications reading Regulatory Data, All applications (not AV or backup) read/write Regulatory Data

(File Access Rule)

Add to Applications reading "Cloned" Regulatory Data, All applications (not AV or backup) read/write "Cloned" Regulatory Data

Add cloned regulatory file content set

Remove original regulatory content file set

Select "Applications reading `Cloned' Regulatory data"

Add to Applications reading Proprietary Data, All applications (not AV or backup) read/write Proprietary Data

(File Access Rule)

Add to Applications reading "cloned" Proprietary Data, All applications (not AV or backup) read/write "Cloned" Proprietary Data

Add cloned proprietary file content set

Remove original proprietary content file set

Create dynamic application class

Add process to application class

"Applications reading `Cloned' Proprietary data"

Add to Applications reading Regulatory Data, All applications allowed reading from Regulatory Data app

(Clipboard Access Control)

Add to Applications reading
"Cloned" Regulatory Data, All applications allowed reading from "Cloned" Regulatory Data app

(Clipboard Access Control)

Modified rule should read:

Select Dynamic Application class

"Applications reading `Cloned' Regulatory Data

When applications in any of the selected app classes:

"All Applications" Attempt to read data by

"Applications reading `Cloned' Regulatory Data"

 

Add to Applications reading Proprietary Data, All applications allowed reading from Proprietary Data app or Print Screen

(Clipboard Access Control)

Add to Applications reading "Cloned "

Proprietary Data, All applications allowed reading from "Cloned" Proprietary Data app or Print Screen

Modified rule should read:

Select Dynamic Application class

"Applications reading `Cloned' Proprietary Data

When applications in any of the selected app classes:

"All Applications" Attempt to read data by

"Applications reading `Cloned' Proprietary Data"

and

"Print Process performing a Print Screen"

 

Add to Applications reading Proprietary Data, Data Scan matches Proprietary Data

(Scan Event Log Rule)

Add to Applications reading "Cloned" Proprietary Data, Data Scan matches "Cloned" Proprietary Data

Add
cloned proprietary file set

Remove original proprietary file content

Select "Applications reading `Cloned' Proprietary data"

Security-Data Classification (on close)

Data scan on CLOSE as being required, All Applications, write Regulatory, Proprietary Data

File Access Control

Data scan on CLOSE as being required, All "Cloned" Applications, write "Cloned " Regulatory, Proprietary Data

Add cloned regulatory and proprietary file content sets

Remove original regulatory and proprietary file content file sets

 

Data scan on CLOSE as being required, Apps reading Regulatory, Proprietary Data, write All Files

Data scan on CLOSE as being required, "cloned" Apps reading "cloned" Regulatory, Proprietary Data, write All Files

Modify rule to:

When any application in the selected application class:

"Applications reading `Cloned' Regulatory Applications"

and

"Applications reading `Cloned' Proprietary Applications"

 

Security-Data Classification (temporary process)

Add to Applications recently reading Regulatory Data, All applications allowed reading from Regulatory Data app

(Clipboard Access Control Rule)

Add to Applications recently reading " cloned" Regulatory Data, All applications allowed reading from "cloned" Regulatory Data app

When applications in the following selected applications classes "All Applications"

Attempt to read clipboard data written by

Select

"Applications reading `cloned' Regulatory data"

Create dynamic application class:

"Applications recently reading `cloned' Regulatory data

After 60 seconds"

Add to Applications recently reading Regulatory Data, Data Scan matches Regulatory Data

(Scan Event Log)

Add to Applications recently reading "cloned" Regulatory Data, Data Scan matches "cloned" Regulatory Data

Add
cloned regulatory file set

Remove original regulatory file set

Select dynamic application class:

"Applications recently reading `cloned' Regulatory data"

Add to Applications recently reading Proprietary Data, All applications (not AV or backup) read/write Proprietary Data

(File Access Control)

Add to Applications recently reading "cloned" Proprietary Data, All applications (not AV or backup) read/write "cloned " Proprietary Data

Add
cloned proprietary file set

Remove original proprietary file set

Create dynamic application class:

"Applications recently reading `cloned' Proprietary data

After 60 seconds"

Add to Applications recently reading Proprietary Data, Data Scan matches Proprietary Data

(Scan Event Log)

Add to Applications recently reading " "cloned" Proprietary Data, Data Scan matches "cloned" Proprietary Data

Add
cloned proprietary file set

Remove original proprietary file set

Select dynamic application class:

"Applications recently reading `cloned' Proprietary data"

Add to Applications recent reading Proprietary Data, All applications allowed reading from Proprietary Data app or Print Screen

(Clipboard Control Rule)

Add to Applications recent reading "cloned" Proprietary Data, All applications allowed reading from "cloned" Proprietary Data app or Print Screen

When applications in any of the following selected applications classes "All Applications"

Attempt to read clipboard data written by

Select

"Applications reading `cloned' Proprietary data"

and

"Process performing a print screen"

Select dynamic application class:

"Applications recently reading `cloned' Proprietary data"

Security-Data Loss-Prevent Leakage

IM and P2P applications, read clipboard data from Print Screen, Regulatory, Proprietary Data apps

(Clipboard Control)

IM and P2P applications, read clipboard data from Print Screen, "cloned" Regulatory, "cloned" Proprietary Data apps

When applications in any of the following selected applications classes "All Applications"

Attempt to read clipboard data written by

Select

"Applications reading `cloned' Proprietary data"

and

"Applications reading `cloned' Regulatory data"

and

"Process performing a print screen"

 

IM and P2P applications, read/write Regulatory or Proprietary Data

(File Access Rule)

IM and P2P applications, read/write "cloned" Regulatory or Proprietary Data

Add
cloned proprietary file set

Add cloned regulatory file set

Remove original proprietary and regulatory file sets

 

Regulatory, Proprietary Apps, client/server for P2P, IM, IRC protocols

(Network Access Rule)

"Cloned" Regulatory, Proprietary Apps, client/server for P2P, IM, IRC protocols

Select

"When any of the following selected Application classes"

"Applications reading `Cloned' Regulatory data"

"Applications reading `cloned' Proprietary data"

 

Applications reading Regulatory Data-allowed to print

(Monitor)

Applications reading "cloned" Regulatory Data-allowed to print

Select

"When any of the following selected Application classes"

"Applications reading `Cloned' Regulatory data"

 

All applications, Data Scan matches Regulatory Data on removable media or CD burn directories

(Scan Event Log)

All applications, Data Scan matches "cloned" Regulatory Data on removable media or CD burn directories

Modify file sets to include:

Cloned file content regulatory data in CD-burning folders

Cloned file content regulatory data on removable media

Remove original file sets

 

Apps recently reading Regulatory, Proprietary Data, client/server for TCP and UDP services with external hosts

(Monitor Rule)

Apps recently reading "cloned" Regulatory, "cloned" Proprietary Data, client/server for TCP and UDP services with external hosts

Select "When any of the following selected Application classes"

Applications recently reading cloned regulatory data

Applications recently reading cloned proprietary data

Add variable for newly created external IP address

 

MS spoolsv, read/write Regulatory Data

(Monitor Rule)

MS spoolsv, read/write "cloned" Regulatory Data

Add the "Cloned" Regulatory Data File Set

 

All applications, Data Scan matches Regulatory Data on network share

(Scan Event Log)

All applications, Data Scan matches "Cloned" Regulatory Data on network share

Add the cloned regulatory file set on network share

 

Set Differentiated Service to Mission Critical, Apps reading Regulatory, Proprietary Data, client/server for TCP and UDP

(Network Access Rule)

Set Differentiated Service to Mission Critical, Apps reading "cloned" Regulatory, Proprietary Data, client/server for TCP and UDP

Select in any of the following application classes:

Applications reading cloned proprietary data

Applications reading cloned regulatory data

Add newly created remote address variable

 

For the cloned rule module Security-Data Loss-Prevention by User:

• Replace "Applications Reading Regulatory Data" with "Applications reading `Cloned' regulatory Data."

• Replace "Applications Reading Proprietary Data" with "Applications reading `Cloned' proprietary Data."

• Replace " File Content-Regulatory Data" with "`Cloned" File Content-Regulatory Data."

• Replace "File Content-Proprietary Data" with "`Cloned' Proprietary Data."

• Adjust the rule description and notification as required. Clone the notification rule and make changes.

For the cloned rule module Security-Data Loss-Prevent Data Theft:

• Replace "File Content-Regulatory Data" with "`Cloned' File Content-Regulatory Data."

• Replace "File Content-Proprietary Data" with "`Cloned' Proprietary Data."

• Adjust the rule description and notification as required. Clone the notification rule and make changes.

For the cloned rule module Security-Data Loss-Prevent Data Theft by Desktop:

• Replace "File Content-Regulatory Data" with "`Cloned' File Content-Regulatory Data."

• Replace "File Content-Proprietary Data" with "`Cloned' Proprietary Data."

• Adjust the rule description and notification as required. Clone the notification rule and make changes

9.5.1 Deploying DLP Using Cisco Security Agent Scanning Data Tags

Follow these steps to deploy DLP using scanning data tags:

1. If you are using DLP content scanning, first upload the Cisco Security Agent DLP license.

2. Clone DLP rule modules from the original DLP policy.

3. Create new DLP policy and assign the cloned rule modules to the newly created DLP policy.

You can add and customize rules and notifications for the appropriate rule modules (for example, for the data leakage rule module, you can add data leakage per user). On the basis of your initial meetings with the customer, you can create a new rule module with the appropriate rules.
By default, the DLP rules protect and monitor regulatory and proprietary information. For sensitive information within files, the file must be scanned initially either on opening or on closing of the file. If the pattern and the number of occurrences of the pattern are found within the file, the file will be tagged as containing sensitive information. A scan event log rule is added to take actions such as monitoring the event and notifying users who are noncompliant.
DLP scans can be performed on access, using DLP background scanning, or in real-time when a file is closed, if a policy violation occurs (scanning data tags only).

4. Initially configure DLP background scanning (see Section 8.2.1, "Background Scan").

5. Perform an on-access scan on selected hosts (see Section 8.2.2, "On-Access Scan").

6. Test the DLP policy by triggering a violation, such as copying regulatory information to removable media.

You can also clone the default notifications, customize them, and you can include various tokens, such as (content_clean), referring to sensitive information contained in the file.
For example, to perform data discovery of credit card and social security numbers, follow these steps:

1. Leave the number of occurrences in the pattern count set to 30, or increase this value.

2. Configure a host scanning task to occur on weekly schedule.

3. Use the Cisco Security Agent Data Discovery Report to view sensitive information.

4. Use the Data Details Report to view sensitive data movement.

5. Use the Justification Reports to view user acknowledgments.

9.5.2 Deploying DLP Using Static Tags

Follow these steps to deploy DLP using static data tags:

1. Identify critical business applications and sensitive data files using static tags.

2. Monitor sensitive information flow with Cisco Security Agent's default DLP policies.

3. Customize DLP policies to allow only critical business application to access local sensitive information, and deny all other applications accessing this sensitive information.

4. Configure external IP addresses so that sensitive information can travel between authorized networks and servers.

5. Configure user states for DLP rule modules to allow authorized user access to sensitive information.

9.6 Creating Exceptions for DLP

Follow these steps to create exceptions for DLP:

1. When using scanning tags, increase the pattern count, and the number of occurrences found in the file. These settings can be modified from the Management Center for Cisco Security Agents by choosing Global Settings > Scanning Tags > View.

2. Enter file exceptions in the Management Center for Cisco Security Agents by choosing Variables > File Sets and File Content-Regulatory Data or File Content-Proprietary Data and entering the exception information directly in the "but not" fields.

3. You can exempt files from scanning in the DLP background scan initiated by <Data Scan on Open> (to exclude files from being scanned in the DLP background scan, create a new DLP file set that includes the tagged information and "but not" files to be excluded).

4. You can now insert the $JE DLP-Background Tagged File Exclusions in the rule "Data scan on Open," making it required for processes performing a background search, as in the Security-Data Classification on Open rule module.

5. You can exempt applications from being scanned in the DLP background scan initiated by <Data Scan on Open>.