I'm currently evaluating CSA 5.1.
I realized that not only CSA is indeed a great, "powerful" security software (if configured/deployed correctly!) but it proved to be one of the most challenging security software I've ever worked on.
I've read CSA documentation (install guide, user guide) many times.
I have no problems installing CSA-MC, installing CSA agents, CSA-MC Interface Navigation so far. It is the policies (especially Rule Types!) that I'm having difficulty understanding it. I find it very confusing, the event wizard to create exception rule is nice but can be messy. I believe creating policies/rules manually is a more cleaner, effective approach (correct me if i'm wrong here)
here's the scenario of the pilot system i'm working on:
- Windows 2003 Server (a domain member)
- running Microsoft Windows Server Update Services (WSUS) and MS SQL engine
- running TrendMicro OfficeScan Client
here's the server security policy i would like CSA Agent to enforce:
- prevent Windows 2003 file systems from being erased, modified.
- prevent Microsoft WSUS files from being erased, modified.
- prevent trendmicro officescan client files from being erased, modified.
- allow Microsoft WSUS Services to operate normally (can access internet, download updates, apply and distribute to clients via networks)
- allow trendmicro officescan client signature updates as well as delete/clean/quarantee viruses on system
- protect system from network attacks (I will use nessus scanner to simulate this)
- prevent system administrator/anyone from surfing the internet, chatting on msn on the server.
- prevent software installation when CSA Agent is active
- protect system from malwares
I've decided Windows 2003 system, WUS and trendmicro updates (patches, hotfix or service packs) can only be applied when CSA Agent is manually/temporarily disabled from the CSA Agent system tray icon by CSA Security Admin.
so where do i start?
I hope someone can advice, or provide me a guide or steps that I can follow, especially on which rule types i need to apply.
To prevent Windows 2003 file system files from being erased or modified, CSA has already built in File Sets for System Data files, System boot files, etc. You would simply create a File Access Control rule to deny write access when Any application attempts to access System data files, boot files, etc...
However, I'd be curious to see if this might block Windows Updates. There, depending on how your Windows Updates are rolled out, you may need to change the action to Query User (w/ challenge option) or have the Rule Module only applied when the user is an Administrator.
You need to create exceptions for this legitimate traffic, so you don't have to keep unlocking the agent. If you post the rules that are firing, I can explain the precise exceptions you will need to allow the processes to execute.
Thank you for your input guys!
I really appreciate it.
Here's one of many events as an example.
Rule 182 (General Application Permissions - all Security Levels [V5.1r74] is firing the following events:
The process 'C:\Program Files\Update Services\service\bin\wsusservice.exe' (as user NT AUTHORITY\NETWORK SERVICE) attempted to call the function CreateFileW("c:\windows\microsoft.net\framework\v1.1.4322\Config\machine.config") from a buffer (the return address was 0x6baef0). The code at this address is '50c64304 00f6031f 75308b46 08ff5008 50e8cd45 177c8943 7458c643 0401833d' This either happens when a process uses self-modifying code or when a process has been subverted by a buffer overflow attack. The operation was denied and process terminated.
so far I've created a Policy with the User State Conditions (only matches NT AUTHORITY-NETWORK SERVICE, NT AUTHORITY-SYSTEM)
I then created a System API control rule
- Allow **\Program Files\Update Services\service\bin\wsusservice.exe to access system functions from code executing in data or stack space (Included patterns:
so far so good, but I'm having doubts whether my rule is optimized or not.
well, i'm still new to security, so I don't know how safe something is or not, but as long as you can guarantee that an attacker can't get control of wsusservice.exe, you should be good.
As far as protecting wsusservice.exe, you might even be able to make a rule that says only NT AUTHORITY-SYSTEM can invoke that, or you can make a file access control rule that restricts write access and limits read access.
I had to make a similar leap with svchost.exe being able to modify memory of currently executing applications.
The best place to start is cloning all your policies, this way you can use the compare feature against the originals.
You are going to have to play with the new test group you create to get it working perfect.
Also, putting the servers in all groups and watching what is blocked is a easy way to configure the rules to what you want.
I usually use the wizard and re-name the rules, so i know what they are.
Only configure the allow rules. And test if what you want is blocked by default, you will notice alot of what you want is.
Also play with application investigation and read some the tunning books. So far I am up to three CSA class's and two books.
Another approach is get a test box [Vmware machine or something] and do everything you want to block in test mode and use the wizard to allow or disallow. if you are a large enterprise it is also advise to have Cisco come in. We usually include them on pre-deployment meetings and various health check throughout the deployment.