Background: This is a new deployment scenario in a small/medium-sized enterprise, about 5K hosts and 3K users. LOTS of different, old/new applications and OS's. Config mgmt is non-existant - it's the wild west. Oh, and we have a development group, so there's some custom apps out there as well as new renditions popping up every so often.
I'm *very* new to Traps and have been tasked to "make it work". So far, I've got my ESM server and console up and Traps agents deployed to about 25 endpoints for testing, running with out-of-the-box default policies. Things are going swimmingly from what I see - essentially no false positives. I'm inclined to push this thing out to the whole org immediately.
Unfortunately, my boss is less confident and is nervous about ticking off the end users and having a riot on our hands. He's concerned that Traps will have a ton of false positives as we deploy it out to the end users and has directed me to put all policies in "notification mode" only. The plan is to deploy department by department (OU by OU), so the idea is to have one set of policies for enforcement, and a duplicate set of policies set to notify only. As we deploy and "soak" an OU, it will be in notify only mode. After a few weeks, we want to move it to enforcement. Once all OUs are moved into enforcement, we will delete the notify only policies.
While I see the logic in that cautious approach, I don't see an easy way to do it within ESM. It seems like we would have to somehow duplicate the default policies and go through hundreds of these policies, line by line and change the activation. I see days to weeks worth of work just setting that up. There's got to be an easier way. OR I need someone to tell me "There's not really any way to do that so change your strategy".
Any help or advice?
Solved! Go to Solution.
I’m with your boss. We have had a couple of our countries stall with deploying Traps because of the disruption caused to the team with processes not launching. Mainly in-house developed stuff but still causes a mild panic for people. The deploy and see does really work with management at this point ;)
What we did (are doing) is to use the TrapsVDITool and verdict all the machines (executables) before deployment. This means we have no surprises in regards to files on the end machines.
Once this was completed we then deployed the Traps agent with confidence.
Only additional was we have a policy that allows Office macros run but notify. The idea is that we didn’t want a helpdesk storm and we can verdict then approve business related stuff. After a month we will remove this policy (modify) and then anything new will be evaluated on a case by case basis.
Hopes this helps :)
Thanks Glen! I can see that would be very useful!
I can't seem to find where to download the Traps VDI Tool. Any help?
Couple of lessons we have learned the hard way:
To to get around 1) and 2) we created a script that we run from a central server which modifies the Sigcheck CSV so it has UNC path rather than local paths. This means the TrapsVdiTool can access the files from a client with the agent.
Another option is to run the Sigcheck from a central machine which means it already has UNC paths. We initially did this but the process was slow even for our small fleet of 300 servers. A new script was created that distributes the running of Sigcheck to each of the servers, saving the signatures to a central share. This was throttled to 10 servers running simultaneously which reduced the time from 7-10 days to ~30 hours.
Once a machine has been fully verdicted then the agent can go on the machine. We then verdict again locally on the machine so the local cache is immediately populated.
Let me know if I can be of further assistance :)
I got a bunch of errors. Any ideas on what's causing this?
A few notes up front:
1. I confirmed Traps runtime services were completely stopped.
2. I confirmed that the sigcheck .csv file had coherent data
3. I am running with god mode permissions (domain admin)
4. I do not have Windows Firewall running
5. I am running the VDI tool from the machine that I ran the sigcheck against (my own workstation)
6. I have run VDI with both SSL binding on and off (we're using SSL for connections to the ESM)
7. I have run VDI with the uninstall password and without.
8. We are using default port 2125.
9. I've made no changes to hash bulk size, tool timeout, or wildfire verdicts check interval
10. I've run VDI both with "Wait for WildFire Verdicts" set to false and true; same with Write malware to cach.
11. I've made no changes to "Write grayware to cache" (stayed at "True")
Have you come across those errors?
Definitely don't need Domain Admins. At most local administrator on the endpoint but lets move on :)
Firstly can you confirm you are running TrapsVdiTool using "Run as administrator"?
Yeah... back to that whole "I'm an idiot" thing... I think I need to turn in my IT nerd creds or something.
That was the problem. I owe you a beer.
LOL - I'm just glad it was something simple. Always good to have a second set of eyes peer review something that might have been missed :)
Hold that beer... I'll take a virtual lemonade instead ;)
Have a great day!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!