In some enterprise environment, the sensitive documents that needs to be protected by IDM, are locate in some kind of restricted area. The DLP Enforce cannot access these files logically/physically, or have no rights to access these files. Under such scenario, how can we create a remote IDM?
The solution/workaround for this kind of scenario is to install a separate DLP Enforce inside the restricted area where the documents files locate, create a IDM profile in this DLP Enforce, then copy the profile into another DLP Enforce.
Under the testing environment, we installed 2 DLP Enforce: Enforce1 and Enforce2. The Enforce2 has the rights to access the documents in the file server, and Enforce1 doesn't.
Here are the steps to create remote IDM using copy of RDX file.
From Enforce2:
1. Create a IDM Profile, and select 'Use Remote SMB Share':
Image may be NSFW. Clik here to view.
2. Choose 'Submit Indexing Job on Save':
Image may be NSFW. Clik here to view.
3. Check out the indexing is finished:
Image may be NSFW. Clik here to view.
4. After the indexing completed, the rdx file will be created under the \SymantecDLP\Protect\index folder:
Image may be NSFW. Clik here to view.
In Enforce1:
5. Create a dummy zip file that contain a dummy file, for example, one zip file contains one txt file:
Image may be NSFW. Clik here to view.
6. Create a IDM profile, select the option 'Upload Document Archive to Server Now', and select the dummy file create on previous step:
Image may be NSFW. Clik here to view.
7. After the indexing finished, there will be rdx files under the \SymantecDLP\Protect\index folder:
Image may be NSFW. Clik here to view.
8. The SN of the profile on Enforce1 will be different to the one on Enforce2.
In our example, the SN of the profile on Enforce1 is 151.1, the SN of the profile on Enforce2 is 1101.2
Copy the rdx files from Enforce2 to Enforce1, to the same folder.
And, rename the profile from Enforce2 into the one of Enforce1:
Image may be NSFW. Clik here to view.
9. Restart the detection server to make the change loaded:
Image may be NSFW. Clik here to view.
10. From the event log of the detection server, there will be one message say the profile is loaded:
Image may be NSFW. Clik here to view.
11. Create a policy to use this IDM profile. Then the sensitive documents will trigger incidents in Enforce1.
Symantec Data Loss Prevention for Mobile connects to your corporate network through Wi-Fi access or through cellular 3G connectivity. Network traffic for Webmail, third-party applications such as Yahoo and Facebook, and corporate email applications including Microsoft Exchange ActiveSync,IBM Lotus Notes Traveller, is sent through the HTTP/S protocol. Corporate email can be sent through Microsoft ActiveSync as either HTTP or HTTPS protocol information. Microsoft ActiveSync receives the information from the corporate proxy server after it has gone through detection; then, sends the message to the corporate Exchange Server. Messages that are sent through applications such as Facebook or Dropbox can be blocked from the message, depending on your policies.
Image may be NSFW. Clik here to view.
The above graphic illustrates the connections necessary to enable Symantec Data Loss Prevention for Mobile:
Mobile devices must connect to the corporate network through a virtual private network (VPN) to send corporate messages or access the corporate network. The Mobile Prevent solution requires that mobile devices use the VPN On Demand feature to create a constant, protected VPN connection. If you are not connected to the corporate network, Mobile Prevent cannot detect any policy violations.
Your mobile device connects to the VPN server to gain access to your corporate network.
The VPN server assigns an IP address to each mobile device that connects to it. These IP addresses form a VPN subnetwork. The VPN subnetwork lets your mobile devices access the corporate network and the corporate proxy server. You can specify a range of IP addresses that your VPN server can assign to other devices. All of the IP addresses that the VPN server assigns to your mobile devices are within this range. If a range of addresses were not specified for your VPN server, the network could randomly assign IP addresses to your mobile devices. A specific range of IP addresses lets Symantec Data Loss Prevention identify which IP addresses are assigned to mobile devices and which addresses are not connected. Using a range of IP addresses assists in identifying which mobile device generated an incident.
If you deploy Mobile Prevent and Network Prevent together, the IP address identifies Network and Mobile incident types.
On the Mobile Prevent side, VPN On Demand ensures that the VPN connection is not interrupted. Apple mobile devices use VPN On Demand to dynamically create a VPN session. VPN on Demand starts the VPN session when connecting to a specific list of configured domains (for example .com, .net, or .org). Certificate-based authentication is required to configure the VPN On Demand feature. By configuring how VPN On Demand automatically enables VPN on an iOS mobile device, you can ensure that all traffic goes through your corporate network. You need a Web proxy that is deployed in transparent mode to route traffic from the mobile devices in your corporate network to Symantec Data Loss Prevention. The network traffic is routed uses the ICAP service.
You can use a mobile device management (MDM) solution to apply the network and VPN configuration.
VPN configuration can be specified in a configuration profile by your mobile device management (MDM) solution. The MDM solution applies a configuration profile to each mobile device that you want to connect to your corporate network.
Use a mobile device management (MDM) solution to manage and apply a wide variety of configuration settings to multiple mobile devices. You can load user profiles where corporate mail settings, VPN settings, security certificates, and proxy server settings are preconfigured onto the mobile devices. To access the Mobile Prevent for Web Server, you must use an MDM solution to apply the VPN server configuration profile. The VPN server configuration profile sets the conditions for VPN On Demand to route all network traffic through the VPN and into your corporate network. Only network traffic flowing in your corporate network can be monitored for violations.
Implementing Mobile Prevent :
The Mobile Prevent for Web Server integrates with a VPN server, an MDM solution, and a Web proxy server using ICAP. If it detects confidential data in Web content, the proxy will reject requests or remove HTML content as specified in your Mobile Prevent policies.
First, you need to know the high-level steps that are required for implementing Mobile Prevent. You can check the cross-referenced sections for more details. There are two deployment scenarios for Mobile Prevent: the Mobile Prevent as a standalone product, and Mobile Prevent installed in combination with Network Prevent. The following procedure assumes that you are implementing Mobile Prevent as a standalone product. If you want to implement Mobile Prevent and Network Prevent, you must also follow the implementation instructions for Network Prevent.
About deploying Mobile Prevent as a standalone solution :
When you deploy Mobile Prevent as a standalone solution, no other detection server is deployed with the Mobile Prevent for Web Server. The Mobile Prevent for Web Server interacts with the Enforce Server and the corporate proxy server to monitor and prevent incidents on mobile devices. The following diagram describes how the Mobile Prevent solution fits into your corporate infrastructure:
Image may be NSFW. Clik here to view.
In this deployment, mobile devices connect to the corporate network through your VPN server. The VPN server assigns each mobile device an IP address. This address lets the device access the internal corporate network. After the device is assigned a unique IP address, all HTTP, HTTPS, and FTP traffic is monitored by the Mobile Prevent for Web Server. Each device must be connected to the corporate network through the VPN. If the VPN connection to the corporate network is lost, Mobile Prevent cannot detect any violations.
iPads and iPhones use a native feature called VPN On Demand to create a secure VPN connection automatically without user intervention. VPN On Demand requires certificate-based authentication to create the connection to the VPN Server.
After the VPN connection is established, traffic is sent through the proxy server and analyzed by Mobile Prevent for Web Server. Traffic between the proxy server and the Mobile Prevent for Web Server is done over the ICAP protocol. If no violations are discovered, the traffic is sent to its destination either internally or externally. If violations are discovered, an incident is created and response actions are implemented. Incidents are recorded on the Enforce Server.
When a mobile device sends an email through Microsoft Exchange ActiveSync, the HTTP/HTTPS packets are sent to the ActiveSync server. The packets are then sent to the Exchange Server. Any corporate email should go through Microsoft Exchange ActiveSync. Mobile Prevent does not support the SMTP protocol.
Note: Mobile Prevent does not support response mode (RESPMOD).
Below implementing procedures assume that you already have your VPN and proxy servers running in your environment.
Procedure Step 1 : Add a new Mobile Prevent Server.
Adding a detection server Add the detection servers that you want to your Symantec Data Loss Prevention system from the System > Servers > Overview screen.
You can add the following types of servers:
Network Monitor Server, which monitors network traffic.
Network Protect Server, which inspects stored data for policy violations (Network Discover).
Network Prevent Server, which prevents SMTP violations.
Network Prevent Server, which prevents ICAP proxy server violations such as FTP, HTTP, and HTTPS.
Mobile Prevent for Web Server, which monitors and prevents HTTPS, HTTPS, and FTP violations over mobile devices.
Note: If your Symantec Data Loss Prevention license includes both Mobile Prevent for Web and Network Prevent for Web Servers you add a single detection server called Network and Mobile Prevent for Web Server.
Endpoint Server, which controls Symantec DLP Agents that monitor endpoint computers.
Classification Server, which analyzes email messages that are sent from a Symantec Enterprise Vault filter, and provides a classification result that Enterprise Vault can use to perform tagging, archival, and deletion as necessary.
Procedure Step 2: Configure your Mobile Prevent Server.
Configuring the Mobile Prevent for Web Server
You can use a number of configuration options for Mobile Prevent for Web Server. For example, you can configure the server to:
Ignore small HTTP/S requests or responses.
Ignore requests to or responses from a particular host or domain (such as the domain of a business subsidiary).
Ignore user search engine queries.
To modify your Mobile Prevent for Web Server configuration
Go to System > Servers > Overview and click the Mobile Prevent for Web Server.
On the Server Detail screen that appears, click Configure.
You can verify or modify settings on the ICAP tab as described in subsequent steps. The tab is divided into several sections: Request Filtering, Response Filtering, and Connection.
Verify or change the Trial Mode setting.
Verify or modify the filter options for requests from HTTP clients (user agents). The options in the Request Filtering section are as follows:
Ignore Requests Smaller Than Specifies the minimum body size of HTTP requests to inspect. (The default is 4096 bytes.) For example, search-strings typed in to search engines such as Yahoo or Google are usually short. By adjusting this value, you can exclude those searches from inspection.
Ignore Requests without Attachments Causes the server to inspect only the requests that contain attachments. This option can be useful if you are mainly concerned with requests intended to post sensitive files.
Ignore Requests to Hosts or Domains Causes the server to ignore requests to the hosts or domains you specify. This option can be useful if you expect a lot of HTTP traffic between the domains of your corporate headquarters and branch offices. You can type one or more host or domain names (for example, www.company.com), each on its own line.
Ignore Requests from User Agents Causes the server to ignore requests from user agents (HTTP clients) you specify. This option can be useful if your organization uses a program or language (such as Java) that makes frequent HTTP requests. You can type one or more user agent values (for example, java/6.0.29), each on its own line.
Note: The Response Filtering options are not supported for Mobile Prevent.
Verify or modify the filter options for responses from Web servers. The options in the Response Filtering section are as follows:
Ignore Responses Smaller Than Specifies the minimum size of the body of HTTP responses that are inspected by this server. (Default is 4096 bytes.)
Inspect Content Type Specifies the MIME content types that Symantec Data Loss Prevention should monitor in responses. By default, this field contains content-type values for Microsoft Office, PDF, and plain text formats. To add others, type one MIME content type per line. For example, type application/wordperfect5.1 to have Symantec Data Loss Prevention analyze WordPerfect 5.1 files.
Note that it is generally more efficient to specify MIME content types at the Web proxy level.
Ignore Responses from Hosts or Domains Causes the server to ignore responses from the hosts or domains you specify. You can type one or more host or domain names (for example, www.company.com), each on its own line.
Ignore Responses to User Agents Causes the server to ignore responses to user agents (HTTP clients) you specify. You can type one or more user agent values (for example, java/1.4.2_xx), each on its own line.
Verify or modify settings for the ICAP connection between the HTTP proxy server and the Mobile Prevent for Web Server. The Connection options are as follows:
TCP Port Specifies the TCP port number over which this server listens for ICAP requests. This number must match the value that is configured on the HTTP proxy that sends ICAP requests to this server. The recommended value is 1344.
Maximum Number of Requests Specifies the maximum number of simultaneous ICAP request connections from the HTTP proxy or proxies. The default is 25.
Maximum Number of Responses Specifies the maximum number of simultaneous ICAP response connections from the HTTP proxy or proxies. The default is 25.
Connection Backlog Specifies the number of waiting connections allowed. A waiting connection is a user waiting for an HTTP response from the browser. The minimum value is 1. If the HTTP proxy gets too many requests (or responses), the proxy handles them according to your proxy configuration. You can configure the HTTP proxy to block any requests (or responses) greater than this number.
In the Mobile IP Ranges fields, enter the range of IP addresses that your VPN server is configured to assign to mobile devices. The IP addresses are used to identify the incidents that were triggered from mobile devices as Mobile incidents.
The IP addresses you enter into this range do not dynamically affect the VPN Server. This range is only to identify your mobile devices in the administration console. You must enter the exact same range of IP addresses when you configure the VPN Server to assign the addresses.
Click Save to exit the Configure Server screen and then click Done to exit the Server Detail screen.
Procedure Step 3: Configure your VPN Server with the IP address range that you want to assign to the corporate mobile devices for the Mobile Prevent sub-network
Procedure Step 4 : Configure your VPN profile with the MDM application.
You must configure the VPN profile before mobile devices can connect to the corporate network. The VPN profile combines security certificates, the VPN server configuration settings, VPN On Demand settings, and any network configuration settings. Normally, the VPN profile is set and applied through your MDM solution. Along with the VPN profile, you can configure other aspects of your mobile device such as Microsoft Exchange ActiveSync, firewall properties, or LDAP settings.
Procedure Step 5 : Define ICAP services on proxy to route traffic to Mobile Prevent Web Server.
Procedure Step 6 : Create and deploy a policy for Mobile Prevent.
Creating policies for Mobile Prevent
You can create the policies that include most standard response rules. The response rules include Add Note, Limit Incident Data Retention, Log to a Syslog Server, Set Attribute, and Set Status.
You can also incorporate the response rules that are specific to Mobile Prevent Server as follows:
Network Prevent and Mobile Prevent: Block HTTP/HTTPS
Blocks the posts that contain confidential data (as defined in your policies). This includes Web postings, Web-based email messages, and files that are uploaded to Web sites or attached to Web-based email messages.
Note:
Certain applications may not provide an adequate response to the Network Prevent and Mobile Prevent: Block HTTP/HTTPS response action. This behavior has been observed with the Yahoo! Mail application when a detection server blocks a file upload. If a user tries to upload an email attachment and the attachment triggers a Network Prevent: Block HTTP/HTTPS response action, Yahoo! Mail does not respond or display an error message to indicate that the file is blocked. Instead, Yahoo! Mail appears to continue uploading the selected file, but the upload never completes. The user must manually cancel the upload at some point by pressing Cancel.
Other applications may also exhibit this behavior, depending on how they handle the block request. In these cases a detection server incident is created and the file upload is blocked even though the application provides no such indication.
Network Prevent and Mobile Prevent: Remove HTTP/HTTPS Content
Removes confidential data from posts that contain confidential data (as defined in your policies). This includes Web-based email messages and files that are uploaded to Web sites. Note that the Remove HTTP/HTTPS Content action works only on requests.
Network Prevent and Mobile Prevent: Block FTP Request
Blocks FTP transfers that contain confidential data (as defined in your policies).
For details on setting up any response rule action, open the online Help.
Go to Manage > Policies > Response Rules and click Add Response Rule.
Even if you do not incorporate response rules into your policy, Mobile Prevent captures incidents as long as your policies contain detection rules. You can set up such policies to monitor Web and FTP activity on your mobile device before implementing the policies that block or remove content.
If you have configured your proxy to forward both HTTP/HTTPS requests and responses, your policies work on both. For example, policies are applied to both an upload to a Web site and a download from a Web site.
To create a test policy for Mobile Prevent
In the Enforce Server administration console, create a response rule that includes one of the actions specific to Mobile Prevent. For example, create a response rule that includes the Network Prevent and Mobile Prevent: Block HTTP/HTTPS action.
Create a policy that incorporates the response rule you configured in the previous step.
For example, create a policy called Test Policy as follows:
Include a Content Matches Keyword detection rule that matches on the keyword "secret."
Include a Network Prevent and Mobile Prevent: Block HTTP/HTTPS response rule.
Associate it with the Default policy group.
Procedure Step 7 : Test the system by generating an incident against your test policy.
Testing Mobile Prevent
You can test Mobile Prevent by sending an email that violates your test policy.
To test your system
Connect your mobile device to the Internet and connect to your corporate VPN.
Open your corporate email client and send an email with an attachment containing confidential data. For example, access your Microsoft Outlook client and send an email with an attachment containing the word secret and paragraphs of other text.
In the Enforce Server administration console, go to Incidents > Mobile and click Incidents - All. Look for the resulting incident. For example, search for an incident entry that includes the appropriate timestamp and policy name.
Click on the relevant incident entry to see the complete incident snapshot.
Procedure Step 8 : If required, troubleshoot the implementation.
See the Symantec Data Loss Prevention System Requirements and Compatibility Guide for more details on configuring Mobile Prevent to work within your organization.
Your Technical Contact ID: (check with your Local Technical Support Representative)
You will receive a confirmation email with a tracking number, and within 24 to 48 hours you should receive an email telling you if the file is viral or not. If it is viral, you will be provided with a set of rapid release definitions. These can be installed to your system so that Symantec Endpoint Protection or Symantec AntiVirus can then detect the infected file and prevent a re-infection.
9) Submit the file to Threat Expert (owned by Symantec).
Automated analysis can be performed for some types of threats through http://www.threatexpert.com. This step can quickly identify the sites the threat is coded to contact so they can be blocked at the firewall. Symantec Support does not provide troubleshooting for http://www.threatexpert.com, and this step does not replace the need to submit files to Symantec Security Response.
SymHelp is a cross-product diagnostic utility designed for troubleshooting and identifying common issues that customers encounter.
SymHelp is designed to support the Symantec Endpoint Protection 12.1 RU2 and Windows 8 & Windows 2012 Operating Systems.
In case if you try running the Legacy SEP Support Tool on the machine with Windows 8 / Windows 2012 Operating System OR Symantec Endpoint Protection 12.1 RU2, then you may receive the error as below:
Image may be NSFW. Clik here to view.
Supported Products
Currently SymHelp supports the following Symantec products:
Symantec Backup Exec 11d to 2012
Symantec Backup Exec System Recovery 6.5 to 8.x
Symantec Data Loss Prevention 11.0 and later
Symantec Endpoint Protection 11.0 and later
Symantec Mail Security for Microsoft Exchange 6.5.2 and later
9) To collect the SymHelp Load Point Analysis Logs for the Symantec Support, click on "Save"
Image may be NSFW. Clik here to view.
10) Insert all the Customer Information to Save the Report File, Browse to the Location to which you would like to Save the SymHelp Log file (Default Location would be the same location from where SymHelp.exe has been Run) and then click on "Save" Button.
Image may be NSFW. Clik here to view.
11) SymHelp would start the saving the file to the Destination Location.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
12) By Default, Saved Location would be the same location from where SymHelp.exe has been Run.
Image may be NSFW. Clik here to view.
13) In case if we click on "Save and Send to Symantec Support", it would save and upload the SymHelp Logs to the Symantec FTP server.
The upload to the FTP server would require internet connection.
You would have to give the entire path to the Symantec Technician when required.
Image may be NSFW. Clik here to view.
Image may be NSFW. Clik here to view.
14) In case you need to Submit the Load Point Analysis and Full Data Collection Report, you may need to follow the steps provided in the Article:
Submitting information about detections to Symantec Security Response
We can configure your computer to automatically submit information about detections to Symantec Security Response for analysis.
Symantec Response and the Global Intelligence Network use this submitted information to quickly formulate responses to new and developing security threats. The data that you submit improves Symantec's ability to respond to threats and customize protection. Symantec recommends that you always allow submissions.
We can choose to submit any of the following types of data:
■ File reputation
Information about files that are detected based on their reputation. The information about these files contributes to the Symantec Insight reputation database to help protect your computers from new and emerging risks.
■ Antivirus detections
Information about virus and spyware scan detections.
■ Antivirus advanced heuristic detections
Information about potential threats detected by Bloodhound and other virus and spyware scan heuristics. These detections are silent detections that do not appear in the Risk log. Information about these detections is used for statistical analysis.
■ SONAR detections
Information about threats that SONAR detects, which include high or low risk detections, system change events, and suspicious behavior from trusted applications.
■ SONAR heuristics
SONAR heuristic detections are silent detections that do not appear in the Risk log. This information is used for statistical analysis. We can also manually submit a sample to Response from the Quarantine.
We can enable your computer to submit information about detected threats to Symantec Security Response. Symantec Security Response uses this information to protect your client computers from new, targeted, and mutating threats. Any data we submit improves Symantec's ability to respond to threats and customize protection for your computer. Symantec recommends that you submit as much detection information as possible.
We can manually submit a sample to Symantec Response from the Quarantine page. The Quarantine page also lets you determine how items are submitted to Symantec Security Response.
To configure submissions to Symantec Security Response
1) Select Change Settings > Client Management.
2) On the Submissions tab, check Let this computer automatically forward selected anonymous security information to Symantec. This option lets Symantec Endpoint Protection submit information about the threats that are found on our computer.
Symantec recommends that you keep this option enabled.
3 Select the types of information to submit:
■ File reputation
■ Antivirus detections
■ Antivirus advanced heuristic detections
■ SONAR detections
■ SONAR heuristics
SONAR heuristic detections are silent detections that do not appear in the Risk log. This information is used for statistical analysis.
4) Enable Allow Insight lookups for threat detection to allow Symantec Endpoint Protection to use Symantec's reputation database to make decisions about threats.
Insight lookups are enabled by default. Symantec recommends that we allow Insight lookups. Disabling this feature disables the Download Insight and may impair the functionality of SONAR and Insight Lookup.
However, we can disable this option if you do not want to allow Symantec to query Symantec Insight.
In it, we will look at using Application Learning in an incident response situation. The purpose of application learning is for the SEP client to collect and monitor the applications and services that run on client PCs. I do want to point out that I only use this for incident response. While it is perfectly acceptable to use this in a normal situation, if you have many clients, your database can grow quite rapidly. If you do decide to use this on a regular basis, you should check out the Best Practices Guide to Application Learning in Symantec Endpoint Protection Manager
Now, let's get started. From time to time I come across a problem user who is no stranger to re-infection. I have a special purpose group setup for such cases. Application learning is enabled for this group. Enabling application learning is a two step process.
Log in to the SEPM:
Navigate to Admin page >> select your Local Site and select Edit Site Properties. Tick the checkbox for "Keep track of every application that the clients run". This will enable the feature.
Go to the Clients page and create your special purpose group and uncheck inheritance. Go to the Policies tab at the top and under Settings select Communications Settings. Under Upload tick the checkbox for "Learn applications that run on the client computers". This tells the SEP client to monitor all applications and upload it to the SEPM.
Now, this process will not be completed immediately. Logs will start to come in but it will depend on what you have your heartbeat set to. For this special purpose group, I like to set the heartbeat from anywhere from 5-15 minutes. Since this is usually done for one or two clients at a time, this should not be a problem. I like to give the entire process a few hours to take shape before I really dig into it. Once you feel enough time has passed, you can begin reviewing what applications are running on the PC.
A new box will come up which will allow you to do some filtering:
Image may be NSFW. Clik here to view.
Feel free to edit as you see fit and select Search when completed. You will get a similar result if all is working correctly:
Image may be NSFW. Clik here to view.
Now, what I like to do is export the results and compare it to a list of known good process that are on our golden image(s). This can be a tedious task although it makes it slighly easier to find bad processes when you have a list of what you know contain good ones. When I find what I believe are bad processes I will submit them to ThreatExpert and Virustotal for analysis. If it's found to be malicious, I submit to Symantec Security Reponse so they can create a signature for it.
I hope this article has been helpful for you. Please post any feedback or questions that you may have.
Lately it has been noticed an increasing spread of threats which, entering a system by various means are encrypting several files on the attacked system like office documents, database files, e-mail archives, which represent a value for the attacked customer.
Those threats generally, after encrypting the files, sometimes delete themselves or propagate through the network.
To decrypt the file the hackers generally ask to pay a certain amount of money.
In order not to create misunderstandings, customers need to be aware of the following: encrypted files will remain encrypted. These should be replaced from a known-good backup (and Enterprises are responsible for regularly backing up their own important data).
Symantec products do not decrypt files that have been affected by these threats.
Why? The reason is as simple as very often not considered. The majority of these kind of threats is using an RSA public-key cryptography at 1024 or 2048 bits. Despit of a number of commercial tools which are released the truth is such: for large RSA key sizes (in excess of 1024 bits), no efficient method for solving this problem is known (this is the so called "RSA problem")
Anyway, to pay the hackers is not a solution at all.
When a customer pays the hackers, there is no guarantee that the attacker can or will supply a method of unlocking their computer or decrypting their files. For some variants, Symantec has received reports that the threat was received, the attacker provided a code to allow the threat to un-do the encryption that has been done on the customer’s files. Then, once Symantec updated our detection, the threat .exe is removed (deleted/quarantined) and the un-encryption can no longer continue.
When customers pay hackers for threats, such as these, it encourages attackers to continue these tactics and additional attacks against everyone.
If the infection somehow already entered in our environment, the damage, unfortunately is already done.
Anyway, if we identify the threat in a timely manner, we can prevent the threat to spread and contain the damage.
Whenever you find a system in your environment which is being infected from this kind of encrypting threat, the first thing to do, even more than in other cases is:
Isolate the machine from the network!!
Afterwards, you will need to identify the virus finding the executable file and submit it to Symantec Security Response.
Hint: in order to help yourself in identifying the malicious files, you can run a threat analysis on the affected machine using the SymHelp tool:
In order to stop the eventual expanding of the threat in your environment, through the Symantec Endpoint Protection, you can use the “Application and Device Control” component to block the execution of that specific file, identifying it through the hash MD5:
Moreover, again using the “Application and Device Control” component it is possible, it is possible to harden the overall security of the system with a specific policy:
Anyway, this is a general mean of prevention, helpful but not specific for this kind of threats.
It is always recommended to test the policy accurately before applying it massively to any production environment.
- Lock your system down
Surely effective solution which will protect you from this and other kind of threats, it is to use the Symantec Endpoint Protection feature which is called “System Lockdown”.
It is based on the idea that an organization uses a determined and pre-allowed set of application which can be collected and allowed by an administrator, blocking the execution of anything else.
CAUTION! Anyone who would like to implement this feature is invited to test it deeply! An incorrect deployment of the feature can highly compromise the functionality of the systems in object.
- Granular approach (using Application and Device Control)
We can implement an application and device control policy to block the execution of the most common file extensions used by this class of threats, in the paths which are known to be the common launch points.
About “Application and Device Control” in general:
Attached to this article it is given an example of policy which can be imported in SEP Manager and it is ready to use.
Please keep in mind: before implementing this policy massively in a production environment, test it on a small grouop of machine, verify its compatibility to your needs. Also feel free to customize it as you may find more appropriate
What are the features of our policy?
- Blocking Auto-Run (works out of the box)
- Blocks access to script files (works out of the box)
- Blocks the execution of files with extension “.exe”, “.com”, “.scr”, “.pif” from the known launch points of those threats and also from some kinds of archives.
Here the complete list:
%appdata%\
%appdata%\*\
%temp%\
%temp%\*\
%temp%\rar*\
%temp%\7z*\
%temp%\wz*\
%temp%\*.zip\
%iappdata%\
%localappdata%\
%localappdata%\*\
%userprofile%\Local Settings\Application\
%userprofile%\Local Settings\Application\*\
C:\$Recycle.Bin\
C:\$Recycle.Bin\*\
Please Note: This policy is going to block whatever file with the listed extension which is executing from the given locations. This may include also genuine third party applications or custom made applications.
You can anyway exclude custom application from being blocked adding them in the section “Do not apply to the following processes” located in the condition of the rule.
There are two most powerful tools from Sysinternals that can help us lot in our search for
suspected threats on our systems.
1. Autoruns for Windows
2. Procexp
AUTORUNS :
You can download Autoruns for Windows from http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx
Runs on Windows XP and higher and Server 2003 and higher
Logon This entry results in scans of standard autostart locations such as the
Startup folder for the current user and all users, the Run Registry keys, and
standard application launch locations.
Explorer Select this entry to see Explorer shell extensions, browser helper
objects, explorer toolbars, active setup executions, and shell execute
hooks.
Internet Explorer This entry shows Browser Helper Objects (BHO's),
Internet Explorer toolbars and extensions.
Services All Windows services configured to start automatically when the
system boots.
Drivers This displays all kernel-mode drivers registered on the system
except those that are disabled.
Scheduled Tasks Task scheduler tasks configured to start at boot or logon.
AppInit DLLs This has Autoruns shows DLLs registered as application
initialization DLLs.
Boot Execute Native images (as opposed to Windows images) that run
early during the boot process.
Image Hijacks Image file execution options and command prompt
autostarts.
Known DLLs This reports the location of DLLs that Windows loads into
applications that reference them.
Winlogon Notifications Shows DLLs that register for Winlogon notification
of logon events.
Winsock Providers Shows registered Winsock protocols, including
Winsock service providers. Malware often installs itself as a Winsock
service provider because there are few tools that can remove them.
Autoruns can uninstall them, but cannot disable them.
LSA Providers Shows registers Local Security Authority (LSA)
authentication, notification and security packages.
Printer Monitor Drivers Displays DLLs that load into the print spooling
service. Malware has used this support to autostart itself.
Sidebar Displays Windows Vista sidebar gadgets
Getting More Information about an Entry
There are several ways to get more information about an autorun location
or entry. To view a location or entry in Explorer or Regedit chose Jump To
in the Entry menu or double-click on the entry or location's line in the
display. You can view Explorer's file properties dialog for an entry's image
file by choosing Properties in the Entry menu. You can also have Autoruns
automatically execute an Internet search in your browser by selecting
Search Online in the Entry menu.
Autoruns is the best and most reliable (Since it is from Microsoft
Sysinternals ) tool for determining whether a file is Legitimate or
Suspicious.
Download and run Autoruns. Once it is executed it takes few minutes
(sometimes) to scan all the entries on your computer.
Once this is done on the top click on "Options" and select "Hide Microsoft
and Windows entries" then click on the refresh button.
Now whatever is left behind is the common load point for any Threat on
your System.
Browse through each of the tabs to check if you find anything without a
publisher or with a suspicious Name.
You will get the location and the registry entry for that file.
The best part is, If you are not sure about the file just right-click on it and
click "Search Online" and it will try to find some information on that file or
entry. Once you have got any suspicious entries either you just go ahead
and delete it by right-clicking on it or Submit it to Symantec Security
Response so that they will review the file and get back to you.
If it is clean you will get a mail that it is clean. If it is a threat you will get a
mail with complete steps on how to get rid of it and what actually it is
(Trojan/Worm/Spyware etc )
To submit the file to Symantec Security response go to https://submit.symantec.com/retail or /basic or /Essential or /BCS
depending on your support contract with Symantec.
PROCEXP :
You can download this tool from http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
It can be used in Windows XP and higher and Server 2003 and higher
Process Explorer is an advanced process management utility. You can call
it an advanced version of Task Manager
You can view detailed information about a process including its icon,
command-line, full image path, memory statistics, user account, security
attributes, and more. When you highlight a particular process you can view
the DLLs it has loaded or the operating system resource handles it has
open.
When we look at the Task Manager we are not able to determine what are
legitimate files and what are Unknown or threat files. We can also get the
location of where the file is located.
Threats mostly load under svchost.exe or rundll32.exe so in the task
manager it just shows that either svchost or rundll32 is running but when
we use Procexp we can know which DLL or while file is loading under
these and the location as well.
It also has a color coding and a publisher name against each process that
makes us easier to determine whether it is legitimate or suspicious.
Once we get the filename we can submit it to https://submit.symantec.com/retail or /basic or /Essential or /BCS
depending on your support contract with Symantec.
This document contains all the versions of SEP and SEPM (Symantec Endpoint Protection Manager) which were released since the first version of SEP in autumn 2007.
It contains the Enterprise Editions (EE) and Small Business Editions (SBE)
This is the sixth of an informal series on how to keep your enterprise environment secure using often-overlooked capabilities of Symantec Endpoint Protection (and the OS upon which it functions).
The first article, Using SEPM Alerts and Reports to Combat a Malware Outbreak, demonstrated how to use reporting features of SEP 12.1's SONAR component to identify Suspicious files for which there were no AntiVirus signatures yet created.
The second, Recovering Ransomlocked Files Using Built-In Windows Tools, deals with a few possible ways how to prevent and recover from one of today's most-destructive threats, should it infect your network and hold your data hostage.
Third came Two Reasons why IPS is a "Must Have" for your Network, which illustrated how SEP's optional Intrusion Prevention System (IPS) component can help security admins keep their organization secure and track down infected computers on the network
The Day After: Necessary Steps after a Virus Outbreak is for use after the attacks have ended. This fourth article intends to help admins prevent further attacks and make recovery from any future infection as painless as possible.
This new "Symantec Insider Tip" article aims to provide advice and examples of how to get your suspicious files to the correct team, in the correct format, with all the correct information necessary for speedy processing.
Symantec's Official Article
By "submission" I mean sending questionable files to Symantec's Security Response department for analysis. Please read the following article for the official word on the submissions process.
How to Use the Web Submission Process to Submit Suspicious Files
For files that are suspected of being malicious, your Technical Support Engineer can provide the correct submission URL based on your current contract.
Symantec adds protecion against thousands of new threats every day. Definitions are continuously updated in response to submissions received by customers, so please submit:
Files that are given bad reputations by the SymHelp Threat Analysis Scan with a recommendation to "submit" or "remove"
Files that are recommended for submission by Symantec Tech Support, after your SymHelp diagnostics or other logs are examined
Files which other vendors detect but are not found by Symantec Endpoint Protection or another Symantec security product
Files which a SEPM's SONAR or IPS reports indicate are responsible for suspicious activity
Malicious files that are engineered to attack Android, Linux, Mac and other non-Windows systems are also submitted through the same web portals. There's no special URL necessary for non-Windows threats.
What Not to Submit
In almost all cases, Security Response needs the undetected malicious executable file which is responsbile for the infection. Submitting any of the following to them will be of little use.
Text files, .ini files, .xml files and similar
Files that have been corrupted or locked by a threat like Trojan.Cryptolocker
Phishing mails (these are not harmful in themselves- if there is a mail with a suspicious attachment, submit that attachment. If the mail has a link to an .exe, download the .exe and submit that)
Files that have been digitally signed by Microsoft or another major vendor.
Files that are already detected by SEP or another Symantec security product (.vbn for example)
Screenshots of the malicious file or the damage it has done
Output from the SymHelp diagnostic tool (send those .sdbz or .sdbd files to Technical Support, not directly to Security Response!)
Any materials related to a new or existing Technical Support case
For safety reasons, anything submitted to Security Response stays in Security Response. Those files cannot be forwarded on to other departments.
The web portal system will not be able to process:
Files larger than 20 MB
Compressed (zipped) files with more than 9 files inside
Compressed (zipped) files which contain more than 20 MB of content
Compressed (zipped) files with a password
Compressed into a format other that ZIP or RAR
Also:
If you believe that a detection is a False Positive, please only submit it to https://submit.symantec.com/false_positive/. That's the way to make sure they get to the correct team.
How to Submit It
When filling out the form, you will need to provide your name, company name, email address and Support ID number. You can also enter comments into the Additional File Information field.
Tip!
Please be sure that the email address used for submissions is a Contact Email address associated with your company's account. Otherwise the submission may not be processed as quickly as your contract entitles.
Ensuring Everything is On Track
Immediately after submitting, there will be an acknowledgement screen displayed. A short time later, an email will be dispatched containing the submission's Tracking Number.
Use that reference should you need to make contact with any questions. If hours pass without receiving a Tracking Number, please check your junk mail folder or the email processing rules within your company. If there still is no sign of the mail, contact Technical Support to ensure that the submission has in fact been successfully recived and is being queued up for processing. (They can identify the submission using the unique MD5 hash of one of the submitted files or the email address that was specified.)
Submissions may be processed quickly or it may require several days. This all depends on the current amount of activity in the worldwide threat landscape- something beyond Symantec's control.
When analysis is complete, another email will be dispatched which contains an overview of the findings.
If that suspicious file has been confirmed to be malicious, this mail will contain information on how to download new Rapid Release definitions so you can apply protection throughout your organization.
The final mail sent will supply details, when available, on what file changes, network activity and other nastiness this particular malicious file does.
If you have submitted a file that you believe is malicious, don't just wait for Security Response to produce definitions against it! There are important actions that must be taken in order to prevent that infection from spreading its damage throughout your network. See Step 3. Quarantine the Infected Computers in the following article:
If you can't just pull the network cable on the infected computer, there are many ways SEP's components can lock down the system and the network and help slow the spread of the threat.
It's also a good idea to submit the file to threatexpert.com for a quick, automated analysis of the file. That may alert you to (for example) Internet IP addresses or domains that you should be blocking at the corporate firewall, severing communications to the threat's remote Command & Control servers.
Q. Can't I just email the malicious file to Symantec?
A. No, the only method of getting suspicious content to Security Response is via the web portal. Sales, Tech Support and other departments within Symantec cannot receive potentially malicious content.
Q. I thought SEP was automatically making a lot of submissions of files in the background- why don't I get Tracking Numbers for those?
A. When configured to do so, SEP will send anonymous data to Security Response. Symantec Response and the Global Intelligence Network use this submitted information to quickly formulate responses to new and developing security threats. The data that you submit improves Symantec's ability to respond to threats and customize protection. (So, please do always allow submissions!)
Image may be NSFW. Clik here to view.
As the information submitted is done so anonymously, there is no way to trace it back and send out a tracking number. The article below has details:
Q. We have found a mountain of malicious files! We've put them all in one giant 500 MB .zip. I can submit that, right?
A. Sorry, no. Think of all the freight deliveries coming into a city. Rather than building a supersized railroad with tracks 100 feet apart and a car big as a cruise ship, all the incoming goods are divided up into a long train of standard-sized freight cars. That's the way the delivery system is designed. The same goes for submissions to Security Response. Each .zip needs to have no more than 9 files within and a decompressed size of 20 MB or else it will go off the tracks.
Q. What if the file I need to submit is larger than 20 MB?
A. Malicious files are generally (but not always!) smaller than that. For large files, check with Tech Support. They can supply instructions on how to proceed.
Q. In my spare time I am building a comprehensive collection of every executable that has ever existed. Wow, there's a heaping cartload, and I'm only up to 1996! Just in case one of them may have been malicious, I'll submit these beauties all at once to Security Response to see if there has ever been a variant of virus, worm, or whatsit that your engineers have never seen.
A. Thanks, but no. Please only submit files that are suspected of being malware involved in a current outbreak on your own network. Our resources are committed to helping combat today's real-world security threats.
Q. I write code for a software company. Is there any way to submit my latest build to Symantec, ahead of its public release, to make sure my customers won't experience False Positives on this new (and initially unknown) version?
If in doubt about whether or not to submit a particular file, please do ask! Tech Support has trained experts who can examine a diagnostic and swiftly spot the suspicious materials within. They can also provide best practice and recommendations that can help keep your network, data and users safe.
Many thanks for reading! Please do leave comments and feedback below.
This is the standard interface to enter Explicit Group Update Providers in SEP 12.2.x:
Image may be NSFW. Clik here to view.
This interface is servicable enough with a small number of entries, but when you are entering in hundreds of entries, this interface can be time consuming. Using instructions similar to the KB article "How can I add a large number of hosts to a Host Group in Symantec Endpoint Protection", we can enter in multiple entries easily into the Explicit Group Update Provider List (or the multiple Group Update Provider list). Here are the instructions that are based off the ones in the linked knowledge based article.
1. Login into your SEPM management console
2. Go to Policies - Live Update
3. Export an existing Live Update policies that includes at least one explicit GUP in it that you want to bulk add GUP's to.
4. Rename the exported policy from *.dat to *.zip
5. Open up the zip archive and extract the main.xml file
6. Open the main.xml file
Image may be NSFW. Clik here to view.
7. Find the section marked <ExplicitGUPMapping> and copy the whole section.
8. Create a new excel document
9. Add a list of subnets in Column B of of the document and a list of the corresponding GUPs per subnet in Column D
Image may be NSFW. Clik here to view.
10. In Column F you will need to paste in a list of unique 128 bit Hex keys that are as long as your list of hosts
Image may be NSFW. Clik here to view.
11. Add the beginning XML tag to Column A (example: <ExplicitGupEntry ClientSubnet=")
Image may be NSFW. Clik here to view.
12. In Column C place the tag information that occurs after the subnet, but before the IP address (example: " GupMappingType=GUP_IPADDRESS" GupMappingValue=")
Image may be NSFW. Clik here to view.
13. In Column E we place the XML tag information that happens after the IP addres, but before the unique key (example: " Port=2967" _d="false" _i=")
Image may be NSFW. Clik here to view.
13. In Column G you paste in the closing tag information (example: " _t="1354330697081" _v="6"/>)
Image may be NSFW. Clik here to view.
Things to be aware of in this step as an FYI:
o _v parameters can all be the same
o _t parameters can all be the same
14. Use Excel to fill in Columns A, C, E, G with the information you placed in the first row.
Image may be NSFW. Clik here to view.
15. Copy Columns A through G and paste them into your text editor of choice. You will have to remove the the tabs in the document to get the formatting correct. If you are using Notepad copy one of the tabs and use Find/Replace to remove the tabs. After you are finished you will have a list that looks like this:
Image may be NSFW. Clik here to view.
16. Copy and past this into the explicit GUP section of the main.xml file
Image may be NSFW. Clik here to view.
17. Save the main.xml file and zip it up.
18. Rename the .zip file to a .dat file
19. Import this policy into your SEPM and have an updated list of GUP providers.
Image may be NSFW. Clik here to view.
This method should only be used if you are dealing with an extremely large number of GUPs. For a handful of GUPs any time savings you gained from this method would be minimal.
This same method can be used for inputting multiple GUPs into the SEPM by using the steps listed (altered for the XML) and going under the GUPRuleSet section of the main.xml file. For this section you will only need 4 columns. Column A will be the beginning of the XML tag, Column B will be the hex string that occurs after i=", Column C you can copy everything before the IP address, Column D will be your GUP IP Addresses, and Column E will be the closing of your XML tag following the IP address.
Test this in your development environment before importing it directly into your production environment.
Did you know that it IS possible to monitor web traffic using the SEP firewall? In this article, I will show you how to monitor web traffic using the SEP firewall.
Before we get started there are a couple of things you should be aware of:
While the SEP firewall can handle this task, Symantec Web Gateway is a better fit if you need to do this permanently
Monitoring web traffic will not work correctly if your web traffic goes through a proxy server. SEP cannot differetiate between proxied and non-proxied traffic. Another reason why SWG works better for this task.
With that in mind, let's get started.
Request: Monitor web traffic (port 80 and 443)
Solution: Configure the SEP Firewall to handle this task
The first step is to create a new network service for 80/44 traffic
Login to you SEPM and navigate to Policies >> Policy Components and highlight Networks Services. Under Tasks click Add a Network Service...
Type in a Service Name (Web Traffic) and click Add...
Leave the Protocol at TCP and add 80,443 in the Remote Port line. Click OK
You should see the following:
Image may be NSFW. Clik here to view.
One that is created, we can move on to adding a rule to the SEP firewall to monitor the traffic
Go into the Policies page and highlight the Firewall policy. Add a Firewall policy and give it a name (Monitor Web Traffic)
Click Add Rule...
Give the rule a name (Log_Web_Traffic)
Select the radio button for Allow Connections
Select the radio button for Only the applications listed below: and click Add...
Enter iexplore.exe in the File Name field and click OK. You can add more browser names if you wish.
Image may be NSFW. Clik here to view.
Click Next
Leave the radio button checked for Any computer or site. Click Next
Now, we need to select our newly created network service. Check the radio button for Only the communications selected below:
Put a check in the Web Traffic box and click Next:
Image may be NSFW. Clik here to view.
Select the radio for Yes to create a log entry when the rule is matched. Click Finish and make sure the new rule is at the top of the stack.A ssign the new policy to the groups you want to monitor traffic on and ensure the clients get the new policy.
Once clients start browsing, you can verify the rule is working by checking the logs on the SEPM. Monitors >> set Log type to Network Threat Protection, set Log content to Traffic. Edit any advanced settings that you want and click View Log
You will get a log similar to the below screenshot:
Image may be NSFW. Clik here to view.
You will likely need to highlight one of the lines and select Details to get more granular. Here we get a better view:
Image may be NSFW. Clik here to view.
So there you have it. Monitoring web traffic using the SEP firewall. It's really just a quick and dirty way to do it if you need something temporarily. Hopefully this has been helpful for you.
Here we can see how we can back up the database on demand. From the Admin page we've got the Back Up Database Now option and from the Start Menu > SEPM Tools, we can back up the database from there too.
Image may be NSFW. Clik here to view.
Backing up the embedded database: Scheduled
We can also set up a schedule to back up the database at a regular interval. So here we've set up the backup server using SEPM01. This is quite useful if you have multiple SEPMs accessing the same database. You can choose which SEPM is going to be responsible for taking the load of doing the backup. We can see the backup path. This isn't editable. This is the only location where the backup is stored, so you need to make sure that's the location that's being backed up and taken offsite. You can choose the number of backups to keep in this location. We can back up logs as well if you wish, that will obviously make the backup larger, and we have the Schedule Settings.
You can set up schedules for the automatic backup of both MS SQL and embedded databases in the SEPM.
Backups occur automatically at the scheduled time. Backup files are stored in a backup folder created in the path specified for the server data root.
To back up an embedded database from the SEPM console, in the SEPM console, click Admin. On the Admin page, click Servers and under View, click the icon that represents the embedded database.
Under Tasks, click Edit Backup Settings.
In the Backup Settings for Local Site dialog box, mark the Schedule Backups checkbox and specify the backup schedule.
The backup is placed in a zip file labeled with the date on which the backup occurs.
Image may be NSFW. Clik here to view.
Restoring the embedded database
And of course if we've done backups, we can do a restore of the database. To do the restore, we need to ensure the console is logged off and the service is stopped. Then from the Start Menu we choose the Database Back Up and Restore and then select the Restore option. You then need to drill down and find the particular backup to restore from. It will be searching that one database backup location. So if you have taken your database backups offsite, you would need to make sure they're being copied back to that location before you run this process.
Image may be NSFW. Clik here to view.
Configuring database maintenance
We need to ensure that our database is maintained. We can edit the database properties and set up General and Log Settings. That will enable us to prune the database size so we're only keeping a certain amount of data. We can choose to manage it by a number of entries or a number of days. Anything outside of that time will then be deleted. It's worth remembering and worth checking your compliance for this site because once the data has been deleted, it's not available for analysis or reporting.
Database maintenance options help you to manage the size of your database by specifying how long to keep data.
To configure database event options:
On the console, click Admin, select a site and click Edit Site Properties.
Click Database and on the Database tab, set the days to keep risk events. Set how frequently you want to compress identical risk found events into a single event and the number of days to keep the compressed events.
Image may be NSFW. Clik here to view.
Preparing for disaster recovery
So to prepare for disaster recovery, we need to make sure of course we've got all the backups of not only the database but also all the relevant files that are needed to recover the SEPM environment. Here we can see the database default backup file location. And we need to back up the disaster recovery file, which is another important file holding a lot of settings relevant to the configuration. We need to save the IP address and the host name of the SEPM so we can recreate it, and copy the files to the secure location.
Image may be NSFW. Clik here to view.
The disaster recovery file
The disaster recovery file holds a number of different information like the Apache details, the certificates and licensing, also the settings.propertiesfile holding a lot of very key information including your encryption password.Image may be NSFW. Clik here to view.
Best practice: Disaster recovery preparations
So some best practices for disaster recovery preparations. We have got a very good reference in the Implementation Guide for Preparing for a disaster recovery. But you need to make sure you have your relevant files including the sylink.xml, your disaster recovery files. Record all the names of the servers, the host names, the IPs. Make sure you know the information about the site details, the settings.propertiesfile, and make sure you test your disaster recovery procedure.
Image may be NSFW. Clik here to view.
Performing disaster recovery
So to perform a disaster recovery we need to restore the SEPM Manager using that disaster recovery file, which will restore the database to the point in time.
Image may be NSFW. Clik here to view.
Helpful links:
Article: Symantec Endpoint Protection 12.1: Best Practices for Disaster Recovery with the Symantec Endpoint Protection Manager
This is the fourth of an informal series on how to keep your enterprise environment secure using often-overlooked capabilities of Symantec Endpoint Protection (and the OS upon which it functions).
The first article, Using SEPM Alerts and Reports to Combat a Malware Outbreak, demonstrated how to use reporting features of SEP 12.1's SONAR component to identify Suspicious files for which there were no AntiVirus signatures yet created.
The second, Recovering Ransomlocked Files Using Built-In Windows Tools, deals with a few possible ways how to prevent and recover from one of today's most-destructive threats, should it infect your network and hold your data hostage.
Third came Two Reasons why IPS is a "Must Have" for your Network, which illustrated how SEP's optional Intrusion Prevention System (IPS) component can help security admins keep their organization secure and track down infected computers on the network
This fourth article is for use after the attacks have ended. It intends to help admins prevent further attacks and make recovery from any future infection as painless as possible.
Malware infections can be devastating. Crucial files corrupted, data lost, intellectual property stolen, reputation tarnished, endless man-hours of labor wasted. Every company has their horror stories.
Hopefully not! Though the steps necessary for recovery will differ from network to network and threat to threat, once an outbreak is over, there is always one best course of action: Learn the lesson- prepare better defenses.
How Did the Bad Guys Get In?
If possible, determine how and where this infection began. See if the entry route can be determined- and that door firmly shut!
This will be difficult, as SEP is not a forensic application. It may be possible to see which computers have had active Downloader threats on them: identify all the computers that were affected by a particular threat, and then examine those systems in more depth.
As an example: an exported Risk Report from the SEPM will contain the unique hash of the threat sample. With some filtering (and hiding columns for clarity), it's clear that all of the following computers detected the same Downloader.Trojan on the same day. Chances are this malicious .exe had been present there, and then new definitions were downloaded and applied which added detection against it. The next time the application ran (or a scheduled scan ran) it was picked up.
Image may be NSFW. Clik here to view.
My advice would be to examine those five computers to see if they have weak passwords, or are missing patches and hotfixes, or if they have peer to peer clients installed, or if their internet browser download history shows unusual activity. See what clues might be there!
Change the Secret Plans- Quick!
Many threats have the ability to ability to upload files from a compromised computer. If the outbreak that has just ended was one with Infostealer capabilities, ask "what information did the intruders have access to?"If sensitive data was on the laptop, workstation or server that was even temporarily pwned, assume that it is now in the hands of an unknown remote party. Take measures, if possible, to ensure that what they got away with is outdated and useless. For instance:
There have been cases where databases full of customer usernames and passwords have been stolen. Inform whoever needs informing and then ensure that all of those user passwords are reset.
In other cases, attackers have left behind evidence that the details of every account in Active Directory were harvested. In such cases, hackers can RDP right into the company at will using valid admin credentials (without needing a single piece of malware) unless strong new passwords are made mandatory for every account.
The chances of sensitive data being successfully stolen are reduced if Data Loss Prevention (DLP) is used. If such a security tool is not already in use, it might be a good idea to implement one before there is another breach. The 2013 Cost of Data Breach Study may help determine if DLP is a good investment.
Do Not Fight with One Arm Behind Your Back and Shoelaces Tied Together
Too many companies are still relying on old releases of SEP that have only the bare-minimum AV component installed. Symantec Endpoint Protection is not Symantec AntiVirus, our long-retired product which only offered traditional signature-based scanning. SEP a powerful suite of security tools.
SEP 11 (which is now past its End Of Limited Support) came with AntiVirus, plus optional Proactive Threat Protection (PTP), firewall, IPS, and Application and Device Control (ADC) components. SEP 12.1 enhanced the performance and effectiveness of all of those tools and added the powerful Insight reputation-based protection.
To dramatically improve the defense of your network and everything on it, use a modern product with adequate components. AV, IPS and Insight should be seen as an absolute minimum. ADC, PTP and Network Threat Protection (NTP, the firewall) supplement their power at blocking malicious activity before it can get in place, and make removal much easier. Definitely upgrade and use these features!
It's appropriate to quote at length from Step 5. Post-op: Prevent Recurrence here:
Patching vulnerabilities
Vulnerabilities are computer software flaws that can be exploited by malicious code. These vulnerabilities can be repaired by applying patches provided by the software vendor. In today's network environment, regular patching is a requirement. Every network should have a Patch and Configuration Management Policy for testing new patches and rolling them out to client computers. Patching plans should focus not just on operating systems and browser add-ons, but all deployed software. Any software installed on a computer should be regularly checked for updates—from office utilities to databases to web server applications. All software should be cataloged and regularly checked for updates. Internally developed code should be regularly audited for security holes and fixed as soon as possible. Appliances such as routers and printers should also be checked for software updates and patched quickly. This can be a lot to manage, but it is vitally important in preventing security incidents.
AutoPlay (AutoRun)
Autoplay is a functionality in Windows that allows files to automatically be opened or "played". This feature is useful to launch installation files and other applications from CDs and USB flash drives, but over the last few years has become one of the largest attack vectors in the enterprise environment. While USBs may provide an initial source of infection through the use of AutoPlay, most network drives are designed to use this functionality too. This allows threats to attack from a network drive as soon as the drive is mapped. Since antivirus software is designed to scan the local hard drive, the threat will be able to attack the client computer without detection or prevention, unless additional measures like Network Auto-Protect are employed.
In order to protect your network, disabling AutoPlay is the recommended course of action. This can be done on individual computers, pushed out to client computers using the Group Policy editor, configured by a policy in Symantec Endpoint Protection, or accomplished by disabling the external media ports on the computer entirely from within the BIOS. There is also a known Windows vulnerability within the autoplay feature that may re-enable it unless Windows patches are applied.
Network shares
First and foremost, access to all network shares should require a strong password not easily guessed. "Open Shares" are network shares that allow the inherited permissions from the user to validate access. These do not require an additional authentication and therefore allow threats to spread very fast. Open shares should be minimized as much as possible, and when they are absolutely essential to business continuity, write and execute privileges should be restricted.
If a user only needs to obtain files from a source, they should only be granted read access. For added security, write access for users needing file-transfer capabilities can be limited to a "temporary" storage folder on a file server, which is cleared semi-regularly. In terms of execution permissions, limit this access to administrators or power users who have such need. Disabling or limiting access to two other share-types is also recommended: Admin$ shares allow complete root access on a computer to any user that can authenticate as a member of the administrator group; Inter-Process Communication (IPC) shares, or IPC$, are intended to help communication between network-available processes and other computers on the network.
The problem with the aforementioned shares is that, regardless of whether strong passwords are in place, once a user is logged on to a system with elevated rights, any threat present can use the credentials to access Admin$ or IPC$ shares available on the network. Once the user is logged in, the rights and permissions are implicit -- the door has been unlocked. Anything that user account has access to will be accessible to anything that impersonates the account.
The best practices in this regard are:
Do not auto-map network shares, instead supply a desktop icon to allow users access to the drive as needed.
Do not log on using an account with elevated privileges (such as the domain or local Admin) unless absolutely necessary to perform a certain task.
Be sure to log off once the task is completed.
For most day to day duties, use a more restrictive account.
Email
Email attachments, while perhaps not as prevalent as in years past, are still used to spread malicious code today. Most email servers currently on the market provide the ability to strip certain attachment types from emails. Limiting the types of files that are valid as attachments handicaps many threats' ability to spread.
Investing in AntiSpam software is another way of reducing exposure to threats. Doing so reduces the number of phishing scams and spam that reach end users, and thus the network as a whole.
Education
An educated end user is a safer end user. Ensure that your users understand the basics of safe computing, such as the following:
Do not give passwords to anyone or store them in an easily accessible location, either physical or electronic.
Do not open unexpected email attachments from known or unknown sources.
Do not click on unknown URLs.
Scan software downloaded from the Internet before installing it.
Having documentation, internal training, or periodic seminars on computer security available gives your users options for learning more about the topic.
Firewalls and other tools
Perimeter firewalls are critical to protect the network as a whole, but cannot cover all points of entry. Client firewalls add an extra layer of security by protecting individual computers from malicious behavior, such as Denial of Service attacks, and are critical to manage today's threat landscape.
Beyond basic firewalls, network and host-based Intrusion Detection Systems (IDS) and Intrusion Protection Systems (IPS) can help monitor unwanted activity on the network, and in many cases stops or alerts on the offending traffic in real time. Many client-side firewalls today provide these features.
Emergency Response Team and Plans
Even after all these tasks are complete, it is still a good idea to be prepared in case of the worst. Draft a plan how to respond to a potential outbreak and assign tasks and responsibilities to members of an Emergency response team. How quickly will an alert be generated if there's something on the network? Will there be administrators available to deal with it? How easy is it to reroute traffic and services on the network? Can compromised computers be isolated quickly before they affect other computers? Having plans in place for these things makes dealing with unpleasant situations much easier and saves both time and money.
Great Stuff! What Other Steps Should Also Be Done?
Use "Defense in Depth." Don't just defend at the endpoint- have a corporate firewall, mail security product and so on to safeguard all means of entry.
Final Recommendation
Your Symantec Endpoint Protection Manager contains in-depth records of threat-related activity, and the SEPM can alert you when there is a potential security incident for which manual action should be taken. For example, some threats have ways of "tricking Windows" into protecting their processes from certain AntiVirus technologies. It is possible to create a notification for incidents where SEP detects a threat but ultimately leaves it alone.
Image may be NSFW. Clik here to view.
In the above example, the administrator will receive a mail whenever and of these Left Alone events occur. The admin can then take a closer look at that computer and stop an infection before it can secure its foothold. So: definitely use SEPM notifications and scheduled reports. These empower admins to know what is happening in their network- much better than finding out a breach from the news media or from law enforcement!
Conclusion
Increase the Peace! With a bit of best practice and careful attention, disasters can be avoided. Yes, some effort will be involved- effective preventative measures can either be taken now, or there can be a lot of panicked screaming and running around in a mad rush during the next inevitable breach or destructive outbreak. Symantec provides the tools, but what happens to your business tomorrow is up to you.
Many thanks for reading! Please do leave comments and feedback below.
DLP Agent supports to be installed in a Failover environment. Think about two endpoint servers, the first one is the Primary Endpoint Server and the other one is the Secondary Endpoint Server. The DLP agent can be installed under these two endpoint server. And, if the primary endpoint server is down, the DLP agent will connect to the secondary endpoint server after the timeout.
On the example below, we installed two endpoint server under the same DLP enforce server with these two IP address: 192.168.1.201 and 192.168.1.202. These two servers are named as Primary Endpoint Server and Secondary Endpoint Server.
Image may be NSFW. Clik here to view.
Then, during the installation of the DLP agent, we need to input the IP address or the hostname of these two servers at the same time:
Image may be NSFW. Clik here to view.
After the installation, the DLP agent will connect to the Primary Endpoint Server. We can check this by the netstat command on the DLP agent:
Image may be NSFW. Clik here to view.
There are two method to change the endpoint server of the DLP agent.
The first one is using the DLP Enforce Server Console:
select the DLP agent from the console, click 'Actions' button, choose 'change Endpoint Server':
Image may be NSFW. Clik here to view.
The second one is letting the DLP agent change the endpoint server after failover.
Defaultly, the DLP agent will change to the secondary endpoint server after 3600 seconds after the primary one is down. We can change this timeout in the Agent advanced settings:
Image may be NSFW. Clik here to view.
After the timeout, we can check the connection on the DLP agent again:
At the core of Symantec DLP, lies the policy of it, which determines the successful or not so successful implementation of Symantec DLP at organizations. Since DLP is not the perimeter security or the endpoint security, it is the security built around data itself, therefore, it can cause huge impact if policy is not defined properly. And this is the reason, why Symantec DLP is always implemented in monitor mode initially! This means that if policy is violated, incident will be raised but there won't be any blocking.
In this article, we will briefly look into the policy of Symantec DLP. This should give beginner a kick start understanding of policy of Symantec DLP in few minutes of time. Before that, if you wish, you can see the below links for Symantec DLP basics for beginners.
Whether it is data loss prevention through endpoints(PC, Laptop) or data in motion (network, email) or data at rest (SAN, NAS etc), Symantec DLP matches the data against the policy that is defined. If data matches with policy, defined action is taken (monitor or block or move to safer location etc)
Policy is defined and resides on Enforce platform and on detection servers. For defining and modifying policy, you must have access to administrator account of DLP. Policy can be built from scratch or we can choose to create from 60+ templates which is already defined by Symantec. These templates are grouped according to different industry like pharma, banking and finance etc.
Policy has two different parts:
1. Detection Rules
2. Response Rules
Detection Rules:
There are two main ways of detection.
1. Described data: Where we can describe the data clearly with the help of keywords, data identifiers, regular expressions etc. This is most simple way to define rules. For example- in regular expression, we can define a number(say account number). We can define that the account number is 10 digits, where first 5 digits is only 0 and 1, and next 5 digits are 0 to 8. In this case, if the number in a file which is going out through email is 1230945689, then no policy is triggered. But, if the number is 0001180012, then policy will be triggered and incident will be generated if other conditions of policy also match. As per the regular expression definition, 1st number is not the account number, but 2nd number is account number.
2. Fingerprinted data: This consists of structured data, also called as Exact Data Match (EDM) and unstructured data, also called as Index Data Match (IDM). In EDM, we can defined database, its table or its combination. If anything from that is sent out, policy is triggered. Whereas in IDM, we have to provide the whole document in the policy. Symantec DLP makes an index from that document. Now, policy can be defined that if, say 60%, of this document is being sent out, policy should be triggered.
Threshold count can also be defined. This will say that if an email contains 10 account numbers then only incident should be generated. Also And, Or, If logic can be defined. Exceptions can also be defined.
Response Rules:
There are many response rule that can be set. One of them is notification where email can be sent to sender/manager/IT security. On-screen pop up can be enabled.Another response rule is blocking. With blocking data leakage can be prevented. Another response rule can be conditional encryption of data, data being moved to other location etc. Custom response rule can also be created.
All detection capabilities (EDM/IDM/DCM) are compatible and accurate with many Western European and Asian languages. For unsupported languages, many detection processes may still work, but are not fully tested. User interface localized many languages too. For details, you may need to contact Symantec.
Defining policy rules in Symantec DLP is so flexible and dynamic, that almost any condition can be met and policy can be written for that. Obviously, with the flexibility, also comes the complexity.
With this, I tried to provide a glimpse of what policy and rules are in Symantec DLP. This is a very huge subject in itself and learning to define policy takes substantial amount of time. For more details, one can refer to Symantec Admin Guide for DLP or help files on policy page of Symantec DLP.
This whitepaper focuses strictly on providing guidance on how to successfully deploy the Symantec Endpoint Protection 12.1 protection stack components to a Citrix VDI Environment. This whitepaper does not cover deploying Symantec Endpoint Protection 12.1 workstations in a non-VDI environment or other more general administration concerns or Citrix server best practices in general; for guidance on these topics, please refer to the relevant product documentation. Note also, to date the content of this document has been validated with the US English versions of Citrix XenServer 5.6, XenDesktop 5.6 and Provisioning Services 6.0 as well as Symantec Endpoint Protection 12.1 RU1 running on Microsoft Windows Server 2008. Symantec Endpoint Protection can function seamlessly in a Citrix VDI environment. Simple policy and configuration changes can increase performance and reliability in that environment.
Supporting Links and Other Useful Online Resources:
Best Practices for Symantec Endpoint Protection on Citrix and Terminal Servers
Symantec Endpoint Protection Small Business Edition 12.0 Frequently Asked Questions
What are the new features in Symantec Endpoint Protection Small Business Edition 12.0 ?
Image may be NSFW. Clik here to view. Uses Apache as the web server instead of IIS
Image may be NSFW. Clik here to view. Built in Flash Video tours
Image may be NSFW. Clik here to view. Integrated Online Support Tool, Peer-to-Peer Discussion Forums, Contact Support
Image may be NSFW. Clik here to view. Licenses is required to be installed.
Image may be NSFW. Clik here to view. Serial No. of the Product can be seen in the Console
Image may be NSFW. Clik here to view. Number of license allocated to clients and number seats left can be seen in the Console.
Image may be NSFW. Clik here to view. Link to download SEP Support Tool from the SEP Client User Interface
Image may be NSFW. Clik here to view. Tamper Protection and Proactive threat protection are hardcoded and are enabled .
Image may be NSFW. Clik here to view. SEP Firewall disabled by default
Image may be NSFW. Clik here to view. Clients will conduct their own LiveUpdate call daily at 9:45 PM
Image may be NSFW. Clik here to view. The database will automatically purge data as it becomes old or as the database fills up. No database configuration or maintenance is required.
Image may be NSFW. Clik here to view. A weekly Executive Summary report and a notification messages will be delivered to the email specified during the installation. These reports and notification messages are configurable and additional Email addresses can be added as needed.
Image may be NSFW. Clik here to view. Administrators can reset forgotten passwords of SPC.
Are there any features or functions in SEP 11.0 that are not in Symantec Endpoint Protection 12?
The following Features of SEP 11.0 are not there in SEP 12.0
Image may be NSFW. Clik here to view. There is no location awareness functionality
Image may be NSFW. Clik here to view. Replication functionality is not there
Image may be NSFW. Clik here to view. SEP 12 supports Only single site type of deployment with Embedded Database
Image may be NSFW. Clik here to view. No AD integration
Image may be NSFW. Clik here to view. No GUP functionality
Image may be NSFW. Clik here to view. SQL is not supported.
Image may be NSFW. Clik here to view. Client communication mode cannot be changed.
Image may be NSFW. Clik here to view. No option to add password to stop the smc service from the SPC.
Image may be NSFW. Clik here to view. No option to add a Management server list
Image may be NSFW. Clik here to view. No option to add Domain
Image may be NSFW. Clik here to view. Database configuration is hidden.
Image may be NSFW. Clik here to view. There is no option to configure a Internal live update server .
Image may be NSFW. Clik here to view. Firewall Rules/Policy has been scaled down.
Image may be NSFW. Clik here to view. Default client communication port is 8014 .This will change if port is being utilized it will search and bind to next open port. This is hard coded
Can LUA be configured with SPC ( SEP 12) ?
NO. SPC can only take update from Symantec Live update .
Can we update the definition of SPC using manually?
Yes we can use .jdb to update the definition manually on SPC.
Can I deploy the SEP 12 Client using AD GPO?
Yes the SEP 12 client can be deployed using AD.
Will I be able to use the Symantec Protection Center to manage SEP 11.0 clients ?
No SPC will only manage a SEP 12 client , not SEP 11 or SAV 10 clients.
How many client are supported by SEP 12?
The maximum number of clients supported by SEP 12 is 100.
Can SPC receives logs from SAV 10.x. ?
Yes the logs of SAV 10.x can be seen in SPC
How can I create a single exe package in SEP 12?
We can create single exe using the Custom Installation ( Advanced ) option of the client Installation wizard
What is the migration path for SEP 12 ?
Migration detects and migrates installations of the following Symantec legacy virus protection software:
Image may be NSFW. Clik here to view. Symantec AntiVirus Corporate Edition 9.x and 10.x
Image may be NSFW. Clik here to view. Symantec Client Security 2.x and 3.x
Image may be NSFW. Clik here to view. Symantec Endpoint Protection client 11.x
Are all client settings migrated?
No. Tamper Protection settings are not migrated. The Antivirus , Liveupdate and Centralized exception settings are migrated
Follow the below procedure steps provided here to deploy Endpoint FlexResponse plug-ins.
Procedure Step 1 : Obtain (or create) an Endpoint FlexResponse plug-in zip file.
Contact a Symantec partner or Symantec sales representative.
Endpoint FlexResponse plug-ins are not available with the default Symantec Data Loss Prevention installation.
Procedure Step 2 : Configure any Endpoint credentials on the Enforce Server. (Note :This step is optional)
Configuring endpoint credentials :
You must add credentials to the Credential Store before you can access credentials for Endpoint FlexResponse or the Endpoint Discover Quarantine response rule. The credentials are stored in an encrypted folder on all endpoint computers that are connected to an Endpoint Server. Because all endpoint computers store the credentials, you must be careful about the type of credentials you store. Use credentials that cannot access other areas of your system. Before your endpoint credentials can be used, you must enable the Enforce Server to recognize them.
To create endpoint credentials
1] Go to: System > Settings > General.
2] Click Configure.
3] Under the Credential Management section, ensure that the Allow Saved Credentials on Endpoint Agent checkbox is selected.
4] Click Save.
5] Go to: System > Settings > Credentials.
6] Click Add Credential.
7] Under the General section, enter the details of the credential you want to add.
8] Under Usage Permission, select Servers and Endpoint agents.
9] Click Save.
Procedure Step 3 : Deploy the plug-in to your endpoint computers using the Endpoint FlexResponse utility and third-party systems management software (SMS).
About deploying Endpoint FlexResponse plug-ins on endpoint computers
You must install Symantec DLP Agents on the endpoint computers before deploying Endpoint FlexResponse plug-ins. The Agents must be connected to an active Endpoint Server.
See the Symantec Data Loss Prevention Installation Guide for information on how to install the agents.
You must deploy Endpoint FlexResponse plug-ins on each endpoint computer where you require Endpoint FlexResponse actions. You can use a manual installation or a silent installation method to deploy the plug-in. Silent installation methods involve using systems management software (SMS), to distribute and install software on all of your endpoint computers. You may need to create SMS scripts to access the installation folder.
This section assumes that you have created or otherwise obtained an Endpoint FlexResponse plug-in that is packaged as a ZIP file.
Deploying an Endpoint FlexResponse plug-in on endpoint computers requires the following steps:
Step 1 : Copy the Endpoint FlexResponse utility to your endpoint computers.:
You use the Endpoint FlexResponse utility to manage Endpoint FlexResponse plug-ins. The Endpoint FlexResponse utility is not part of the default Symantec Data Loss Prevention download and is only available through Symantec or Symantec partners.
Step 2 : Copy any third-party Python modules that your plug-in requires to your endpoint computers.
Step 3 : Enable Endpoint FlexResponse on the Enforce Server :
Enabling Endpoint FlexResponse on the Enforce Server
Before you can use Endpoint FlexResponse plug-ins in your response rules, you must enable Endpoint FlexResponse functionality through the Enforce Server. By default, Endpoint FlexResponse functionality is not enabled. You enable Endpoint FlexResponse functionality through the Advanced Agent Settings.
To enable Endpoint FlexResponse functionality
1] Open the Enforce Server administration console and navigate to: System > Agents > Agent Configuration and open the Agent configuration that is currently applied to the Endpoint Server that is connected to the Agents where you are deploying the Endpoint FlexResponse plug-in.
2] Click the Advanced Agents Settings tab.
3] Find the PostProcessor.ENABLE_FLEXRESPONSE.int setting.
4] Change the setting to 1.
5] Click Save and Apply.
Step 4 : Deploy the Endpoint FlexResponse plug-in using the Endpoint FlexResponse utility. (flrinst.exe). Use one of the following options:
Deploy your plug-in manually on a single endpoint computer. This option is most useful when you are developing or testing an Endpoint FlexResponse plug-in.
Deploying an Endpoint FlexResponse plug-in using the Endpoint FlexResponse utility
You use the Endpoint FlexResponse utility to deploy Endpoint FlexResponse plug-ins. The plug-ins must be in a .zip package format.
To deploy an Endpoint FlexResponse plug-in
1] On an endpoint computer, open a command window and navigate to the Symantec DLP Agent installation tools directory. The default location of this directory is c:\Program Files\Manufacturer\Endpoint Agent\
2] Enter the following command:
flrinst.exe -op=install -package=<path_to_plug-in> -p=<myToolsPassword>Where:
<myToolsPassword> is the Tools password for your Symantec Data Loss Prevention deployment. If you have not specified a Tools password, use the default password: VontuStop.
<path_to_plug-in name> is the full path to the plug-in .zip file.
Deploy your plug-in using a silent installation process and SMS software. This option is most useful when you are deploying a production-ready Endpoint FlexResponse plug-in.
Deploying Endpoint FlexResponse plug-ins using a silent installation process
You can use system management software (SMS) to deploy Endpoint FlexResponse plug-ins on multiple endpoint computers. Although the details of creating installation scripts for SMS software are beyond the scope of this document, note the following requirements:
You must install Symantec DLP Agents on the endpoint computers before deploying Endpoint FlexResponse plug-ins. The Agents must be connected to an active Endpoint Server.
You must install the Endpoint FlexResponse utility (flrinst.exe) on each endpoint computer where you will deploy Endpoint FlexResponse plug-ins.
You must make the Endpoint FlexResponse package ( a .zip file) available to each endpoint computer. You can copy the package to each endpoint computer, or you can make the package available on a network drive that is accessible by all endpoint computers.
To deploy your plug-in, use the command-line options of the Endpoint FlexResponse utility when creating your installation scripts.
Remove the Endpoint FlexResponse utility after deploying your plug-in. If you leave the utility installed on the endpoint computers, a malicious user could use the utility to uninstall or alter your Endpoint FlexResponse plug-in.
See your individual SMS application documentation for more information on how to deploy using SMS.
The Endpoint FlexResponse utility is only available through Symantec and Symantec partners. It is not included with the Symantec Data Loss Prevention distribution.
Step 5 : Create response rules that use Endpoint: FlexResponse actions that reference the plug-in, and add these rules to an active policy.
See "Implementing policy detection" in the Symantec Data Loss Prevention System Administration Guide.
Procedure Step 4 : Enable Endpoint FlexResponse actions on your Enforce Server :
Enabling Endpoint FlexResponse on the Enforce Server
Before you can use Endpoint FlexResponse plug-ins in your response rules, you must enable Endpoint FlexResponse functionality through the Enforce Server. By default, Endpoint FlexResponse functionality is not enabled. You enable Endpoint FlexResponse functionality through the Advanced Agent Settings.
To enable Endpoint FlexResponse functionality
1] Open the Enforce Server administration console and navigate to: System > Agents > Agent Configuration and open the Agent configuration that is currently applied to the Endpoint Server that is connected to the Agents where you are deploying the Endpoint FlexResponse plug-in.
2] Click the Advanced Agents Settings tab.
3] Find the PostProcessor.ENABLE_FLEXRESPONSE.int setting.
4] Change the setting to 1.
5] Click Save and Apply.
Procedure Step 5 : Add Endpoint FlexResponse actions to your response rules :
Adding a new response rule
Add a new response rule from the Manage > Policies > Response Rules > New Response Rule screen.
To add a new response rule
Click Add Response Rule at the Manage > Policies > Response Rules screen.
At the New Response Rule screen, select one of the following options:
Automated Response
The system automatically executes the response action as the server evaluates incidents (default option).
Smart Response
An authorized user executes the response action from the Incident Snapshot screen in the Enforce Server administration console.
Symantec Help (SymHelp) is a diagnostic utility designed for Symantec Endpoint Protection used in identifying common issues and providing quick solutions to common problems. SymHelp - with a run time around three minutes - provides the ability to automatically detect whether a system with a supported Symantec product has a known issue or is in an otherwise problematic condition. In addition to the individual tests results and their statuses, the SymHelp report contains links to documents in the Symantec knowledge base which provide detailed information on how to resolve an issue or pursue further investigation as to its cause and resolution.
SymHelp does not permanently alter any files on the computer unless the user explicitly agrees to this when specially prompted. SymHelp does not permanently install anything on your computer when it runs.
To learn more about how SymHelp can help with your Symantec Endpoint Protection can help solve your problem quickly, take a look at the following video:
In situations where SymHelp is unable to successfully resolve your issue, SymHelp can help expedite your experience with our Technical Support staff by capturing essential logs and uploading them so that Symantec has the information available to quickly identify problems and provide solutions.
To learn more about how SymHelp can help with your Symantec Endpoint Protection case, take a look at the following video:
