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

In previous posts, I’ve described the monitoring experience in Forefront Endpoint Protection 2010 (FEP) Release Candidate. Those descriptions includes the FEP dashboard as well as built-in reports. In real life, however, no one expects an administrator to stare at the dashboard and wait for something to happen. Instead, administrators expect to get notified when security incidents are detected.

FEP security alerts are used to detect incidents about which administrators want to get notified. When designing FEP alerts, we’ve used the following guidelines:

1. Important – Administrators should be actively notified on FEP alerts (by email notification).
2. Actionable – There should be a recommended action associated with each alert.
3. Timely – Administrators should be notified on security incidents in a timely manner.
4. Manageable – Enable administrators to control the number of alerts issued per day.
5. Correct – Avoid false positives by providing threshold based alerts

The following alert types are provided with FEP 2010:

Tip: In addition to email notifications, FEP alerts are kept as event log entries in the FEP server as well as in the FEP DB. These event logs are useful when alert forwarding is required (e.g. Operations Manager, SNMP).

Ziv Rafalovich,
Senior Program Manager

In an earlier post we mentioned the integration of FEP with Configuration Manager and described the FEP dashboard, which is an extension to the Configuration Manager console. Another aspect of this integration is the FEP troubleshooting reports, which make usage of Configuration Manager reporting framework.

To begin with, each operation going from the server to FEP clients (or vice versa) is performed by Configuration Manager. It is only natural that troubleshooting should use the information kept in the Configuration Manager database and surface that to administrators trying to troubleshoot FEP operations.

Two main tasks performed by administrators are client roll out (deployment) and policy distribution. These two tasks use the Configuration Manager software distribution capabilities (a SW package being advertised to a collection).

FEP provides two troubleshooting scenarios, which can be found at the bottom of the FEP dashboard.

Figure 1 - Links to FEP troubleshooting reports

• Deployment Overview: Identify deployment success ratio, which FEP client versions are found in the org, as well as errors reported while trying to roll out FEP to clients.
• Policy Distribution Overview: Identify distribution success ratio, which policies are actually applied on clients, as well as errors reported while trying to apply policies.

The third link brings administrators to a single report where all of the Configuration Manager related activity is presented (including network data) for a single computer. This is useful when administrator is trying to work out a problem on a specific computer.

Deployment Overview report

After opening the deployment overview report, an administrator immediately sees the deployment status for each collection in his Configuration Manager deployment. This is extremely useful since the FEP dashboard is not filtered by collections.

Next, the administrator can select a collection and drill down to see more deployment details.

Note: Like any Configuration Manager report, an administrator may click the icon on the left () to drill down for more.

Tip: In order to generate a report for the entire organization, simply select the “all systems” collection

Figure 2 - FEP Deployment overview

After the report has been filtered by collection, the administrator is presented with breakdown of FEP versions found, as well as deployment states and failures.

Having computers grouped by their deployment state (or failure) enables an administrator to troubleshoot a single computer and apply the fix to all computers facing the same symptom.

Figure 3 - FEP Deployment for a specific collection

Finally, the administrator can drill down to a specific computer and see FEP related data such as deployment activities, policy distribution and network related data.

Figure 4 - Computer details report

Policy Distribution Overview

Since policy distribution is similar to client roll out (both use the Configuration Manager software distribution capabilities), troubleshooting follows the same concepts and uses similar reports.

Figure 5 - FEP Policy Distribution Overview

Ziv Rafalovich,
Senior Program Manager

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

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