Content Integrity Control
EFT's ICAP functionality is invoked through Event Rules, sending files to antivirus or data leak prevention (DLP) servers that detect file pass/fail based upon user-defined rules. Users can configure rules on a DLP server to send a reply to EFT with access denied if the file contains social security numbers (SSNs) or credit card numbers (CCNs), for example. Antivirus servers scan the files for viruses and return a response to EFT whether a virus was found or not. (Refer to File: Scan Action for the procedure for adding the action to an Event Rule.)
The Internet Content Adaptation Protocol (ICAP) is an HTTP-like protocol that is used for virus scanning and content filtering. According to RFC 3507:
ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses.
On a DLP server, you can define rules to search files for SSNs or CCNs. For example, if you send a file containing a valid CCN, the DLP server will flag it and return a denied message to EFT. (To test this rule, you can put the universal test credit card number 4111 1111 1111 1111 in a text file and send it through the DLP via an EFT Event Rule.)
On an antivirus server, you can specify violation text in ICAP response headers: “X-Virus-ID:INFECTED” or ”X-Response-Info:blocked” or both (semicolon-separated).
EFT does not return an error or any type of indicator from the Content Integrity Control Action if a file isn't completely processed/analyzed by an antivirus or DLP server due to the size of the file being larger than what is supported by that particular server. For example, MyDLP will process a maximum of 10 MB of data; if a flag is embedded in a file that is after the 10 MB limit, MyDLP will not detect the policy violation.
Suppose EFT sends an 11 MB file to myDLP, which has a max processing capacity of 10 MB. The myDLP server has a policy to return a failure for any files containing credit card numbers. The 11 MB file has a credit card number embedded at the end of file. As a result, the myDLP server would return to EFT that the Action was a success, because the myDLP server did not process the credit card number.
Refer to Content Integrity Control Tab for details of creating a CIC profile.
Content Integrity Control Actions are also captured in the EFT log, after you enable #log4cplus.logger.Events.ContentIntegrityControl=TRACE in the logging.cfg file. (Remove the # in front of that line.)
Below is a diagram demonstrating EFT decision points for Content Integrity Control (ICAP) success or failure.
Related Topics