How to solve Error: “Error 1802: Corrupted incident received”

By | Symantec DLP Enforce | No Comments

Extend the tablespace:
See technote, Extend tablespace (LOB_TABLESPACE, USERS, etc.) when nearly or critically full
Once you have resolved the tablespace issue, you can rename the .bad files to .idc files, and the system will then store them in Oracle normally.
See technote, What is a .bad file?
Open a command prompt as Administrator
cd to the incidents folder on Enforce:
\SymantecDLP\Protect\incidents (Windows)
/opt/Vontu/Protect/incidents (Linux) or /var/SymantecDLP/incidents
As a precaution backup all files in the incident folder to another location.
Rename the files from .bad to .idc.
Here is an example of the files, be sure to only rename the .bad to .idc.
Before: l1508521889832.idc_1506531432885.idc.1510146362333.bad

After: l1508521889832.idc_1506531432885.idc.1510146362333.idc

You can run the following command to rename all the files at once:

rename *.bad *.idc

Enforce should then begin to process the incident file.
Note: If you see incidents from some detection servers that are being stored normally, the cause is unrelated to a tablespace issue and the cause is likely due to a configuration issue on the affected detection servers.

Creating a new agent attribute in Symantec DLP

By | Symantec DLP Endpoint Prevent, Symantec DLP Enforce | No Comments

To create user-defined attributes, follow these steps:

  1. Choose Agent Groups from the System > Agents menu. Then, click the Manage Agent Attributes link.
  2. On the Agent Attributes screen, click New to begin the attribute creation process. A Configure Agent Attribute screen appears.
  3. Add the name of the attribute. Names can contain 1 to 100 characters.
  4. Add a description of attribute. Descriptions must contain only alpha and numeric characters.
  5. Select a domain, either User Domain or Machine Domain. There are two types of attributes for user-defined agent groups:
    • User Domain – Attributes related to the logged-in user; for example, the domain attribute “department.”
    • Computer domain – Attributes related to the computer; for example, computer attribute “location.”
  6. Add a search filter. You can select from existing applied attributes to define a search filter.
  7. Specify an Active Directory attribute. Only Active Directory attributes are supported for user-defined agent group attributes.
  8. Click Save. Clicking Save saves your attribute but does not apply it.
  9. Test the attribute and fix any issues you find in testing. To test, export the attribute(s) from the Attribute List screen and review the attribute. Then, use the Attribute Query Resolver test tool that runs on the Windows host where the endpoint is installed, to test the attribute
  10. Apply the tested attributes. Agents start reporting attribute values as soon as the agents resolves the attributes on Active Directory.
  11. Verify that agents are reporting attribute values. Go to the System > Agents > Overview > Agent List screen and verify that the agents are reporting attribute values. You can select a particular agent entry and see the Preview Pane. The Preview Pane lists all predefined and user-defined attributes and their values, conflicts, and alerts.

Configuring LDAP Lookup Plugins in Symantec DLP 15.5+

By | Symantec DLP Enforce | No Comments

To configure one or more LDAP Lookup Plugins, need to follow the below procedure steps.
 

#Description
1Add directory connections from System > Settings > Directory Connections                a) Confirm Authentication test is successful                b) Go to Index Settings tab, complete rebuilding the index (MUST be completed at least once)                c) Go to Index and Replication Status – confirm information is populated with version number and date etc.
2Create custom attributes: (say)Employee Info———————TitleNamePhoneEmailOffice Location Business Info——————DivisionDepartment 
3Create a LDAP plug-in                a) Configure Lookup Parameters                b) Modify Lookup Plugin Chain to enable the plugin               c) Reload plugin each time any modification is made
4Test Lookup

It is important to understand the User Objects in Active Directory Users and Computers and their corresponding LDAP mappings. LADP mapping attributes may differ for different versions of AD schema. See the Microsoft artile for User Object User Interface Mapping.

Reference:
https://docs.microsoft.com/en-us/windows/desktop/ad/user-object-user-interface-mapping

http://edocs.mitel.com/UG/UCA_Web_Help/Admin_Web_Help/7.0/uca/common_ad_ldap_field_mappings.htm

You may need to run a powershell command to find all properties of the user with samAccountName and collerate attributes mapping. For example, you want see all properties of the user BobJones in your AD. Try the following command in powershell:  PS C:\> Get-ADUser BobJones -Properties *

Reference:

https://ss64.com/ps/get-aduser.html

Say you want to display the following Attributes and here’s the steps are needed:

AttributesAs per Microsoft KBUse Get-ADUser (your env)
Business Divisioncompanycompany
Business Departmentdepartmentdepartment
Employee TitletitlebusinessCategory
Employee NamedisplayNamedisplayName
Employee PhonetelephoneNumbermobile
Employee EmailE-mail-Addressesmail
Employee Office LocationphysicalDeliveryOfficeNameoffice

So the attribute will look like below:

attr.Name=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):displayName

attr.Office\ Location=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):office

attr.Office\ Phone=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):mobile

attr.Email=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):mail

attr.Division=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):company

attr.Department=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):department

attr.Title=:(|(sAMAccountName=$endpoint-user-name$)(sAMAccountName=$file-owner$)):businessCategory

Disable SSLv3, TLSv1.1, and TLSv1.0 on Data Loss Prevention components

By | Symantec DLP Enforce | No Comments

Configuration change

$DLPDIR is the DLP installation directory

TunnelFile/parameterOld valueNew valueNotes
Browser <–> Enforce serverEnforce:$DLPDIR/Protect/tomcat/conf/server.xmlsslEnabledProtocols=”TLSv1,TLSv1.1,TLSv1.2″sslEnabledProtocols=”TLSv1.2″Recycle Vontu Manager service
Enforce <–> Detection serverEnforce:$DLPDIR/Protect/config/MonitorController.properties andDetection:$DLPDIR/Protect/config/Communication.propertiesSSLcipherSuite = TLS_RSA_WITH_AES_128_CBC_SHASSLcipherSuite = TLS_RSA_WITH_AES_128_CBC_SHA256Ensure SSLautonegotiate is set to false in both files.
Recycle Vontu Monitor and Vontu Monitor Controller services
Detection/Endpoint server <–> Endpoint agent“EndpointCommunications.SSLCipherSuites” in Enforce Management Console (System > Servers > Overview > Server Settings)TLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHA256Recycle Vontu Monitor service (Endpoint server) 

How to create, sign, and import an SSL certificate signed by a Trusted Certificate Authority

By | Symantec DLP Enforce | No Comments

Keytool.exe location

  • Windows:
    • 14.x and 15.0: <DRIVE>:\SymantecDLP\jre\bin
    • 15.1: <DRIVE>:\Program Files\Symantec\Data Loss Prevention\Server JRE\1.8.0_162\bin\
    • 15.5: <DRIVE>:\Program Files\Symantec\DataLossPrevention\ServerJRE\1.8.0_181​\bin\
  • Linux:
    • 14.x and 15.0: /opt/SymantecDLP/jre/bin/
    • 15.1: ​/opt/Symantec/DataLossPrevention/Enforce Server/15.1/jre/bin/
    • 15.5: /opt/Symantec/DataLossPrevention/ServerJRE/1.8.0_181/bin

Note: On Linux, execute ./keytool

.keystore location

  • Windows:
    • 14.x and 15.0: <DRIVE>:​\SymantecDLP\Protect\tomcat\conf\
    • 15.1: <DRIVE>:\Program Files\Symantec\Data Loss Prevention\Enforce Server\15.1\Protect\tomcat\conf\
    • 15.5: <DRIVE>:\Program Files\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\tomcat\conf\
  • Linux:
    • 14.x and 15.0: /opt/SymantecDLP/Protect/tomcat/conf
    • 15.1: ​/opt/Symantec/DataLossPrevention/Enforce Server/Protect/tomcat/conf
    • 15.5: /opt/Symantec/DataLossPrevention/EnforceServer/Protect/tomcat/conf​

Notes:

  • In Linux, all commands must be executed as root.
  • In Windows, all commands need to be executed via CLI with Admin access.
  • Command to see the hidden “.keystore” file: ls -la
  • As per the DLP Admin Guide (p. 151 in 15.7 version), the Tomcat store uses a X.509 certificate must be provided in Distinguished Encoding Rules (DER) format – which is a .cer file.
  • The instructions below involve chained certs, when the Root or Intermediate CAs are required – i.e., “the Signed” certificate. The format of using a .p7b file therefore applies in that instance – otherwise, the cert is unsigned, and one would simply import the .cer file.

Resolution

  1. Back up existing keystore.
    • Windows command:  copy <14.x/15.0/15.1/15.5 file path>\.keystore <14.x/15.0/15.1/15.5 file path>\keystore.bkup
      • 14.x and 15.0: C:\Protect\tomcat\conf
      • 15.1: ​C:\Program Files\Symantec\Data Loss Prevention\Enforce Server\15.1\Protect\tomcat\conf
      • 15.5: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\tomcat\conf
    • Linux command:  cp  <14.x\15.0\15.1\15.5 file path>/.keystore <14.x\15.0\15.1\15.5 file path>/keystore.bkup
      • 14.x and 15.0: /opt/SymantecDLP/protect/tomcat/conf
      • 15.1: /opt/Symantec/DataLossPrevention/Enforce Server/15.1/Protect/tomcat/conf​
      • 15.5: /opt/Symantec/DataLossPrevention/EnforceServer/15.5/Protect/tomcat/conf​
  2. Generate a new keystore file with the required parameters, and register the certificate.
    • Windows command: <14.x\15.0\15.1\15.5 file path>\keytool -genkeypair -alias tomcat -keyalg RSA -keysize 2048 -keystore \SymantecDLP\jre\bin\.keystore -validity 365 -storepass protect -dname "CN=SERVERNAME, OU=DLP, O=SYMANTEC, L=Cupertino, ST=California, C=US"​
      • 14.x and 15.0 keytool path: C:\SymantecDLP\jre\bin
      • 15.1 keytool path: C:\Program Files\Symantec\Data Loss Prevention\Enforce Server\15.1\jre\bin
      • 15.5 keytool path: C:\Program Files\Symantec\DataLossPrevention\ServerJRE\1.8.0_181\bin​
      • 14.x and 15.0 .keystore path
  3. Generate a CSR file
    • \SymantecDLP\jre\bin\keytool -certreq -alias tomcat -keyalg RSA -keystore .keystore -storepass protect -file "VontuEnforce.csr"
  4. Send VontuEnforce.csr to CA admin, so they can generate a chained cert file in the current format.
  5. Copy the VontuEnforce.p7b chained cert file to \SymantecDLP\jre\bin\.
  6. Import the chained certificate.
    • \SymantecDLP\jre\bin\keytool -import -alias tomcat -keystore \SymantecDLP\jre\bin\.keystore -trustcacerts -file \SymantecDLP\jre\bin\VontuEnforce.p7b
    • Enter the keystore password.
      • Top-level certificate in reply:
        Owner: XXXXXX
        Issuer: XXXXXX
        Serial number: XXXXXX
        Valid from: XXXXXX until: XXXXXX
        Certificate fingerprints:
        MD5:  **Deleted**
        SHA1: **Deleted**
        … is not trusted. Install reply anyway? [no]:
    • Type Y or YES and press ENTER.
    • Certificate reply was installed in keystore.
  7. Copy the .keystore file from the source to its final destination.
    • copy \SymantecDLP\jre\bin\.keystore \Protect\tomcat\conf\.keystore​​
  8. Restart the Vontu Manager (14.x and 15.0) or Symantec DLP Manager (15.1 and 15.5) service.

NOTE:

If you change the keystore password from the default, ‘protect’ when generating a new keystore, you must update the password values in the following two files:

    1. <InstallPath>\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\tomcat\conf\server.xml
      •         <Certificate certificateKeystoreFile=”${catalina.base}/conf/.keystore” certificateKeystorePassword=”protect”/>
    2. <InstallPath>\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\config\Protect.properties
      • # keystore password
        com.vontu.manager.tomcat.keystore.password = protect

How to obtain the Symantec DLP Server Log files: location and description

By | Symantec DLP Enforce | No Comments

DLP provides many operational log files that can be used to interpret how the system is running.

In DLP 15.0 and earlier, the log folders are found in the following locations:

Linux: /var/log/SymantecDLP/

Windows: \SymantecDLP\Protect\logs\

In DLP 15.1 and newer, the log folders are found in the following locations:

Windows:

C:\ProgramData\Symantec\Data Loss Prevention\Enforce Server\15.1\logs\

C:\ProgramData\Symantec\Data Loss Prevention\Detection Server\15.1\logs\

Linux:

/var/log/Symantec/DataLossPrevention/Enforce Server/15.1/

/var/log/Symantec/DataLossPrevention/Detection Server/15.1/

Log File Name Description Server
Aggregator0.log This file describes communications between the detection

server and the agents.

Look at this log to troubleshoot the following problems:

¦ Connection to the agents

¦ To find out why incidents do not appear when they should

¦ If unexpected agent events occur

Endpoint detection

servers

BoxMonitor0.log This file is typically very small, and it shows how the application processes are running. The BoxMonitor process oversees the detection server processes that pertain to that particular server type. For example, the processes that run on Network Monitor are file reader and packet capture. All detection servers
ContentExtractor0.log This log file may be helpful for troubleshooting

ContextExtractor issues.

All detection servers,

Enforce Server

DiscoverNative.log.0 Contains the log statements that the Network Discover native code emits. Currently contains the information that is related to ,pst scanning. This log file applies only to the Network Discover Servers that run on Windows platforms. Discover detection

servers

FileReader0.log This log file pertains to the file reader process and contains application-specific logging, which may be helpful in resolving issues in detection and incident creation. Look at this log file to find out why an incident was not detected. One symptom that shows up is content extractor timeouts All detection servers
IncidentPersister0.log This log file pertains to the Incident Persister process. This process reads incidents from the incidents folder on the Enforce Server, and writes them to the database. Look at this log if the incident queue on the Enforce Server (manager) grows too large. This situation can be observed also by checking the incidents folder on the Enforce Server to see if incidents have backed up. Enforce Server
Indexer0.log This log file contains information when an EDM profile is indexed. It also includes the information that is collected when the external indexer is used. If indexing fails then this log should be consulted. Enforce Server (or

computer where the

external indexer is

running)

jdbc.log This log file is a trace of JDBC calls to the database. By default, writing to this log is turned off. Enforce Server
MonitorController0.log This log file is a detailed log of the connections between the  Enforce Server and the detection servers. It gives details around the information that is exchanged between these servers including whether policies have been pushed to the detection servers or not. Enforce Server
PacketCapture.log This log file pertains to the packet capture process that

reassembles packets into messages and writes to the

drop_pcap directory. Look at this log if there is a problem

with dropped packets or traffic is lower than expected.

PacketCapture is not a Java process, so it does not follow the same logging rules as the other Symantec Data Loss

Prevention system processes.

All detection servers
PacketCapture0.log This log file describes issues with PacketCapture

communications.

All detection servers
RequestProcessor0.log This log file pertains to SMTP Prevent only. The log file is primarily for use in cases where SmtpPrevent_operational0.log is not sufficient. SMTP Prevent

detection servers

ScanDetail-target-0.log Where target is the name of the scan target. All white spaces in the target’s name are replaced with hyphens. This log file pertains to Discover server scanning. It is a file by file record of what happened in the scan. If the scan of the file is successful, it reads success, and then the path, size, time, owner, and ACL information of the file scanned. If it failed, a warning appears followed by the file name. Discover detection

servers

SmtpPrevent_operational0.log This operational log file pertains to SMTP Prevent only. It is the primary log for tracking health and activity of a Mail Prevent system. Look at this file for information on the communications between the MTA and detection server. SMTP Prevent

detection servers

Tomcat\Localhost.<date>.log This log file contains information for any action that involves  the user interface. The log includes the User Interface red error message box, password fails when logging on ) and Oracle errors (ORA –#). Enforce Server
Tomcat\ Localhost_access_log.<date>.txt

 

This log contains the record of all URLs requested. Enforce Server
VontuIncidentPersister.log This log file contains minimal information –stdout and stderr  only (fatal events). Enforce Server
VontuManager.log This log file contains minimal information –stdout and stderr  only (fatal events). Enforce Server
VontuMonitor.log This log file contains minimal information –stdout and stderr  only (fatal events). All detection servers
VontuMonitorController.log This log file contains minimal information –stdout and stderr  only (fatal events). Enforce Server
VontuNotifier.log This log file pertains to the Notifier service and its

communications with the Enforce Server and the

MonitorController service. Look at this file to see if the

MonitorController service registered a policy change

Enforce Server
VontuUpdate.log This log file is populated when Symantec Data Loss

Prevention is updated.

Enforce Server
WebPrevent_Access0.log This access log file pertains to Web Prevent only. It records all the requests that Web Prevent processes. It is similar to Web access logs for a proxy server. Web Prevent

detection servers

WebPrevent_Operational0.log This operational log file pertains to Web Prevent only. It

reports the operating condition of Web Prevent such as

whether the system is up or down, connection management, and so on. This log is the primary log file for tracking Web Prevent operations.

Web Prevent

detection servers

What Are the Differences Between the “same” and “any” Components in Symantec DLP Rules?

By | Symantec DLP Enforce | No Comments

A rule can have multiple parts to it. On creating a rule, you can add conditions under “Also Match”. By default, these conditions must both match in the “same” component. A component can be the Envelope, Body or Attachment of a message. Each attachment is considered a different component.

The “any component” setting allows a match when one part is in the body and another is in the attachment. The “same component” setting requires the two parts to be in the same component.

For example, if you are matching for last name and social security number, if “any component” is selected, an incident is created if the name is in the body and the social security number is in an attachment of an e-mail. If the same component is selected (for both), then both last name and social security numbers must be in the same component. In this case, if the social security number is in one attachment and the last name is in another attachment, the violating data are in different components, which will not trigger a match.

Note that each match condition includes a component setting. When using multiple conditions, be aware of how the component settings of each condition will interact. In the above example, if you select “same component” for the SSN and “any component” for the last name, a match will be triggered when either item is in either component. The reverse is also true (if “any component” is selected for SSN, and “same component” for last name). However, with three or more match conditions, the situation becomes more complex. You should carefully review these settings for rules with many match conditions, to be sure that you are getting the matches that you intend.

How to gather a process dump using the ProcDump Tool

By | Symantec DLP Enforce | No Comments

Microsoft Windows

  1. Download the ProcDump tool for Windows and save it to the root of the C: drive on the system in question.
  2. Run the commands from the command prompt.

The following syntax can be used while running the tool depending on what data is required in the process dump file:

procdump [-64] [-c CPU usage [-u] [-s seconds] [-n exceeds]] [-h] [-e] [-ma] [-r] [-o] [ [dump file]] | [-x][arguments]

Common Switches:

  • -ma — Creates a dump of all process memory. This switch should always be used for support cases in order to ensure as much information as possible is collected.
  • -e — Creates a dump when the target process encounters an unhandled exception. This is useful for most crashes.
  • -t — Generates a dump when the process ends, even if no errors were encountered.
  • -w — Instructs ProcDump to wait for a process with the specified name to launch. This is used when you want to start ProcDump before the process.
  • -i — Install ProcDump as the post mortem debugger for Windows Processes. This will allow ProcDump to automatically be invoked on application errors.
  • -u — When run with no other arguments, will uninstall ProcDump as the post mortem debugger.
  • -c — Specify a CPU threshold at which to generated a dump. This is typically used when troubleshooting high CPU usage issues.
  • -m — Specify a memory usage threshold (in MB) at which to generate a dump.  This is typically used when troubleshooting high memory usage issues or memory leaks.
  • -s — Write a dump after specified number of seconds.  This is useful in conjunction with -c and -m.
  • -n — Write n number of dumps.
  • -x [arguments] — Have ProcDump execute the executable and writing the dump file to the specified arguments.
  • -64 — Forces the creation of 64-bit dump. This switch should generally not be used on 32-bit processes.

 

Linux

  1. Download and install the ProcDump tool for Linux, per the instructions on GitHub, to the system in question.
  2. Run the commands from the command prompt with sudo.

The following syntax can be used while running the tool depending on what data is required in the process dump file:

sudo procdump [OPTIONS...] TARGET

Common Switches:

  • -C –CPU threshold at which to create a dump of the process from 0 to 100 * nCPU.
  • -c — CPU threshold below which to create a dump of the process from 0 to 100 * nCPU.
  • -M — Memory commit threshold in MB at which to create a dump.
  • -m — Trigger when memory commit drops below specified MB value.
  • -n — Number of dumps to write before exiting.
  • -s — Consecutive seconds before dump is written (default is 10)

TARGET must be specified as -p pid, where pid is of the process in question.

Command Line Examples:

  1. Immediately generate a full memory process dump for CcSvcHst.exe: procdump -ma CcSvcHst.exe
  2. Generate a full memory process dump for the process with PID 4512 when it exists: procdump -ma -t 4512
  3. Attach to a process with the name httpd.exe when it launches. Then generate a full dump, if it encounters an unhandled exception: procdump -ma -e -w httpd.exe
  4. Have ProcDump run BadApp.exe and write a full dump to C:\Dumps if it encounters an unhandled exception: procdump -ma -e -x C:\Dumps C:\Program Files\BadApp\BadApp.exe
  5. Install ProcDump as the postmortem debugger, and instruct it to write full dumps to C:\Dumps: procdump -ma -i C:\Dumps
  6. Create up to 3 full dumps of the process with PID 3213, if that process consumes 75% or more total CPU for 10 seconds: procdump -ma -c 75 -s 10 -n 3 3213

References:

http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
https://github.com/Microsoft/ProcDump-for-Linux

How to configure the LDAP Lookup Plug-In within Symantec DLP

By | Symantec DLP Enforce | No Comments
To implement an LDAP Lookup Plug-In
  1. Create the following custom attributes at System > Attributes > Custom Attributes:

    LDAP givenName

    LDAP telephoneNumber

  2. Create a directory connection for the Active Directory server at System > Settings > Directory Connections.

    For example:

    • Hostname: enforce.dlp.company.com

    • Port: 389

    • Base DN: dc=enforce,dc=dlp,dc=com

    • Encryption: None

    • Authentication: Authenticated

    • username: userName

    • password: password

  3. Test the connection. The system indicates if the connection is successful.

  4. Create a new LDAP plug-in at System > Lookup Plugins > New Plugin > LDAP.

    Name: LDAP Lookup Plug-in

    Description: Description for the LDAP Plug-in.

  5. Select the directory connection created in Step 2.

  6. Map the attributes to LDAP metadata.

    attr.LDAP\ givenName = cn=users:(|(givenName=$endpoint-user-name$)(mail=$sender-email$)
    (streetAddress=$discoverserver$)):givenName
    attr.LDAP\ telephoneNumber = cn=users:(|(givenName=$endpoint-user-name$)(mail=$sender-email$)
    (streetAddress=$discoverserver$)):telephoneNumber
  7. Save the plug-in. Verify that the correct save message for the plug-in is displayed.

  8. Enable the following keys at the System > Lookup Plugins > Lookup Parameters page.

     

    • Incident

    • Message

    • Sender

  9. Create an incident that generates one of the lookup parameters. For example, an email incident exposes the sender-email attribute. There must be some corresponding information in the Active Directory server.

  10. Open the Incident Snapshot for the incident.

  11. Click the Lookup button and verify the custom attributes created in the Step 1 are populated in the right panel.

fixing Enforce Server migration fail for three-tier environments due to “DatabaseProcessCheck”

By | Symantec DLP Enforce | No Comments

Stop all Symantec Data Loss Prevention database sessions:

  1. Reboot the Enforce Server.
  2. Access the database server.
  3. Start SQL*Plus:
    sqlplus /nolog
  4. Log on as the SYS user:
    SQL> connect sys/password@protect as sysdba
    Where password represents the SYS password.
  5. Run the following query to identify processes running in the database:
    SELECT module, action, client_identifier FROM v$session
    WHERE (
    UPPER(module) LIKE 'VONTU%' OR
    UPPER(client_identifier) LIKE 'VONTU%' OR
    UPPER(module) = 'SYMANTEC DLP: INCIDENT DELETOR' OR
    UPPER(module) = 'DATAUSER_MERGE' OR
    UPPER(module) = 'DATA INSIGHT DATA REFRESH'
    ) AND
    module <> 'Vontu Refresh CBO Stats' AND
    UPPER(module) NOT LIKE '%SCHEMA UPGRADER%';
  6.  If the query identifies running processes, run the following command to stop them:
    SET SERVEROUTPUT ON;
    DECLARE
        CURSOR inactive_process IS
    SELECT 'ALTER SYSTEM KILL SESSION ' || '''' || sid || ',' || 
    serial# || ''''
    AS kill_stmt, module, sid, serial#
              FROM v$session
             WHERE (
                    UPPER(module) LIKE 'VONTU%' OR
                    UPPER(client_identifier) LIKE 'VONTU%' OR
                    UPPER(module) = 'SYMANTEC DLP: INCIDENT DELETOR' OR
                    UPPER(module) = 'DATAUSER_MERGE' OR
                    UPPER(module) = 'DATA INSIGHT DATA REFRESH'
                   ) AND
                   module <> 'Vontu Refresh CBO Stats' AND
                   UPPER(module) NOT LIKE '%SCHEMA UPGRADER%';
    BEGIN
        FOR x IN inactive_process LOOP
    DBMS_OUTPUT.put_line(x.kill_stmt);
    EXECUTE IMMEDIATE x.kill_stmt;
    END LOOP;
    END;
    /
  7. Resart the migration process.