Endpoint Protection

Preventing an infection that would have otherwise slipped by SEP!!!!!!!!!!!!!!!!!!!!!!

The EXE was allowed to RUN, but my custom file policy is blocking it at this moment:

Domain name:	IVRS-SEP1
Site name:	IVRS-SEP01
API:	File Write
Action:	Block
Test mode:	No
Windows domain:	VRNTDOM1
User	jobclub
Server name:	VRDSMSEP2
Group name:	My Company\Client Computers\JobClub
Computer Name
Current:	VRJC0020VZQH580
When event occurred:	VRJC0020VZQH580
Event type:	Application Control Rules
Event time:	01/11/2010 14:24:40
Severity:	Critical
Begin time:	01/11/2010 14:24:39
End time:	01/11/2010 14:24:39
Rule name:	File and Folder Access Attempts_Write File
Alert:	Yes
Send SNMP trap:	0
Caller Process ID:	3864
Caller Process Name:	C:/Documents and Settings/jobclub/Local Settings/Temp/Installer.exe
Target:	C:/Documents and Settings/jobclub/Application Data/Malware Defense/mdext.dll
User name:	jobclub
Description:	Prevent creation of DLL fils in application data folders

 Wow..Looks you have REAL Control over your applications using Application Control.

Would it make sense to stop any .exe from executing in the c:\documents and settings\username\Local Settings\Temp and a few other places that malware likes to hide?

Should a legit .exe really execute from here anyways?

 When you download a file and run it without saving it will execute from %temp%

Yeah, there's the kicker - you have JAVA and a few other supposedly legit things using that, plus check under a user profile, application data for example - you'll find EXE and DLL files.
IMO, this violates security common sense, but since when was Adobe and some others like GOOGLE!!!! ever accused of being concerned about security?
So I've created some exceptions to allow a few things we use like web meeting software, and similar to work.
As a side, it's blocked some folks from installing GOOGLE Chrome! Yes, like I say, google ignores SECURITY and Microsoft policy by installing to and running from the user profile area, attempting to actually install the Chrome browser........ we found it so lax in security that we banned use of that browser early on anyway, but I found it interesting who and what attempts to install there.
You have to have some exceptions, but I simply have created those exceptions "as needed" and sit back while these rogue things are blocked.
Here's a kicker - SEP an hour ago didn't recognize it, now with a scan I triggered (update content and scan) it's suddenly saying "oh, I know this threat!".

Just shows how critical it is to stay current........sort of interesting to note they did have today's defs, so were current, but now have a later build of todays defs.

So really I could force users to save the file first before running as opposed to just opening.....

Yea I was wondering about java executing from there as well....I'm seeing a decent portion of infections originating from these locations and are considering locking a few of these locations down. Problem is we have a fair amount of in-house apps so I need to do some checking there but it's certainly not a bad idea to lock this down.

You can run it in "test mode" so it will alert you as if it's blocking, but not really  block
It's a brilliant test move - it acts like it's blocking stuff from your view, but the customer sees nothing odd.
You can then see what it WOULD have blocked if the policy was in production..........

I have been meaning to ask what the difference between Test (log only) and Production was in terms of what should I expect...so now that's answered...thanks :)

I am attempting to emulate this, and would like more details on exactly which rules and wildcards you used.

Thank you.

ShadowsPapa,  Do you think could export and post your custom policy?

Thanks.