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
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:
Malware was detected on a computer. This alert is triggered based on mitigation.
Navigate to FEP computer details report to identify the malware(s) detected on the computer.
A malware is spreading across the organization. This alert is triggered based on number of detections.
Number of computers detected with the same malware in 24 hours.
Navigate to FEP malware detail report to learn more about the malware and see the list of infected computers.
Repeated Malware Detection
A computer is being repeatedly infected by the same malware. This alert is triggered based on number of repeated detections.
Navigate to FEP computer details report to learn more about the computer as well as the malware
Multiple Malware Detection
A computer is being infected with multiple malware types. This alert is triggered based on number of malware detections on a single computer.
Navigate to FEP computer details report to learn more about the computer as well as the malware types
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).
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
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
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
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