Forefront Endpoint Security 2010 (FEP) Release Candidate was just released. In this post, we will discuss ways for administrators to monitor FEP. There are several monitoring features provided with FEP2010 - this is the first in a series of posts about these monitoring features.

One of the key architecture changes from FCS is FEP’s alignment with System Center Configuration Manager. Configuration Manager provides the platform for client distribution and policy settings, as well as data collection to and from clients.

The FEP Dashboard is an extension to the Configuration Manager console. After deploying the FEP console extension to Configuration Manager (either on the server or on administrator’s laptop), a new node appears in the navigation tree called “Forefront Endpoint Protection” (see Figure 1).

Goals:

• Provide a single pane of information to an administrator who needs to know how FEP is doing, as well as a starting point for drill down into FEP features and troubleshooting.
• Serves as a Launchpad for the administrator to drill down to troubleshooting or other day to day tasks.

Figure 1 - FEP Dashboard

Capabilities of the FEP dashboard (see the labeled figure above):

1. Computers targeted by FEP: Unlike other security suites, FEP does not require a new discovery mechanism for computers in the organization. Instead, it queries the Configuration Manager database for workstations, laptops and servers (dropping mobile devices). Once discovered, the administrator may decide to protect the clients by creating a software distribution advertisement for collections containing all the clients.
   • Tip: Administrators can open the FEP collections and drill down to the “Deployment\Not Targeted” collection to identify those computers that are going to be unprotected without manual intervention (e.g. creating an advertisement).
   • Tip: The only way to capture administrator’s intention is to have the FEP related advertisement to active (never expire). Make sure you have this checked when creating your own.
2. Deployment status: Once an administrator starts to deploy FEP on clients, the clients are moved from the “not targeted” collection to one of the following deployment states:
   • Locally Removed - Computers where the FEP client was locally removed either by a user with local administrator permission or by another software (e.g. malware).
   • Failed - Computers for which the FEP client setup program reported a failure.
   • Pending – Computers for which an active Configuration Manager software distribution advertisement is trying to install the FEP client.
   • Out of date – Computers for which the reported FEP version is older than the one installed at the server.
   • Deployed – Computers with FEP client deployed.
3. Health status: For those computers either in “deployed” or “out of date” state, the FEP dashboard provides additional health information:
   • Protection inactive – The FEP service is reported to be turned off.
   • Not responding – Computers which have not reported for the last 14 days.
   • Healthy – Neither of the above.
4. Malware activity status: Shows computers with malware activity. FEP surfaces computers with the following infection states:
   • Infected – Computers where FEP could not fully mitigate a malware instance.
   • Restart\Full scan required – Computers where FEP mitigated a malware incident but requires additional action in order to complete the mitigation.
   • Recent activity – Computers where malware was detected and successfully mitigated (within the last 24 hours).
5. Definition status: Enables administrators to drill down into computers which failed to update their FEP definitions.
6. Policy distribution: Enables administrators to drill down into computers where Configuration Manager failed to distribute FEP policy.
7. FEP baselines: Presents administrators with a quick compliance view into the FEP baselines.
   • Tip: Administrators may create their own DCM baselines and use FEP Configuration Items (CIs). In order to add (or remove) baselines to the FEP dashboard, a “FEP” category should be added (or removed) to the baseline.
   • Note: The FEP dashboard is built on top of Configuration Manager collections. Each of the hyperlinks in the FEP dashboard leads to a collection which holds the actual computers sharing the same symptom.

Ziv Rafalovich,
Senior Program Manager

Hello Administrators,

Today we announce Microsoft Forefront Endpoint Protection (FEP) 2010 release candidate (RC) to the public. For us, the FEP team, it is an exciting date which takes us closer to the Release to Manufacture date. For every product team in MS the RTM date marks the ends of a very long path of product development. Please, go ahead and download the release candidate. We are looking for your feedback!

The release candidate has several improvements over the beta we release in July.    In this blog post and the several posts that would be published in the next few days, we will describe these improvements in detail.  

One of the exciting new features in FEP is FEP support for the data center. We are proud to introduce 3 new features: (i) a set of predefined policies for common server workloads (ii) FEP Security Management Pack, and (ii) group policy support for the FEP client.

FEP 2010 Predefined Security Policies

One of the major pains we heard from administrators over the years is the difficulty of configuring servers such that they are both secured and highly available. To address this pain, FEP 2010 includes a set of pre-defined security policies for 15 server workloads. For each workload, the policy contains unique settings customized for the workload. For example, the predefined policy for SQL Server contains a list of SQL processes that should be excluded from real time protection, otherwise SQL performance could be significantly degraded. 

The predefined policies are built based on the knowledge of security experts across Microsoft and performance experts from the various workload teams. For example, the SQL pre-defined policy was reviewed by the SQL team, and even run on the SQL performance lab to ensure that the recommended policy does not impose significant performance overhead. Using these predefined policies, administrators can easily deploy endpoint security to the organization’s servers, using the FEP console within the Configuration Manager console (Figure 1). Please, go ahead and deploy the policies and send us suggestions for improvement (via the FEP forum).

Figure 1: The FEP New Policy Wizard. The administrator can easily choose a pre-defined policy for more than 15 server workloads.

FEP 2010 Security Management Pack

Many server administrators told us that their preferred monitoring tool is System Center Operations Manager. Hence, the FEP 2010 RC also includes the FEP 2010 Security Management Pack. This is standard management pack that can be imported to Operations Manager 2007 R2 and to be used for real time monitoring, alerting, and remediation of security incidents generated by the FEP client.   

The FEP 2010 Security Management Pack serves two goals. First, organizations that use Operations Manager to monitor servers can now use their preferred tool also for security monitoring. Second, for organizations that require guaranteed real time monitoring for their critical systems, like servers, the management  pack uses Operations Manager real-time capabilities to ensure real-time reporting.   

Besides real-time monitoring and alerting, the FEP 2010 Security Management Pack includes a cool reporting feature. If you install Operations Manager Reporting Services, you can install also the FEP 2010 Security Reporting MP (included with the FEP Security Management Pack download). Once installed, you can use Excel to connect to the Operations Manager DB and generate your own custom reports. Really cool, try it ('fep2010 security mp.msi' on the download page) !

FEP 2010 Group Policy Support

From the early days of Forefront Client Security, we’ve heard  customers asking to manage endpoint protection using Group Policy. In FEP 2010 RC, we enable this feature.

The FEP 2010 RC provides the following support for group policy management

• We provide an ADMX file that enables administrators to control the FEP client settings using Group Policy. The ADMX file provides granular control of over 100 FEP 2010 client settings and is intended to be used on computers that either do not have the Configuration Manager client installed or require granular settings that are not available using the Configuration Manager policy mechanism.
• The Forefront Endpoint Protection 2010 Group Policy tool enables administrators to translate FEP policies into Group Policy. This means that administrators can define a policy using FEP 2010 console, export it to an XML file using the FEP console, use the Group Policy tool (Figure 2) to translate it into a Group Policy object, (keeping the policy semantics), and then distribute the policy using the Group Policy mechanism. We will continue to discuss the Group Policy tool, in one of our future posts.  

Figure 2: The Forefront Endpoint Protection 2010 Group Policy tool enables administrators to translate FEP policies to group policies.

So, it is time for you to try the FEP RC version, and it is time for us to get back to work and to release the RTM version.

Shai Rubin

Senior Program Manager

In the previous posts, we’ve described the FEP monitoring experience using FEP dashboard, reports and alerts. However, daily security routines often include some more “advanced” scenarios of security investigation.

When looking at malware activity, an administrator may want to consume the raw data from FEP and look at it from different angles. For example, administrators might like to get answers to the following questions:

• Show me “active” malware types in the organization.
  • In this case, “active” might be a malware which was detected in the last day, week or month.
• Show me “new” malware types in the organization.
  • In this case, “new” refers to a malware type which was detected in the organization for the first time in the last day, week or month.
• Filter out malware according to severity, category or even action taken.
• Group detections per computer, user or even process.

In order to support such scenarios, we’ve added a new database view which holds all malware activity detected by FEP. This view can be queried by external tools such as SIEM (Security Information and Event Management) products for longer-term retention, correlation or reporting.

For those administrators who need immediate access to FEP data, we’ve brought the FEP database view together with the Microsoft Excel pivot table feature. With FEP, we are providing an Excel file (FEP-S Reports Sample.xlsx) which can be used to support the scenarios just mentioned. You can download it with the FEP Security Management Pack download (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab50ace0-1f68-453a-85bb-61de286ec4c8)

Note: The Excel file was tested using Office 2010. In order to use it you need to have read access to the FEP historical database (or at least to the vwFEP_AM_NormalizedDetectionHistory database view).

In the FEP-S Reports Sample.xlsx workbook, the FEP Detection Log worksheet provides a table of all FEP detections. You may filter, search or sort by any of the provided columns.

Tip: Throughout the spreadsheet, we use a red icon in order to highlight events that have happened in the last 24 hours, and a yellow icon for those events that have happened in the last 7 days.

The FEP Malware Log worksheet provides a pivot view of malware activity per malware type.

Ziv Rafalovich,
Senior Program Manager

Hello!

If you're attending TechEd Europe 2010, And you want to learn more about Forefront Endpoint Protection 2010 and the Forefront Endpoint Protection Security Management Pack, we have a set of sessions you might like to attend:

• SIA03-HOL - Forefront Endpoint Protection (FEP) 2010 Overview
• SIA301-LNC - Forefront Endpoint Protection 2010 Overview
• SIA304-IS - Forefront Endpoint Protection 2010-Security Management Pack: Enabling Real Time Monitoring and Optimized Policies for Servers
• SIA308 - Advanced Threat Detection and Removal with Forefront Endpoint Protection 2010

Session times and rooms can be found in your schedule. Attend and find out about the latest in Forefront Endpoint Protection!

Thanks!

FEP Overview

FEP 2010 is implemented as both an extension to System Center Configuration Manager and as a management pack for System Center Operations Manager, which provide enterprise management experience, and a common client (agent) that provides protection on managed machines. That means that if you have System Center Configuration Manager, or System Center Operations Manager installed, then all you have to do is to install the extensions for Configuration Manager, or import the FEP 2010 Security MP into your existing Operations Manager infrastructure in order to add Endpoint Protection functionality.

FEP 2010 has two major System Center components - an add-on for System Center Configuration Manager 2007 (“ConfigMgr”), and one for System Center Operations Manager 2007 (“OpsMgr”). Each FEP component leverages the unique capabilities of the associated management product. Due to differences in the capabilities of ConfigMgr and OpsMgr, each FEP component delivers different functionality.

The FEP extension for ConfigMgr provides deployment, monitoring, reporting, and policy management functionality for FEP, from directly within the ConfigMgr console. The OpsMgr MP provides monitoring and alerting from within the OpsMgr console.

FEP Policy Overview

FEP gives you a choice of two ways to manage policy. First, if you have ConfigMgr deployed and the FEP 2010 product installed, then you can use the FEP node in the ConfigMgr console to author policies. ConfigMgr (via its Software Distribution feature) will deploy the policies for you to the monitored FEP agents. However, if you prefer, or if you do not have ConfigMgr deployed (such as when you are only using the OpsMgr MP), you can use Group Policy to author and distribute policy.

The following chart will help you decide between using ConfigMgr or Group Policy for policy management.

If you ultimately choose to manage policy with ConfigMgr, then you will find that the experience is very straightforward. New policies you create are all based off of a template- you choose a group of settings organized by goal, e.g. “protect domain controllers” or “minimize performance impact to desktops”, etc., and the new policy will contain settings optimized for that goal. You can edit the settings as you wish, and to deploy the policy, simply bind it to a ConfigMgr collection. Only one policy will be in effect for any collection at any given time.

The remainder of this article will describe the experience of using group policy to manage FEP policy.

Managing FEP Policy with group policy

FEP contains a set of tools for helping to manage FEP policy with group policy. These tools include:

1. ADMX and ADML files to enable authoring and editing FEP specific policy settings with group policy
2. FEP2010GPTool.exe, a tool which allows you to import settings from a FEP policy file into a GPO, or export FEP settings from a GPO into a FEP policy file
3. Setting templates (in the form of FEP policy files) for common server roles such as domain controller, SQL server, etc.

At the simplest level, all you need to do to manage FEP policy with group policy is to install the ADMX into your admin tools workstation, create and link a GPO, and edit the FEP policy settings in the GPO, using Group Policy Editor.

However, there are some more advanced scenarios that you might want to think about.

Scenario 1 – Optimizing FEP policy for multiple server roles

In this scenario, let’s assume that you want to deploy optimized settings to your servers. For instance, let’s say that you want domain controllers to get a policy that will cause the least performance impact on the domain controller role, and you want Exchange servers to get a policy that will minimize performance impact on Exchange, etc. Let’s further assume that some of your servers might host more than one role.

There are two ways to go about doing this, and how you choose to do this completely depends on how you prefer to do policy targeting in group policy.

1.1 You prefer to target policies with OU’s or security groups

If you strongly organize your machines into OUs or security groups, then you might just want to create one policy per role and link it to the appropriate OU, or use security filtering in group policy management console (GPMC) to restrict the policy only to the target group. This essentially allows you to specify the target machines individually.

In this case, all you need to do is to create a GPO, link (and filter, if applicable) it appropriately, and then use the FEP group policy tool to import the correct role-specific settings into that GPO.

Here’s a hint- if you have a set of servers that have multiple roles, then you can use the FEP GP tool to import each of the policies into the same GPO. Import the policies in order from lowest precedence to highest precedence, and make sure that you only have the “clear existing FEP settings before import” checkbox checked when you import the first policy. For example, if you have machines that are combination DC + DNS + DHCP servers, then import the following four policies: FEP Default Server policy, FEP DHCP Server policy, FEP DNS Server policy, FEP Domain Controller policy. The “clear settings” box should only be checked when you import the default policy. This will import and merge all the settings into a single GPO.

1.2 You prefer to target policies using WMI filters

If you prefer a more dynamic targeting approach, then you can have group policy layer your policies for you. In this case, you simply create one GPO for the FEP default server policy, and one GPO for each server role. Set the default server policy at lowest precedence. Link all the policies to the domain, and use WMI filtering on each of the policies. For instance, you can restrict the default server policy to servers only by filtering on the ProductType property in the WMI Win32_OperatingSystem class: http://msdn.microsoft.com/en-us/library/aa394239(VS.85).aspx. ProductType is also useful for identifying and filtering domain controllers.

For other roles on Windows Server 2008 and Windows Server 2008 R2, you can use the properties in the Win32_ServerFeature class to identify and filter by role: http://msdn.microsoft.com/en-us/library/cc280268(VS.85).aspx. This works well for built-in roles like IIS and File Server.

For Windows Server 2003 machines, and for roles that aren’t part of Windows, you can use the Win32_Service class to look for services that indicate role presence, e.g. the MSSQLSERVER service identifies SQL machines.

After you have created a WMI filter for each policy and linked your policy to the domain, then group policy will automatically deploy the appropriate settings to each computer. It’s important to ensure that you use GPMC to prioritize the policies correctly so that defaults or lower priority role settings don’t overwrite higher priority role settings.

Scenario 2 – Deploying an identical policy to non-domain-joined computers

This is a very easy scenario. Once you have authored a policy using GPEDIT, if you are happy with the settings and want to deploy the same settings to non-domain-joined servers, then you can use the FEP group policy tool to export the settings you like to a FEP policy XML file, and then you can script the application of that policy.

The export process varies slightly depending on how you handle multiple roles.

If you merge your roles together into single GPOs (as in scenario 1.1 above), then you can simply use the FEP group policy tool to export FEP settings from that GPO.

If you use policy layering (as in scenario 1.2 above), then you should identify a domain joined server with the same set of roles, which has already had your policies applied, and use the FEP GP tool to export the settings from the local group policy object on that server.

There are two ways to apply FEP policy with script. First, you can provide the path to the policy file as a parameter during installation of the agent MSI package. Second, you can use the ConfigSecurityPolicy.exe tool to apply a FEP policy at any point. These topics are covered in the FEP documentation.

Scenario 3 – Duplicating policies between domains

This scenario is also very easy. Simply create GPOs on the “target” domain matching those on the “source” domain, and ensure that they are linked and/or WMI filtered correctly. Then use the FEP group policy tool to export the settings from each GPO in the source domain, and use the tool again to import the appropriate settings into the correct GPO on the target domain.

Eric Fitzgerald,
Senior Program Manager