Scan Jobs Within Forefront Security For SharePoint

There are several types of scan jobs that exist within the Forefront for SharePoint framework, each of which may be appropriate for an arbitrary task depending on your requirements. The three scan jobs that exist within Forefront for SharePoint are:

  • Quick Scan
  • Manual Scan
  • Realtime Scan

Quick Scan

The first type of scan job offered is the quick scan. This is a useful scan job when you have a single entity that you wish to scan quickly or if you want to trip a one time scan of your environment using varying engines (those engines outside of those which are tripped by other job files). Quick scan will bring a treeview of your site hierarchy and the relevant available document libraries into its dialog, where you can navigate to the varying assets of the site in order to select the one that is currently of interest to you. If you want to scan the entire environment, you can simply choose the highest parent element which will allow you to trip a scan with the arbitrary engine on the entire environment. Once you find the entity that you wish to implement the scanning on, highlight it, and choose the engine that you wish to implement the scanning against. This is typically an engine that would not have already gone scanned the entity during another job, which would be somewhat useless. You will see that there is a Bias threshold option that is also available through the interface that will allow to set baselines on performance factors depending on whether you are selecting multiple engines for the scan job. You can set the arbitrary action that you wish to commit against files found out of compliance with your selections, as well as the option to trip the notifications option (as discussed in other articles) which can either send notifications to the Forefront for SharePoint WebParts or route an email request (with or without the replacement macros, it depends on whether you have custom configuration within your notification macros).

Manual Scan

A manual scan interacts with the pre-created jobs, and therefore if you haven’t gone through the job creation dialog it is rather useless. There are three main options that are displayed with each arbitrary job, not related to whether the service is currently running or not:

  • Virus Scanning
  • File Filtering
  • Keyword Filtering

If you have not created a job yet, now would be an excellent time to.

To create your first job, on the main menu within the FSSP client, select the jobs option and then create job, which will bring up a small WinForms dialog. This dialog will allow you to create a new job based on whatever task criteria that you currently need within your environment, with you want to update a scan engine, grab a log o violation incidents, perform a manual scan, and several other important options. These created jobs are run similar to the services.msc snap-in, in the initial grid that was unpopulated previously when invoking the ForeFront For SharePoint Manager client you will find your created job which you can simply start by using the start green button.

In the job creation menu, there is one confusing item. The product file located above the task field might make you think that there are multiple products that you can work with, however this selection should only be used for uninstalling and installing jobs. The option options outside of the task dropdown that you will see are the add and remove buttons used within this dialog to be certain that the jobs you are concerned about are the only job files being deployed are those which you have selected, the schedule which will allow you tag a schedule flag to your selected job, and the options menu which has general faculities for working with your selected jobs. Most of the options that you will see are specific to the task that are being run, however there are some options that are common between all jobs, such as the authentication you want to use when running the job.

Once you have your job selections as you want them, the job files have to be deployed to appropriate server. In the following dialog, you will have the option to select a server for which the jobs will run, simply select the server under the Available servers, and move the appropriate servers to the left hand side dialog so that the job files are deployed to the appropriate machines.

Now you should be able to tag your deployed job files to your Manual Scan instance. You can either run that job now, and reuse that job as much as you would like in the future with other scan instances as the need arises.

Real-time Forefront for SharePoint Scan Job

The last type of job within the Forefront for SharePoint framework is a real-time scan job, which is arguably the most important type since it allows real-time scanning into documents that are loaded into the Forefront for SharePoint framework at runtime. Whenever a document is uploaded or downloaded from a Forefront for SharePoint protected document library, it has the ability to go through a scanning process that is tripped. This is the most needed scanning configuration needed within a SharePoint environment since it allows the user the option to be protected as files are transferred between various parties, therefore a file is not arbitrarily scanned by some scheduled or manually tripped scan job but rather is constantly checked and cleared for malware as it works its way through your communications and collaborations environment.

This is important because Forefront for SharePoint’s purpose is to protect the data that lives within a SharePoint repository, not the data as it exists within your client machine. The purpose of SharePoint is to build virtual teams built out of various groups of information workers, and keeping critical business data within an accessible and richly featured collaborations environment, Forefront for SharePoint is built to protect content repositories at this level. 

There are several important differences between a real time scan engine and the other scanning options already discussed. Since the service exists when certain criteria is trip (such as a download or upload of a document out of a SharePoint document library), there are certain thresholds that can be set which allow you to tailor your environment accordingly.

  • Some of the options that are available are:
  • Scan document on upload
  • Scan document on download
  • Allow users to download infected documents
  • Attempt to clean infected documents
  • Time out scanning settings
  • Scanner threading options
Share

Enhancing SharePoint With Forefront AV Vendors Aggregation (MEM) and a Proper Update Policy

Corporate antivirus SharePoint protection is only as good as your AV vendor builds and how well you assimilate updates to their arbitrary AV scanning engines. For that reason, Forefront for SharePoint has built in mechanisms that will allow you to aggregate and incorporate AV vendors various scan engines into one cohesive unit protecting your SharePoint content repositories in a method that conforms to your enterprise antivirus policy. This is one of the most important features of Forefront for SharePoint, since you don’t have to buy sister software platforms, can use your current AV software platforms, and purchase additional AV software as your metrics determine out of the Forefront for SharePoint reporting modules.

Default Forefront for SharePoint Engines to Use With SharePoint

If you have other engines that you wish to implement with Forefront Security for SharePoint, all licensed engines can be assimilated into your Forefront Security for SharePoint framework using the scanner updates option. Forefront for SharePoint is somewhat indifferent to the engines you wish to implement, therefore arbitrary engine implementation is one of the greatest features that Forefront For SharePoint promotes.

Updating Arbitrary Forefront for SharePoint Scan Engines

The option of executing updates on assorted Forefront for SharePoint digested AV scan engines with miscellaneous vendors is a rather straightforward process, and is completed through the Settings menu in the FSSP client (the first pane when launching the FSSP client, see other article for options of working with the FSSP client application), which will allow you to attach to your appropriate server and show the handle and arbitrary updating agenda, depending on your current configuration. If you desire to update manually through this interface, that option is also available, using the update now feature which will allow you to trip an instantaneous update of your elected AV scanning engine. The relevant engines are updated by means of a component within Forefront for SharePoint called the Forefront for SharePoint Updater Server (AntEngUp), which will facilitate the updating processes for the relevant scan engines and pertinent AV signature files.

For each of the AV scanning engines within your SharePoint environment, simply select the server that you require to configure for updates. In the bottom portion, a slight details pane will populate presenting your:

  • Engine Version
  • Signature Version
  • Update Version
  • Last Checked
  • Last Updated

This should tell you all the relevant information regarding the current status of the arbitrary scanning instance, which should allow you to make intelligent decisions about your scanning engine update policy. To bring up to date a relevant AV scan engine on a schedule or for an update now option, there has to be a particular path for the Forefront for SharePoint service to seize the AV update file from, which can be from the FSSP FTP or HTTP site, or if you have a central SharePoint server that captures relevant updates to populate throughout your SharePoint environment (typically still through the Sybari FTP or HTTP site), you can enter that information into the update path. This is fairly normal, moreover recommended, since it means that only one of your front end web servers running SharePoint has to query outside of your network while the other remain unaffected.

Using a Proxy With Forefront for SharePoint

If you use a proxy within your network to gain external access, you can use the proxy setting dialog, invoked through the Use Proxy Server checkbox, which will allow you to specify the:

  • IP
  • Port
  • Username
  • Password 

settings of your proxy server so that you can successfully receive updates with your network arbitrary proxy configuration.

Using the Remaining Forefront for SharePoint Dialog Options

The rest of the options within this dialog are pretty straightforward to tailor an AV scanning engine Forefront for SharePoint update policy. You can use the data option to set the check for updates, the time for the update, the frequency of the update, the repeat option to select a schedule repetition of update checks, enabling updates for your arbitrary scan engine, and setting up multiple servers to assimilate updates. It is also best to choose the option to perform updates when the Forefront for SharePoint service starts, so that whenever your AV services begin they have the most relevant scan engines. Your SharePoint antivirus policy is only as good as your scan engines, having an antivirus solution in place without having a policy by which to update those engines doesn’t offer adequate protection for your SharePoint environment. However, the way that you schedule the updates should be based on your corporate Antivirus policy, so should be able to conform to your standards in an adaptive environment.

There will be a small lapse from what you initially get a new update within the Forefront for SharePoint framework while the new files are adapted to your environment. You current scan jobs will temporarily suspend themselves while they assimilate the newly gained data.

Share

Using the FSSP for SharePoint WebParts

Using the FSSP for SharePoint WebParts

One of the most significant pieces of functionality that can be implemented within a corporate antivirus policy is the display and archiving of virus infected notifications, their origin, and how those files are handled within a communications and collaborations environment. Within the FSSP framework, these events are called event notifications or events, basically anything which trips a routine which has to intervene and handle. These types of routed messages are probably already defined within your corporate Antivirus policy as to how to handle and route the messages, therefore it is advised to configure FSSP to handle them accordingly. Collaboration environments are especially prone to virus infections since they are the result of numerous parties putting efforts into a singular entity, the data is tossed back and forth very frequently, and therefore is more prone to malware infestation.

For a network and SharePoint administrator, these notifications are exceptionally critical, for both real time protection patching and quarterly auditing reports (these reports are necessary for a company to make any decision as to how to handle AV software implementations and upgrades). The advantage of using is there is a built-in functionality to expose these events to an arbitrary administrator in a convenient method using your SharePoint portal or through well-planned email routing (which is in turn quite flexible), which can either then be brought up through an Outlook client or by using the Outlook Web Access WebParts on your administrative SharePoint My Site.

Implementing the FSSP WebParts

Implementing the FSSP SharePoint WebParts is a very quick and easy task; it is exactly the same as adding any other custom WebPart to you’re a WebPart page that you expose through your virtual server WebPart gallery. When FSSP installed, it should have dropped the appropriate WebPart assembly files into the bin directory, and made the relevant safe controls entry into the SharePoint WebPart config so that the WebParts may run appropriately. The .dwp files should have already been placed into your web part gallery, so there is no importation necessary in order to run the WebParts. The two WebParts that are packaged with the FSSP installation are:

  • Summary
  • Detailed Notifications 

(you can expose other FSSP functionality through additional programmatic efforts, or by implementing the FSSP ActiveX control on an arbitrary SharePoint page using Microsoft Office Frontpage or Microsoft Office SharePoint Designer 2007)

Firstly, switch your page to the WebPart addition page by selecting modify shared page in your WSS or SharePoint site. Once you have this open, invoke the virtual server WebPart gallery by making the appropriate selection in the WebPart gallery task pane. Under this selection, you should see the above two WebParts. Simply drag the WebPart onto your page and the notifications installation should be complete. Besides the notifications being sent to these alert type WebParts, they can also be routed to any number of email addresses of your choosing. If you are a document heavy company relying greatly on SharePoint content repositories, it is advised that you created a virusdetected@yourcompany.com address, since one hit of malware within your environment can cause a considerable quantity of messages if it propagates to numerous locations.

Using the FSSP Notifications

There are default notifications that are set, however in FSSP there are a sundry amount configurations that are accessible and configurable depending on what your corporate antivirus policy mandates. In order to shape FSSP notification options, you must launch the FSSP client and invoke the Reports task pane. There are several other options that are available under the reports task pane as well, outside of FSSP notification management and implementation. You can query into metrics involving incident management and reports so that you can build reportable metrics accounts for quarterly or monthly audit reports. You can also build reports related to malware currently housed within your quarantine, which is helpful to dig into what viruses may be affecting you in the majority of caught instance. There are several options available from this FSSP notifications dialog, however drilling down into the Notification portion allows us to tackle the specific configuration options relating to notifications and how these notifications are sent to both the administrator and to the SharePoint WebParts.

Configuring FSSP Notifications to Your Environment

Once the FSSP notifications dialog appears, you will see the names of all notification roles and whether they are enabled or disabled. From this dialog, you can see the split between the web and email notifications, which will allow you granular management of those events which are crucial to normal business operations so can be routed through email, and those which mandate just review through a web interface. The web notifications are obviously those which are sent to the SharePoint interface through the FSSP SharePoint WebParts described above.

Enabling and disabling notifications is as simple as clicking a buttons (the green go arrow and the red stop square), the same for configuring a certain notification if you would like to tailor how what information the notification displays and who the specific notification is sent to. When you select a certain notification, it will show the relevant information in the task pane below. This is also the configuration screen, where you can insert FSSP macros, sort of similar to threading tags in the SharePoint page that are replaced at runtime with relevant information regarding the specific incident. There are quite a few that you can leverage to make rather detailed messages, making it fairly simple to conform to your corporate antivirus policy.

An important part of customizing these messages is to use the substitution macros that are included with the FSSP framework. There are variety of these substitutions macros that are available for your to configure with your notification system:

  • %% – includes the % in the relevant files
  • %Company% – Name of AV vendor that picked up the infected file
  • %File% – Name of the infected file
  • %Filter% – Name of filter that detected infected file
  • %Folder% – Where the virus was found
  • %ScanJob% – Name of Scanjob that performed the routines
  • %Server% – Name of FSSP server that detected infected file  %State% – Was the file detected, skipped, or cleaned
  • %Virus% – Name of virus that infected the arbitrary file
  • %Virus Engines% – Relevant engine that detected the infected file

Once you implement a substitution macro(s) within your custom notification event, you will begin to get relevant information with your routed event information with even more detailed data regarding infected files within your SharePoint environment. You can archive these messages if you need to maintain a log for quarterly audits or if that activity is relevant to your corporate antivirus policy. These are powerful mechanisms if you need more relevant detailed information about your SharePoint environment threat levels. This can offer you immense insight into what engines are offering benefits, and those which are not having much beneficial impact and therefore should be disposed of.

Share