CSA Tuning process

[taylr]

Can anyone point me to a resource to research the Alerts that come up in the Event log so that I know if it should be allowed or denied? For instance. How would I know if this process not supposed to be able to insert code into another process?

TESTMODE: The process 'C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\cda0537e8e2624c74cdaea2d34c7c7df\update\update.exe' (as user NT AUTHORITY\SYSTEM) attempted to insert code ('Windows Message code 1030') into another process. The process 'unknown process' was targeted. The operation would have been denied. Details Rule 1009 Wizard

[chickman]

If you don't have an in-depth knowledge of what that specific product does, the easiest way is to deny it and see what happens. Obviously it would be hard if the server was in production. But would it be possibly test after working hours? If you have the latest virus def. then you might be able to rest slightly assured that the product is not malicious in nature. If you place it in deny, replicate the process, and then see if it hinders the application or process. With that, you'll know that it is something you can block or need to allow.

BTW, I believe this to be the Microsoft Auto-Updater, someone please correct me if I'm wrong. You will want to deny this connection and action. That is unless you don't mind updates being pushed from a 3rd party.

Hope this gives some insight.

[pmccubbin]

Excellent question. I always use a Google search as a starting point if I don't know what the Alert means.

You also received some good advice about doing these things after hours and beginning your tuning by trying a deny to see what happens. I hate to make it sound so hit or miss but with the vast number of commercial applications, not to mention the home-grown ones, the Testing and Tuning process can certainly be a messy one.

One other thing I have found that helps this process is a naming convention for all changes. I include a date in the name for easy searching and I always try to be consistent in the titles and descriptions. In this way anyone can do a search on the changes

and stand a good chance of finding one that has mistakenly broken an application.

I'm sure other people in this forum have tips on the Testing and Tuning process, too.

Hope this helps.

[jwalker]

I agree as well. The tuning process is pretty much trial and error (even in a production environment) for us. Basically, after our "learning period" we create all necessary exceptions. Once we figure we have seen all legitimate processes, we lock the agent down. Occasionally, there is a process that is irregular that gets blocked, so we have to make an additional exception. In your case, this process is associated with auto updates. I would not recommend making an exception for this traffic.

[taylr]

By naming convention for changes do you mean the names of policies? Can you give me an example?

[pmccubbin]

A naming convention would be employed for all changes you make to rules themselves, either direct edits of the canned rules or via exceptions through the wizard.

I always include a date, a 3 letter acronym for the company who owns the CSA MC or the department that manages the box, and a brief descriptive phrase of what the change regards. For instance, (Forsythe Solutions Group) FSG15jan07_Antivirus_exception.

If more than one group manages the box, that is, groups with different functional responsibilities like servers and desktops, it is essential that these groups agree on the convention to be used. In this way troubleshooting can be conducted without spending alot of time determining who made the changes. A quick glance at the name of the change to the rule should be all it takes.

I also have whomever makes a change include their initials and the date in the description field.

Hope this helps. It takes some upfront work to get it right but it's well worth it in the long run.

[tsteger1]

Nice system Paul, if only I had that kind of discipline.... maybe with 5.2...

[tsteger1]

Are you the only IT support in your organization? If not, you might want to check with your Windows support folks to see if they are using WAU or WSUS.

They may have this set to run and CSA would block it.

I've created exceptions for WSUS in CSA but it probably helps that I'm the WSUS, AV and CSA guy and know we use it...

As far as other alerts and what they mean, I'll echo the comments above and add that nothing can substitute for a good working knowledge of the OS's you have CSA running on and time spent examining the event logs and testing exceptions.

There is no magic bullet I'm aware of (except maybe for the collective knowledge in this forum and asking the right questions...).

Tom

exceptions

[fkhan6_wb]

Tom

How did you exempt WSUS?

We have Windows Update application class that is allowed to run All applications. Also all applications are allowed to run Windows Update application class. Finally Windows Update application class is allowed to be downloaded and attempted to execute.

What should be included in the Windows Update application class?

Right now it includes common WSUS executables.

The desktop team are piloting Windows Auto Update SUS/WSUS and we started receiving these CSA events even after creating the exemptions:

The program 'C:\WINNT\SoftwareDistribution\Download\S-1-5-18\89eac72c57853ef9bba7565ec92a0e74\update\update.exe' was recently downloaded and attempted to execute. The user was queried whether to allow this operation. The user chose 'Terminate'.

The current application 'C:\WINNT\System32\svchost.exe' (as user) tried to execute the new application 'C:\WINNT\SoftwareDistribution\Download\S-1-5-18\7013138e8ed23434f5f702bf739c3fdf\WindowsInstaller-KB893803-v2-x86. exe' and the user was queried. The user responded by choosing 'No (as default)'.

Any thoughts?

[tsteger1]

You need to allow Svchost.exe to execute your WSUS app class.

You also need to exempt your app class from the Trojan Detection rule section "Downloading and invoking executable files"

Your app class for WSUS should include this:

@windows\SoftwareDistribution\**\*.exe

This will cover the updates as they download and execute.

Tom

[fkhan6_wb]

Thanks Tom,

The info you provided it very helpful.

currently WSUS inclueds

@system\wuaclt.exe

@system\wuaclt1.exe

@system\wupdmgr.exe

@system\wuauclt*.exe

**\update\update.exe <- but "@windows\SoftwareDistribution\**\*.exe

" is better and more restrictive.

I found that these WSUS events accured on systems with CSA agents that does not have the latest policies. Particlarly new or re-imaged machines with old agent kits.

Thanks again for your help

[tsteger1]

Glad to hear it, have fun!

[tsteger1]

You know, I just noticed that the first three variables on your list are not needed.

@wuauclt*.exe and @windows\SoftwareDistribution\**\*.exe

should be all you need.

@system\Wupdmgr.exe is not needed for WSUS, it's used to access the Windows Update site.

That should make for a leaner app class.

Sorry I didn't notice sooner,

Tom

[fkhan6_wb]

That would help.

Thanks Tom

Cheers,

Faisal

[TradeSecrets]

Tunning is the hardest part.

How are you pushing windows updates. This looks like a windows update, but I would check with the patch team.