Using the Acceleration Toolkit for Microsoft Forefront Security for SharePoint

Summary: Use this acceleration toolkit for Microsoft Forefront Security for SharePoint (FSSP) to learn how to supply full-fidelity FSSP enablement to a SharePoint environment, regardless of deployment phase. (20 printed pages)

Adam Buenz, Midwave Corporation (Microsoft MVP)

August 2009

Applies to: Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0, Microsoft Forefront Security for SharePoint

Contents

• Getting Started with the Acceleration Toolkit for Forefront Security for SharePoint

• Protecting the Collaboration Environment with Content Hygiene

• Using FSSP to Secure a SharePoint Environment

• Technical Deep Dive: SharePoint Virus Scan Engine API (SP VS API 1.4)

• Prescriptive FSSP Server Topology for Virtualized, Physical, and Mixed-Mode Environments

• Implementing a Topology

• Configuring FSSP

• FSSP, End-to-End Security, Trusted Stacks, and SharePoint

• Conclusion

• Additional Resources

Getting Started with the Acceleration Toolkit for Forefront Security for SharePoint

An acceleration toolkit provides a logical bundling of common documentation, proven server designs, and established research to assist in the accelerated implementation of options for a product. This Acceleration Toolkit for Microsoft Forefront Security for SharePoint (FSSP) targets an arbitrary SharePoint environment, regardless of deployment phase, to provide guidance for architects to rapidly supply full-fidelity FSSP enablement.

Sections in the FSSP Acceleration Toolkit provide you with the following resources:

• An overview of collaboration security in the organization

• An in-depth look into FSSP application architecture and related technical components

• Prescriptive FSSP server topologies for virtualized environments, physical environments, and mixed-mode environments

• Guidance about how to implement FSSP and perform preliminary maintenance, configuration, and management tasks

Protecting the Collaboration Environment with Content Hygiene

Protecting the collaboration environment is a critical consideration when you are designing a progressive security strategy for an enterprise SharePoint environment. It is also an organic, continuing maintenance and administrative effort to ensure that enterprise content and the information workers that employ it are protected from potential malicious code execution and malevolent user-produced content.

Frequently, a collaboration security strategy is overlooked in an industrial-strength SharePoint design. Often, security considerations become focused excessively on built-in SharePoint role assignment and optimal configuration to support secure farm interserver communication. Although such design tasks are fundamental to implementing suitable SharePoint security, all stakeholders must take into account the antivirus (AV) and content filtering aspects during the preliminary design and through ongoing maintenance. Exposing a SharePoint environment with the proper hooks to handle malicious content before a production system goes live can help ensure that, from the beginning, all stored content is benign, protecting both users and the SharePoint platform. This does not mean that executing malicious content compensation measures for previously deployed SharePoint environments is not imperative for a successful collaboration implementation; however, you must take additional steps to achieve complete protection.

Because malicious code can commonly migrate to its target host, specified detection routines must be used to enforce and preserve an important content management concept known as content hygiene. Complete Content Hygiene is the system end state where a piece of content is scanned and cleaned during the changing of storage mediums; for example, when a document is uploaded to a SharePoint document repository either on-demand or on a scheduled basis. This full-circle process protects users from malicious content and protects the SharePoint environment from users, as shown in Figure 1. A scan is initiated whenever a user uploads or downloads SharePoint content (Figure 1, 1). On both a scheduled and on-demand basis, the content stored within SharePoint repositories is scanned (Figure 1, 2).

Figure 1. End state: Complete Content Hygiene

Using FSSP to Secure a SharePoint Environment

Using FSSP enables SharePoint engineers and administrators to centrally manage holistic hygiene and security of SharePoint content, and so work toward Complete Content Hygiene. The distinction between content security and other SharePoint security aspects is important to respect, because the implementation and maintenance of each involves very unique activities and routines. When using Forefront Security for SharePoint, the environment's security aspect that is being considered is content infection handling and filtering—not intrinsic aspects of SharePoint security that are related to, for example, permissions assigned to a SharePoint Securable Object (such as sites, lists, and list items). Although ensuring that such security attributes are well-formed is fundamental to a successful SharePoint deployment, FSSP handles out-of-product security functions to provide a basis for malicious detection routines.

FSSP offers several benefits, and although some might not be a concern for a particular environment, it is important to understand these benefits if they are required to introduce SharePoint for Security features after a production deployment. Of the advantages, three are perhaps the most significant:

• Multiple antivirus (AV) engines for inclusive protection against malware

• Filtering for inappropriate content

• Administration, performance, and Complete Content Hygiene enablement

Aggregating Multiple Antivirus Engines for Inclusive Protection Against Malware

Perhaps the most powerful feature in FSSP is the potential to aggregate multiple engines into a single scanning execution. This enables the incorporation of industry-leading AV engines from reputable security firms such as CA, Kaspersky Labs, and Sophos. By taking advantage of a technique known as Engine Aggregation or Multiple Engine Management (MEM) and Signature Redundancy, FSSP capitalizes on optimal engine combination. This lessens single points of failure by incorporating the latest AV signatures from multiple vendors. The end goal of Engine Aggregation is the introduction of multiple security sources to provide the most rapid response to new threats, which reduces the window of exposure for the SharePoint environment. In a real-world scenario, different security firms commonly release various new signatures in different time increments. Engine Aggregation increases scanning success by obtaining and integrating the first valid signature, regardless of source, thus removing a single source of failure. This model is recognized as Signature Redundant, which means the requisite mechanisms are implemented so that an individual signature scanning failure does not mean a piece of content does not violate the hygiene of the environment due to either update delays or engine deactivation.

Filtering for Inappropriate Content

FSSP is capable of scanning documents for content that is considered inappropriate for a particular organization. This is useful when enforcing corporate language policies or maintaining confidential information. Natively, this function is supported for most Microsoft Office application documents and Open XML file formats, even those that are encrypted by Information Rights Management (IRM) or those that are compressed. The function checks for unwanted text and retains both IRM security settings and necessary recompression. Furthermore, by extending the Blocked File Types function natively provided within the SharePoint platform, FSSP can implement filtering rules for detailed file type elimination. It can also detect whether an extension was altered.

Enabling Administration, Performance, and Complete Content Hygiene

As described earlier, FSSP enables an environment to work to Complete Content Hygiene, ensuring that documents are scanned during content repository upload and retrieval, and while stored through scheduled scans. This can be controlled through the Forefront Server Security Administrator (FSA), which can be used both locally and remotely. An administrator using FSA can manipulate granular performance settings such as those for multithreaded scanning, content scanning redundancy, and AV engine allocation.

Technical Deep Dive: SharePoint Virus Scan Engine API (SP VS API 1.4)

To accurately architect and maintain an enterprise FSSP deployment, you must understand how the AV scanning process executes. Knowledge regarding this process will be of assistance when designing the inclusive topology of the server running Microsoft Office SharePoint Server or Windows SharePoint Services, and provide insight during routine maintenance and configuration tasks.

The Microsoft Office SharePoint Virus Scan Engine (VSE) API (SP VS API 1.4) is the engine that orchestrates scanning tasks. From an application standpoint, SP VS API 1.4 is built upon the Microsoft Exchange Server VS API 2.0 platform; however, there are several changes to the API to optimize it for SharePoint content management, as follows:

• Optimized interserver communication between a SharePoint front-end Web server and a server running Microsoft SQL Server through low-level Windows SharePoint Services API calls. This is significant because SharePoint Server or Windows SharePoint Services relies on circular trips to manage sizable content.

• Removed reliance on MAPI. This is noticeable because Multipurpose Internet Mail Extensions (MIME) properties are heavily used when examining Forefront Security for Exchange Server (FSE). For example, FSE uses the FILE_OBJECT_CAN_DISPLACE MIME property to determine whether an attachment can be deleted, the MIME_OBJECT_DELETED property to delete the attachment, and the FILE_OBJECT_NAME property to create the plain text attachment for replacement as necessary.

From an application architecture perspective, there are three mutually exclusive but deeply related components. The VSE is responsible for receiving content from the Antivirus Manager (AVM) through the use of the SP VS API 1.4 exposed as a COM layer (Figure 2). Using this architecture, the VSE never communicates directly with any of the SharePoint databases, but instead receives and processes files, and subsequently issues a response to the AVM based on the required action (such as clean).

Figure 2. Communication stream

The AV scanning hooks are loaded by opening a listener channel for the HTTP protocol (by using underlying listening mechanisms for processing incoming HTTP requests) in the ASP.NET worker process that is defined according to the corresponding application pool (supported by the World Wide Web Publishing Service). The required routines initialize VSE API SP VS API 1.4 on the C:\Windows Folder\system32\inetsrv\w3wp.exe process (the ASP.NET worker process) by harnessing the available methods exposed by the IMso_VirusScanner interface, as shown in Figure 3.

Figure 3. IMso_VirusScanner containment hierarchy

It is crucial to understand the IMso_VirusScanner interface because it contains:

• The Initialize method for all per-instance initialization and instance-based data querying.

• The Scan method for content stream scanning and management.

• The Clean method for removal and management of infected content.

These components interact to provide a holistic AV management scheme, as shown in Figure 4.

Figure 4. IMso_VirusScanner interaction

Looking at Figure 2 and Figure 4, you can see that the associated processes, such as thread allocation and queuing, can be introduced into the AV work stream. This can provide a more inclusive view of the process, as shown in Figure 5.

Figure 5. Inclusive AV work stream

Prescriptive FSSP Server Topology for Virtualized, Physical, and Mixed-Mode Environments

There are numerous server topologies to consider when designing an original Forefront Security for SharePoint–aware SharePoint environment or assimilating FSSP into a pre-existing SharePoint deployment. Based on both business and financial requirements, SharePoint environments can be architected in a variety of permutations. Although calling out each design is not practical, conventional topologies generally contain distinct segments that translate to deep-rooted deployment phases such as development, testing, staging, user acceptance testing, quality assurance, and production. Thus, it is possible to present a mixture of three recurrent designs, which can be extrapolated for applicability for a satisfactory number of SharePoint environments. Microsoft Forefront Client Security (FCS) will also be included in the discussed designs as a file system protection measure.

Physical and Virtualized Small Farms

A Physical Small Farm (PSF) environment relies exclusively on physical hardware that integrates no virtualization components. It is architected as a single front-end Web server hosting all required SharePoint services, and uses a second independent physical computer to provide database services. This environment is most commonly seen when committing to a pilot SharePoint deployment, and typically is not bound to service-level agreements due to the lack of high-availability and redundancy. When considering an FSSP deployment in a PSF environment, all FSSP components will sit on the front-end Web server, application server, query server, or index server, as shown in Figure 7.

Correspondingly, for a Virtualized Small Farm (VSF), an identical deployment model will be used, as shown in Figure 8, principally because role design is static with such a constrained platform selection. In Table 1, a PSF and VSF share analogous FSSP and FCS deployments.

Table 1. PSF and VSF with separate development environments sharing analogous FSSP and FCS server deployments

Farm or Server	Role	FSSP	FCS
Production farm	Web, query, index	Yes	Yes
Production farm	Database	No	Yes
Development server	Web, query, index, application, database	No	Yes

Figure 6. PSF Forefront topology with separate development environments

Figure 7. VSF Forefront topology with separate development environments

In Figure 6 and Figure 7, it is important to notice that the development server is fully segregated from the remaining components in the production farm, running as a single SharePoint server instance. This is recommended from both a maintenance and security perspective for three reasons:

• SharePoint Server or Windows SharePoint Services uses BLOBs (Binary Large Objects) for file storage. As a result, when responding to content requests, the database execution pipeline uses a buffer manager to allocate memory where the content input rows are copied to handle the request. Because of the size of BLOBs, such requests are commonly spooled to external temporary files flagged by FILE_FLAG_DELETE_ON_CLOSE. Because of this flagging, when the buffer containing the rows is released, these files are subsequently removed. Because of this transitory reconstruction instance, there is a practical security consideration on the production data store.

• Sharing the database component between environments creates the possibility for cross-farm contamination because no "virtual walls" are established between environments. For acutely security-sensitive organizations, establishing this detachment between servers in different farms can be a prerequisite.

• From the maintenance viewpoint, development environments are normally considered disposable and can be destroyed at will by a development team member. Because of this environment discarding, if decommissioning procedures are not in place, database growth and subsequent maintenance can be problematic within the production environment.

Taking these factors into account, if a shared database must be used to consolidate data storage sources, a different FSSP implementation topology must be used to preserve the proper content security that is gained when using the models shown in Figure 6 and Figure 7. As shown in Table 2, because the development farm can possibly contaminate the production farm databases, FSSP must also be implemented on the development front-end Web servers (shown in Figure 8 and Figure 9).

Table 2. PSF and VSF with shared development environments, FSSP and FCS server deployments

Environment	Role	FSSP	FCS
Production farm	Web, query, index	Yes	Yes
Production farm	Database	No	Yes
Development server	Web, query, index	Yes	Yes
Development server	Database	No	Yes

Figure 8. PSF Forefront topology with shared development environments

Figure 9. VSF Forefront topology with shared development environments

Dual Host Mixed-Mode (Hybrid) Medium Farm

A Dual Host (DH) Mixed-Mode (Hybrid) Medium Farm, which is one that uses both virtualization and physical servers, generally consists of a physical index server and SQL Server cluster deployment. The remaining farm components continue to be spread across the virtual machines. The reasoning behind this is straightforward. Because front-end Web servers are essentially stateless and do not contain any "real" data, they are easily reprovisioned and assimilated into the farm.

It is important to notice that this topology is also the first design discussed in this acceleration toolkit that contains a structured process for SharePoint application release management. This is accomplished with the introduction of a staging environment. The goal of this farm is to act identically to the production environment to provide simulation; mimicking production provides appropriate context for applicable quality assurance (QA) testing. As demonstrated in the following topology, although there is dissimilar virtualization between the staging and production environments, there are similar role breakouts and assignments to provide a more intuitive release process to production.

Table 3. DH Hybrid Medium Environments with separate development environments, FSSP and FCS server deployments

Farm or Server	Role	FSSP	FCS
Production farm	Web, query	Yes	Yes
Production farm	Web, query	Yes	Yes
Production farm	Index	No	Yes
Staging farm	Web, query	Yes	Yes
Staging farm	Web, query	Yes	Yes
Staging farm	Index	No	Yes
Development server	Web, query, index, application, database	No	Yes
Development server	Web, query, index, application, database	No	Yes

Figure 10. Dual Host Hybrid Medium Farm Forefront Topology with separate development environments

Triple Host Mixed-Mode (Hybrid) Large Farms

A Triple Host (TH) Mixed-Mode (Hybrid) Large Farm is an inclusive design encompassing several farms that provide various environments to support controlled release processes. Three hosts provide three separate virtualized development environments for individual developers or small teams to make radical code changes with little consequence. Because it is not possible to pollute production under this design, each simply requires FCS and does not require FSSP because the environments can be considered disposable. When development is complete in development silos, this can subsequently be pushed to the integration server to commit initial code changes for preliminary combination with the work of the other team members and to provide initial validation. Generally, within the integration environment, the subset of data is altered repeatedly and has frequent code introductions. As a consequence, it will use its own database server. Therefore, it is not required to put the FSSP server components on the integration farm.

Table 4. TH Hybrid Large Farm with development environment silos, FSSP and FCS server deployments

Farm or Server	Role	FSSP	FCS
Production farm	Web	Yes	Yes
Production farm	Web	Yes	Yes
Production farm	Web	Yes	Yes
Production farm	Query	No	Yes
Production farm	Query	No	Yes
Production farm	Application	No	Yes
Production farm	Application	No	Yes
Production farm	Index	No	Yes
Shared	SQL Server cluster	No	Yes
Shared	SQL Server cluster	No	Yes
Staging farm	Web, query	Yes	Yes
Staging farm	Web, query	Yes	Yes
Staging farm	Index	No	Yes
Integration farm	Web, query	No	Yes
Integration farm	Index	No	Yes
Integration farm	SQL Server	No	Yes
DPM Recovery farm	Web, query, index, application	Yes	Yes
Development server	Web, query, index, application, database	No	Yes
Development server	Web, query, index, application, database	No	Yes
Development server	Web, query, index, application, database	No	Yes

Figure 11. Dual Host hybrid Medium Farm Forefront topology with separate development environments

Implementing a Topology

Server topologies are mutable and can vary from organization to organization, but the steps used to introduce FSSP onto a SharePoint front-end Web server are consistent. Implementing FSSP after a design is chosen can be broken down into two steps: installing the FSSP software and performing the preliminary configuration. Adhering to baseline initial configuration actions can ensure that the desired security and protection level is achieved, and provide insight into how to execute routine maintenance procedures.

Baseline Requirements

As FSSP is run on the front-end Web servers in a SharePoint farm, most of the hardware requirements mirror prescribed front-end Web server requirements.

Table 5. FSSP hardware and software requirements

Hardware or software	Requirement
Processor	Dual processor with at least 2.5 gigahertz (GHz) clock speed
Operating system	Windows Server 2003 with Service Pack 1
Memory	1 gigabyte (GB) available, 2 GB recommended
Disk	550 MB of available disk space
SharePoint	Microsoft Office SharePoint Server 2007 or Windows SharePoint Services 3.0

A MAPI client, such as Microsoft Office Outlook, is also required; however, for platform hygiene, it is always vital to introduce a minimum of client applications to production SharePoint environments. A workaround to avoid this requirement is to install the Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1, which will enable FSSP to send notifications.

Installing FSSP

Before beginning the FSSP installation, it is advisable to create a service account for FSSP services to use. This enables you to explicitly provide security context for some of the FSSP services, which enables adherence to the principle of least privilege. Because this account will be used with the FSSPController service, it is advisable to create an account named DOMAIN\FSSPController or DOMAIN\FSSPControllerService. After the account is created, add it to the local Administrators group of target FSSP front-end Web servers, and to the local Administrators group on the SQL Server environment. Although from a SQL Server perspective the only rights that are mandatory are SecurityAdmin and DBCreator, an Administrators group account enables manual scanning to function properly.

Following the account creation, you can install FSSP either directly on a local server or optionally on a remote server. To begin the installation, using an administrative account, log on to the target SharePoint front-end Web server.

During the FSSP installation of the FSCController and FSSPController services, and the Forefront Server Security Administrator (FSA), you can choose to install on the target SharePoint front-end Web server. The FSCController Windows service is responsible for orchestrating all scanning, and the FSSPController acts as the communication broker between the SharePoint front-end Web server and the server running SQL Server. Both are core components for Forefront Server Security Administrator, which centralizes Forefront management.

To install FSSP

1. Insert the FSSP CD, download the installation file, or mount an FSSP ISO image on a virtual disk.

2. In the InstallShield Wizard, on the Welcome page, click Next.

3. On the License Agreement page, read the complete agreement. If you accept the stated terms, click Yes.

4. On the Customer Information page, type the required User Name and Company according to corporate software installation standards. After you type both, click Next.

5. On the Installation Location page, select the type of installation, Local or Remote.

6. If you are performing a remote installation, the Remote Server Information page appears. Enter the target SharePoint front-end Web server and the Share Directory to use (this defaults to C$).

7. On the Installation Type page, choose one of the following:

   • Client—Admin console only: Only install FSA for remote management.

   • Full Installation: Install the complete FSSP application, including FSA and all related server components.

   Click Next.

8. On the Microsoft Update page that appears, selecting Use Microsoft Update when I check for updates is suggested if it is within the organizational IT update strategy.

9. On the Engines page, eight AV engines for FSSP are listed. However, because the Microsoft Antimalware Engine is required for FSSP functionality and the maximum number of engines is five, you can select a total of four engines. Because you can proactively deactivate engines to compensate for memory consumption balancing, it is also recommended to select four engines. This decision can be changed at a later date, and engines can be substituted. After you select the AV engines to install initially, click Next.

10. On the Proxy Server page, enter any required proxy settings for the updating to function correctly. Click Next.

11. On the Engine Updates Required page, click Next. The updating process searches and updates virus definitions hourly, starting five minutes following the start of the FSSP service.

12. On the Choose Destination Location page, select an FSSP destination folder, which defaults to C:\Program Files\Microsoft Forefront Security\SharePoint. Click Next.

13. On the Select Program Folder page, click Next.

14. On the SharePoint Database Account Information page, enter the previously created FSSPController service account.

15. On the Start Copying Files page, review the previously specified settings, and then click Next.

16. Following installation, you can optionally view the Readme file. Then, click Finish.

Configuring FSSP

After you install FSSP, you should implement the particular configuration tasks to both meet target business objectives and cultivate self-sustaining updates and scanning jobs. Although some tools offer a large amount of utility on a proactive, as-needed basis, becoming accustomed with each enables simplification of potential future maintenance tasks. To support the discovery of components, each major feature is complemented by a structured check box action list providing an activity to ensure that each feature is realized. Although some of these tasks are target necessary or suggested actions, some are recommended as practice procedures to prepare for potential maintenance tasks.

FSA Under the Hood

After you install FSSP, open FSA to centrally manage the local FSSP server settings. The FSA interface layout is sectioned into three different panes, as follows:

• Area pane: Appears on the left, and lists the component areas that can be configured and managed, organized as Settings, Filtering, Operate, and Report.

• Activity pane: Appears on the top right and provides the ability to select a component for management such as a scan job, or other assets such as filtering lists.

• Configuration pane**:** Appears at the bottom of the interface and displays the settings that are available for the current selection from the Activity pane.

Checklist
◊ (Optional) Create a shortcut to FSA on the SharePoint front-end Web server desktop for ease of access.
◊ Locate the Area pane, Job pane, and Configuration pane.

Settings

The uppermost FSA Area in the Area pane, Settings, contains fundamental configuration options for how FSSP scanning and associated jobs function. Within the Settings area, it is possible to control fine details about how individual scan jobs execute, to make AV engine selections, to update AV signatures, and to manage templates for consistent application of FSSP settings across all front-end Web servers in a SharePoint farm.

Building FSSP Scan Jobs

The first selection in the Settings area is to shape FSSP scan jobs, which can be one of two unique types, either real-time jobs or manual jobs.

On a default FSSP implementation, real-time scanning is Enabled with all scanning options On, including Virus Scanning, File Filtering, and Keyword Filtering. After selecting a job in the Activity pane, the corresponding job settings populate the Configuration pane.

Job settings for real-time jobs cannot be selected, because real-time AV settings are managed from SharePoint Central Administration (WCAM). Selecting Configure SharePoint/WSS Antivirus Settings in the Configuration pane opens WCAM. You can display settings on the Operations page by locating the Security Configuration section, and then selecting Antivirus. Antivirus changes made in this section are synchronized back to FSA.

Typically, adjustments to the default settings are not recommended. Following the default implementation, documents are scanned mutually on both upload and download via in-memory scanning, with a violation response to Clean (Repair) infected content. Although these settings are advisable by default, it is prudent to select Deletion Text, and supply a message that both mirrors corporate standards and provides qualified information for replacement values to users.

Although real-time scanning jobs are automated, manual scan jobs provide the means to execute informal scanning on explicit locations. There are numerous circumstances where a manual scan is required. If FSSP is being implemented in an environment that is already deployed, all stored content must be interrogated for malicious content and therefore a manual scan will be run on the entire environment (this could also be a quick scan, which will be discussed later in this acceleration toolkit). From an updating perspective, if rotating AV engine selection between vendors in a production environment, it is recommended to do a full manual scan to ensure all content has been scanned by the latest engines and signatures by those vendors. When Manual Scan is selected in the Activity pane, different SharePoint Securable Objects that act as containers can be selected as the target, such as sites or libraries, in the Configuration pane.

Checklist
◊ Select the Default Realtime scan job, and then open the WCAM Antivirus Settings. Ensure Scan documents on upload, Scan documents on download, and Attempt to clean infected documents are enabled.
◊ On Antivirus Settings, ensure Allow users to download infected documents is disabled.
◊ On Antivirus Settings, if 300 seconds (default) for timeout duration is not suitable, either increase or decrease this value. Generally, the default setting is fitting.
◊ On Antivirus Settings, if 5 execution threads (default) is not suitable, either increase or decrease this value. Generally, the default setting is fitting. For more information about execution threads, see SP VS API 1.4 (Overview: Virus Scan Engine API Implementation).

Configuring Antivirus Settings

The Antivirus section contains scanning engine configuration for engines selected during the FSSP installation. Based on the scan job selected in the Activity pane, you can select distinctive settings so that an engine scheme can be bound to a particular job. Violation rules or Actions (reactions to an infringing piece of content) for individual jobs are specified by selecting Action; by default Clean is selected (and recommended) to attempt content repair. Although it is viable to Skip (log, no action) or Delete (scrap) violating content, Clean is recommended from a content preservation standpoint.

Checklist
◊ Select the default Realtime and Manual scan job settings. If the default configuration is not suitable, make appropriate adjustments.

The Bias settings specify the desired engine allotment scheme that is most beneficial based on business objectives (level of detection accuracy desired) and hardware (how much memory is available). This is mostly configured on an impromptu basis, based on server performance subsequent to implementation use cases. There are five selections available:

• Maximum Certainty - Scan using all selected engines.

• Favor Certainty- Scan using all available engines.

• Neutral - Heuristically choose from the selected engines based on recent results.

• Favor Performance - Based on recent results, vary between using half the selected engines and heuristically choosing only one engine.

• Maximum Performance - Based on recent results, heuristically choose only one engine from the selected engines.

Checklist
◊ Select the default Realtime scan job, leave Action as Clean, set desired Bias.
◊ Select the default Manual scan job, leave Action as Clean, set desired Bias.

Managing Scanning Updates

As discussed earlier, scan engine updates are issued hourly, beginning five minutes after FSSP installation. Recurrent updating is crucial to the collaboration AV infrastructure because updates ensure that the latest signatures are being used for detection.

The Scanning Updates section of the Activity pane lists available engines, associated engine information, and whether updates are bound to a schedule. Because update releases vary between each vendor, and some engines might not be used, individual engines can use a unique schedule. It is also possible to execute unplanned updates for specific engines. More update configuration options are available in the General Options section, described later in this acceleration toolkit.

Checklist
◊ Disable updating for irrelevant AV engines.
◊ Set the desired update schedules for relevant AV engines.
◊ Run manual updates on relevant engines.

Understanding Templates

For larger farm environments, consistent settings across all FSSP–aware SharePoint front-end Web servers are necessary. Templates provide a means to "stamp" settings from an FSSP configuration, and enable import and application of those settings on other front-end Web servers. Three types of templates are available:

• SP Realtime (real-time scan job template)

• SP Manual (manual scan job template)

• Filter Set (filtering template)

New templates generate a template.fdb file, which can be imported either by a local or remote FSSP server.

Checklist
◊ Create and delete a new test SPRealtime template.
◊ Create and delete a new test Filter Set template.
◊ (Optional) Remotely load, then remove a template.

Working with the FSSP General Options

The General Options section is divided into Diagnostics, Logging, Scanner Updates, and Scanning. There are abundant options available in General Options; however, for initial configuration tasks only a few are required.

The Diagnostics section specifies harvesting auxiliary information from FSSP, the disadvantage of which is the associated disk space requirements for storage. Additional logging is available for the two primary scan job types. Additional Manual provides supplementary information for manual scans and Additional Realtime provides additional information for real-time scans. Both write to the ProgramLog.txt file, enabled in the Logging section. Notify On Startup sends an e-mail message based on the destination address specified in the Reporting area every time a scan commences.

Checklist
◊ Enable Additional Manual logging. Run a Manual scan. Examine ProgramLog.txt. Disable Manual logging.
◊ Enable additional Realtime logging. Trigger a Realtime scan. Examine ProgramLog.txt. Disable Realtime logging.
◊ Enable Notify on Startup. Run a Manual scan. Ensure notification is received. Disable Enable Notify on Startup.

The Logging section enables management of global logging options for both platform-provided sources such as the Event log, and FSSP sources such as the FSSP Program log and Virus logs. To use Additional logging as specified in the Diagnostics section, the FSSP Program log must be enabled. The FSSP Virus log logs every virus that FSSP encounters to supply an automatically updated chronological record.

Checklist
◊ Examine Logging options. Toggle Sources as required by corporate initiatives.
◊ Ensure that the Maximum Log Size is set to 25600 KBs. Specifying zero (0) allows unlimited log growth, which could lead to storage issues.

The Scanning Updates section enables global configuration of the scanning update strategy, which differs from the Scanning Updates area where the update settings target a specific engine. The two important actions to consider are presenting any required proxy settings for successful updating, and determining whether the current server should act as redistribution server, orchestrating farm deployment of product and signature updates from a single distribution source.

Checklist
◊ If required, check Redistribution Server to specify the front-end Web server as an update distribution hub.
◊ If a proxy is required, specify all required settings for the updates to Succeed.

The Scanning section contains universal scanning options, different from the Scan Job section, which targets specific scan jobs. Although there are plentiful options available for configuration, the important actions to consider are compressed file behavior, encoded file behavior, and embedded file scanning. Most of these selections depend greatly on the particular organization vertical and purpose for the SharePoint instance (storage types); however, there are some suggested configurations for a default installation.

Checklist
◊ (Suggested) Check Block/Delete Corrupted Compressed Files because this indicates the likelihood of infection.
◊ If using RMS/IRM, disable Block/Delete Encrypted Compressed Files.
◊ (Suggested) Enable Treat Multipart RAR Archives as Corrupted Compressed because file splitting increases chances of undetected infections.
◊ If embedding content (for example, images) in Microsoft Office documents, enable Scan Doc Files As Containers For Inclusive Scanning.
◊ (Suggested) Leave Case Sensitive Keyword Filtering disabled for performance reasons.
◊ (Suggested) Ensure Block/Delete Corrupted Uuencode Files is enabled.
◊ (Suggested) Ensure Treat ZIP Archives Containing Highly-Compressed Files as Corrupted Compressed is enabled to ensure compression does not restrict scanning.
◊ (Suggested) Ensure Treat Concatenated gzips as Corrupted Compressed is enabled for individual files splitting conditions.

Filtering

As discussed in preceding sections, filtering in FSSP provides both Keyword Filtering and File Filtering, the latter extending the Blocked File Types function of SharePoint to interrogate for manipulated file name extensions. Keyword Filtering is most often used to remove vertical-specific or industry jargon and to ensure company confidential information is restricted. File Filtering targets precise file types.

Keyword Filtering is specified by using a keyword list. The keyword list itemizes filtering rules, tabulated as separate line items written by using case-sensitive matching operators (and/or) with keyword arguments specifying either inclusion or exclusion. The rules are created and stored within the Filter Lists section. A list is created (or imported), edited, and then activated on a specified scan job with Keyword Filtering On. Correspondingly, File Filtering is based on a file list in the Filter Lists section, and can be activated on a scan job that has File Filtering On.

Checklist
◊ Create the appropriate Keyword Filtering lists with associated rules in Filter Lists according to corporate naming conventions.
◊ Create the appropriate File Filtering lists with associated rules in Filter Lists according to corporate naming conventions.
◊ Activate the created Filtering Lists with desired action responses on qualified scan jobs.

Working with FSSP Operations

The Operations area, as the name implies, provides an operations console from which to execute scan jobs. Although jobs are configured through various sections in the Settings area, the execution of the job occurs within the Operations area. There are three sections in the Operations area: Run Job, Schedule Job, and Quick Scan. Although real-time jobs are consistently running based on content behavior, the Run Job section enables initiation of manual jobs after specifying whether virus scanning, File Filtering, or Keyword Filtering should be used. The Schedule Job section provides mechanisms for as-needed manual jobs to be executed on a recurring basis. This is considered a prescribed best practice because numerous dissimilar manual scans might be bound to different engines. Executing signature rotation sets enables a varied defense while preserving performance considerations. The Quick Scan section enables true impromptu scan job execution, not relying on any of the jobs defined in the Activity pane but providing spontaneous, destructible jobs.

Checklist
◊ Run a manual job through the Run Job section.
◊ Depending on corporate initiatives, create a staggered manual scan job schedule that is initiated during off hours.
◊ Create and execute a quick job.

Working with FSSP Reports

Within the Report section, the only configurable portion is Notifications; Incidents and Quarantine are strictly for presentation of FSSP-generated data. In Notifications, each FSSP service providing e-mail notification is listed, and the associated notification message with respective replacement keywords. Each notification type can be enabled or disabled and its message customized.

Checklist
◊ Enable or disable Notifications as desired. Depending on corporate initiatives, adjust the relevant notification messages.

Incidents provides chronological reports regarding content that triggered a response. This includes specific content metadata such as the related user and date, stored in the Incidents database, Incidents.mdb (a Microsoft Office Access database file). Use of Incidents enables system engineers to establish whether an individual malicious infection is recurrent, so that they can determine possible source machines. Storage specifications and constraints are also specified in this section because Access databases have a hard limit of 2 GB.

Checklist
◊ View the default Incidents report.
◊ Set the Database Purge settings (30 days is suggested).

Similar to the Incidents database strategy, encoded copies of infected files are pushed to the Quarantine database (Quarantine.mdb). Quarantine also includes other interrogative data such as user and source location, which Quarantine uses to build reports. Storage specifications and constraints are also specified.

Checklist
◊ View the default Quarantine report.
◊ Set the Database Purge settings (30 days is suggested).

FSSP, End-to-End Security, Trusted Stacks, and SharePoint

To fully understand where FSSP fits into enterprise SharePoint architectures, it is essential to recognize the Microsoft approach to handle a concept known as End-to-End Security. And although an organization might not use the inclusive concepts of End-to-End Security, and instead focus on particular platforms, taking into account the prescribed approach aids in understanding how FSSP fits into an inclusive organizational software stack. Briefly, End-to-End Security attempts to introduce consistent security protocols for all data whenever a client device is communicating with the enterprise, to increase security and lessen privacy concerns. This is done by introducing a trusted stack, which includes trusted operating systems, trusted applications, trusted people, trusted data, and security that is being integrated into hardware. Figure 12 depicts the stack.

Figure 12. Trusted stack

The trusted stack is effortlessly translated into a SharePoint environment as a deployment that can take advantage of the trusted stack approach. The trusted stack model can be correlated to particular SharePoint features, as follows:

• Trusted people Information workers that take advantage of the collaboration environment.

• Trusted data Information that is housed with SharePoint content repositories.

• Trusted software The collaboration software that sponsors housing content.

• Trusted operating systems The Windows Server platform.

• Trusted hardware The hardware platform that the collaboration platform uses.

In summary, an organizational investment in a substantial information presence facilitates ease of use for knowledge workers; however, the security attack surface area is broad, ranging from malicious content introduction to Web-specific threats. Therefore, you must examine various approaches to correctly enforce fulfillment of high-level security objectives.

From a Microsoft product standpoint, there are several products that fall under the End-to-End Security umbrella. The Forefront Security product family includes components for securing clients through Microsoft Forefront Client Security, mail server security through Microsoft Forefront Security for Exchange Server, edge security through Microsoft Internet Security and Acceleration (ISA) Server and Microsoft Intelligent Application Gateway (IAG) Server and, of course, FSSP for collaboration security.

Conclusion

Congratulations! The target SharePoint environment should have a more secure, stable, and dependable collaboration infrastructure, promoting contemporary security concepts that protect both users and the platform. Forefront Security for SharePoint (FSSP) is used to introduce content hygiene into the collaboration environment, ensuring that documents are scanned during the changing of mediums and on a scheduled basis while stored within SharePoint document repositories. Coupling content hygiene with built-in SharePoint security mechanisms to control access and authorization is imperative for acutely sensitive organizations, and results in many benefits.

This article addresses in detail the characteristics of FSSP, its advantages, and the inherent security concepts that are provided with FSSP implementation—either designed into a new SharePoint environment or retrofitted into an existing deployment. Various environments are examined, including Physical and Virtualized Small Farms and Hybrid Medium and Large Farms, demonstrating FSSP and FCS targets across a variety of topologies. The article provides accelerated configuration tasks, and activity checklists with practice steps to increase visibility into potential future maintenance tasks.

Additional Resources

For more information, see the following resources:

• Microsoft Forefront Home

• Microsoft Forefront Security For SharePoint Home

• Microsoft Forefront Server Security Blog(Microsoft TechNet)

• ARB Security Solutions (Microsoft TechNet)

• Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1

• SharePoint Server Developer Center

• Office Developer Center