Use EFT’s Content Integrity Control Feature to Add an Extra Layer of Data Security
Best Practice
Use the Content Integrity Control (CIC) Action to create a layer of protection that scans files before they are disseminated to your end users.
EFT’s CIC action uses a standardized protocol, ICAP, to integrate with best-in-class data classification, content inspection, and data loss prevent (DLP) solutions, such as McAfee, Symantec, RSA, and more.
Using the CIC feature lets you centralize the inspection of files as they enter or leave your network, ensuring internal users aren’t exposed to malware or virus infected files, or that confidential data is not leaked or exposed.
To scan a file using the Content Integrity Control Action
1. Create a new Event Rule
2. Add relevant Conditions (optional)
3. Add the Content Integrity Control Action
4. In the Action, click either of the underlined/linked items. The Content Integrity Control dialog box appears.
5. Specify a profile to use.
6. CIC profile - If you are using a defined profile, click the drop-down list to select it, then click OK; otherwise, select <Custom>.
7. File Path - Physical location of the file to send to the ICAP server; %FS.PATH% is the default. You can specify another variable or drive and UNC paths. Wildcards are unsupported.
• % - Click the drop-down list if you want to specify other context variables:
8.Host, Path, Port - Specify the settings used in the antivirus or DLP (ICAP) server to which EFT will send the file for scanning:
a.The Host field cannot be blank
b. By default, the port is set to 1344
9. Mode - Specify one of the following:
a. Request modification (REQMOD) - Request modification mode: Embeds file contents in an HTTP PUT request body, which is then sent in the body of an ICAP request to the server. The ICAP server may respond with a modified version of the embedded request, or a new HTTP response. The ICAP response will depend on your ICAP server’s implementation.
b. Response modification (RESPMOD) - Response modification mode: Embeds file contents in an HTTP 200 OK response body, which is then sent in the body of an ICAP request to the server. The ICAP server may respond with a modified version of the embedded response. The ICAP response will depend on your ICAP server’s implementation.
10. Limit scans to first - (Optional) Specify the number of bytes to scan. Some antivirus solutions only require a subset of a file's contents to test against their database of malware signatures. To keep from transferring large files in their entirety when your ICAP server only needs the first X bytes, you can specify how many bytes are sent. When this check box is cleared, the entire file is transferred to the ICAP server. If the file is smaller than the Max scan size, the entire file will be transferred for scanning.
11. Test Connection - After you specify the connection to the ICAP server, test the connection. If connection fails, verify these settings match the settings defined in the antivirus or DLP solution.
12. Text in ICAP response headers - (Optional) Specify text to search for in the ICAP response header.
13. Text in ICAP response body - (Optional) Specify text to search for in the ICAP response body text.
14. Treat any violation as non-blocking (audit and continue) - Leave this check box cleared if you want violations to stop processing.
15. Always audit these ICAP response "X-" headers - (Optional) Specify “X-“ headers for auditing using ARM. If this option is enabled and no “X-“ headers are specified, all “X-“ headers will be audited. Use semicolons between multiple items. Note this check box only affects whether the specified headers are audited by ARM, regardless of success or failure.
16. Click OK to save the changes in the Event Rule. The name of the profile appears in the Event Rule Action.
CIC is available through our Advanced Authentication Module. For more information, contact your account manager or our Sales department.
Got Feedback? Let us know what you think.