ICAP Engines

Introduction

Internet Content Adaptation Protocol or ICAP is a lightweight HTTP-like protocol used to offload the processing of antivirus (AV) and data loss prevention (DLP) scanning to dedicated servers.

Data One can be configured to stream the content of selected files to an ICAP Server Engine (ICAP Engine, for short) reachable over the network from STENG Peers, for AV and/or DLP scanning.

ICAP scanning can be leveraged in two distinct way:

• explicit scanning: this type of ICAP scanning is completely controlled by the user, according to some logic implemented in a mediation contract (see the following sections for more details)
• implicit scanning: this type of scanning is driven by the optional ICAP configuration settings specified by the user in a VFS Virtual Path, and is automatically applied to all files written to it (see the following sections for more details)

In both cases, the connection details of each remote ICAP Server Engine must be defined by creating one or more ICAP Engine definitions (Configuring an ICAP Engine).

Explicit ICAP scanning

With explicit ICAP scanning, you simply wire one or more ICAP service tasks (see also Configuring Triggerable Service Tasks - ICAP) in a mediation contract workflow template and provide the appropriate input file to be scanned to them, together with some additional ICAP parameters and error handling directive.

Your workflow logic is in charge of how to react to an AV or a DLP breach detection response from the configured ICAP Engine on the current file.

Similarly, your workflow logic is in charge of determining which files indeed need to be scanned and which ones can skip this check.

Implicit ICAP scanning

With implicit ICAP scanning you set the ICAP scanning directive on the Virtual Paths whose files require a scan. The scan will be applied to all files in those Virtual Paths in a way completely transparent to the rest of the platform (see also Adding virtual paths).

Implicit scanning has the following characteristics:

• it is asynchronous
  • any incoming files are fully persisted in the Storage Class underpinning a Virtual Path, before a scan is initiated
  • external protocol clients performing an upload operation on a Virtual Path with ICAP scan will not observe any extra latencies due to ICAP scanning, nor will experience a failure in case a breach is detected during the scan
  • file visibility on Virtual Path is deferred to when the ICAP scan has been completed
• configurable notifications can be emitted when one of these conditions occur: AV threat detected, DLP threat detected, Server unavailable, File scan skipped.
  See also Configuring an ICAP Engine and ICAP Macros
• configurable actions (allow or delete) can be applied to the file when one of these conditions occur: AV threat detected, DLP threat detected, Server unavailable, File scan skipped.
  See also Configuring an ICAP Engine
• ICAP scans can be throttled, by limiting their parallelism, in order not to overload an ICAP Engine.
  See also Defining an ICAP rule