Forefront Client Security Team Blog

Hello FCS experts – and you know who you are. You are the ones who have figured out the tips and tricks for using FCS, and have found the most interesting and relevant TechNet information about FCS. The TechNet team wants to make it easier for experts like you to share their favorite TechNet articles and links, so they’ve release their v1 of social bookmarking.

And you can use it to share your best or favorite links on TechNet or MSDN with others.

Available in two flavors – TechNet (social.technet.microsoft.com) and MSDN (social.msdn.microsoft.com). Chris Slemp has a bunch of info on how to use this great new tool on his blog (http://blogs.msdn.com/cslemp/archive/2008/09/09/launched-social-bookmarking-v1-on-msdn-and-technet-video.aspx).

A tip: use the tags! It makes the relevant content easier to for others to find based on category…

Enjoy!

Today we are pleased to announce the availability of Forefront Client Security Service Pack 1 (SP1).

FCS SP1 adds support for:

Agent protection on Windows Server 2008 – both Server and Core.

Server role support on Windows Server 2008 (server only) for FCS server components.

FCS Enterprise Manager on Windows Server 2008 (server only).

To obtain FCS SP1, first install FCS. After successfully installing FCS, you will be offered SP1 via Microsoft Update. For more information, read the FCS SP1 Release Notes (http://go.microsoft.com/fwlink/?LinkID=126287) or see Microsoft Knowledge Base article 951951 (http://support.microsoft.com/default.aspx/kb/951951)

Did you know that Microsoft has an open source hosting website? Codeplex (www.codeplex.com) is a Microsoft website that hosts customer-driven projects, and allows customer collaboration on these projects.

The cool thing about Codeplex is that it allows YOU, our customers, to share your FCS solutions. There’s a section for Forefront Client Security tools – you can reach it by entering Forefront in the search text box in the upper right of the Codeplex homepage, or go straight there by navigating to http://www.codeplex.com/fcscompete. The full list of available customer-driven tools is on the Releases tab, in the Releases list box on the right hand side.

Yaniv Feldman has posted a solution for updating FCS definitions using MOM 2005 tasks (http://www.codeplex.com/fcscompete/Release/ProjectReleases.aspx?ReleaseId=14225). You can read more about the tool and how to use it on Yaniv’s blog:  http://blogs.microsoft.co.il/blogs/yanivf/archive/2008/06/09/forefront-client-security-remote-definitions-update-using-mom-tasks.aspx.

Johan Blom has also contributed a tool to the FCS Codeplex collection. Johan’s contribution sets scan exclusions for Exchange 2007 servers, making it easier to use FCS to protect your Exchange server. Johan’s project can be accessed on Codeplex here: http://www.codeplex.com/fcscompete/Release/ProjectReleases.aspx?ReleaseId=14026. You can read more about the tool and how to use it on Johan’s blog at http://www.msforefront.com/, and looking for the title “Scanning exclusions when running FCS on Exchange 2007 made easy”.

Hello,

The Forefront and System Center teams recognize the importance of enabling customers to take advantage of both Forefront Client Security (FCS) and System Center Configuration Manager (SCCM) in their environments today.  This is a request that we have received from the Microsoft field and customers around the world.

FCS and SCCM both rely on Windows Server Update Services (WSUS) as a key part of the overall Microsoft architecture.  FCS is optimized for automatic signature distribution via WSUS.   SCCM also uses the WSUS server role for key software distribution scenarios.  This allows each product to do their own jobs effectively, and helps customers limit the infrastructure it may require for both solutions.  Questions have arisen around support for the coexistence of FCS and SCCM in an enterprise, while still leveraging the same WSUS server role.   There have been additional questions and feature requests regarding the automated deployment of FCS signature files through the SCCM console, using the SCCM client relationship. 

We are in the process of writing a Knowledge Base article which will clarify the scenarios that are supported when using Forefront Client Security and System Center Configuration Manager.  At the same time, we are updating the documents which were posted on Codeplex to provide guidance on what customers should do when configuring their environments under the supported scenarios included in the KB article.  We are targeting the release of the KB article and prescriptive guidance by the end of August. 

We really appreciate your patience while we put together the necessary documentation.

Best regards,

Forefront and System Center Teams

For some more technical depth on the Solution Accelerators Forefront Integration Kit for Network Access Protection (NAP), I'd like to introduce Dan Griffin. The following blog post was written by him.

The purpose of this blog post is twofold. First, to briefly answer the following question: how does NAP (see the acronym reference at the bottom) implement sandboxing for non-compliant clients – in other words, how are unhealthy computers are kept separate from the healthy computers?

The second purpose is to answer this question: what does this have to do with the new Forefront/NAP integration kit from Solution Accelerators?

However, before I get to either point, or to the example in the next section, I need to provide some NAP guidance.

Namely, I’ve been asked to clarify that there are in fact five different enforcement methods supported by NAP: 802.1x, DHCP, IPsec, Terminal Server Gateway, and VPN. The example I’ll discuss is DHCP, but you should keep in mind that it suffers from some security shortcomings.

First, DHCP enforcement puts non-compliant client in a restricted network. However, that really only consists of a simple set of default routes, plus the lack of a default gateway. Thus, sophisticated users with administrative access may be able to bypass the restriction and route traffic into the compliant network.

Second, because of inherent limitations in the public DHCP standard, it doesn’t offer server authentication or message integrity. That is, someone with access to your LAN could maliciously modify DHCP traffic without the client or server being able to detect it.

Neither limitation exists in a NAP deployment over certificate-based IPsec, for example. The IPsec client and server are mutually authenticated and the network traffic is protected by encryption and cryptographic checksums.

However, for the purpose of learning about NAP, and for doing a proof-of-concept deployment in a lab, DHCP is tough to beat. It’s less complex to setup than the other scenarios and can thus be done more quickly. For instructions on doing so, see the step-by-step guide here.

That’s it for the introductory stuff – onward to the example.

FCS/NAP Architecture

Suppose, despite the caveats above, that the NAP enforcement scenario is DHCP. Client computers won't be given full access to the corporate network unless they are deemed compliant by NAP.

The first step is that the NAP agent on the client sends a Statement of Health (SoH) along with the request to the DHCP server. In the following diagram, the client could be either of the laptop-shaped images on the left-hand side. The server in this picture, at the bottom of the larger oval, is playing two roles: DHCP server as well as Network Policy Server, or NPS.

The DHCP server receives the DHCP request from the client, extracts the SoH, and relays it to the NPS to be evaluated. In this example, that's just a question of one service talking to another service on the same server.

If the SoH is considered to be compliant, then the DHCP server responds with an IP lease on the main, NAP-compliant, corporate network. If the SoH is not compliant, then the DHCP server grants the client an IP lease on the restricted, non-compliant, sandbox network.

So how does the new FCS/NAP solution play into this? It's a question of what information is included in the SoH, and how it's evaluated by the NPS. FCS/NAP consists of two plug-ins: a System Health Agent (SHA) for the client and a System Health Validator (SHV) for the server (NPS).

Data Flow

The client SHA adds Forefront-related information to the SoH to be evaluated by the SHV. Think of the SoH as a list of answers to preset questions. For example, one item is an answer to the question “Is the Forefront client currently running?” (That’s determined by the data path represented by arrow #2 in the following diagram.) Another is an answer to the question “Are the client’s virus signatures are up to date?” (See arrows #1 and #3.)

When the FCS/NAP SHV receives that SoH (arrow #5), it evaluates each of the answers against the health policy configured by the administrator. For example, if the answer to the question about whether Forefront is running is “No,” then the SHV checks whether the current policy indicates that Forefront must be running on healthy clients.

After evaluating each answer in the SoH in that way, there are two possible states the SHV can report to the NPS:

1.       The client is healthy/compliant, or

2.       The client is un-healthy/non-compliant.

 In the latter case, for each non-compliant policy item, the SHV provides a message to explain to the user the reason, or reasons, why the machine is non-compliant. For example, “The Forefront client isn’t running,” and “The virus signatures are out of date,” etc. These messages are visible via built-in tools such as napstat.exe and netsh.exe.

Additional Configuration Considerations

There are a few NAP configuration scenarios that aren’t distinguished by these diagrams.

The first is NAP in “reporting” mode. In reporting mode, NAP doesn’t actually quarantine non-compliant clients; it simply reports on their health. This is a good configuration for customers who are evaluating or piloting NAP. Reporting mode doesn’t affect the SHV; it still works as described above.

The second scenario is NAP in enforcement mode. Non-compliant clients get quarantined.

Regardless of whether NAP is doing enforcement, there’s also the option of auto-remediation. How does this affect how the SHV behaves?

Without auto-remediation enabled, the SHV again behaves as described above. That is, each aspect of non-compliance is addressed with a string explaining what’s wrong.

However, with auto-remediation enabled, the SHV must place different information into the SoH response when the client is non-compliant. The auto-remediation response information consists of two things:

1.       Different strings are used to distinguish between the scenarios in which the user is expected to take corrective action manually (“instructive”), versus the scenarios in which corrective action will be taken automatically by the SHA (“informative”). The latter is what auto-remediation is all about.

2.       The SoH response must also include programmatic instructions from the SHV to the SHA about what specific auto-remediation actions to take. For example, if one of the required Forefront services isn’t running, and policy requires that it must be running, then the SHV will set the bit in the SoH bitmask instructing the SHA to attempt to automatically start the service.

Acronym Reference

·         DHCP = Dynamic Host Configuration Protocol

·         FCS = Forefront Client Security

·         NAP = Network Access Protection

·         NPS = Network Policy Server (the NAP server)

·         SHA = System Health Agent (client-side NAP plug-in)

·         SHV = System Health Validator (server-side NAP plug-in)

·         SoH = Statement of Health (sent by the client)

More Information

For more information about FCS/NAP, please see:

·         My blog

·         The Solution Accelerators Security & Compliance blog

·         The Forefront blog

·         Forefront on TechNet

·         The NAP blog

·         NAP on TechNet

Bio

Dan Griffin is a software security consultant in Seattle, WA. He previously spent seven years at Microsoft on the Windows Security development team. Dan can be contacted at www.jwsecure.com.

Disclaimer

This posting is provided "AS IS" with no warranties, and confers no rights.

The Forefront Client Security team is pleased to announce the public availability of the Microsoft Forefront Integration Kit for Network Access Protection (NAP)!

NAP is a technology provided with Windows Server 2008, and works with Vista and Windows XP with Service Pack 3. With NAP, you can restrict network access based on the computer’s compliance with your corporate security policy. Computers out of compliance can be prevented from accessing the network until they have remediated the items out of compliance.

For more information about the Integration Kit, including features and customer stories, see the  Solution Accelerators blog (http://blogs.technet.com/secguide/default.aspx), and the Solution Accelerators TechNet site (http://technet.microsoft.com/en-us/library/cc512112.aspx). To download the Integration Kit, see the Microsoft Download center.

The FCS team is pleased to announce support for:

·     Agent protection of Windows Server 2008 – Server and Core.

·     NAP integration.

·     Hyper-V, upon its release.

·     Agent protection of cluster servers.

·     Agent protection of Home editions of Vista, XP Sp2 and XP Sp3.

·     Agent protection of Vista Sp1.

For more information, see the Forefront Team Blog (http://blogs.technet.com/forefront/).

We’ve seen a lot of questions from customers asking whether Client Security can be deployed and managed in an enterprise environment with tens of thousands of users. You can manage an enterprise deployment of more than 10,000 clients from a single Client Security console. 

Forefront Client Security Enterprise Manager provides administrators the ability to manage multiple Client Security deployments from a single server.

After you install Enterprise Manager you are able to centrally manage:

• Client Security policy deployment.
• Alerts from Client Security agents in the entire enterprise.
• Reports from all Client Security deployments in the Enterprise Manager organization.

Enterprise Manager aggregates data from each configured Client Security deployment in your organization.  This aggregated data allows you to centrally view reports on all your Client Security deployments.  Enterprise Manager also eases Client Security policy management among multiple Client Security deployments.

Hello everyone!!  With the successful release of Forefront Client Security v1, it’s time to focus our efforts on the next release!  The Forefront Technology Adoption Team (TAP) is excited to announce the launch of our new program. The next version of the Forefront Client Security product will be bigger and better than the previous version, and so will the TAP, but we can’t do it without your help.

This Microsoft Forefront Technology Adoption Program includes all products under the Forefront product line, not just the Forefront Client Security product. These products are:

·         Forefront Codename “Stirling” – (To learn more about “Stirling”, check out the “Stirling” site.)

·         Forefront Client Security (FCS)

·         Forefront Security for Exchange Server (FSE)

·         Forefront Security for SharePoint (FSSP)

·         Microsoft Internet Security and Acceleration Server (ISA) integration with “Stirling”

Based on your needs, you can utilize just Forefront Client Security or, if your organization uses multiple Forefront products, any combination of the above (we’d really like to find a bunch of customers that use at least two!)  The TAP program is a great opportunity for you and the Forefront product teams to collaborate and learn from each other. Your feedback is heard directly by the product team, helping you and us to improve the product. Feedback is taken in the form of general feedback, bugs reports, and Design Change Requests (DCRs). The program timeline is aggressive, starting November 27, 2007 and finishing in calendar year 2009.

To start your nomination for the Forefront TAP, please fill out the survey by:

1.                  Visiting the Microsoft Connect website

2.                  Signing into Connect with a Windows Live ID

3.                  Visiting the Available Connections page, and clicking “Apply” for the “Forefront TAP”

You will receive a response from Microsoft within 2 - 3 weeks.

If you have any questions regarding the program or the nomination process, please email csfanos@microsoft.com or Stirtap@microsoft.com.

Thanks

Chris

Forefront TAP PM

Forefront Client Security is an enterprise-level antimalware offering. As part of a total security solution, Client Security protects your client computers from malware threats in the enterprise. 

Threats don’t always come from the world outside your firewall.  Your users may be unknowingly bringing malware into the work environment by bringing in items as innocuous as pictures.  Enabling users to protect their home computers from malware threats could reduce the incidence of malware in your enterprise.

Customers who license the Client Security agent on a per-user basis can provide the Client Security agent to employees at no additional cost for protecting home computers.  These home-based Client Security agents must be deployed in an unmanaged configuration; they will not be able to report to your Client Security servers in your enterprise. 

Today we published another Security State Assessment (SSA) definition update on Microsoft Update!

Included in this release is a new check that will provide visibility into end-user configuration of the Windows Firewall. When used with Group Policy, this new functionality aids in firewall management.

The Windows Firewall check reports on:

·         Firewall status (on/off)

·         User-defined exceptions

·         Applicability to each network interface

Determining firewall status:

·         If Windows Firewall is disabled on any network interface, the score is “High”

·         If Windows Firewall is configured by Group Policy, the score is “Informational

Visibility into firewall exceptions:

·         Enumerates each port and application exception

·         Any exception not configured via Group Policy, the score is “Medium”

·         If configured by Group Policy, the score is “Informational”

Another update included in this release is a change to the Unapproved Updates check. In an earlier version, this check enumerated any updates that were available but not yet approved, to provide a complete view on overall vulnerability state. Based on customer feedback, we updated the check to report only on unapproved security updates with a Critical severity.

Please give your SSA summary report a look, and find out more about what these new checks are discovering in your organization!

-Adrienne

Program Manager, Forefront Client Security

While you’ve always had the ability to use MOM 2005 to monitor things like IIS and SQL for your Client Security servers, this management pack gives you the additional ability to monitor some key FCS services:

• Definition Import Failure
• Microsoft Client Security Update Assistant service—That’s the service that allows WSUS 2.0 to be configured to receive updates every hour rather than just once a day. For those of you running WSUS 2.0, you’ll be glad to have the ability to monitor this!
• Forefront Client Security Management service—This service is important because it parses antimalware definitions and adds the information to the collection database table fcs_Threat_Metadata_tbl. And that table is not only read by the management console when you set overrides based on threat, it’s also used by FCS reporting for information about specific threats.

I should clarify; the management pack is installed in your MOM 2005 environment to extend existing MOM functionality, not on your FCS servers.  

Of course, loading the management pack doesn’t impact how you’ll be monitoring your client computers. In other words, you won’t need to redeploy your implementation in order to add this additional monitoring functionality. You’ll continue to use the Client Security consoles you’re familiar with for your client monitoring. The Health Management pack is just for monitoring your FCS servers, not client computers. And just for environments that choose to implement a MOM 2005 monitoring solution. (notice, it’s a MOM 2005 management pack, not a SCOM  management pack, just in case you were wondering “Hey, will this work with SCOM?”)

The FCS management pack is ready for download at this location:  http://www.microsoft.com/downloads/details.aspx?FamilyID=0672b4ca-c6dc-4093-bae6-30eb1560a429&DisplayLang=en

Exciting news!  Forefront Client Security is a finalist for Info Security's 2008 Global Excellence in Anti-Malware Solution!  The Forefront family of products made finalist in four categories - two more than a certain other big security company.

You can read more about the Forefront Info Security 2008 Global Excellence finalists here.

Using WSUS is likely the easiest and most popular way to deploy the FCS client to computers.  As described in the deployment guide, after deploying FCS policy and approving the package Client Update for Microsoft Forefront Client Security (1.0.1703.0) on your WSUS 2.0 or 3.0 server, the FCS client is downloaded and installed on the machine according to your company’s Windows Update policy. 

The FCS package has the ability to detect the language of the machine contacting the WSUS server and install the same FCS language;  for example if you have a French Vista machine you will receive French FCS, or a Japanese Windows Server 2003 server you will receive Japanese FCS.  This works great for the languages that FCS was localized to, but what about the other Windows languages?

The FCS team received great feedback from its customers using non-FCS localized Windows languages who also wanted to take advantage of the easy deployment through WSUS.  In response to that feedback, the FCS team has made changes to the FCS client WSUS installation package to support installing English FCS on those machines running a non-FCS localized Windows language (for example Swedish, Russian, or Finnish).  The exceptions to this are Arabic and Hebrew; the package will not be offered to those because of known issues with the FCS client on those bi-directional languages.

Support for WSUS FCS client deployment for these additional languages should be a great benefit for customers in many parts of the world.  Additional technical documentation on the update will be provided in future TechNet documentation or a knowledge base article, and will include:

·         WSUS deployment still requires that FCS policy is already deployed

·         For non-FCS localized Windows languages, the new installation package does not automatically install the required KB914882 update on x86 Windows XP SP2.  Therefore, prior to WSUS deployment you must deploy the correct OS language version of update (found in the \client directory of the FCS CD media) to XP machines.  No additional work is required for other operating systems.

Re-approval Required

The original client installation package was changed to include detection for these additional languages.  During this process, a new update package was released and the old package was expired.  For this reason, you may notice on your WSUS server that the previous update package is either no longer shown or shows as expired (depending on your view).  You may also see the current package is shown as “Not Approved”.  This is because the Forefront Client Security distribution server role creates an auto-approval rule for the Definition Updates WSUS classification; however the client installation package has a classification of Updates.  Therefore, when the new package is downloaded it will not be automatically approved unless your WSUS administrator has created an auto-approval rule for Updates as well.  This should not affect FCS definition updates and can be easily returned to its previous state by manually approving the new package Client Update for Microsoft Forefront Client Security (1.0.1703.0) on your WSUS 2.0 or 3.0 server (dated Wednesday, October 03, 2007).

Best of luck and happy deployments.

Craig Wiand
Microsoft Forefront Client Security Support

Hello World,

My name is Steve Scholz; I am a Technical Security Specialist for the US. Education Team based out of Long Island, NY. I have been working at Microsoft for just over two years and prior to Microsoft I worked for Sybari Software for five years. Recently during a presales opportunity a customer of mine was looking to use Forefront Client Security in conjunction with a 3^rd party network access tool.  This 3^rd party tool does support Client Security, but was not working as intended at the time.  So they needed something to use as a temporary solution until the 3^rd party tool was fixed. The 3^rd party network access tool could read registry values and make a comparison to determine if Client Security had been updated with the specified policy.  We have also seen this question on the internal distribution list asked a few times:  “How can my customer find out when FCS was last updated so they can script something?” So we wanted to make these tools available.

First, the issue lies in how Client Security writes the SignatureUpdates registry key in FileTime format. Some 3^rd party tools (and humans J) have a hard time reading FileTime format. With the help of a few folks in MSIT and the FSS team, the following script and executable was written.  These tools will convert the HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Signature Updates value from FileTime format to SystemTime format, which is easier for most tools to understand.

The script works with FCS supported operating systems with the exception of Windows 2000, because of the WMI limitations in Windows 2000. One thing to keep in mind is FCS changes the permissions on its registry for security reasons, so I have the script writing to a location that is outside of those changes. This is true for the executable as well, but it is hard coded. In the script you can change the output location but you have to make sure the key exists, as this script was not designed to create a key.  To change the key, change the value for strKeyPath1 in the script.  Make sure the new key has the correct permissions set so the string value can be written and modified.

The executable works on all FCS supported Operating Systems. The only drawback is you cannot change to output location since it has been hard coded. The location is 'HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Forefront\avsignatureapplied-displayable'  on all FCS supported operating systems this was a safe spot where the permissions allowed for writing.  The executable can be found on Codeplex other useful FCS tools can be found here as well.

I hope that you find this information useful.  Please let me know if you have any comments. Also please check out the Microsoft Malware Protection Center for information on the latest threats and definitions.

//begin code

'====================================================================================

' LANG                  : VBScript

' NAME                 : Convert.vbs

' VERSION            : 1.0000 6/30/2007

' AUTHOR            : Steve Scholz

' Description       : Script to convert FCS AVSignatureApplied key from FileTime Format

' to system time Format and write the value to the registry

' HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Forefront     “Readable Date”

'

' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,

' EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED

' WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

'

' Copyright (C) 2007.  Microsoft Corporation.  All rights reserved.

'

' NOTES: Script to convert FCS AVSignatureApplied key from FileTime Format

' to system time Format and write the value to the registry

' HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Forefront     “Readable Date”

'====================================================================================

                Set dtmInstallDate = CreateObject("WbemScripting.SWbemDateTime")

                Set StdOut = WScript.StdOut

                const HKEY_LOCAL_MACHINE = &H80000002

                strComputer = "."

                                Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_

                                strComputer & "\root\default:StdRegProv")

                strKeyPath = "SOFTWARE\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Signature Updates"

                strValueName = "AVSignatureApplied"

                oReg.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

                high = strValue(7) * 2 ^ 56 + strValue(6) * 2^ 48 + strValue(5) * 2 ^ 40 + strValue(4) * 2 ^ 32

                low = strValue(3) * 2 ^ 24 + strValue(2) * 2 ^ 16 + strValue(1) * 2 ^ 8 + strValue(0)

                                all = (high + low) / 10000000

                                rest = "0000000"

                MyString = CStr(all)

                Length = Len(MyString)

                                NewString = ""

                For Position = 1 to Length

                If StrComp(Mid(MyString, Position, 1), ".") = 0 Then

                NewString = Left(MyString, Position-1)

                End If

                Next

                                If Len(NewString) = 0 Then

                                NewString = CStr(all)

                                End If

                dtmInstallDate.SetFileTime NewString & rest

                                ValueString = CStr(dtmInstallDate.GetVarDate)

                strValueName = "Readable Date"

'================================================================================

'To change the key, change strKeyPath1 but this key must exist as this script

'will not create new keys but only a String Value under the specified key

'

'Make sure the new key has permissions set so the String Value

'can be written and modified.

'================================================================================

                strKeyPath1 = "SOFTWARE\Microsoft\Microsoft Forefront"

                oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath1,strValueName,