A new fix has been released for FCSv1in how the system handles Overrides and “Ignore” vs “Ignore Always”. The associated KB article describes the details, but this fix changes a basic functionality of FCSv1 from the admin and end-user perspective, so we wanted to provide some extra guidance to help customers understand what the fix means and how it will affect them.

Impact #1: End-User notification when allowing an application that is blocked by default

First, the scenario in which this applies is when you have selected Ignore in the Overrides tab in a Client Security policy for a specific application that would by otherwise be blocked by default through the FCS antimalware signatures.

Before the fix

If an end user launches the application you have set to Ignore, then the end user will receive a notification despite the administrator having selected Ignore.

OK, so this is obviously not correct. The administrator chose Ignore for the application, and yet clearly the FCS client is NOT ignoring it.

What does the end user see exactly?

• Notification pops up to  informing the end user that the particular application has been ignored
• FCS icon will go red

Why is this bad? The above behavior would result in a help desk call to the administrator.

After the fix

When an end user launches any application that has been configured to Ignore, application launches and end users do not get notified. This is Goodness, The FCS client behaves exactly like the administrator configured it to.

What does the end user see exactly?  Nothing (which is what is desired)

• No notification will be seen
• FCS Icon will not change color

Impact #2: Change in the override model

Before the fix

In the Overrides tab in Client Security policy, you can do these things:

• Be more restrictive or less restrictive for specific applications
• Be more restrictive or less restrictive for a category of applications.

More restrictive = you want to block more than what the default behavior would be.

Less restrictive = you want to block less than what the default behavior would be.

After the fix

In the Overrides tab in Client Security policy, you can do these things:

• Be less restrictive for specific applications.
• Be more restrictive or less restrictive for a category of applications.

In other words, we removed a feature. You can no longer be more restrictive for a specific application. Specifically, you can no longer select Remove or Quarantine for specific applications.

Here how the UI changes:

Policy Dialog Before

Policy Dialog After

By removing this feature for specific applications, we have moved to a pure ”whitelist” model for applications.

Why we did this:

• Moving to a “whitelist” model for specific applications covers the vast majority of customer needs in practice.
• We believe the change makes it simpler to understand what the UI is doing, and as a result simpler to predict the impact on end users.
• Most importantly: it now accurately explains what the FCS client will do. Before the fix, there were situations in which the FCS client behaved inconsistently with respect to what the Client Security policy said; after the fix, the two are consistent.

In general we do not like removing a feature, because that’s just rude. But in this case, the feature caused more problems than it solved. And our job is to make sure your problems are solved, not make new ones.

And they have some incredible information on the impact of the "Storm" worm - and how MSRT is helping!

Take a look!  http://blogs.technet.com/antimalware/default.aspx

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,ValueString

//end code