Export (0) Print
Expand All
Expand Minimize

Reliable Repositories: Using Microsoft Forefront Security for SharePoint to Defend Collaboration

Published: April 11, 2007

By Adam Buenz, MCP, CCSP and Microsoft MVP, Windows Server -- Windows SharePoint Services

See other Security MVP Article of the Month columns.

Introduction

As the techniques and technology that organizations use to construct business information warehouses evolve, malware attack methods similarly improve and advance. When utilizing a Web application, such as Microsoft Office SharePoint Server 2007 (MOSS), to facilitate such a core data repository while fostering a collaboration platform to unite virtual teams, the first thing that comes to mind when analyzing information warehouse security is the Web layer. However, there are numerous planes of security that must be inspected when assessing the inclusive threat background. Employing MOSS as an information warehouse component of an Enterprise Content Management solution exposes the possibility for content-based and malware attacks, greatly expanding the inventory of effective threats. Microsoft Forefront Security for SharePoint (FSSP) provides the essential mechanisms to close this gap. It secures MOSS–based storage mediums so that vital business data can be protected from possible malware that could otherwise compromise repositories. By doing this, it mitigates risks such as revenue loss, operations disruption, and industry embarrassment.

Recently, securing a SharePoint server farm from malware became a requirement for my consulting team, which caters to a particular U.S. military group (referred to here as the 101st SharePoint Squadron). This group uses MOSS to deposit several varieties of unclassified data, ranging from antiterrorism training material to military decoration records. Although the data was regarded as unclassified, the information could influence combat-deployed troops, and, ultimately, the outcome of war. As a sizable military group, the 101st SharePoint Squadron is subject to more frequent malware attacks than most other industry groups, and, in fact, masqueraded malware attacks had been introduced to the SharePoint environment through diverse, obscure channels.

In this article, I examine FSSP application architecture and how integrating FSSP into the inclusive SharePoint infrastructure can augment collaboration platform security to protect both SharePoint users and the SharePoint server farm. FSSP provides this functionality through redundant content scanning by using Multiple Scan Engines (MSEs) powered by 8 market-leading AV engines such as Sophos Virus Detection engine and Norman Data Defense engine, customizable scanning jobs and types, and advanced filtering techniques (keyword, file, and content). The result is mitigated risk from malware so that sensitive environments like the 101st SharePoint Squadron can be adequately protected.

FSSP and the CIA Triad

To better understand how the FSSP security attributes that are being offered relate to the proprietary information that is being protected, it may be useful to show how it relates to a fundamental, universally accepted security standard such as the CIA triad: Confidentiality, Integrity, and Availability (see Figure 1). Although each of its layers has different weight for individual organizations, the CIA triad allows the focus to be shifted to highlight the highest risk for a particular environment, an adjustment that will later influence operational settings for FSSP processes. My central goal with the implementation of FSSP at the 101st SharePoint Squadron was to guarantee confidentiality (See Table 1). Breaches of even a section of unclassified information, if pieced together with other unclassified data, can equip the enemy with dangerous data. Therefore, sacrifices are acceptable in terms of availability; that is, informational Quality of Service may be slightly downgraded in order to ensure that the data is available only to trusted parties.

Figure 1

Figure 1. Forefront and the CIA Triad

CIA Triad Principle

Forefront Security Principle

Confidentiality* Information can only be read and understood by trusted, authorized parties. (*Focus of the 101st SharePoint Squadron)

Information channel malware (viruses, trojans, rootkits) is stopped before reading or sending sensitive information from MOSS.

Integrity Information has not been modified or destroyed by unauthorized parties.

Destructive payload malware is quarantined and dealt with before damage occurs to MOSS and the information stored in it.

Availability Information can readily be accessed with a high level of Quality of Service.

Information is not infected when it is being submitted to, received from, or stored in MOSS which can affect data accessibility.

Table 1. Relating CIA Triad Principles to ForeFront Security Principles

VSAPI, Defense-in-Depth, and MSEs

Unlike other antivirus (AV) bundles that are often used with MOSS, the Microsoft Virus Scanning Application Programming Interface 1.4 (VSAPI) provides a multilayered security approach. This FSSP interface builds on a defensive concept known as Defense-in-Depth (DiD), ensuring that there are no single points of failure that could result in unauthorized security gaps. By using the VSAPI, FSSP can aggregate 8 leading AV engines that use both heuristic-based methods and signature-based methods. By selecting up to 5 simultaneous engines, the AV engines provide a cohesive defensive barrier that remove points of failure. The VSAPI process routines extract from the VSAPI.dll (dynamic link library) when attaching to the w3wp.exe process (which ASP.NET applications run under) and related SharePoint assets.

For the 101st SharePoint Squadron, the maximum number of active engines allowed must be used, since it is atypical that several vendors will neglect the same virus definition. Using multiple vendors promotes DiD, because if one vendor does not timely release a definition, another may do so. The multiple AV engine instantiation is functionally supplemented by the Multiple Engine Manager (MEM) ranking. MEM allows operations to be gauged so that numerous engines can be ranked by evaluating age and past performance parameters. The output of this process is that the most significant, functioning engines are used initially when executing an arbitrary scan. In the case of the 101st SharePoint Squadron, which uses several engines, MEM adjusted accordingly to properly protect the environment.

When implementing multiple engines, you will need multiple computing cycles to power the various AV engines. This precise balance between inclusive server performance and AV engine routine operations ties directly into the layers of the CIA triad when deciding on what principle is the focus of your organization (See Figure 2 and Table 1).

Figure 2

Figure 2. Balancing Server Performance and AV Engine Performance

How the CIA triad pieces are appraised for your organization will affect an important FSSP concept known as the bias settings. These settings provide an approach to weigh out what is critical for your organization. This varies from the probability that a piece of malware will be caught by an implemented engine to whether general performance of the machine should be optimized. Running multiple engines requires a commitment from the machine to supply the needed computing cycles. Therefore, the structure of the CIA triad will affect how bias settings are tiered.

There are two extreme settings, two Favor-based values, and one inner neutral value that are supplied for your use in the FSSP bias settings. The settings range from Maximum Performance, which will only scan with one engine based on MEM output, to Maximum Certainty, which will scan items with all five engines, if implemented. Because the 101st SharePoint Squadron’s biggest concern is capturing and managing malware as opposed to any performance factors, Maximum Certainty is a lucrative setting to use. However, it would be possible to use one of the middle “Favor” values, such as Favor Certainty, which would use all engines that are online and active. Because the Squadron is only concerned with scanning with available engines, Favor Certainty suffices since it will only employ engines considered active by FSSP.

FSSP Scan Jobs

There are several types of scan jobs to tie directly back into any number of engines of FSSP. The scanning options offered by FSSP can generally be broken down into two major types and one minor type. Background and Real-time Scanning (also known as On-Access Scanning) are the two foundational scanning options and generally run without user interaction. However, it is also possible to construct manual scan jobs that will allow you to create manageable tasks that can be scheduled on a customizable timetable. Each of these scan jobs allow you to select engines from the available engine inventory, allowing you to customize scan job engine choice to build an overall greater protection strategy.

Whereas most AV server software will generally scan only files hosted directly on the server machine, FSSP provides real-time processes. Using this feature, real-time scanning can be allowed to scan files as they are sent or received from MOSS, such as files stored in document libraries. For files already stored on the medium, background scanning jobs can be used in order to take advantage of the latest virus definitions (see Figure 3).

Figure 3

Figure 3. On-Access and Background Scanning

Although the default 3 Realtime Process Count configured when you first install FSSP is generally sufficient for most environments, the RealtimeProcessCount registry value can be moved up to an extreme level of 10. As stated previously, all of this functionality depends on the VSAPI hook that will route the documents through the appropriate scanning queue. The processes will work in a round-robin fashion whereby sequential checks will be performed on process busyness. If a process is found to be currently committed, the request is subsequently handed off to the next process for handling. For the 101st SharePoint Squadron, whose particular environment employed a four-processor inventory, an 8 value for the processing count (two per processor) was sufficient because it is considered high volume, providing the desired level of redundancy. Because of the Scan Recovery Option, which defaults the timeout value of a scan to 10 minutes (specified in the RealtimeTimeout registry value), if a process could not successfully be restarted, the relevant administrative staff and I are notified so that we can deal with the issue appropriately.

With the large engine inventory being used for FSSP, manual scan jobs were not very frequent in the 101st SharePoint Squadron. Real-time scanning and background scanning often are sufficient to satisfy the obligatory levels. However, when new AV software was purchased, or an engine that is not configured for use in real-time scanning settings was used, we did perform manual scan jobs. This was a constructive approach since a majority of the global configuration was kept intact. Furthermore, manual scan jobs were exceedingly helpful in a variety of other scenarios:

  1. Verifying operational efficiency

  2. Evidence indicated that a potential malware outbreak may have occurred

  3. New organizational compliance measures have been introduced

Intelligent Content and Keyword Filtering, Better Security

For some administrators, reliance on the inherent SharePoint server filtering mechanisms through the use of the Blocked File Types configuration is essential to maintaining the operation of their environment. Blocked File Types are also one of the most frequently used pieces of configuration functionality for the 101st SharePoint Squadron to ensure that files stored in MOSS comply with organizational storage policies. Using FSSP, the filtering concept that Blocked File Types provide can be taken a step further. FSSP permits filtering of file types that normally might embed masquerading malware even if there is logic to hide extensions or the file contains an alerted file extension. You can set the FSSP settings to declaratively filter by files that meet a certain extension argument, such as whether the extension is an .exe that immediately indicates malware. This is mostly analogous to the Blocked File Types configuration that is provided natively.

You are much more likely to succeed, however, by using FSSP generic filtering, which functions by binding a generic filter to an available file type, as opposed to just filtering out .exe file extensions using a regular expression (matching a particular file extension). This allows FSSP to appropriately apply rules to content such as an .exe that has had the extension changed to a .doc file, which would normally pass blocked file extensions. The filtering can also be extended to include other metadata such as file names or file sizes. For the 101st SharePoint Squadron, nearly 90 percent of the malware that we detected was being introduced through an altered file extension. Therefore, this generic filtering is exceptionally critical. In addition, to ensure that overload isn’t experienced on the Microsoft SQL Server database cluster, all files over 500 MBs are subject to a filter using the wildcard comparison operator *.*>5 MB.

In a collaborative environment that empowers users, it is increasingly important that the content being posted maintains compliance with currently implemented organizational standards on language and the appropriate use of that language. Because users are generally allowed to post whatever content they desire on a SharePoint site (as long as it is not considered malicious as specified by Blocked File Types configuration and there are appropriate permissions), not filtering content that could be considered offensive to other users becomes a big concern. FSSP provides mechanisms that allow you to examine both strings and sets of strings to determine whether the content being posted matches patterns of strings that may be considered provocative. This is generally very important to organizations that maintain high standards on racial and sexual discrimination, because offensive content posted might lead to legal implications if found by offended parties.

Sexual discrimination was something that the 101st SharePoint Squadron particularly wanted to manage before it was ever a problem. Therefore, keyword filtering became increasingly important. Unfortunately, several offensive slang words and phrases employed by users were not found in prepopulated FSSP keyword lists that attempt to include content that may be considered distasteful. By defining new keyword filtering lists, first the relevant, less common keywords were associated and then the actions that should be taken when the situation is satisfied—such as either placing the item in quarantine or obtaining notifications—were subsequently taken. This allowed the 101st SharePoint Squadron to maintain a high level of conformity with stringent sexual harassment standards by including vernacular unique to military groups.

Conclusion

As MOSS becomes a de facto standard for Web application data warehouses, the chances that a piece of malware will infect precious data repositories increases. Preventing these attacks is exceptionally important, yet standard security routines typically aren’t sufficient to thwart knowledgeable malware authors. By noticing, and respecting, that the security of stored business information must be part of an overall security program, control and assurance over the aggregate SharePoint server environment can be amplified. FSSP provides the advanced mechanisms to properly equip SharePoint administrators and architects with a sophisticated, practical toolkit to approach such a threat landscape. This toolkit mitigates content-based attacks, ensuring that MOSS is providing reliable repositories.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft