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).
Figure 1 - FEP Dashboard
Capabilities of the FEP dashboard (see the labeled figure above):
Ziv Rafalovich, Senior Program Manager
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.
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.
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) !
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
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.
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:
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
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:
Session times and rooms can be found in your schedule. Attend and find out about the latest in Forefront Endpoint Protection!
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 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.
You should consider managing FEP policy with ConfigMgr if…
You should consider managing FEP policy with Group Policy if…
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.
FEP contains a set of tools for helping to manage FEP policy with group policy. These tools include:
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.
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.
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.
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.
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.
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