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) 

Troubleshooting Symantec File Reader Restarts

By | Symantec DLP Endpoint Prevent, Symantec DLP Network Discover | No Comments

FileReader restarts usually occur due to timeout issues.  These timeouts are generally caused by the following:

  1. Connectivity issues with the Monitor Controller or Network
  2. Poorly written RegEx Rules
  3. A bad email message.  Bad messages can be caused by incorrect header information or foreign characters in the message that Symantec DLP is unable to process

If the FileReader restarts itself occasionally, this is normal behavior.  However, if you are experiencing consistent FileReader restarts in your environment, there are a few things you can do to determine the cause:

  1. FileReader may fail to start (and restart) if it can’t receive all the configuration information it needs. To troubleshoot the exact cause, look in the FileReader log first to identify which FileReader subsystem isn’t starting. Once it’s identified that a particular subsystem isn’t receiving its configuration, one should look in the MonitorController log to see if the corresponding subsystem has been initialized successfully. One of the common failures is inability to ignite cryptographic keys in the MonitorController because the ignition password on the disk got out of sync with the Administrator password in the database. In this case the password issue must be fixed and only after that should the MonitorController be restarted. Look at the VontuMonitorController.conf file in the config directory. Check the java heap size. If it is the default value of 128 and 256, you will probably need to increase the memory setting of the heap depending on the RAM available on the server.
  2. Too many exceptions in policies. Each new exception, while improving the ability to “short-circuit” detection, also has the knock-on effect of multiplying the size of the overall detection matrix – all of which is loaded into memory when FileReader starts. While there is no exact limit on the total number of exception, a good rule of thumb is that more than 10 exceptions in a policy will start to have an impact at some point – after which the next exception may result in FileReader being unable to load.
  3. Check to make sure the MessageChain.CacheSize & MessageChain.NumChains match the CPU Cores.
  4. Check your policies.  Oftentimes FileReader restarts will occur because of a particular policy.  For example, if a Regex in a particular policy exceeds given thresholds (such as maximum component time), then the FileReader will restart.  Look at the log files for the “intentionally restarting process” message which identifies the message chain component causing the restart.  If this component is “Detection” the most likely cause is a poorly written regular expression.
  5. Check for “bad” messages. Save the *.vpcap file that contains the message in question. You can use the file for testing without having to actually send the message again.
  6. Check for locked *.vpcap files.
    1. Stop Packet Capture so that you do not get noise in the test. Start FileReader process. If the *.vpcap file gets picked up, the inductor is working. If the inductor is not working, find out why. The most common problem is that some process has a lock on the files. Other than that, collect the FileReader log and contact support.
  7. If the inductor is working, the problem may be in the Layer 7 Parser or the Content Extractor. Visually inspect the FileReader log for any exceptions, warnings or severe log messages.
  8. While the Content Extractor can often have problems processing various file formats it can rarely, if ever, be blamed for a FileReader restart.
  9. Dying threads can cause FileReader to stop reporting heartbeats and eventually be restarted. Look in VontuMonitor.log for exceptions. Each exception in that log file is an indicator of a serious problem (Java crash or other defect) and is a likely cause of a FileReader restart.

Symantec Network Detection is not working for DLP User Groups that index the Domain Users AD Security Group

By | Symantec DLP Network Discover | No Comments

Do not reference the Domain Users Security Group from a DLP User Group. Any users whose primary group is Domain Users will not be indexed by Enforce. Instead add users to a separate security group and reference that group from the DLP User Group. In addition you can also point the DLP User Group to the individual AD user or an OU(Organizational Unit) that contains that user.

For example, in order to index the user below from a DLP User Group, you would need to add the Engineering AD group as that user is a member of that group. However if you were to add the Domain Users group, it would not index that user because Domain Users is that user’s primary group.

User's Primary Group

 

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.

Converting your LOB tables from BasicFiles to SecureFiles format in Symantec Data Loss Prevention 14.6 and 15.x:

By | Oracle DB | No Comments

This solution applies to Oracle 11g Standard (11.2.0.4), Oracle 11g Enterprise (11.2.0.4), and Oracle 12c Enterprise (12.1.x and 12.2.x) databases and allows you to continue running your system during the conversion process.

NOTE: This solution cannot be applied to Oracle 12c Standard (12.1.x and 12.2.x) databases. See “Solution #2” if you are on Oracle 12c Standard.

Symantec provides a LOB space management script (DLP_lobspace_mgmt_b.pls) that converts BasicFiles Large Object (LOB) storage to SecureFiles LOB storage in your database when you run the database space reclamation utility (DLP_Lobspace_reclaim.sql).

Unlike BasicFiles LOB storage, SecureFiles LOB storage tracks deleted LOBs and makes that space available after the retention period expires. After converting to SecureFiles LOB storage, you do not need to run a script to reclaim LOB space in your database. Space reclamation is handled automatically.

Update the LOB space management script

Updating the LOB space management script requires that you update the DLP_lobspace_mgmt_b.pls and DLP_Lobspace_reclaim.sql files.

NOTE: The process to update your database to use SecureFiles for LOB storage temporarily requires roughly the same amount of space that the LOB tablespace currently consumes. For example, if your LOB_tablespace takes up 20 GB, you need an additional 20 GB of space in LOB_tablespace to successfully run the update. After you complete the process, the data used size returns to the previous size (approximately) and decreases as space reclamation automatically occurs. To add LOB_tablespace file to increase the amount available refer to article 159990.

Incidents continue to be written to the Enforce Server during the SecureFile format conversion process. The process does not affect Enforce Server functions and there is minimal performance impact.

NOTE: For large databases (.5 TB or more) and for environments that have continuous incidents being added every minute, it would be best practice to stop the Incident Persister service while running the LOB_lobspace_reclaim.sql.  Otherwise the UNDO_RETENTION initialization parameter will need to be increased significatly as well as the size of the UNDO Tablespace

To update the files on Symantec Data Loss Prevention systems, follow these steps:

  1. Obtain the latest LOB space management script by completing the following steps:
    1. Download LOB_Space_Management_Script-September2019.zip attached to the bottom of this KB article.
    2. Move the file to a temporary location on your Enforce Server computer.
  2. Navigate to where the  DLP_lobspace_mgmt_b.pls and dlp_lobspace_reclaim.sql files are located on the Enforce Server:
    • Version 15.0 and earlier:
      • Linux: /opt/SymantecDLP/Protect/install/sql
      • Windows: C:\SymantecDLP\Protect\install\sql
    • Version 15.1:
      • Linux: /opt/Symantec/DataLossPrevention/Enforce Server/15.1/Protect/install/sql
      • Windows: C:\Program Files\Symantec\Data Loss Prevention\Enforce Server\15.1\Protect\install\sql
    • Version 15.5 and later:
      • Linux: /opt/Symantec/DataLossPrevention/Enforce Server/<DLPVersion>/Protect/install/sql
      • Windows: C:\Program Files\Symantec\DataLossPrevention\EnforceServer\<DLPVersion>\Protect\install\sql
  3. Rename the DLP_lobspace_mgmt_b.pls and DLP_Lobspace_reclaim.sql files.
  4. Extract the new DLP_lobspace_mgmt_b.pls and DLP_Lobspace_reclaim.sql files from the LOB_Space_Management_Script-September2019.zip file to the same directory. Refer to step 2 for directory locations.

Convert the Oracle 11g or Oracle 12c Enterprise database to SecureFiles LOB storage

To use the database space reclamation utility to convert your Oracle 11g BasicFiles LOB storage to SecureFiles LOB storage, follow this procedure:

  1. Back up the Oracle database before making any changes.
  2. Open a command prompt and navigate to the directory that contains the database space reclamation script. Refer to step 2 in “Update the LOB space management script” for the location.
  3. Connect to sqlplus as the SYS user: sqlplus sys/[sysdba password] as sysdba.
  4. Run the database space reclamation utility: @@DLP_Lobspace_reclaim.sql.
  5. Run the following query to verify that the tables are in SecureFiles LOB storage format:
    select table_name, securefile from user_lobs where table_name like '%LOB%';
    The query returns yes in the securefile column to indicate that the tables are in SecureFiles LOB storage format.

Solution #2

This solution applies to all supported databases and requires that you shut down the system during the conversion process.

Unlike BasicFiles LOB storage, SecureFiles LOB storage tracks deleted LOBs and makes that space available after the retention period expires. After converting to SecureFiles LOB storage, you do not need to run a script to reclaim LOB space in your database. Space reclamation is handled automatically.

If you are using an Oracle 12c Standard database that still includes BasicFiles LOB storage tables, you should convert them as soon as possible to take advantage of the improved functionality of the SecureFiles LOB storage format. You must convert your tables to SecureFiles format before running the Upgrade Readiness Tool when upgrading to the next release of Symantec Data Loss Prevention.

You can manually convert your Oracle 12c LOB tables from BasicFiles to SecureFiles using the following procedure:

  1. Back up the Oracle database before making any changes.
  2. Shut down all DLP services on your Enforce Server. The following links are to the Symantec Data Loss Prevention 15.5 help. Your service names may be slightly different. You can also refer to the topics “Starting and stopping services on Linux” and “About starting and stopping services on Windows” in the Symantec Data Loss Prevention Administration Guide appropriate to your version.
  3. On the Oracle server, stop the Oracle Listener service. This will prevent external connections to the database that may interfere with the export/import process. The remaining steps will need to be executed on the Oracle server directly.
  4. Estimate there is enough space on the database hard drive for the SecureFiles export by running the following queries:expdp protect/<protect password> NOLOGFILE=YES ESTIMATE_ONLY=YES TABLES='MESSAGELOB'

    expdp protect/<protect password> NOLOGFILE=YES ESTIMATE_ONLY=YES TABLES='MESSAGECOMPONENTLOB'

    expdp protect/<protect password> NOLOGFILE=YES ESTIMATE_ONLY=YES TABLES='CONDITIONVIOLATIONLOB'

    Use the estimates that the queries provide to confirm whether there is sufficient space on the database hard drive. If there is enough space, proceed to step 5.

  5. Export the MESSAGELOB, MESSAGECOMPONENTLOB, and CONDITIONVIOLATIONLOB database tables to the data pump directory:expdp protect/<protect password> dumpfile=protect_messagelob.dmp logfile=protect_messagelob.log directory=DATA_PUMP_DIR tables='MESSAGELOB'

    expdp protect/<protect password> dumpfile=protect_messagecom.dmp logfile=protect_messagecom.log directory=DATA_PUMP_DIR tables='MESSAGECOMPONENTLOB'

    expdp protect/<protect password> dumpfile=protect_cvlob.dmp logfile=protect_cvlob.log directory=DATA_PUMP_DIR tables='CONDITIONVIOLATIONLOB'

  6. Verify that the tables appear in the data pump directory:
    select DIRECTORY_NAME, DIRECTORY_PATH from dba_directories where DIRECTORY_NAME = 'DATA_PUMP_DIR';
  7. Import the tables from the data pump directory as follows:

    impdp protect/<protect password> dumpfile=protect_messagelob.dmp logfile=protect_import_message.log directory=DATA_PUMP_DIR table_exists_action=REPLACE transform=LOB_STORAGE:SECUREFILE

    impdp protect/<protect password> dumpfile=protect_messagecom.dmp logfile=protect_import_messagecom.log directory=DATA_PUMP_DIR table_exists_action=REPLACE transform=LOB_STORAGE:SECUREFILE

    impdp protect/<protect password> dumpfile=protect_cvlob.dmp logfile=protect_import_cv.log directory=DATA_PUMP_DIR table_exists_action=REPLACE transform=LOB_STORAGE:SECUREFILE

  8. Run the following query to verify that the tables are in SecureFiles LOB storage format:
    select table_name, securefile from user_lobs where table_name like '%LOB%';
    The query returns yes in the securefile column to indicate that the tables are in SecureFiles LOB storage format.
  9. Restart the Oracle Listener service on the Oracle server.
  10. Restart all DLP services on your Enforce Server. The following links are to the Symantec Data Loss Prevention 15.5 help. Your service names may be slightly different. You can also refer to the topics “Starting and stopping services on Linux” and “About starting and stopping services on Windows” in the Symantec Data Loss Prevention Administration Guide appropriate to your version.