Network Prevent proactively stops data loss through email and Web communications. Network Prevent integrates with existing email message chain and Web infrastructure technologies to capture network communications and block those transmissions that contain confidential data.
Network Prevent gives organizations the following capabilities:
Stop confidential data loss. Network Prevent blocks email, Web (HTTP/HTTPS), and FTP communications that contain confidential data.
Implement encryption policies. Network Prevent analyzes email messages and selectively routes those messages that contain confidential content to an encryption gateway for secure delivery. This feature enables you to enforce enterprise-wide encryption and archiving policies.
Enforce workforce compliance. Through automatic blocking and encryption, Network Prevent effectively enforces workforce compliance with government regulations and company policies.
The Network Prevent product module provides two detection servers:
Network Prevent Server monitors and analyzes outbound email traffic in-line and (optionally) blocks, redirects, or modifies email messages as specified in your policies. Network Prevent integrates with industry-standard mail transfer agents to let you monitor and stop data loss incidents over SMTP.
See About Network Prevent (Email).
Network Prevent Server integrates with an HTTP, HTTPS, or FTP proxy server for in-line active Web request management. When the server detects confidential data in HTTP, HTTPS, or FTP content, it causes the proxy to reject requests or remove HTML content. You specify the desired behavior in your policies.
See About Network Prevent (Web).
You can configure Symantec Data Loss Prevention Network Prevent detection server for either email (SMTP) or Web (HTTP/HTTPS/FTP) protocols. A single Network Prevent Server cannot be configured for both passive monitoring and active prevention. However, you can configure each server with any mix of monitoring-only policies and active traffic management policies (block, redirect, modify) at the same time.
Symantec Data Loss Prevention administrators can define the in-line email and Web request management actions on the Configure Response Rule page of the Enforce Server administration console. Policy authors can configure a policy for prevention (in-line management) or for monitoring only on a per-policy basis. Policy authors can qualify response rules by specifying conditions, such as the incident severity and the match count ranges. The conditions allow them to differentiate those cases that require blocking or modification from those that only require a logged incident.
Note: For prevention actions to function correctly, relevant policies must be deployed on in-line servers.
About Network Prevent (Email) :
Network Prevent (Email) servers integrate with standard MTAs for in-line active SMTP email management. Policies that are deployed on in-line SMTP Prevent Servers direct the MTA to perform any of the following actions:
Block the message
Reroute the message (for example, to an encryption gateway or to a quarantine system)
Tag email messages based on specific content and other message attributes.
Network Prevent (Email) prevent actions describes the different actions that Network Prevent (Email) can take when an email message violates a configured policy.
Action : Block delivery of messages violating a policy :
In this case, the MTA does not deliver messages to the intended recipients. Administrators can create a Block SMTP Message response rule to have the MTA send a non-delivery report to the message sender. This report contains the text that is specified in the response rule and is generated at the moment the message is blocked.
Note:
The MTA-generated non-delivery report is different from the sender notifications that you can configure as a type of response rule. The Enforce Server generates and sends sender notifications. If the connectivity between the Prevent Server and the Enforce Server is active when a message is blocked, the sender notification message is generated quickly. However, if there is an interruption of the Prevent Server and Enforce Server connectivity, the sender notification message is not generated until connectivity is restored.
Symantec Data Loss Prevention administrators can configure email message blocking and Enforce Server-generated sender notification actions on the Configure Response Rule page. Then policy authors can use the response rules to set up an appropriate incident remediation workflow on the per-policy basis.
Action : Redirect messages violating a policy to an external quarantine/review/release system :
In this case, the message is redirected to an address that is configured in a Block SMTP Message response rule. This address is typically the address of a mailbox or mail list that administrators or managers use to review and release the messages. These mailboxes are outside of the Symantec Data Loss Prevention system. To use this feature, an MTA administrator must configure all redirect or review addresses as individual sender exceptions on each MTA. You cannot perform this configuration using the Enforce Server administration console.
Note:
Keep redirect addresses in the policy user interface synchronized with sender exception addresses configured on the MTAs.
Administrators can enable and configure message redirection in a Block SMTP Message response rule on the Configure Response Rule page. They must provide an address in the Redirect Message to this Address field.
Action : Tag messages violating a policy, causing a downstream gateway-based message encryption solution to encrypt them :
You can configure gateway-based message encryption systems to take action based on certain keywords in the message subject. You can also configure actions based on the presence of certain MIME message headers (typically an extension header that starts with "X-"). You can configure a policy to modify the message subject or to add or modify the message headers.
Note:
Be sure to keep the configuration of your message encryption system synchronized with the relevant details of Symantec Data Loss Prevention policies.
Administrators can enable and configure message tagging for down-stream encryption by creating Modify SMTP Message response rules on the Configure Response Rule page. Policy authors can then use the rules to set up an appropriate incident remediation workflow on the per-policy basis.
Action : Tag messages with policy violation data
A message might violate more than one policy. You can add special headers to those outgoing messages that report data regarding the number and severity of violated policies. These headers can then be used to trigger different downstream responses based on the header data. Three different headers are available for this purpose. Each one is enabled by setting the corresponding Advanced Setting value to "true." The three multiple-policy-related advanced settings are:
@RequestProcessor.TagHighestSeverity - When set to true, an additional email header reporting the highest severity among multiple violated policies is added to the message. For example, "X-DLP-Max-Severity: MEDIUM" indicates that most serious policy violation was of Medium severity.
@RequestProcessor.TagPolicyCount - When set to true an additional email header reporting the total number of policies that the message violates is added to the message. For example, "X-DLP-Policy-Count: 3" indicates that the message violated three different policies.
@RequestProcessor.TagScore - When set to true an additional email header reporting the total cumulative score of all the violated policies is added to the message. Scores are calculated using the formula: High=4, Medium=3, Low=2, and Info=1. For example, "X-DLP-Score: 7" indicates that the violated policies added up to a total score of 7. For example, if the message violated a policy with a High severity (4) and another policy of Medium severity (3) the total score is 7.
Note that when any of these advanced settings are true, the corresponding header is added to all messages. This occurs even if they only violate a single policy.
For more information please refer my article https://www-secure.symantec.com/connect/articles/configuring-network-prevent-server-reflecting-or-forwarding-mode
For information about integrating a Symantec Data Loss Prevention Email Prevent Server with your MTA, see the Symantec Data Loss Prevention MTA Integration Guide for Network Prevent (Email).
About Mail Transfer Agent (MTA) integration :
Choose an integration architecture and configure your Mail Transfer Agent (MTA) to work with the Network Prevent Server.
Review the Symantec Data Loss Prevention MTA Integration Guide for Network Prevent (Email). Familiarize yourself with the compatible integration architectures.
The Network Prevent Server can operate with your MTA in either reflecting or forwarding modes:
@ Reflecting mode. In reflecting mode, the Network Prevent Server receives messages from an MTA. It analyzes them, and then returns them to the same MTA (with instructions to block the messages or process them downstream). In essence, the server returns messages to the same IP address from which they arrived.
@ Forwarding mode. In forwarding mode, the Network Prevent Server receives messages from an upstream MTA. It analyzes them, and then sends them on to a downstream MTA or hosted email service provider. You can specify a list of IP addresses or hostnames for the next-hop mail server in the Network Prevent Server configuration.
You can also configure a single Network Prevent Server to work with multiple MTAs.
Specifying one or more upstream mail transfer agents (MTAs) :
By default, Network Prevent Server can accept connections to the ESMTP service port from any system on the network. You can restrict Network Prevent Server ESMTP communication to a designated set of mail transfer agents (MTAs) for security reasons. Create a "whitelist" of authorized systems. If you whitelist one or more systems, other systems that are not on the whitelist cannot connect to the Network Prevent Server ESMTP service port.
Note that an MTA whitelist might be affected by the RequestProcessor.BindAddress setting. By default, the RequestProcessor.BindAddress setting is 0.0.0.0, and the listener binds to all available addresses. If RequestProcessor.BindAddress instructs the listener to bind to a specific IP, a white listed MTA must also be able to reach the listener address.
To create a whitelist of systems allowed to communicate with the Network Prevent Server:
1] Go to System > Servers > Overview and click on the wanted Network Prevent Server.
2] On the Server Detail screen that appears, click Server Settings.
3] Scroll down to the RequestProcessor.AllowHosts field.
By default, RequestProcessor.AllowHosts is set to any, meaning that all other systems on the network can communicate with this Network Prevent Server.
4] You can limit the systems that are allowed to connect with this Network Prevent Server. Delete any and enter the IP addresses or FQDN of the systems you want to authorize. Separate multiple addresses with commas. For example: "123.14.251.31,smtp_1.corp.mycompany.com,123.14.223.111." Separate addresses only with commas; do not include spaces.
5] Click Save.
Changes to this setting do not take effect until you restart the server.
About Network Prevent (Web) :
Network Prevent (Web) integrates with HTTP, HTTPS, or FTP proxy servers using Internet Content Adaptation Protocol (ICAP) for in-line active Web request management. Policies that you deploy to in-line Prevent Servers direct the HTTP proxy to reject HTTP requests based on specific content.
Note:
The configuration of ICAP on an HTTP or FTP proxy depends on the proxy vendor and is usually described in the proxy's documentation.
If a request violates a policy, Network Prevent Servers can instruct the proxy by ICAP to reject the request. Symantec Data Loss Prevention administrators can configure a Reject HTTP Message response rule on the Configure Response Rule page. The response rule defines the text or HTML content to be sent to the browser in response to the violating request. After the rule is created, policy authors can use it to configure prevention policies.
Testing Network Prevent :
You can test Network Prevent by sending a Web email that violates your test policy.
To test your system
1] Open a browser that accesses the Internet through your HTTP proxy server.
2] In the browser, access a test Web email account and send an email with an attachment containing confidential data. For example, access an account in Hotmail and send an email with an attachment containing the word Secret and paragraphs of other text.
3] In the Enforce Server administration console, go to Incidents > Network and click Incidents - All. Look for the resulting incident. For example, search for an incident entry that includes the appropriate timestamp and policy name.
4] Click on the relevant incident entry to see the complete incident snapshot.
Troubleshooting information for Network Prevent Server :
The following table describes a common problem when using Network Prevent Server and suggests a possible solution.
Problem : appear in Network reports, but Symantec Data Loss Prevention does not perform the action specified in the relevant response rule.
Possible Solution :
Incidents This is expected behavior when the Network Prevent Server is running in trial mode (the default setting). If you do not want to run in trial mode, change the setting.