finjan vital security for email technical white paper

Version 7.0

Vital Security™ for E-MailTechnical White Paper

Page ii of 60

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 iii 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 iv 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


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

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

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

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

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

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.

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

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

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

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:

of 60


Legend

3.3Vitalviola

Unlikdownmech

The Vwith storethe measy

The qquara

The qfile.

All thquara

Zo lne protected by SurinGate for E-MaiZone Protected by Vital Security for E-Mail

Domain A Domain B

#3#2

User C1

#4

Domains A and B - defined as internal domainsDomains C and D - external domainsUser C1 - Added manually to SurfinGate for E-Mailuser tree (via the console)

#1. Outgoing - message send from internal to non-internal domain#2. Incoming - message send inside the internaldomain#3. Incoming - message send from internal domain toother internal domain#4. Incoming - message send to non-internal domainbut specific user is known#5. Incoming - message send to internal domain fromoutside

Domain C

#1

Domain D

#5

Figure 1: Classifying Incoming vs. Outgoing Messages

Quarantine Management Security for E-Mail modifies e-mail messages as part of normal operation. It detects policy tions and delivers a modified version of the e-mail, without the violations, to the end user.

e Vital Security for Web, an e-mail message that was modified cannot be simply restored by re-loading it from the web. For this reason, Vital Security for E-Mail contains a quarantine anism, with the purpose of allowing a complete restoration of the original message.

ital Security for E-Mail quarantine is implemented as a set of disk folders that stores ZIP files original unmodified data. For each e-mail message that is modified, all the modified parts are d in a ZIP file and assigned a unique ID (filename). This filename is logged and also attached to odified e-mail message (as part of the modification notification to the end user) to allow for

finding and recovery of the original message, if required.

uarantine manager is configurable. Administrators can define what files will be stored in the ntine, based on criteria such as e-mail sender and recipients, file types, e-mail size, etc.

uarantine size can also be controlled by setting limits on its size and on the hold time of each

is is designed to ensure access to unmodified data from one side, but also ensure the ntine will not over inflate and become full (which may mean new data could not be

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.

of 60

http://www.ordb.org/

http://mail-abuse.org/


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.

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

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.

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.

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.

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.

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.

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.

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.

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.

of 60


Start

Object Policyfound?

Allow

SenderPolicy found?

Certificatepolicy found?

No

No

Allow

Allow

Block

UseDefault Policy

Apply codescanner

(fetch or calculateprofile)

Block

Block

Block

Block

Scan

No

Comparepolicy to profile

No violationViolation found

Allow

Allow

Scan

Scan

Apply Anti-VirusScanning

VirusDetected?

No

Yes

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

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

of 60


Ple se note that some of the encodina g methods are handled by Microsoft CDO, while other (such as

racter-set neutral. It is able to handle messages in all

4.3 Pro-Active Code Scanners

4.3.1 Code Scanning for Java, ActiveX and Scripts

E-Mail depends on the type of

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 chacharacter sets supported by Windows. This is due to the character-set support built inside the Microsoft CDO services.

The actual code scanning that is performed by Vital Security forcode, as described in the following table:

Mobile Code Type Scanning Action

Java Each Java class is scanned separately and added to the active

e

l link, Vital Security for E-d

ital Security for E-Mail applies class-level scanning

content list. The profile is then compared to policy and each class that violates the policy is stripped out of the message (th<APPLET> tag stays in place).

In case of reference to an externaMail cannot scan the code, so the <APPLET> tag is strippeout, 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 Vand 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.

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

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.

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:

OK

not OK

Pass Object

In database?

no

yes

Generate Object ID

Incoming Code

Object

Scan and create security profile

Save profile

Profile

Objects DB

Compare Profile to

Security PolicySecurity

Policy DBBlock object

Figure 3: Proactive Code Inspection Flow

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

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:

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.

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 Extensions

001, 002, 286, 3GR, ACM, ADT, APP, ASP, AX?, 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.

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.

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).

of 60


Figure 5 : SMTP Relay Deployment

Pros Cons

Independent solution; works with all mail servers on scanning incoming messages, and with most of them for outgoing and internal messages.

Requires e-mail clients and DNS settings changes - all e-mail clients must explicitly assign Vital Security for E-Mail 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.

of 60


.

Figure 6:Exchange 2000 Plug-in Deployment

Pros Cons

Transparent to end users (no configuration changes required)

Limited to Exchange 2000

Full scanning of outgoing and internal messages when working with Outlook in workgroup mode (as opposed to Internet Mail mode)

Scanning overload on the Exchange machine. May require memory and CPU upgrade.

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.

of 60


Mail

Server

Vital Securityfor E - Mail

POP3/ IMAP

SMTP SMTP

SMTP

Vital Security (Web)

Database Server

Database

Console

FHTT

P HTTP

HTTP

Users

SMTP

FHTTP

ODBC

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

of 60


evenly over the day.

The current Finjan estimate is that one Vital Security for E-Mail server can easily handle a 5,000 user organization. This of course may vary from organization to organization, depending on the type of e-mail load expected and the nature of e-mail messages pasting through the server.

Note, however, that in such an organization, it is still recommended to deploy at least two servers, to ensure high level of service, and maintain redundancy between servers, in case one server fails.

of 60


6 Technology In Depth

6.1 Product Architecture Vital Security for E-Mail is built on Windows 2000 services, including the IIS 5.0 SMTP Virtual server, and Windows 2000 CDO services for breaking apart e-mail messages. The following block diagram describes the internal architecture of Vital Security for E-Mail :

Database Management

Policies & Profiles

Policy Checker

Object ID Generator

Filters (Sender / Objects / Extensions

Certificate Scanner

Size Restriction Detector

SMTP Event Sink

Java ScannerActiveX Scanner Script Scanner

E-Mail Message

HTML Scanner

Mobile Code Objects

HTMLPages

FHTTP Server (Plug-ins and management interface)

Console Data (Activity M

IIS SMTP Virtual Server (Listening on port 25)

Port 3142 Finjan Control Channel Interface

Memory Cache (Policies & Profiles)

Body Part / Attachment

Modified Body Part / Attachment

Logging Information Security Profile

Quarantine Manager

Quarantine Folder Database Server

Vital SecurityDatabase

Un-Modified E-Mail Parts (Zipped)

Script Tags

McAfee Anti-Virus Scanner HTML, Active Content, Programs & Documents

Type Detector

E-Mail Message Parser

MIME Parser SMTP Parser

Message Composer

Anti-Virus Updates

Anti Virus Updates Manager

(Policies, Logs, Profiles, AV Signature updates)

FHT

TP

Figure 8: Vital Security for E-Mail block diagram

of 60


The following table explains in brief the function of each block in the diagram:

SMTP Event Sink Interface to the IIS SMTP service, receiving e-mail messages for inspection and filtering, and controlling the SMTP service to enable modification of messages.

FHTTP Server Finjan’s control channel protocol handler. In Vital Security for E-Mail, the default port for listening is 3142, and it is used for console connection only.

E-Mail Message Parser Receives e-mail data from the SMTP Event Sink, breaks the e-mail apart, passes all e-mail parts for inspection, potentially receives the modified data back, and reconstructs the mail message for delivery to the user.

Policy Checker This is the decision engine and the ‘heart’ of Vital Security for E-Mail. It sends data to the anti-virus engine and the code scanners, collects profile information, applies policies, logs them into the database and sends the possibly modified data back to the E-Mail parser.

Type detector Detects type of e-mail part, classifying it as code or pure data. The classification information is used to pass the data stream to the appropriate scanner.

Quarantine Manager Manages the quarantine of Vital Security for E-Mail. Stores on local disk folders the unmodified form of any data changed by Vital Security for E-Mail policy checker.

Anti-Virus Scanner The NAI Olympus Anti-Virus engine. Receives any HTML page, mobile code, programs, document, and potentially any data object from the policy checker, applies AV scanning on it, and may pass back a repaired version of the data, in case virus is detected.

HTML Scanner Scans HTML content, applying HTML rules of filtering dangerous HTML tags, and passing script tags into the Script scanner.

Code Scanners The code scanning engines of Vital Security for E-Mail, which is identical to the scanning engine of Vital Security for Web. Analyzes and creates a profile for mobile code objects.

Database Management Database management is responsible for caching policies and profiles, for sending data and logs to the database server, and for retrieving AV signature database updates from the database server.

Database Server A Separate server, usually runs on a separate machine. Responsible for managing the security database, and also for getting anti-virus signature database updates from the NAI FTP site.

of 60


Security Database The database storage of Vital Security. Stores users policies, code profiles, log entries and Vital Security’s device settings. It can be either Access (Jet) database, or Oracle database, depending on the platform of the database server.

The next sections describe some of these core components of Vital Security for E-Mail in more detail.

6.2 Type Detection In order to apply policy correctly, Vital Security for E-Mail has to determine the content type for each part of the e-mail message. Vital Security for E-Mail looks for the following types of data:

• All active content, including HTML, Mobile Code, and anything else classified as either program files or documents is passed to the Anti-Virus scanner. There is also an option to pass all data (including any body part and attachment) to the anti-virus scanner, and not just programs and documents.

Once this AV scanning is performed, and if no virus was found, the following scanners are applied:

• HTML content is passed to HTML Inspection.

• Java classes and Java archives (.zip, .jar, .cab) are passed to Java Inspection.

• ActiveX Control files and archives (.cab) are passed to ActiveX Inspection.

• Script files and script tags inside HTML pages are passed to script inspection.

• All other content types are not inspected or modified. They are either passed or blocked, based on the Vital Security policy for their file-type (extension).

Vital Security for E-Mail applies a series of rules to classify the data and deduce the content type. It uses a combination of detection by extensions, analysis of SMTP headers, and analysis of actual content, to classify the file and decide which scanner should be applied. In general, the following table illustrates these rules:

Type Purpose Rules

HTML Apply HTML scanner for filtering out dangerous tags and collecting mobile code object tags information.

First bytes contain HTML tags

.HTM, .HTML

Content-Disposition text/html in MIME headers

Java Apply Java code scanner .CLASS files,

‘CAFEBABE’ file header

<APPLET> tag scanning results for detecting Java archives (such as, but not limited to, .jar files)

ActiveX Apply ActiveX code scanner .OCX, .INF files

<OBJECT> tag scanning results for detecting other ActiveX controls and ActiveX archives (such as, but not limited to, .cab files)

of 60


Type Purpose Rules

Executables Apply Executable blocking policy .EXE, .DLL, .COM files

Header analysis of first 8K, to detect PE format

Scripts Apply script scanner HTML analysis of <SCRIPT> tags

.JS, .VBS files

Document Apply Document blocking and auto-launch prevention

All extensions listed in the documents extension list in the console

Program or Document Apply Anti-Virus scanner Any of the above mentioned types, including those in the AV extensions list

6.3 Policy Selection Algorithm Before any message is handled, a policy must be fetched from the database that will be applied on the message. Vital Security for E-Mail 6.0 maintained only one global policy for all, which made this process very simple. Version 7.0 introduced the ability to define policies per user, and different policies for incoming and outgoing messages.

This chapter provides some of the more technical aspects of policy selection and enforcement.

6.3.1 Splitting the Message for Multiple Policies E-Mail messages can be sent to any number of recipients with different policies. Because of that, Vital Security for E-Mail cannot just modify the original message according to the policy. Different recipients mean different policies, which means there can be any number of variants to the message after scanning, from 1 to the number of recipients. For example, if Vital Security for E-Mail scans a 5MB message that was sent to three (3) users - one with restriction for message size and the others without any such restriction – it has to produce two different output messages. In order to achieve that, Vital Security for E-Mail starts the process of analyzing a message by first duplicating it into the minimum number of identical messages needed. In the above case, two copies of the message would be created, one will be scanned with the size restriction rule and sent to recipient number 1, and the other would be scanned without this restriction, and sent to the other two recipients.

This approach allows Vital Security for E-Mail to waste the minimal CPU cycles on the actual scanning, while still providing fully customizable user-based policies.

Note that the recipient does not notice this duplication. Each of the recipients still gets a message with all the three names in the recipient list. The duplication happens only at the SMTP level, where the message is handled twice, and passed twice (two different copies) to the mail server.

Also note that this means one e-mail message can produce multiple logging events in the Vital Security log database. For each “clone” message, different log events can occur.

The diagram below shows the process of policy selection, once a message is received. This process is performed for each recipient, looking for the specific user in the tree, and if not found, looking for a

of 60


domain specific policy. When a user is identified, its policy is fetched from the database. The message is finally split to the total number of different policies that should be applied on the message.

No Yes

Yes

No

No

Yes

o Create New User under new users group.o Use incoming policy

No

o User = "Corp"o Use incoming policy

Yes

Fetch Policy for Identified User(Apply inheritance tree if policy for specific user is empty)

No

No

o User = "Corp"o Use outgoing policy

Yes

Is recipient domain "internal" ?

Is recipient defined in theusers tree?

Is recipientdomain defined

in users tree

Is recipient defined in theusers tree ?

Is Auto-detection ofusers turned ON ?

Is recipient's domaindefined in users tree

o User = recipiento Use incoming policy

o User = recipient's domaino Use incoming policy

Is senderdefined in users

tree?

o User = Sender"o Use outgoing policy

NoYes

Yes

Figure 9 : Policy selection algorithm

Note that the diagram shows that for each sender/recipient pair, there could be one of six policy decisions made:

• Recipient’s incoming policy

• Recipient’s domain incoming policy

• Recipient is created as new user, and inherits incoming policy of new users group.

• “Corp” user incoming policy

• Sender’s outgoing policy

• “Corp” user outgoing policy

Also note that once the actual user is selected, the policy still depends on the users tree inheritance. A user can be defined in the tree with a fully inherited policy, which means the actual policy that will be used is the policy of its father, and this inheritance tree can go all the way up to the “Corp” user

of 60


level.

Only after the full identification of all the policies that are relevant to a given e-mail message (by constructing all policies for all recipients of the e-mail), is the message duplicated in the minimal number of “clones” that are required, and actual content analysis starts.

of 60


7 Vital Security’s Static Code Inspection

7.1 Java inspection A Java applet is comprised of one or more compiled class files. The first class of the applet (also called the Applet class) has the applet name, and inherits from the Java Applet class. Typically, the applet class files would all be stored on a web server, under a directory known as the CodeBase URL.

The applet class files (and possibly other non-code files) may be stored in a single archive file in order to speed up the lengthy HTTP process. Three archive types are in use: zip, Jar (extends the zip archive structure with an additional meta info folder and files), and CAB (Microsoft’s cabinet archive format).

Applets within archives may be digitally signed. Applets in Jar files may be signed with Netscape’s object signing method, and applets in CAB files may be signed with Microsoft’s Authenticode technology. Using Authenticode, it is also possible to sign Applets directly even if not inside a CAB.

It is important to understand that the exact same applet may be found on web sites in different configurations. It can be packaged into different archives, have a different digital signature, or even contain some “free” class files (i.e. classes that are not used by the Applet). Still they all represent the same applet security-wise, and therefore have the same profile.

Vital Security for E-Mail can perform code scanning on Java classes or on complete Java applets, depending on the way the applet is embedded inside the e-mail message. In most cases, Vital Security for E-Mail performs class level inspection. This is the case, for example, when class files are attached to an e-mail message. If, however, an Applet is embedded in the e-mail in a way that will cause the e-mail client (Outlook, for example) to actually execute the Applet, and if the entire applet is embedded inside the e-mail message (and not just the first class), then Vital Security for E-Mail performs a full Applet analysis on it. Note that this happens only if the e-mail message includes the entire Applet AND the body part of the e-mail is the HTML page that activates the applet (by including an APPLET tag referring to other e-mail parts). It is impossible to create such e-mail with a normal mail client, and requires some programming skills.

This behavior differs from the behavior of Vital Security for Web, because unlike Vital Security for Web, where the activation of the applet is performed at the time of the HTTP download, e-mail scanning may go through Vital Security for E-Mail days before it is being activated. There is no sense in downloading it from the web at the time of scanning, as the actual content on the web may completely change when the user actually opens the e-mail and the Applet is activated.

Note that the implication of this different approach is that Vital Security for E-Mail will show different behavior than Vital Security for Web when scanning applets. In most cases, for one applet, a series of log events will be generated (one for each class), and all the classes will be added to the active content list, instead of just the single applet.

of 60


7.1.1 Applet ID Generation The input to the process is the content of the applet class. The Applet ID Generator of Vital Security for E-Mail does not prefetch all the applet components from the web. It analyses the class header and lists all the classes that it requires (either by inheritance or by direct invocation). Every class from the list is fetched only if it is embedded inside the e-mail message, and analyzed in a similar way to add more classes to the list. The prefetch stage ends when all the listed classes were found inside the e-mail message. Note that usually only Java applets are not embedded inside the e-mail, so the process will end up having just the first class. The Applet ID Generator then calculates a consolidated hash value of all the applet classes (using the MD5 method). This value is the unique identifier of the applet; the same applet code will always generate the same ID, and even the slightest change in the applet code will generate a different ID.

7.1.2 Policy Selectio The applet ID and the ID of the requesting user are used to lookup the Policy Database and find whether a specific policy applies to the current applet request. If not, the default policy is used instead.

Figure 10: Applet content inspection

of 60


7.1.3 Java Code Scanning Java code scanning is performed if the policy in force requires checking of its profile against the policy.

The Code Scanner first tries to retrieve the applet’s profile from the database, using the Applet ID as the unique key. If the profile is found, no further scanning is required. If the profile is not found, it needs to be generated. The code scanner scans the body of the code, looking for potentially risky operations such as file system access, connection to other hosts and other services. Based on this scanning, it generates the applet’s profile and stores it in the database, keyed by the Applet ID.

The scanning process includes resolving of method parameters, and extracting inter-class relationships in order to identify what this applet would attempt to do on the user’s desktop. It is possible that method parameters would bind to actual values only in run-time (e.g., parameters holding user input or desktop properties). Such parameters cannot be resolved by offline analysis, and are declared by the scanner as Unresolved. In terms of the profile, an unresolved parameter could map to any possible resource.

The profile contains all the potentially hostile operations that the applet might perform on the client’s desktop. It is a subset of the complete list of operations that Vital Security can protect against, as described in the general Vital Security for E-Mail white paper. For example, Registry operations are not relevant for Java applets, so they will never appear in their profile.

7.1.4 Substitute applet generation Unlike Vital Security for Web, Vital Security for E-Mail does not generate substitute applets. When a Java applet is blocked, it is simply removed from the e-mail, and a text notification message is added as an attachment to notify the user about the blocking.

7.2 ActiveX Inspection Vital Security for E-Mail performs content inspection of complete ActiveX Controls. The process is very similar to the inspection of Java applets, so Figure 10 10 applies to ActiveX as well.

A control consists of one or more Portable Executable (PE), usually with the extension of .OCX. Typically, when multiple object files belong to a single control, they are stored in a CAB archive. A special *.INF file in the archive describes where to find the object files and how to install and run the ActiveX control on the users machine. The CAB archive may be digitally signed with Microsoft’s Authenticode technology.

7.2.1 Object ID Generation The input to the process is the content of the control’s PE file. If an INF file is present, and it points to additional files, then they are fetched (either from the CAB archive or from the net). The prefetch stage ends when all the required files were brought in. Windows libraries (such as

of 60


kernel32.dll and user32.dll), and other common libraries (such as MFC libraries) are not fetched because Vital Security contains a pre-analyzed profile for them, and expects them to already be on the desktop host. The Object ID Generator then calculates a consolidated hash value of all the object files (using MD5 algorithm). This value is the unique identifier of the control. The same control code will always generate the same ID, and even the slightest change in the control code will generate a different ID.

7.2.2 Policy Selection The object ID and the ID of the requesting user are used to lookup the Policy Database and find whether a specific policy applies to the current object request. If not, the default policy is used instead. This is exactly the same process as in the Java scanner.

7.2.3 Code Scanning The ActiveX scanning process is similar to the Java scanning process except, of course, for the Code Scanner. The differences in the problem domain are:

• Java byte code is a well-defined standard format, with clear and non-ambiguous references to other Java classes. PE on the other hand is arbitrary Windows binary code, which may employ various compilation and optimization techniques. For example, it might be impossible to distinguish between a function call and a jump to an arbitrary memory location.

• The Java language libraries are standard, and are relatively easily mapped to resource access operations. Windows system libraries may differ between different operating systems (95, NT, 98, etc.), different internationalized versions and different installed products. Therefore, mapping one version of a specific library is not enough – all versions must be mapped.

• Windows user libraries (such as MFC - the Microsoft Foundation Classes) are not guaranteed to be on every desktop, and their versions are even less predictable than those of system libraries.

Finjan developed a novel algorithm and method to scan Windows executables, and generate profiles that include all resource access operations contained in the code. The algorithm comprises of two steps. The first step is to profile all the windows services that an ActiveX control may try to use. This is done by Finjan and the results are packed into the Vital Security product. The second step involves finding the ‘match’ between the control and the windows services. This is done when analyzing controls as they pass through the Vital Security server.

7.2.3.1 Profiling the Windows APIs and MFC library As explained, the first step is done off-line, by Finjan, and the results are packed into the Vital Security product. This step involves profiling of approximately 25,000 function calls that are found in the Windows system, creating a profile for each and every one of those function calls.

• All the documented Windows APIs, such as the functions found in the windows

of 60


KERNEL32.DLL, are manually assigned a profile, based on their documentation. A profile of a function contains all the resource access operations that may be attempted by this function. For example, the OpenFile API from the KERNEL32.DLL is assigned a file read/write profile.

• The Windows binary file is disassembled. The disassembled code is analyzed to generate its underlying call graph. The nodes in this graph are the functions and methods contained in the file. An arc from node A to node B means that method A invokes or jumps to method B. The leaf nodes are either function from this file, which do not call/jump other functions or functions from other libraries.

• The profile of each undocumented function is now calculated by traversing the graph, and accumulating the combined profile of all the visited nodes and leaves.

• Functions from unknown libraries are assumed to have a “full” profile, i.e., including all the resource access operations.

7.2.3.2 Profiling an ActiveX control When Vital Security for E-Mail scans an ActiveX control, it basically scans the import table of the control, and builds a profile based on the calls to known and profiled functions that where pre-analyzed by Finjan.

This profiling assumes the control is a standard ActiveX control, that uses the standard system and/or framework (MFC) services for performing its work. Under this assumption, an accurate profile of the control can be generated.

If the control uses unknown imported functions, it is automatically assigned a full profile, assuming that it has the potential to do anything and violate all possible policies. Effectively, Vital Security for E-Mail will block it unless specifically allowed by virtue of its unique hash ID.

Note that although theoretically there is no way to analyze binary code so as create its full profile, Vital Security for E-Mail’s inspection algorithm manages to come very close by assuming some basic behavior rules that ActiveX controls adhere to.

7.2.4 Substitute control generator If the ActiveX control does not violate any permission in the policy (and all other filters are set to allow the control to pass), then the original control code is sent to the end user.

Otherwise, a substitute compatible control is generated that would perform no resource access on the user’s desktop. Instead, this control pops up a message dialog, informing the user that the original control was blocked, and the reason. The substitute control is then sent to the user.

7.3 Script Inspection Vital Security for E-Mail performs content inspection of scripts, when found inside HTML page

of 60


tags, or when it detects standalone script files (usually as *.js or *.vbs files).

Unlike the code scanning done for ActiveX and Java, Vital Security for E-Mail scans each code block as a standalone piece of code (e.g., only the script inside one script tag). It does not try to resolve the relationship between different script blocks on a page.

Vital Security for E-Mail assigns unique IDs to script code blocks, and displays them on the console.

Also, although script files can be digitally signed, Vital Security does not apply its digital signature scanning on scripts.

7.3.1 Code Scanning The script code scanning of Vital Security is very similar in concept to the code scanning of Java and ActiveX, although it is much simpler in nature.

Scripts are not compiled. They are found as regular text files in source format. Vital Security’s code scanning of script performs text-match comparisons, looking for possibly hostile operations that a script can perform.

As in the case of Java and ActiveX, Vital Security for E-Mail contains a built-in list of system functions and services a script may use to access local resources. For each such function, Vital Security contains a profile of the resource access operation this function will perform.

Each script tag is buffered inside Vital Security for E-Mail and not sent to the end user until the end of the script tag is found and the entire script ‘chunk’ can be analyzed.

When a script is scanned, and when a known function call is found, the policy is checked against its profile. If there is a policy violation, the script is considered hostile and is stripped out of the page.

Also, because a script is always replaced with an identical number of space characters, the total HTML page size sent to the browser always stays the same as the original. This is what allows Vital Security for E-Mail to perform HTML & Script scanning ‘on-the-fly’, not buffering the whole page, and thus keeping the user’s surfing experience as close to normal as possible.

7.3.2 Blocking multiple scripts on a page There are many instances when script tags on an HTML page will refer to a script tag that appears ‘above’ them on the page. If Vital Security for E-Mail stripped this tag, an error message would be displayed by the browser to the end user, notifying them that a script block is missing.

Vital Security for E-Mail’s solution to this problem is simply to remove all subsequent script tags from the HTML page, even if they do not violate the policy. Since the page behavior was already changed, by removing one script tag, removing the rest of the script tags reduces over blocking, and makes the HTML page sent to the end user more stable, with significantly fewer error messages.

Note that Vital Security for E-Mail only removes script tags of the same language as the blocked script (i.e., JavaScript or VBScript tags).

of 60


7.3.3 Detecting Script Language Detecting the language of a script tag is not a trivial task. A SCRIPT tag may include a language tag, but it also may not. Scripts may appear inside other tags as calls to other script tags on the page, and in this case, they usually don’t include a language specification.

Vital Security for E-Mail has to attempt to predict how the browser will treat those tags when no language is specified. Vital Security for E-Mail tries to do this by simulating the browser’s behavior. However, sometimes Vital Security for E-Mail will be unsuccessful in correctly predicting just how the browser’s script interpreter will behave. This is because there are multiple browsers on the market, and their behavior may differ from version to version.

In addition, Vital Security for E-Mail does not retain the relationship information between different script tags, and, in many cases, the language of a script can only be determined by knowing the language of another script block in the same document. Therefore, Vital Security for E-Mail may sometimes fail to correctly identify the script language.

In such cases, Vital Security will select the most restrictive JavaScript and VBScript policy, and apply this policy against the script. For example, if JavaScript is set to be scanned, and VBScript set to be blocked, and Vital Security for E-Mail encounters a script with an unknown language, it will block it, even if the actual language is JavaScript and should have been scanned.

Finjan has invested a significant amount of time and effort in improving the scanning process to better handle such issues, and will incorporate such into future releases.

of 60


8 Vital Security Product Security Measures

8.1 Self-protection Being an important part of an organization’s security scheme, all of the Finjan server products (Vital Security for Web, Vital Security for E-Mail and the Vital Security for Clients server) are secured from outside attacks by the incorporation of following measures:

• Password protected access to the Vital Security Console

• Database administrator password support

• Configuration files encryption

• Overall robust architecture that is built to handle failures gracefully

The password for entering the console may be set by the administrator in each organization, and is used to prevent unauthorized users from using the console to modify the organization’s policy.

The database password is a fixed password, set and used only by Finjan’s internal code to make sure only Finjan’s application can gain access to the database.

Finjan’s configuration files are encrypted using a scrambling algorithm. Again, this is done to make sure a typical user who gains access to the system cannot use such to change security settings.

Note that all of these measures are NOT intended to protect against hackers who have already gained access to the Vital Security machine. Once access has been gained, these measures have already been circumvented.

In order to better protect the a Vital Security for E-Mail machine against hacker threats, external measures must be taken, such as using a dedicated machine for Vital Security (i.e., one having only Vital Security installed and no other services or software), putting Vital Security in a DMZ so as to allow access to it only from internal IP addresses, etc.

In addition to that, Vital Security for E-Mail runs as a DLL in the process space of the IIS service, which runs under the local system account, and relies upon the Operating System to protect and isolate the Vital Security process from other processes running on the same machine, as well as to protect the Vital Security machine against intrusion and/or other denial of service.

of 60


8.2 Deploying Servers in a DMZ To further protect the Vital Security Server and Database, it is recommended to place them in a separate DMZ segment of the network. A DMZ is typically created on a segment attached to a separate NIC (Network Interface Connection) on the firewall, or between two routing devices (such as router or firewall), as shown in Figure 11, below. Both internal and external traffic can enter the DMZ but neither can pass through without the inspection and authorization of the routing devices. Typically, the firewall would be configured to allow internal users to access the Vital Security Server, and block external access to the Vital Security Server. It would also be configured to allow SMTP traffic to enter the Vital Security for E-Mail server from both the Internet and the e-mail clients, and allow Vital Security for E-Mail to establish SMTP connection to the mail server.

Figure 11: Vital Security in a Demilitarized Zone

of 60


9 Known Security Limitations Finjan invests a lot of effort in ensuring that design and implementation will be as secure as possible. However, technological limitations still exist. This section describes the technological limitations of Vital Security, explains the risks involved, how Vital Security deals with them, and how the administrator can further secure the organization by making some calculated-risk decisions.

9.1 Encrypted Communication E-Mail messages may be encrypted. This is usually referred to as SMIME messages, or to attachments that are password protected (such as password protected ZIP files).

When Vital Security for E-Mail encounters an encrypted message, it cannot inspect the content. Vital Security for E-Mail can be configured to pass or block the entire e-mail message.

In addition, in the general case of un-scannable objects (such as ZIP with password), Vital Security for E-Mail can be configured to reject the message (return it to the sender), or to pass the message on, but with a warning to the end user notifying him that the message was not scanned and may contain dangerous content.

The best solution for this problem is to use a desktop security solution that is capable of inspecting the actual content on the desktop, after it has been decrypted. Finjan’s Vital Security for Clients product provides exactly that, and strengthens corporate security by handling active content received via encrypted communication.

9.2 Dynamic Creation of HTML Pages A script can use an operation such as JavaScript’s Document.Write operation to create HTML pages on the client machine. Since these tags are created dynamically on the end user machine, they are not seen by the Vital Security server, and cannot be inspected.

Such tags may include calls to other types of objects (such as Java or ActiveX), or even other script tags with policy violations.

As a possible solution to this problem, Vital Security could block all Document.Write operations, and prevent this situation from ever happening. However, this would cause massive over-blocking of scripts, as Vital Security cannot identify whether the Document.Write operation is used to create legitimate HTML tags or active content tags. The over-blocking caused by such a solution may be higher than what is acceptable.

Vital Security tries to minimize the risk of this potential exploit by looking for “/APPLET” and “/OBJECT” strings inside scripts to try to detect attempts to create such tags dynamically. When such scripts are detected, they can be stripped off the page, by blocking the “access other applications” violation.

A desktop PC-based solution is the best possible approach. Finjan’s Vital Security for Clients

of 60


effectively protects against the threat of the dynamic creation of APPLET, OBJECT and SCRIPT tags, by monitoring such dynamically created active content tags when they are actually being executed by the browser.

of 60

of 60


10 About Finjan Finjan Software’s Vital Security™ is the only complete and integrated Secure Content Management solution in which individual best-of-breed security applications work together in concert to proactively respond to changing security threats today and tomorrow. Supplementing traditional security methods, Vital Security defends enterprises against Malicious Mobile Code using intelligent behavior analysis and comprehensive policy management. Vital Security is designed with High Availability and scalability, for enterprises of all sizes, including those with over 100,000 users. Finjan is recognized by analyst firm IDC as the leader in the worldwide Malicious Mobile Code security market. For more information, visit http://www.finjan.com.

© 2004 by Finjan Software, Inc., and/or its subsidiaries WWW.FINJAN.COM Printed in the U.S.A. USA VSE7.0WP3.1 02.04 EN Finjan, Finjan logo and Vital Security are trademarks or registered trademarks of Finjan Software, Inc., and/or its subsidiaries. All other registered and unregistered trademarks in this document are the sole property of their respective owners. The Finjan Software products described in this document are protected by one or more of the following U.S. Patents: 6092194, 6167520, 6480962, 6209103, 6298446, and 6353892 and may be protected by other U.S. Patents, foreign patents, or pending applications.