Finjan Vital Security For eMail Technical White Paper

Vital Security™ for E-Mail
Technical White Paper

Version 7.0

Technical White Paper Vital Security™ for E-Mail

1 INTRODUCTION 5

1.1 GENERAL OVERVIEW OF FINJAN PRODUCTS 5
1.2 INTRODUCTION TO VITAL SECURITY FOR E-MAIL 6
1.3 PURPOSE & SCOPE 6
1.4 DEFINITIONS, ACRONYMS & ABBREVIATIONS 7
1.4.1 DEFINITIONS 7
1.4.2 ABBREVIATIONS 8

2 PRODUCT OVERVIEW 9

2.1 VITAL SECURITY FOR E-MAIL COMPONENTS 9
2.2 MULTI-LEVEL SECURITY POLICY 9
2.3 CODE SCANNING AT THE GATEWAY 9
2.3.1 POLICIES AND PROFILES 10
2.4 THE SECURITY POLICY 10

3 FEATURES AND BENEFITS 11

3.1 CONTENT INSPECTION AND PROACTIVE CODE SCANNING 11
3.2 MULTIPLE POLICIES SUPPORT 12
3.2.1 MANAGING MULTIPLE POLICIES 12
3.2.1.1 User Identification 12
3.2.1.2 User Auto-Detection 13
3.2.2 INCOMING VS. OUTGOING POLICIES 13
3.2.3 HOW DOES IT WORK? 14
3.3 QUARANTINE MANAGEMENT 15
3.4 ANTI-SPAM SUPPORT 16
3.4.1 BLOCKING MESSAGES FROM OPEN RELAYS 16
3.4.2 BLOCK SPECIFIC SMTP SERVERS 17
3.4.3 BLOCK BY RECIPIENTS COUNT 17
3.4.4 DETECT SPAM USING KEYWORD ANALYSIS 17
3.4.5 EXTENDED ANTI-SPAM FEATURES (MAILSHELL) 17
3.4.5.1 Classification of Incoming Messages 17
3.4.5.2 Analysis of Incoming Messages 18
3.4.5.3 Actions Performed on Incoming Messages 19
3.4.5.4 Reports 21

Page ii of 60


3.4.5.5 Configuring Anti-Spam Settings 22
3.5 DISCLAIMERS 22
3.6 CONTENT SCANNING 22
3.7 MS OFFICE DOCUMENT AUDITING AND WATERMARKING 23
3.8 ACCESS CONTROL MANAGEMENT OF MS OFFICE DOCUMENTS 23
3.9 LOGGING 24
3.10 ADMINISTRATIVE ALERTS 24
3.11 NOTIFICATIONS TO END-USERS 25
3.12 SYSTEM ROBUSTNESS 25

4 CONTENT INSPECTION 26

4.1 CONTENT INSPECTION FLOW 26
4.2 BREAKING THE E-MAIL APART 27
4.2.1 HANDLING ARCHIVES 28
4.2.2 DATA ENCODING 28
4.3 PRO-ACTIVE CODE SCANNERS 29
4.3.1 CODE SCANNING FOR JAVA, ACTIVEX AND SCRIPTS 29
4.3.2 HANDLING EXECUTABLES 30
4.3.3 HANDLING DOCUMENTS 30
4.3.4 HANDLING PLUG-INS 31
4.3.5 COOPERATION WITH VITAL SECURITY FOR WEB 31
4.3.6 UNSCANNABLE OBJECTS 31
4.4 THE ACTIVE CONTENT DATABASE 32
4.5 ACTIVE CONTENT FILTERING 33
4.5.1 ACTIVE CONTENT FILTER 33
4.5.2 SENDERS FILTER 33
4.5.3 DIGITAL CERTIFICATE FILTER 33
4.5.4 CERTIFICATE SERVER 34
4.6 THE ANTI-VIRUS SCANNER 35
4.6.1 SCANNING DIFFERENT FILE TYPES 36
4.6.2 SIGNATURE DATABASE UPDATES 36

5 DEPLOYMENT OPTIONS 38

5.1 SMTP RELAY MODE 38
5.2 MICROSOFT EXCHANGE 2000 PLUG-IN MODE 39
5.3 DEPLOYING MULTIPLE SERVERS 40
5.4 PERFORMANCE AND SCALABILITY 41

Page iii of 60


6 TECHNOLOGY IN DEPTH 43

6.1 PRODUCT ARCHITECTURE 43
6.2 TYPE DETECTION 45
6.3 POLICY SELECTION ALGORITHM 46
6.3.1 SPLITTING THE MESSAGE FOR MULTIPLE POLICIES 46

7 VITAL SECURITY’S STATIC CODE INSPECTION 49

7.1 JAVA INSPECTION 49
7.1.1 APPLET ID GENERATION 50
7.1.2 POLICY SELECTIO 50
7.1.3 JAVA CODE SCANNING 51
7.1.4 SUBSTITUTE APPLET GENERATION 51
7.2 ACTIVEX INSPECTION 51
7.2.1 OBJECT ID GENERATION 51
7.2.2 POLICY SELECTION 52
7.2.3 CODE SCANNING 52
7.2.3.1 Profiling the Windows APIs and MFC library 52
7.2.3.2 Profiling an ActiveX control 53
7.2.4 SUBSTITUTE CONTROL GENERATOR 53
7.3 SCRIPT INSPECTION 53
7.3.1 CODE SCANNING 54
7.3.2 BLOCKING MULTIPLE SCRIPTS ON A PAGE 54
7.3.3 DETECTING SCRIPT LANGUAGE 55

8 VITAL SECURITY PRODUCT SECURITY MEASURES 56

8.1 SELF-PROTECTION 56
8.2 DEPLOYING SERVERS IN A DMZ 57

9 KNOWN SECURITY LIMITATIONS 58

9.1 ENCRYPTED COMMUNICATION 58
9.2 DYNAMIC CREATION OF HTML PAGES 58

10 ABOUT FINJAN 60

Page iv of 60


1 Introduction

1.1 General Overview of Finjan Products
Vital Security™ for E-Mail (VSE) is a key component in the Finjan Vital Security™ platform and
the only content security solution that provides Secure Content Management (SCM) technology,
which includes antivirus (AV), Internet access control (IAC), employee Internet management (EIM),
e-mail scanning, and proactive Mobile Malicious Code (MMC) protection in a fully integrated, Best-
of Breed solution.
Finjan’s approach to mobile code security is to provide multiple lines of defense (Web, e-mail, and
desktop), where each line employs different tools and technologies to detect and block mobile code
that does not adhere to pre-configured security policies.
Lines of defense at the gateways to the corporate network are:
• Proactive content inspection and blocking of hostile mobile code objects.
• Filtering based on hash of known mobile code objects.
• Filtering by origin (source) and by digital signatures of code.
• Reactive blocking of known viruses, using the NAI Olympus anti-virus engine.
Lines of defense at the user’s desktop are:
• Detection of start/stop events of mobile code objects in the system.
• Runtime monitoring of mobile code object activities at the operating system level.
• Runtime monitoring of Java applets at the Java Virtual machine level.
• Ability to control (kill) mobile code objects.
• Filtering based on mobile code hash and URL.
Vital Security™ for Web implements the Gateway line of defense for HTTP/FTP/HTML traffic.
It scans HTML and mobile code objects at the gateway, away from critical resources, to develop a
profile of the code. Mobile code objects with profiles that do not reconcile with the enforced
security policy are not passed to the requesting browser.
Vital Security™ for E-Mail implements the Gateway line of defense for SMTP and POP3 traffic
and performs the same kind of content inspection done by Vital Security for Web, on E-Mail
messages.
Vital Security™ for Clients implements the desktop line of defense. It integrates with the
operating system, detecting when mobile code starts to run, monitoring it at run-time, and enforcing
the security policy on it.
Using Vital Security Console – the management console for Finjan’s products – system

Page 5 of 60


administrators can manage and control a corporate-wide security policy for all Internet
downloadables in the network, including ActiveX, Java, executables, JavaScript, VB Script and
embedded Plug-ins.
Vital Security for Web, Vital Security for E-Mail and Vital Security for Clients all support security
auditing through detailed log-based activity reports, that can be produced and viewed using the
logging and reporting feature built into the Vital Security Console.

1.2 Introduction to Vital Security for E-Mail
Vital Security for E-Mail products provides a complete e-mail security solution, including proactive
scanning of ActiveX, Java, Visual Basic Script and JavaScript, and also reactive scanning of all
documents and executables for known viruses, using the NAI Olympus anti-virus engine.
Using a patented, real-time content-inspection process, Vital Security for E-Mail identifies and
blocks malicious code without relying on database updates. Centrally managed, Vital Security allows
companies to tailor security policies for departments and users and enables secure e-business.
Vital Security for E-Mail also provides a powerful and flexible platform for controlling e-mail
entering the organization. With Vital Security for E-Mail, organizations can control code coming
into their organizations based upon sender, type, digital signature and trust. In all cases, Vital
Security for E-Mail still inspects all mobile code and allows the creation of white lists or black lists.
Vital Security for E-Mail may be deployed in various ways, according to the number of clients,
access patterns, network topology, other e-mail gateway products and organizational practices. Vital
Security for E-Mail is scalable and flexible, and will allow for organizational change and growth.

1.3 Purpose & Scope
The purpose of this document is to explain the technology and basic architecture of the Vital
Security for E-Mail product, and help the reader to better understand how it works, starting with an
overview of Vital Security for E-Mail, followed by a more in-depth explanation of the technologies
used and implementation details.
The Target audience is:
• Customer CIO, MIS and IT managers
• Business partners
• Finjan Marketing & Sales

Page 6 of 60


1.4 Definitions, Acronyms & Abbreviations

1.4.1 Definitions

Active Content, Mobile Code
These two terms are used synonymously to describe any code that is delivered
and executed on a desktop host during network access. Users may not be aware
of the Active Content activity. Active Content is typically driven by (but not
limited to) HTML documents. It can be delivered by various tools (e.g., browser,
e-mail, office application, push client) and protocols (e.g., HTTP, FTP, SMTP).
Vital Security provides proactive protection against potentially harmful Active
Content such as ActiveX, Java, executables, JavaScript, VB Script and plug-ins,
delivered via HTTP, FTP over HTTP, and Native FTP.

Active Content Object
A generic name for a specific Active Content unit. May refer to Java Applets,
ActiveX Controls, JavaScript scripts, Visual Basic Scripts, plug-in modules, etc.
Active content objects may also be referred to as "downloadables", or simply as
“objects".

Applet A program written in the Java programming language and implemented as a Java
Applet. A browser that supports Java may download and run the applet
automatically.
ActiveX A native-code program that conforms to the ActiveX Control specifications. A
browser that supports ActiveX may download and run it automatically.
CDO Collaboration Data Objects. Another set of Microsoft COM-based APIs that can
be used, among other things, to manipulate e-mail messages.
Document A document is a file that contains information that the user can read, view , or
hear. It is most often a word processed letter, a picture, a sound byte, or any
similar type of information. In the context of this document, Web pages (e.g.,
HTML, XML, DHTML, MIME).
FHTTP Finjan’s protocol for communication between the components of the Vital
Security Server family, such as communication with the database server and
communication between a server and the console. This protocol is based on the
standard HTTP protocol.
Group A collection of users and/or sub-groups. Groups are the means to define a
hierarchical structure for all the users in the organization.
MAPI Messaging API. Usually refers to Microsoft APIs for sending and receiving mail
messages and communicate with Mail servers.
MIME MIME is an acronym for Multipurpose Internet Mail Extensions, and refers to
an official Internet standard that specifies how messages must be formatted so

Page 7 of 60


that they can be exchanged between different e-mail systems. MIME is very
flexible format, which permits the inclusion of virtually any type of file or
document in an e-mail message. MIME messages can contain text, images,
audio, video, or any other application-specific data.
MS/TNEF Microsoft’s Transport Neutral Encapsulated Format. An encoding format used
by Microsoft for passing binary and textual data (usually rich-text formatted
messages) between “MAPI Enabled” e-mail clients.
Usually visible as a Winmail.dat attachment when viewed with non-MAPI e-mail
clients.
Security Policy The set of operations that are allowed to be performed on the resources of
desktop computers. A security policy may be defined for each user or group.
Security Profile All the operations that an active content object has the potential to invoke on the
resources of the client computer.
User An individual client in the organization. A user is typically identified by user
name, domain/group name and/or the user's computer IP address.

1.4.2 Abbreviations
API Application Program Interface
CEL Content Examination Library (Finjan Software)
COM Component Object Model
DLL Dynamic Load Library
DMZ DeMilitarized Zone
DNS Domain Name Server/Service
FTP File Transfer Protocol
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS Secure HTTP
JVM Java Virtual Machine
NIC Network Interface Card
SDK Software Development Kit
SMTP Simple Mail Transfer Protocol
SSL Secure Socket Layer
TBD To Be Determined
URL Universal Resource Locator
VPN Virtual Private Network

Page 8 of 60


2 Product Overview
This overview assumes the reader is generally familiar with the product and therefore does not cover
all of its features in depth. For detailed description of the product’s feature and how to use them,
please refer to the Vital Security for E-Mail’s User Manual.

2.1 Vital Security for E-Mail Components
Vital Security for E-Mail consists of three components:
• The Vital Security for E-Mail server: Runs on Windows 2000 Server.
• The Vital Security database server: Manages the Vital Security database, stores the security
policies, security profiles and activity log. The database engine can be the Windows Jet database
or an Oracle database, depending on the platform used for the Database Server.
• The Vital Security Console management console: A central tool for managing the corporate
security policies, controlling multiple Vital Security servers and generating reports.
All three components may reside on a single host or on three separate hosts. If only one Vital
Security for E-Mail is installed, it can be installed as a standalone server, without any database server
component.
This document focuses on the Vital Security for E-Mail server component, since it is the one that
contains all the security enforcement features. For more information on the Vital Security.

2.2 Multi-Level Security Policy
Vital Security for E-Mail’s management console enables the system administrator to define a
corporate policy to be enforced on E-Mail messages. Vital Security for E-Mail 7.0 allows different
policies to be defined for different users. This is described in detail in section 3.2.
Vital Security for E-Mail also allows the administrator to define ‘exceptions’ to the default policy for
each user. For example, it is possible to filter e-mail by their sender and certificates, as well as filter
code objects by their hash and signatures. These options are also described in detail in the next two
chapters.
Please refer to the Vital Security for E-Mail’s User Guide for a detailed description of security
policies and how to manage them.

2.3 Code Scanning at the Gateway
Vital Security for E-Mail is installed at the corporate entry point for E-Mail traffic, and inspects the
mobile code objects that attempt to enter the network. Vital Security for E-Mail scans the E-Mail

Page 9 of 60


messages, performs a signature-based anti-virus scanning on all parts of the e-mail (body and
attachments), as a first filter for known malicious code, and then applies a second line of defense
(the proactive one) on all other code objects, looking for potentially risky functions such as file
system operations and network operations. Based on this inspection, Vital Security for E-Mail
generates a security profile and checks it against the security policy set for the organization. The
security policy defines the resource access permissions. Based on this comparison, Vital Security
then determines whether to block the mobile code object or to pass it into the network.

2.3.1 Policies And Profiles
The security profile contains all potentially sensitive resources and hostile operations that the active
content object can perform on the client’s desktop. Similarly, a security policy represents the parallel
set of permissions to access restricted resources:
• File system operations: Read, Read/Write. File query operations, such as directory listing, are
considered as Read. File modification operations, such as Delete or Rename, are considered as
Read/Write.
• Network access operations: Listen, Connect, Send, and Receive.
• Registry operations: Read, Write.
• Operating System operations: Creating, terminating, or changing the priority of processes and
threads, accessing other applications that are running, loading dynamic link libraries, and more.
• JVM and Browser operations: Involve access to internal objects inside the browser or the Java
Virtual Machine, such as using the browser services to send e-mail, read/write cookies, change
the settings of the Java Virtual Machine Security Manager, and more.

2.4 The Security Policy
Vital Security for E-Mail’s management console enables the system administrator to define a
corporate policy to be enforced on E-Mail messages. A new feature in Vital Security for E-Mail 7.0
allows different policies to be defined for different users. This is described in detail in section 3.2.
Vital Security for E-Mail also allows the administrator to define ‘exceptions’ to the default policy for
each user. For example, it is possible to filter e-mail by their sender and certificates, as well as filter
code objects by their hash and signatures. These options are also described in detail in the next two
chapters.
Please refer to the Vital Security User Guide for a detailed description of security policies and how
to manage them.

Page 10 of 60


3 Features And Benefits

3.1 Content Inspection and Proactive Code Scanning
Vital Security for E-Mail is a full e-mail content security and management server. It scans all e-mails
coming into and leaving the organization, applies a series of scanning rules that are based on
scanning the actual content of the e-mail, and can modify the e-mail message according to the
corporate policy.
When Vital Security for E-Mail receives an e-mail for inspection, it invokes a series of rules,
configurable from the consoles GUI, and either allows, blocks or modifies the e-mail content, based
on the outcome of those rules. The algorithm for determining how to handle a specific piece of
content goes through the following steps:
• Breaking the e-mail apart into a collection of content objects, such as the e-mail body,
attachments, content inside archives, etc.
• Detecting the type of each of the content objects, in order to determine which of the scanners
and filters should be applied on it.
• Applying anti-virus scanning for all active content, programs and documents. If known virus is
detected, data is blocked regardless of other filters.
• Filtering by known objects with pre-defined policy.
• Filtering by senders with pre-defined policy. Sender policy can be applied specifically for active
content from this sender, or on the whole e-mail message.
• Filtering signed code and e-mail messages by certificates.
• Applying Vital Security’s patented proactive code scanning engines, calculating the code’s
profile, and allowing or blocking the active content based on comparing the profile against the
user's policy
Type detection in Vital Security for E-Mail is based on a combination of SMTP headers analysis,
Message MIME formatting, HTML pages scanning, file names (specifically, file extension), and
actual data analysis. The result of this scanning can classify each content as active content (e.g. a
program or a document that may contain some code), or as simple data. According to this
classification, some of the filters may be skipped. For example, when setting Vital Security to scan
only programs and documents for viruses, it means that when an image (for example, a .GIF file) is
transferred, it will not be scanned.
Note, however, that Vital Security’s type detection goes beyond file names and MIME types. For
example, a GIF file that is actually an HTML file will be detected as such, classified as HTML page,
and virus scanning will be applied on it.
Vital Security for E-Mail’s key benefit lies in its ability to proactively scan code coming from the

Page 11 of 60


Internet, profile the code to determine what resource access operations it may attempt to perform,
and block code that attempts to perform operations that are not allowed according to the predefined
policy. This is the heart of Vital Security’s ability to block new attacks without any prior knowledge
of them, and close the Window Of Vulnerability left open by traditional reactive approaches.
Vital Security allows the administrator to set a block/allow/scan policy for every active content type.
For each type of code, an "Allow" policy generally passes it through without modification. A
"Block" policy will generally block the active content object from being sent to the user. A "Scan"
policy will generally create a unique identifier for the code object, pass the code through the
appropriate code scanner, and compare the code profile to the policy.
The content inspection capabilities of Vital Security for E-Mail are discussed in chapter 4

3.2 Multiple Policies Support

3.2.1 Managing Multiple Policies
Vital Security for E-Mail 7.0 supports enables the administrator to define multiple policies for
different cases. Different policies can be assigned to different users, and different policies can be
assigned to incoming and outgoing e-mail messages.
This enables the administrator to define privileged users that have a more relaxed policy than others.
Usually this is required for the internal users in the IT department. It can also be used, in
conjunction with the lexical analyzer rules, to define specific keyword scanning that applies to
different department. For example, in the legal department, a tighter scanning may be applied to
ensure no sensitive information leaks out, or to add legal disclaimers to all outgoing e-mail messages.

3.2.1.1 User Identification
Until Vital Security 7.0, a user was identified by their static IP address. Under this model, a user is
always identified by their machine, and a machine must have a static IP address assigned in order to
create and assign a special policy for it.
Under DHCP environments, where IP addresses are allocated dynamically, a policy can be set for an
IP range, allowing for the setting of group policies for users by assigning them a special IP range in
the DHCP server.
In version 7.0, Vital Security introduces the ability to identify real users by their login name, and
allocate policies to users instead of machines. Users can be identified by several unique identifiers.
They can be identified by their IP address, like before, but they can also be identified by their NT
domain login name, which serves as the way to identify a user, no matter what machine they are
using.
In Vital Security for E-Mail, a user can also be identified by their e-mail address.
In addition, the following user identification support is provided:
Microsoft Active Directory – Allows customers to use their existing Active Directory settings to

Page 12 of 60


define which policies users receive based on their Active Directory group membership.

Microsoft Active Directory provides the following benefits and support:
• Users do not need to be managed in Vital Security (i.e., They continue to be managed only in
Active Directory).
• Vital Security is aware of Active Directory groups.
• Users can define a group policy in Vital Security for each relevant Active Directory group.
• When accessing the Internet, a user receives (inherits) policy based on their Active Directory
group membership.
• If a user changes groups or is added to a new group, Vital Security automatically applies the
new policy.

3.2.1.2 User Auto-Detection
Usernames can be automatically added to the Vital Security users database, using the auto-discovery
feature. This way, any user that passes through Vital Security is added to the Vital Security’s user tree
and can be assigned a policy.
Vital Security Console can also be used to import users from an existing NT domain, instead of
waiting for the user to be discovered automatically. This functionality can be used to define, in
advance, all users that require special policies in Vital Security. Those users should be imported by
name or IP address into the Vital Security users tree, arranged according to logical Vital Security
groups, and policy can be assigned to these groups, or to individual users.
Last, users can be added manually to the database, by simply typing in their domain and username.
Auto-Detection can be enabled or disabled. By default, Auto-Detection is disabled when Vital
Security for E-Mail is first installed. Auto-Detection can remain disabled if the user intends to
maintain only a global (corporate) policy and does not need to establish group or user policies.

3.2.2 Incoming vs. Outgoing Policies
Vital Security for E-Mail approach for setting policies for outgoing e-mail messages is based on the
concept that a typical organization will apply more strict rules on the incoming traffic than on the
outgoing traffic, but will still want to perform some scanning on outgoing messages.
For example, a typical setup would be to scan incoming messages using all scanners, including the
anti-virus engine and the pro-active code scanning engines, to apply some additional filters based on
certificates, known senders, etc. However, for outgoing messages, it would be enough to scan for
known viruses (to avoid spreading virus), and to add some legal or other disclaimers to some or all
of the messages.
In order to simplify creating those rules, Vital Security for E-Mail rules are more focused on
incoming policies. It is then possible to define which of these rules are also applied outbound, on
outgoing messages.
Outgoing policies are grouped as follows:
• Anti-Virus scanning

Page 13 of 60


• Code scanning – for all the proactive code scanners
• Document blocking – for the extension and auto-launch blocking rules
• Size restrictions
• Recipient count restrictions
Each of these families of restriction can be turned OFF for outgoing policies, while still being
applied for incoming.
In addition to that, disclaimers and keyword scanning have specific direction associated with each
rule. Different disclaimers can be defined for incoming and outgoing messages, based on e-mail
direction and on the results of the keyword scanning.
This unique approach for policy definition takes into consideration all the common scanning rules,
while removing all the non-relevant ones (such as Spam detection on outgoing messages), and makes
the life of the administrator much easier when defining e-mail policies.

3.2.3 How Does It Work?
Each e-mail that passes through Vital Security for E-Mail is first classified to be either incoming or
outgoing, and then the appropriate user policy is enforced on it. For this to be possible, the
administrator has to define in the console the list of domains that should be considered as internal
domains.
When Vital Security for E-Mail inspects an e-mail message, it first analyses the list of recipients. For
each recipient that is in the list of internal domains, or is specifically defined in the users tree, the
message is considered incoming. For all other recipients, it is considered as outgoing. Note that this
means that all internal e-mails (e.g. e-mail messages sent between users of the organization) are
scanned using the incoming mail policies.
The e-mail is then split internally into a number of messages, according to the number of different
policies that should be applied on the e-mail, and each part is handled separately, with policy being
enforced on it. The end result is that different users with different policies may receive different
variants of the message.
Also note that for outgoing messages, the outgoing policy that is enforced depends on the sender of
the message, because the recipient is external to the system and not defined in the users tree.
The following diagram illustrates how Vital Security for E-Mail classifies an e-mail as incoming vs.
outgoing, and which policy is applied to it:

Page 14 of 60


Zonene protected by SurinGate for E-Mail l
Zo
Protected by Vital Security for E-Mai
Legend

Domains A and B - defined as internal domains
Domains C and D - external domains
#2 User C1 - Added manually to SurfinGate for E-Mail
#3 user tree (via the console)

#1. Outgoing - message send from internal to non-
internal domain
#2. Incoming - message send inside the internal
#4
Domain A Domain B
domain
#5 #3. Incoming - message send from internal domain to
other internal domain
#1
#4. Incoming - message send to non-internal domain
but specific user is known
#5. Incoming - message send to internal domain from
outside

User C1

Domain C
Domain D

Figure 1: Classifying Incoming vs. Outgoing Messages

3.3 Quarantine Management
Vital Security for E-Mail modifies e-mail messages as part of normal operation. It detects policy
violations and delivers a modified version of the e-mail, without the violations, to the end user.
Unlike Vital Security for Web, an e-mail message that was modified cannot be simply restored by re-
downloading it from the web. For this reason, Vital Security for E-Mail contains a quarantine
mechanism, with the purpose of allowing a complete restoration of the original message.
The Vital Security for E-Mail quarantine is implemented as a set of disk folders that stores ZIP files
with original unmodified data. For each e-mail message that is modified, all the modified parts are
stored in a ZIP file and assigned a unique ID (filename). This filename is logged and also attached to
the modified e-mail message (as part of the modification notification to the end user) to allow for
easy finding and recovery of the original message, if required.
The quarantine manager is configurable. Administrators can define what files will be stored in the
quarantine, based on criteria such as e-mail sender and recipients, file types, e-mail size, etc.
The quarantine size can also be controlled by setting limits on its size and on the hold time of each
file.
All this is designed to ensure access to unmodified data from one side, but also ensure the
quarantine will not over inflate and become full (which may mean new data could not be

Page 15 of 60


quarantined and will be lost).
Vital Security for E-Mail 7.0 introduces a new enhancement to quarantine management. It can be
configured to store full e-mail messages in the quarantine, instead of just the modified parts. This
wastes some quarantine space, but makes it easier to recover modified messages when required.
Vital Security for E-Mail 7.0 can also be configured to forward all messages that need to be
quarantined into another mailbox. This can be used either as an alternative method to store
modified messages, or as an addition to the file quarantine. Note that for e-mail forwarding mode,
there is no enforcement on quarantine size.

3.4 Anti-Spam Support
Spam e-mail is considered as annoying to say the least, but can become a real productivity killer as
the amount of Spam is getting bigger and bigger. Vital Security for E-Mail 7.0 includes several new
features that are all targeted to help the organization detect and block Spam messages, including
detecting open-relay systems, detecting Spam by keywords, and blocking e-mail based on recipients
count.

3.4.1 Blocking Messages From Open Relays
Spam e-mail is characterized by its mass distribution, and often also by the attempt of the sender to
stay anonymous. For this reason, spammers will often use another SMTP server to send their e-mail.
SMTP servers that allow that, by allowing basically anyone to send e-mail messages through them,
are known as ‘open relays’, and are considered a major source of Spam mail.
There are a number of Internet based initiatives, which provide information about open relay
servers. They maintain a database of known open relay systems, which can be queried using standard
DNS requests, and return an answer whether a given server is an open relay. It is possible to use
such servers over the Internet, and it is also possible to purchase such a server to run locally inside
the organization, for better performance. The two biggest open-relay databases that exist today are
ORDB (http://www.ordb.org) and MAPS (http://mail-abuse.org)
Vital Security for E-Mail can work with both databases, and with any other database that supports
the same DNS query format, in order to detect and block mail messages that originated from an
open relay system. It checks any of the SMTP servers in the chain of transfer of each mail message,
and blocks if any of them are classified as an open-relay.
Vital Security for E-Mail can be configured to work with more than one database, and it can be
configured to either query all the databases and allow the e-mail in only if all the databases do not
classify it as Spam (e.g. take a very suspicious approach to Spam detection), or to query them in
parallel and classify based on the first answer received (e.g. treat the databases as backup to each
other).
Note that in the rare case an e-mail is being classified as Spam by an open relay database, it is
possible to bypass this by adding the specific sender or sender’s domain to the Sender list with an
allow policy. This list takes precedence over any other blocking rule, except the Anti-Virus engine.

Page 16 of 60


3.4.2 Block Specific SMTP Servers
Vital Security for E-Mail can be configured to manually block SMTP servers that are known to be
sending Spam and were not added to the open-relay database. This can be used, for example, to
block Spam in a more controlled way, as an alternative to the open-relay database, or as an
expansion to the open-relay database.
Blocking is based on the IP of the SMTP server. Vital Security for E-Mail performs DNS query on
all SMTP servers to resolve the SMTP servers’ chain of delivery to IP addresses and also handles
multiple IP addresses for a specific SMTP server.

3.4.3 Block By Recipients Count
Spam is often characterized by being sent to a large distribution list. In some cases the spammer will
attempt to hide this by putting all the recipients in the BCC field. In other cases, their names will
appear in the TO and CC fields. Vital Security for E-Mail can be configured to block e-mail if there
is more than a given limit of recipients to this e-mail.

3.4.4 Detect Spam Using Keyword Analysis
Vital Security for E-Mail can detect and block Spam e-mail based on lexical analysis of the text
inside the e-mail. This feature is also very powerful for classifying e-mail messages by types, for
purposes other than Spam blocking.

3.4.5 Extended Anti-Spam Features (MailShell)
Vital Security for E-Mail has an optional anti-spam component, which has the following features:
• Classification of incoming messages based on probability of being spam.
• Customizable actions to perform on messages, based on classification.
• Reports that display spam-related statistics.

3.4.5.1 Classification of Incoming Messages
Vital Security for E-Mail incorporates the MailShell SpamCatcher engine – an award-winning anti-
spam solution, reputed to have the lowest rate of “false-positives”, or messages mistakenly classed as
spam.
Each incoming message is analyzed by SpamCatcher, and given a SpamScore, or probability that it is
spam. This value can be from 0 to 100, where 100 is definitely spam and 0 is definitely not spam.

Page 17 of 60


Vital Security for E-Mail uses the SpamScore to classify each message into one of the following
bands of spam probability:
1. Highest
2. High
3. Medium
4. Low
5. Lowest

The purpose of these bands is to simplify the task of defining how to handle incoming messages,
based on their SpamScore (see below).
Vital Security for E-Mail ships with default ranges for these bands, recommended by MailShell. The
administrator may change the values as needed.
The following graph, generated from Finjan’s own mail server data, shows a typical distribution of
SpamScores. It is easy to see that the levels should not be of equal size, e.g. 0-20, 21-40, 41-60 …

3.4.5.2 Analysis of Incoming Messages
The MailShell SpamCatcher engine periodically downloads rules and other information from
MailShell’s servers that contain the following types of information:
• “Fingerprints” of known spam messages

Page 18 of 60


• Tricks commonly used by spammers
• Words that typically appear in spam messages
• Rules for analysing spam

SpamCatcher uses over 1000 rules to analyze each incoming message, and its fingerprint is
compared against a list of known spam fingerprints. The end result is a probability from 0 to 100
that a message is spam.
As an alternative to the periodical rule and database updates, the SpamCatcher engine offers the
capability of checking each message’s fingerprint against MailShell’s online database, which is always
up-to-date. However, using this option incurs a significant cost, performance-wise.

3.4.5.3 Actions Performed on Incoming Messages
After a message is classified into one of the levels of spam probability, Vital Security handles it
according to the action defined for the specified level. The following actions are available:
• Block the message.
This is most useful for the highest spam level. The message will be deleted, unless the
administrator has used the Console to define that such messages be quarantined.
Note: the setting for spam quarantine is distinct from the setting for AV quarantine.
• Insert MIME headers containing the SpamScore and Vital Security spam level name into
the message.
These headers are invisible to the end user, but e-mail clients such as MS Outlook allow users to
define message handling rules based on these headers. For example, a user could define a rule
that places all messages belonging to a specific spam level into a special folder.

Page 19 of 60


This is useful for spam levels that occasionally contain “false positives”, or messages that are not
really spam. The end user can check regularly for false positives and delete the rest very quickly.
Some e-mail clients such as MS Outlook allow the user to view the MIME headers.

Page 20 of 60


This feature can be. used in order to see what SpamScore was given to a message.

The SpamScore entries are shown in the Internet headers section in the screen above.
• Prefix the subject with customizable text.
This can be used to add a visual cue for the end user by prefixing the subject with text that is
relevant to the spam level, e.g. “SPAM4”. Rules can also be defined using e-mail clients to
handle messages with subjects containing the specified text.
• Prefix the message body with a customizable disclaimer.
This can be used to warn the user of potentially offensive content appearing below.
• Allow the message through unchanged.
This is recommended for the lower spam levels.

Note: messages that are not blocked continue on to be scanned for MMC, AV etc.

3.4.5.4 Reports
Vital Security for E-Mail provides a number of new reports:
• Spam Score Distribution (depicted above)
Helps to choose optimal values for the spam level thresholds.
• Spam Level Distribution
Pie chart showing the percentage of incoming e-mails pertaining to each spam level.
This chart shows in a very simple manner just how much spam is coming into the organisation.
Proof of ROI.

Page 21 of 60


• Top 20 Users by Average Spam Score
Bar chart showing the top 20 users, based on the average spam score of received messages.

3.4.5.5 Configuring Anti-Spam Settings
The anti-spam functionality is controlled by entries in the server’s configuration file. These values
are not accessible via the Console.

3.5 Disclaimers
Vital Security for E-Mail can add text notifications to any incoming or outgoing e-mail passing
through it. The most common use of this is to add a legal disclaimer to all outgoing messages, but it
can also be used to add disclaimers based on the user who sends the e-mail (for example, attach legal
disclaimer to e-mail coming out of the legal department, and a more general disclaimer to all other
users).
Disclaimers can be added at the top or bottom of the scanned e-mail message, or as an attachment.
They can contain customizable text, like any other Vital Security notification, using the concept of
‘variables’. For example, a disclaimer can contain a variable named ‘%server_name%’ which will be
replaced by the name of the Vital Security for E-Mail server that added the disclaimer.
Last, disclaimers can be conditional, and depend on the result of the content scanning. This is
described in section 3.6 below.

3.6 Content Scanning
Vital Security for E-Mail contains a powerful keyword scanning engine that can be configured to
categorize e-mail based on text scanning. It has built-in dictionaries to detect e-mail that can be
classified as adult or sexual, Spam, gambling and more.
The keyword detection engine can be configured to perform complex logical AND/OR and word-
count combination on words from the dictionary or custom words. The result of this logical clause
are used to classify the text as a match/mismatch to the rule.
Keyword scanning can be applied on all or some of the e-mail parts. It can be applied on the Subject
line, on the e-mail body, on text and Microsoft office document attachments, or on any combination
of those.
When an e-mail is classified as matching a specific keyword filtering rule, Vital Security for E-Mail
can either block or allow the e-mail, or it can add a disclaimer (see section 3.5 above). Each rule can
have different action take on incoming and on outgoing messages.
Vital Security’s console contains an intuitive graphical editor to allow for easy definition of keyword
scanning rules. This editor allows building logical inspection rules, combine them with dictionary
words, select the parts of the e-mail to apply the scanning on and define the action to be performed.

Page 22 of 60


3.7 MS Office Document Auditing and Watermarking
Document watermarking is a patented, revolutionary new feature introduced in Vital Security for E-
Mail 7.0, which does not exist in any of the e-mail scanning products in the market today.
This feature provides to customers auditing reports about movement of MSOffice documents
through the corporate e-mail system. By the usage of Finjan’s unique identifier (“watermark”), which
becomes an invisible part of the document, Vital Security for E-Mail can collect and represent to the
customer complete information about the entering, leaving and internal movement of any MS
Office document.
Watermarking allows an organization to keep track of the flow of sensitive office documents inside
the organization and even keep track of when documents leave the organization and to which
destination.
Every time an office document is transferred (via e-mail) from one user to another, the transaction is
logged. This can be a very powerful feature for detecting and tracking the history and whereabouts
of an internal document, as well as determining whether or not it has reached users who should not
access to such documents. Document watermarking can also be used to detect when a document
left the organization (for example, when a contract was sent to a law firm for inspection), and when
it came back.
Document watermarking is smart enough to detect a document even if it has been edited and
changed. It works by adding a secret ‘stamp’ on the document that uniquely identifies it for all future
transactions.
Finally, watermarking can be applied on all documents, or it can be selectively applied by defining
keyword scanning rules that serve as a condition for watermarking. This can be used to track only
legal documents, for example, by looking inside the document for typical legal terminology, and only
logging all transactions involving such documents.

3.8 Access Control Management of MS Office Documents
The combination of Content Scanning and Watermarking provides a full Access Control
Management to MS Office documents, without the need to install any software agent on every
desktop that is running MS Office.
This is achieved by adding text to the document header or footer (or at any other location within an
MS Office document) that contains usage restrictions. For example, if document writer specifies in
document header “this document can be viewed by Company Executive Committee personnel
only”, the administrator can define a policy that detects documents with this restriction and allows it
to be sent only to users associated with Company Executive Committee group.
As a result of this Watermarking feature, Vital Security for E-Mail will guarantee that this document
will not be sent via e-mail to other users and will audit any such attempt. The combination of
Content Scanning and Watermarking provides sophisticated Access Control Management and
auditing of MS Office documents.

Page 23 of 60


3.9 Logging
When Vital Security for E-Mail blocks or modifies an e-mail message due to policy violations, a log
event is sent to the database server. This log event contains the violation information (virus found,
code scanning detected policy violation, etc.). Logs are collected in the database for reporting, but
can also be extracted to external systems either manually or automatically, through the use of CSV
(comma-separated values) files.
It is also possible to automatically create W3C standardized logs for logging all web requests. This
feature allows for better integration with logging and reporting systems that depend upon getting
on-the-fly logging information from the network infrastructure servers.
There are two basic types of events logged by Vital Security: System and Active Content.
• System logging – Records general system events such as date and time, server, action type,
and information about the event that occurred.

• Active Content logging – Records Active Content activity; including Date/Time, Source,
Server, User/IP, Active Content Name, Active Content Type, Action Type, URL/Sender,
File Name, Description, and additional relevant blocking information.

System and Active Content logs are accessed by selecting the Servers option first, then selecting the
Logs option (left panel icons in the Vital Security Console)files.
Starting from version 7.0, a log event can also be automatically sent to standardized logging servers,
such as a SYSLOG server. Also, it is now possible to automatically create W3C standardized logs,
specifying in more detail, which log fields should be collected. This new feature allows for better
integration with logging and reporting systems that depend on getting on-the-fly logging information
from the network infrastructure servers.

3.10 Administrative Alerts
Vital Security can send e-mail alerts to the administrator when certain events occur. Alerts are
divided into two areas:
• System Events
• Security Violations

Each of these can be turned ON or OFF. For example, you can turn on just system events alerting,
to cause Vital Security to alert the administrator when a system event, such as a license expiration
event, occurs. You can turn on security violations alert to notify the administrator whenever active
content is blocked due to policy violation.
In order to use the alerts, it is necessary to pre-configure Vital Security with SMTP server account
information, and with the administrator e-mail address. Vital Security will send all e-mail
notifications to this mailbox.

Page 24 of 60


3.11 Notifications to End-Users
In addition to central logging, Vital Security for E-Mail can also notify the user about modifications
made to his e-mail messages. These notifications come in the form of a modification to the e-mail
body, an attachment with more detailed information about violations found and the location of
items in the quarantine, as well as a customized message that can be used by the administrator to let
users know about corporate policies regarding blocked e-mail messages.
Last, in some cases, when Vital Security for E-Mail cannot scan a specific message or attachment, as
in the case of encrypted archives, it is optional to pass the e-mail to the end user with a warning
message, or to return such e-mail messages to the sender, with notification that the message was not
delivered because it could not be scanned.
Most of these notifications are fully configurable and customizable. They can be turned on or off,
and the text can be edited, either via the console, or via external configuration text files.

3.12 System Robustness
Vital Security for E-Mail is built to be robust, stable and to avoid any loss of data. E-Mail traffic is
considered very sensitive and no e-mail should ever be lost by a relay system.
For this reason, Vital Security for E-Mail is designed with high data reliability in mind. It is built over
the IIS SMTP virtual server, which handles all SMTP communications, as well as handling failures
gracefully by queuing any message until it is successfully delivered to the next hop (the mail server).
The IIS SMTP service is also capable (as any Windows 2000 service) to recover from failures and
restart itself. Vital Security for E-Mail benefits from this feature and in the rare case of a program
failure in Vital Security for E-Mail, the IIS SMTP service will be restarted automatically, and SMTP
functionality will resume in no time.
In addition, Vital Security for E-Mail has its own built-in queue for handling any intermittent error
condition during scanning. This mechanism can store the message for later scanning and delivery. It
also has built in timers for delivering such messages to a bad mail folder or to the end user with a
warning, if scanning could not be performed in a preset time frame.
Vital Security for E-Mail is also built with high availability in mind. It does not depend on any
external component to function, and, for example, can cache all policies and logging information, in
case of a database server failure. This ensures continuous e-mail scanning as long as the IIS SMTP
service is running.

Page 25 of 60


4 Content Inspection

4.1 Content Inspection Flow
The general decision-making flow of Vital Security is shown in the following diagram. It assumes
that all filters are enabled, and are arranged in the default order.

Page 26 of 60


Start

Apply Anti-Virus
Scanning

Virus
Yes
Detected?

No

Object Policy
Block Allow
found?

No

Sender Allow
Block Policy found?

Scan
No

Certificate Allow
Block policy found?

No Scan

Use
Block Allow
Default Policy

Scan

Apply code
scanner
(fetch or calculate
profile)

Violation found Compare No violation
policy to profile

Block Allow

Figure 2: Content Inspection Algorithm

4.2 Breaking The E-Mail Apart
The first thing Vital Security for E-Mail has to do when receiving an e-mail message for inspection is
to break it apart and apply scanning on each body part and attachment. Vital Security for E-mail
does that using Windows 2000 services known as CDO (see above, 1.4.1), and also using some

Page 27 of 60


internal parsers for handling various MIME formats, MS/TNEF format, etc.
Vital Security for E-Mail also keeps the context of the e-mail parts and uses it during inspection, so
that references between different parts of the messages are taken into consideration while scanning
is applied.
For example, an e-mail message may contain an HTML body part with a reference to an object
(which may be an executable) that is attached to the message.
Vital Security for E-Mail can also reconstruct a message before it can apply scanning (when a
message is sent as a multi-part message). This is done by collecting all parts into a special queue,
preventing them from being passed on to the end user. Once all parts are collected, the full message
is reconstructed, scanned, potentially modified, and then broken back to parts in about the same size
as the original parts, and sent on.

4.2.1 Handling Archives
Vital Security for E-Mail applies full policy scanning on ZIP, GZIP, CAB and JAR archives as well
as self-extracting ZIP files. Other types of archives are scanned only by the anti-virus engine.
Vital Security for E-Mail can scan archives recursively. Each archive is expanded and each file inside
the archive is scanned. In case an archive is located inside another archive (nested archives), Vital
Security for E-Mail can recursively scan the internal archive. The level of recursive scanning is
configurable and defaults to 5 levels down for the proactive scanner. The NAI anti-virus engine also
performs recursive scanning (on archives other than ZIP, JAR and CAB), and goes 300 levels down
(not configurable). This limited scanning depth is required to avoid bomb-archives that are nested
infinitely, a ‘trick’ used by hackers to perform denial of service attacks on scanning engines.

4.2.2 Data Encoding
Data inside e-mail messages may be encoded. This is done usually to enable the data to cross the
barriers of different types of mail servers, minimize e-mail size, and for other various reasons.
Vital Security for E-Mail is able to detect and parse several formats of data encoding formats:
• RFC 822 (RFC1521)
• 8 Bit
• Base64
• Binary
• MAC-Binhex40
• Quoted-Printable
• UUENCODE
• MS/TNEF
• Compound Message Document

Page 28 of 60


Please note that some of the encoding methods are handled by Microsoft CDO, while other (such as
MS/TNEF) are handled by Finjan code. This enables Vital Security for E-Mail to not depend on
Microsoft’s MAPI library, which is somewhat limited, buggy in many cases, and also not
distributable without the full office package.
Also note that Vital Security for E-Mail is character-set neutral. It is able to handle messages in all
character sets supported by Windows. This is due to the character-set support built inside the
Microsoft CDO services.

4.3 Pro-Active Code Scanners

4.3.1 Code Scanning for Java, ActiveX and Scripts

The actual code scanning that is performed by Vital Security for E-Mail depends on the type of
code, as described in the following table:

Mobile Code Type Scanning Action

Java Each Java class is scanned separately and added to the active
content list. The profile is then compared to policy and each
class that violates the policy is stripped out of the message (the
<APPLET> tag stays in place).
In case of reference to an external link, Vital Security for E-
Mail cannot scan the code, so the <APPLET> tag is stripped
out, and a violation of ‘reference to external link’ is logged.
When operating in emergency mode (server level setting), all
<APPLET> tags are stripped out, without applying any code
scanning.
Note that Vital Security for E-Mail applies class-level scanning
and NOT applet level scanning. This means that for applets
that are constructed from multiple classes, Vital Security for
E-Mail behaves differently from Vital Security for Web, and
will create a profile for each class separately instead of one
profile for the whole applet.

Page 29 of 60


Mobile Code Type Scanning Action

ActiveX Each ActiveX control is scanned and added to the active
content list. The profile is then compared to policy and each
class that violates the policy is stripped out of the message (the
<OBJECT> tag stays in place).
As in the case of Java, references to external links cannot be
scanned, so the <OBJECT> tag is stripped out and a violation
of ‘reference to external link’ is logged.
When operating in emergency mode (server level setting), all
<OBJECT> tags are stripped out, without applying any code
scanning.
Scripts <SCRIPT> tags and script attachments are scanned and
profile is compared to policy.
When blocking a <SCRIPT> tag, all subsequent script tags on
the same HTML file are also stripped out (to prevent user
errors of cross referencing between tags).
As in the case of Java and ActiveX, links to external scripts
that cannot be scanned, are stripped out.

4.3.2 Handling Executables
Vital Security for E-Mail can be configured to either block or allow executable attachments.
Executables are not scanned for profile, but they are, of course, scanned for known viruses.
The list of files that are assumed to be executables, and are passed through the executable type
detector, is configurable via the console. In order to verify that a file is actually an executable, Vital
Security for E-Mail analyses the binary structure of such files and blocks them, only if they are
detected as a real executables.
One exception is .COM files, which cannot be analyzed, so they are always blocked if policy is set to
block executables.

4.3.3 Handling Documents
Vital Security for E-Mail has an advanced document filtering engine that is capable of blocking
either simple document attachments, or blocking documents only when they are going to be
automatically launched by the e-mail client.
In simple blocking mode, Vital Security can be configured to block any document by its extension,
as well as by its MIME type. In e-mail messages, the MIME type of a document is mapped to the
MIME headers of the e-mail message that are part of the standard SMTP headers. Vital Security for
E-Mail can block all documents of a specified MIME type, and wildcards can be used to block
families of documents (for example, to block all audio files, you could set Vital Security for E-Mail

Page 30 of 60


to block “audio/*” MIME type).
In auto-launch blocking mode, Vital Security for E-Mail performs an analysis of body part HTML
tags to detect document attachments that will be automatically activated by the e-mail client. Such
attachments are blocked.
Vital Security for E-Mail 7.0 introduces a new feature, which is to block documents with double
extensions. Hackers use the double extension technique often to fool users into opening documents
that seem to be of a harmless type, such as “AnnaKornikova.jpg.vbs”. Although Vital Security is not
susceptible to such attack, and will scan such files according to their correct extension, double
extension usage is considered a strong indication of a hostile attack. Therefore, such files can be
blocked regardless of their actual behavior.

4.3.4 Handling Plug-ins
Vital Security handling of plug-ins is simply to strip all <EMBED> tags out of any HTML content.
The user is notified about the change to HTML pages.

4.3.5 Cooperation With Vital Security for Web
When Vital Security for E-Mail scans e-mail and finds reference to active content, which is external
to the e-mail message, it usually blocks this specific reference and reports a violation of ‘reference to
external link’. This is because Vital Security for E-Mail doesn’t see the actual active content, so it
cannot scan it.
Vital Security for E-Mail 7.0 has a feature designed to allow it to cooperate with Vital Security for
Web and avoid blocking such links, without compromising on security. When this mode is enabled
(by checking the “Operate in cooperation with Vital Security for Web” check-box), external links are
modified in a way that ensures that Vital Security will properly scan them when they are loaded
afterwards via HTTP.

4.3.6 Unscannable Objects
Sometimes, Vital Security for E-Mail will encounter files that cannot be scanned, although their type
indicates that they should be scanned. A good example of such file is a ZIP file that is password
locked. Another example are Java applets that are malformed or partial, which means the Java code
scanner cannot fully resolve the applet to a complete profile.
Under those cases, Vital Security for E-Mail allows the administrator to decide how to handle such
files. They can be allowed, effectively ignoring the failed scan result, and in a way compromise the
security in order to get better transparency.
They can also be allowed with a warning, telling the user that the message could not be scanned,
delegating the responsibility of whether to open or delete the message to the end user. This should
also be considered as a compromise of the security in order to get better transparency, although
better than the allow option.

Page 31 of 60


Last, the safer approach is to block such files because they cannot be trusted. In this mode, the e-
mail is returned to the sender with a notification that the message did not reach its destination.

4.4 The Active Content Database
Whenever a code is scanned by Vital Security for E-Mail, an active content entry is added to the
active content list, and the code’s profile is stored in the Vital Security database.
This serves the following purposes:
• It creates a thorough database of all active content objects going into the organization, and is
used to generate reports about the characteristics of active content that was scanned by Vital
Security.
• It allows the administrator to set specific policies for specific known active content objects. This
is described later in this section.
When the same code object is later revisited, its profile will be fetched from the database, in order to
improve performance and avoid the need to re-scan the same code object over and over again.
The following diagram illustrates this flow:

Incoming Scan and create
Generate In no
Code security profile
Object ID database?
Object

yes

Save profile
Objects
DB
Profile

Compare
Security Profile to not Block object
Policy DB Security Policy OK

OK

Pass Object

Figure 3: Proactive Code Inspection Flow

Page 32 of 60


4.5 Active Content Filtering
Vital Security for E-Mail can filter mobile code based on decision factors other than the code
profile. There are three filters that can be applied in order to decide whether to block or allow a
mobile code object from reaching its destination. The administrator can set the order of those filters,
to decide which takes precedence, in case of conflicts between them.
Each filter can cause Vital Security for E-Mail to Allow the code, Block it, Scan it or go on to the next
filter, if no specific policy was found that applies to the object.
The administrator can set the policy filters and default policy of Vital Security in such a way to allow
only code that was specifically allowed by one of the filters and block everything else (a restrictive
approach), to block known attacks by the filters and allow everything else (a permissive approach),
or any combination thereof. Effectively, this implements a very flexible Active Content filter.

4.5.1 Active Content Filter
For every Java applet, ActiveX control, executable or script file that passes through Vital Security for
E-Mail, an MD5 hash is calculated, and used as a unique identifier for the object. The administrator
can then look at the code profile using the console, see what kind of security violations it performs,
if any, and assign a specific Block or Allow policy to it.
This enables the administrator to override the general security policy for specific code objects.
When Vital Security encounters a mobile code object, it will first check the hash against the Active
Content list to see if a specific policy was assigned to this object, and acts accordingly.
Note that for scripts, a hash and profile is generated only for standalone script files (such as .js, .vbs
files) and not for script tags that are embedded inside HTML content.
Also note that in the case of executable files, only a hash is generated, without a profile, since Vital
Security for E-Mail does not apply any code scanning on executables.

4.5.2 Senders Filter
Vital Security for E-Mail allows the administrator to set an additional block/allow filter for whole e-
mail messages from specific senders (for blocking known spammers), and for mobile code objects
inside e-mail messages, based on its sender. The second option of filtering is more refined than
conventional e-mail filters that block all the e-mail from specific spammers.

4.5.3 Digital Certificate Filter
E-Mail messages may be digitally signed by their sender, usually by installing a certificate in their e-
mail client. This certificate is used for signing their outgoing e-mails, and ensures the identify of the
e-mail sender.
Active content code objects may be digitally signed by their code publishers to guarantee the identity

Page 33 of 60


of the publisher. Signed Java applets are usually packaged in Jar (Java Archive) files, based on
JavaSoft’s and Netscape’s object signing technology. ActiveX Controls are usually packaged in CAB
files, based on Microsoft’s Authenticode technology. Authenticode signature may also be attached to
the native binary files, so an .OCX file, for example, may be signed even if it is not inside a CAB.
Both Netscape and Microsoft Authenticode formats use the X.509 Digital Certificate standard.
A publisher certificate is issued by a Certificate Authority (CA) with a specific class level and validity
period. Issued certificates expire at the end of this period. The issuing CA may also prematurely
revoke them if their integrity was somehow compromised.
Vital Security for E-Mail 7.0 certificate filter can detect and apply policies on signed e-mail messages
and on signed active content object attached to the message. It can identify e-mail messages signed
using Microsoft Authenticode™ technology and code object signed using any of the code signing
technologies described above. When Vital Security for E-Mail applies policies on full e-mail
messages, it bypasses all the other filters and does not scan the e-mail parts, with the exception of
the anti-virus scanning.
Vital Security for E-Mail allows the administrator to maintain a list of known certificates for the
purpose of applying policies to them. A certificate database is maintained by scanning all signed
messages and code objects that pass through Vital Security for E-Mail and adding signer information
and their public key information into the database. Certificates can also be imported manually from
certificate files. The administrator can then view this database and define specific CAs and/or
specific publishers as “allowed” (trusted) or “blocked” (untrusted).
Note: Like Vital Security for Web, Vital Security for E-Mail implements a partial certificate
processing. It checks that the signed code is structured correctly, verifies signature information with
the trusted lists, and verifies expiration date of the signed code. Vital Security does not do a
revocation test with revocation servers.

4.5.4 Certificate Server
Vital Security Server can run on Windows and Unix platforms. When running on Windows
platforms, Vital Security can inspect signed code and analyze the signed package to retrieve all the
required signature information. When running on a Unix platform, Vital Security cannot analyze
signed code on its own, because the Microsoft Authenticode structure is not published and can only
be inspected using Microsoft-supplied APIs. Therefore, there is a need for a secondary Finjan
Certificate Server that runs on a Windows platform and does all certificate analysis for the Vital
Security Server. This server should be installed separately, and will inspect signed code and return
signature information to the requesting Vital Security Server.
The Vital Security Console and the Oracle database client will only run on a Windows 2000 system.
(see the Vital Security Installation Guide for more details). Since the Certificate Server is part of the
Vital Security Console installation, the option to install this server is selected during the Vital
Security Console installation.

The following diagram illustrates this configuration:

Page 34 of 60


Vital Security
Server (UNIX)

Figure 4: Certificate Server Configuration

Note that Vital Security can still detect whether an active content object is signed or not, so only
signed objects are sent to the certificate server for inspection and there is virtually no performance
penalty involved when adding a certificate server. However, it is still an optional component. When
such a server is not installed, Vital Security simply skips its internal certificate filter and goes on to
the next filter.
The certificate server does not apply any policies. It communicates with the Vital Security Server and
with the Finjan FHTTP protocol, receives code objects, and returns signature information to the
Vital Security Server.

4.6 The Anti-Virus Scanner
Vital Security for E-Mail scans every part of the e-mail that is classified as program or document
using the NAI Olympus engine. NAI is the world-class leader in anti-virus scanning and the
Olympus engine is the same engine included within NAI’s own products.
Vital Security for E-Mail uses this engine as a first level filter to scan and repair any file. After
applying AV scanning, if the file is a known virus and cannot be repaired, it will be blocked without
further scanning applied.
However, if the file was detected as clean, or was repaired, it is still passed to the next level of code
scanning to detect any policy violation and apply the pro-active scanning which is the heart of Vital
Security for E-Mail.

Page 35 of 60


4.6.1 Scanning Different File Types
The NAI anti-virus scans many types of files and archives. It is used not just to scan for mobile code
objects, but also other file types that are considered by NAI as prone for virus infection.
Table 2 lists all file types and archives that are scanned by default using the NAI anti-virus engine.
Note that in addition to these, any file classified by Vital Security for E-Mail as active content is also
passed to the anti-virus scanner for inspection.
This table is updated as to the date of the release of this document. Note that it may change (usually,
expand) when a new signature database is released.

Type Extensions

Default Program 001, 002, 286, 3GR, ACM, ADT, APP, ASP, AX?,
Extensions BAT, BIN, BO?, CHM, CMD, CLA, CNV, COM,
CPL, DEV, DL?, DOT, DRV, EXE, FO?, HLP,
HT?, IM?, INF, INI, LIB, MB?, MOD, MPD, MRC,
MS?, OBJ, OCX, OLB, OLE, OV?, PCI, PDR, PIF,
QLB, QPW, REG, SCR, SMM, SYS, TLB, TSP,
VBE, VBS, VBX, VS?, VWP, VXD, WP?, XLB,
XML, XSL, XTP, WIZ, WPC, WSI, WS?
Macro Extensions ASD, CDR, CPT, CSC, DIF, DOC, DOT, D?B,
GMS, JS?, MD?, MPP, MPT, MSG, MSO, OBD,
OBT, OLE, PP?, POT, RTF, SHB, SHS, VS?, WBK,
WPD, XL?
Compressed files ??_, COM, EXE, GZ?, TD0, TGZ

Archives ARC, ARJ, CAB, COM, EXE, ICE, LZH, RAR,
TAR, TD0, ZIP

Table 2 : Extensions list for anti-virus scanner

4.6.2 Signature Database Updates
Vital Security for E-Mail also manages all updates of the virus database automatically. This task is
divided into two steps. The Vital Security database server is responsible for fetching any new
database updates from the FTP site (defaults to NAI’s FTP site), or from a local folder (in case the
administrator prefers to fetch updates from another source). This update is done periodically, and
timing can be configured from the console (default is once a week).
Vital Security for E-Mail connects periodically to the database server (every 60 seconds) for
receiving security policy updates. As part of the policy update, a new virus database can be
downloaded to the Vital Security for E-Mail machine (from the database server), and be applied
immediately.

Page 36 of 60


This two-tier architecture ensures that an organization downloads the AV database only once from
the NAI site (by the database server), therefore minimizing the network overhead. It also ensures
that all Vital Security for E-Mail servers are always updated and synchronized, with the same virus
database version applied on all servers.
Naturally, this update process is completely automatic. It does not require any user intervention and
does not require any server restart. However, using the console, it is also possible to perform a
download of a signature database manually. This is useful during a virus outbreak, to ensure the new
signature database is retrieved immediately.
The signature update is a safe process. Every database download is checked for consistency. If it is
found to be bad, it is ignored, and a log message is generated. In such cases, the previous database
stays in place and the AV engine continues to function normally.

Page 37 of 60


5 Deployment Options
Vital Security for E-Mail is typically installed in a protected portion of the network, either within the
firewall's “demilitarized zone” or in the internal network, behind the firewall. The Vital Security
Console may be installed anywhere on the network. It is typically installed on the Vital Security
server’s host and/or on the administrator’s workstation.
Vital Security for E-Mail servers should be deployed as the entry point for SMTP traffic to the
organization. That is, as the internet entry point for SMTP traffic and the mail server from one side,
for scanning incoming messages, and between the end users and the mail server from the other side,
for scanning internal and outgoing messages.
Multiple Vital Security for E-Mail servers can be load balanced to provide a scalable solution when
one server cannot handle the load, or when high-availability is required. This is usually accomplished
with third-party load balancing tools.
Vital Security for E-Mail can also be installed as a plug-in on a Microsoft Exchange 2000 server
machine, making the deployment a very easy task, automatically scanning all messages as they enter
the server.
Last, Vital Security for E-Mail can be installed in a mixed environment with Vital Security for Web),
and be managed from the same console using the same database server. This allows for easy
management of active content policy for web and e-mail together, using the same console, saving
time and lowering the cost of ownership.

5.1 SMTP Relay Mode
In this configuration all clients must be explicitly configured to access Vital Security as their
outgoing SMTP server. Vital Security should also be configured as the SMTP entry point, and in
turn, to relay all scanned e-mail messages to the mail server. See Figure 5. (Note that in the diagram,
the database server is drawn as a separate server, but it can also be installed on the same machine
with the Vital Security for E-Mail server).

Page 38 of 60


Figure 5 : SMTP Relay Deployment

Pros Cons
Independent solution; works with all Requires e-mail clients and DNS settings
mail servers on scanning incoming changes - all e-mail clients must
messages, and with most of them for explicitly assign Vital Security for E-Mail
outgoing and internal messages. as their SMTP server.
No overhead on the mail server. Cannot scan outgoing and internal e-
mail traffic when proprietary protocol is
used to communicate with mail server
(e.g. Microsoft Exchange in workgroup
mode, Lotus Notes, etc)
Available as a hardware appliance
optimized for best performance.

5.2 Microsoft Exchange 2000 Plug-in mode
In this configuration, Vital Security for E-Mail plugs into an existing Microsoft Exchange 2000
server. The Exchange server passes all the e-mail messages to the plug-in for inspection, as shown in
Figure 6. The plug-in communicates with the database server via Finjan’s FHTTP protocol, for
retrieving policy and for sending logs to the database.

Page 39 of 60


.

Figure 6:Exchange 2000 Plug-in Deployment

Pros Cons
Transparent to end users (no Limited to Exchange 2000
configuration changes required)
Full scanning of outgoing and internal Scanning overload on the Exchange
messages when working with Outlook in machine. May require memory and CPU
workgroup mode (as opposed to upgrade.
Internet Mail mode)

5.3 Deploying Multiple Servers
Several Vital Security for E-Mail relay servers can work together in parallel. This can be done in
order to handle a load situation, where one Vital Security server is not enough to handle the load, or
in order to build an environment with no single point of failure, and thus achieve high availability of
SMTP connections.
In order to support multiple servers environment, several Vital Security for E-Mail servers can be
load-balanced and connected to the same database server.
In addition, Vital Security for E-Mail can be installed in conjunction with Vital Security for Web
servers and be managed from the same management console.
The following diagram illustrates an environment with several Vital Security for E-Mail servers,
operating in parallel, using a load-balancing device to split the load (i.e. SMTP requests) between
them, along with a group of load-balanced Vital Security servers for web traffic.

Page 40 of 60


Vital Security
for E-Mail Mail
Server

SMTP SMTP

POP3/
SMTP IMAP

SMTP

FHTTP
Vital Security HTTP
(Web)
HTTP

Users
FHTTP

ODBC

Database
Database Console
Server

Figure 7 : Mixed Vital Security Servers Deployment

Note that there’s only one database server used by all the servers. This ensures that all of the servers
are operating with the same security policy and logging all information into the same place. It also
means all the servers can be managed from a single console.

5.4 Performance and Scalability
Vital Security for E-Mail is designed to be a scalable solution. Several servers can be load balanced,
using tools such as Cisco local-director, Stonesoft, Stonebeat security cluster, and others.
In addition, one Vital Security for E-Mail can handle the SMTP traffic of a relatively large
organization. Lab measurements have shown that in a typical environment, when Vital Security for
E-Mail is running on the Finjan appliance (Dual Pentium III 1GHz with 512 MB of RAM and
18GB SCSI drive), one server can handle approximately 15 e-mail messages per second, with an
average size of 10K per message. This translates to about 1.3 Million messages a day.
Note also that the queue mechanism built into the IIS SMTP service allows Vital Security for E-Mail
to defer the handling of messages at peak load times to a later time, thus spreading the load more

Page 41 of 60

Finjan Vital Security For eMail Technical White Paper

Finjan Vital Security For eMail Technical White Paper

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (10)

Similar to Finjan Vital Security For eMail Technical White Paper

Similar to Finjan Vital Security For eMail Technical White Paper (20)

More from Elliott Lowe

More from Elliott Lowe (16)

Recently uploaded

Recently uploaded (20)

Finjan Vital Security For eMail Technical White Paper