Welcome to bowbridge Anti-Virus for SAP Solutions, version 4.x.

Anti-Virus 4.x is a nearly complete rewrite of the successful bowbridge Anti-Virus product, aiming at addressing the evolving requirements of SAP deployments in on-premises and cloud environments.
We encourage administrators to attentively read this document to familiarize themselves with the components of the product in order to select the best-fitting deployment option and properly scale their installation.

Anti-Virus 4.x is significantly more modular than previous versions of the product to accommodate more deployment options for on-premises, hybrid, and cloud deployments.
This section describes the main modules of bowbridge Anti-Virus v4.x and explains their respective functions.

These components exist in every bowbridge Anti-Virus 4.x deployment.

The Virus Scan Adapter (VSA) is a shared library (a DLL on Windows) that connects to SAP’s Virus Scan Interface (VSI). The VSA is loaded into the SAP kernel (dialog work processes on an ABAP stack and the jstart server process on a Java stack).

The main functions of the VSA are to:

• Process requests to scan local files according to the policy settings
• Process requests to scan memory buffers according to the policy settings
• Return detailed information on the scan results to the SAP kernel/application
• Report version and operational information of the scan components to the SAP kernel

REFERENCE:

Technically, the VSA consists of two libraries, the “VSA wrapper”, and the “VSA implementation library”. Refer to the bowbridge Troubleshooting Guide for more details.

The message broker is the central communication hub interconnecting all components of the Anti-Virus solution. It is based on the Apache Artemis message broker and implements AMQP 1.0 with authentication and SSL/TLS-based encryption to ensure the integrity and confidentiality of all inter-component communications.

VSA clients and scan workers connect to the broker, which dispatches scan requests to the best-available scan worker and routes replies back to the requesting client. Depending on the deployment model, the broker either runs locally on the application server, on a separate host/container, or in the cloud.
All components need to be able to establish a network connection to the broker on TCP/5670.

bowbridge Control is a central, critical component of a bowbridge Anti-Virus 4.x installation. Each installation of bowbridge Anti-Virus 4.x must include precisely one control instance. Its main functions are:

• Storing and managing all licenses related to the installation and distributing them to application server instances.
• Storing and managing hierarchical configurations for scan parameters, MIME-mappings, and active-content detection
• Receiving and storing logs (on-premises deployments only)
• Optionally starting, stopping, and dynamically scaling security worker capacity.

Processes performing the actual threat detection are referred to as “Security Workers.”
Each worker can either run locally on the same host as the VSA and/or broker, but they may also run on a separate host/VM or as a container on an orchestration platform, like Kubernetes.

In cloud deployments, scan workers are operated and monitored by bowbridge as part of the CloudScan offering.

bowbridge MIMEscan processes every scan request, regardless of the remaining scan policy. Its main functions are:

• Perform content analysis to determine the MIME type, the file-type, and the encoding of content.
• Verifying consistency between the extension of the file name and the file’s content. As such, it improves the effectiveness of filtering files by extension only.
• Detection of chameleon/polyglot files
• Enforcing scanning and blocking policies based on extensions
• Enforcing scanning and blocking policies based on MIME-type lists.

The bowbridge archive-extractor security worker ensures recursive scanning of multiple archive file types.

If the security policy requires recursive scanning of archives (Virus Scan Profile parameter SCANEXTRACT), all security checks defined in the policy are applied to every file in the archive. The archive extractor security worker handles the following archive formats:

• SAP SAR/CAR archives
• Old V7 tar archives
• POSIX tar
• GNU tar format
• Solaris 9 extended tar format
• POSIX pax interchange format
• POSIX octet-oriented cpio
• SVR4 ASCII cpio
• Binary cpio (big-endian or little-endian)
• ZIP archives
• ZIPX archives (with support for bzip2, ppmd8, lzma, and xz compressed entries)
• GNU and BSD ‘ar’ archives
• ‘mtree’ format
• 7-Zip archives
• Microsoft CAB format
• LHA and LZH archives
• RAR and RAR 5.0 archives (with some limitations)
• XAR archives

and the following compression formats:

• uuencoded files
• files with RPM wrapper
• gzip
• bzip2
• compress/LZW
• lzma, lzip, and xz
• lz4
• lzop
• zstandard

bowbridge Active Content Detection detects multiple types of executables and active content in files and blocks those files following the security policy.

We continuously improve Active Content Detection. With the initial release of Anti-Virus 4.0, the worker detects the following types of active content:

• Windows PE executables (including DLLs, SCR, CPL, ACM, SYS, OCX, etc.)
• Linux/Unix executables and scripts
• PDF active content (JavaScript and all JS triggers, /Launch, RichMedia, etc.)
• Macros in Office Documents (OOXML and CDF formats)
• OLE
• DDE
• Several injection types (CSV-injection, OS-command injection, etc.)
• Several JS triggers (i.e., HTML event-handler, obfuscated JavaScript)
• XML-based JavaScript triggers (i.e., in SVG files)
• Macromedia Flash
• Microsoft Silverlight
• XSLT
• etc.

This security worker forwards the file to an ICAP server for scanning. ICAP servers are commonly used in web-proxy security and are a cost-effective and centralized approach to malware scanning, albeit not as fast as the other anti-malware engines.

This security worker forwards the file to a local or remote/central ClamAV open-source malware detection engine instance.

While bowbridge does not recommend solely the use of  ClamAV in production environments, it may be a good and cost-effective option for non-production environments or even as a second-opinion scan engine in production environments.

This security worker utilizes the Sophos anti-virus scan engine to scan files for malware.
Bowbridge delivers the Sophos anti-virus scan engine as part of bowbridge Anti-Virus and relays malware definition updates and engine updates within ten minutes of their release by Sophos.

This security worker utilizes the Trellix (formerly known as McAfee) anti-virus scan engine to scan files for malware.

Bowbridge delivers the Trellix anti-virus scan engine as part of bowbridge Anti-Virus and relays malware definition updates and engine updates published by Trellix within ten minutes of their release by Trellix.

These optional modules are required to integrate bowbridge Anti-Virus 4.x with customer-owned cyber-security infrastructure

This worker receives and processes events from other modules and can trigger customizable actions via OS-level scripts. The most common use cases are generating custom alerts, such as emails, or integrating bowbridge Anti-Virus 4.x with SIEM solutions.

This worker forwards bowbridge Anti-Virus event and status information to a Trellix ePolicy Orchestrator (ePO).

When a file is blocked by the VSA, SAP’s default behavior is to discard that file. Its content is deleted and cannot be restored. The Quarantine Worker is therefore designed for customers wishing to retain a copy of blocked files, for example, as evidence or for forensic analysis. It receives copies of files that any of the security workers have blocked and stores them, along with a human-readable description of the blocking reason, in a password-protected archive. This prevents potentially malicious and dangerous files from being opened or executed inadvertently but ensures engineers can reconstruct the blocked content, for example, on an air-gapped system.

Thanks to its modular architecture, administrators can deploy bowbridge Anti-Virus in several different scenarios. This section describes the most common ones to inform decision makers which deployment scenario best meets their specific requirements.

In this deployment scenario, all modules are deployed to the SAP application server(s).

It mimics the only deployment option available in previous versions. It is the easiest upgrade path from earlier versions to version 4.x.

This scenario delivers the highest scan performance as all scanning activity happens locally on each application server and communication between the modules relies on IPC.

However, this deployment model also requires the highest configuration and administration overhead. Administrators must deploy configurations to every application server, monitor status and virus data updates on each application server, etc. Further, in installations needing relatively few scans or which run only interactive applications, the performance gain may not justify the resource and administration overhead of running a dedicated virus-scanning engine on every application server.

In this deployment scenario, administrators need to only install the VSA-client component on every application server.
The control and scan workers are then installed on one or several separate hosts or run in containers, for example, on an orchestration platform, such as Kubernetes.

Several application servers or system-lines with multiple application servers may share scan workers.

This deployment model does not require administrators to deploy workers to their application servers. It only requires VSA clients, which connect to bowbridge-powered scanning services provided by bowbridge on all major hyperscalers or provided by several hosting partners.

Installation in shared directories (i.e., NFS-mounted directories)

Deploying bowbridge Anti-Virus 4.x in directories shared by multiple application servers, such as NFS-mounts, is possible and supported.

However, administrators must pay special attention to the following:

• The temp directory specified in INITTEMP_PATH or the service-unit file MUST be a LOCAL directory.
• Using the default <installation directory>/run path is NOT WORKING. Each instance must have a local run directory.
• All paths specified in the shared configuration must exist and be accessible on all application servers.
• Only ONE application server can download/deploy updates

We strongly recommend reaching out to your bowbridge partner or bowbridge technical support to assist with your configuration’s planning and/or validation.

Distributed with containerized workers

In this “Distributed” deployment scenario variant, administrators do not deploy control and/or scan workers bare-metal servers or VMs but deploy them as container workloads on top of Docker with optional orchestration tools, such as Kubernetes.

Bowbridge provides, maintains, and supports all workers as Docker containers.

Self-managed auto-scaling deployment

bowbridge Anti-Virus supports auto-scaling of scan worker capacities. Based on load high-water marks and low-water marks defined by the administrator, the control worker starts and stops additional workers to handle the load dynamically.

Container-Orchestration with/without auto-scaling

The bowbridge control worker and scan worker containers can be managed by orchestration platforms, such as Kubernetes or Docker Swarm.

Orchestration platforms automate most of the monitoring and ensure optimal utilization of resources. If so configured, they also allow automatic, dynamic, load-based allocation and de-allocation of scan workers.

Semi-distributed vs. fully distributed

In typical environments, some workers use up more resources than others. For instance, determining the MIME-type is usually low-impact, whereas extracting a deeply nested archive or virus-scanning large binary files is CPU-intensive.

To maximize the overall performance without over-allocating resources for workers that don’t need them, it is possible to further split-up the “Distributed” deployment model.

With bowbridge Anti-Virus 4.x, operating each worker on a separate VM or container is possible. Adding resources of a particular type only requires starting up a new VM or adding a container of that type.

For example, running one instance of the MIME-scan worker, two instances of the archive-extractor, one instance of the active content detection worker, and three Trellix malware scanning workers is possible.

IMPORTANT:

Technically, it is also possible to increase the number of worker processes of a particular type in the “semi-distributed scenario,” with all workers running on the same host. However, as CPU resources are shared across all local processes, such a configuration has little to no benefit. Instead, adjusting the number of worker threads may increase scan throughput, especially with large numbers of concurrent scans.