we have several AR responses and all - seem - to work and also each has multiple actions (email, agent install and delete system). Would you check your AR flow again for possible filtering, missing field values or similar?
giving these here for us to see is a must otherwise we cannot help.
A few screenshots won't hurt :-)
thank you for the pictures. I suggest you check - since you said nothing about its status - the ePO email settings and whether you are able to send a test mail.
As for the filtering, we only use RSD to deploy agents to client with name conventions and IP range so we specifically filter for detected system's name (starts with or Contains a given string) and/or has a specific IP address.
I would not think of using "New Detection" as filter because I'm not sure what it means and if that's remains valid for long. Anyway, we also delete detected system immediately as last AR action so everything is new detection so to speak at us..
Filtering could be also made on OS version, family and platform, whichever has values like "Windows", "Linux", "Printer" etc. We do not send agent to printers even if that matches naming convention and IP range, for example.
You could not send agent to detected system you said. Assuming the detection was a Windows computer, did you use a valid and for the client a local admin right account to deploy the agent? Did you check server.log at the time when AR triggered (could have said something more informative).
We use ePo 4.5 and there AR works (email, and so on) on 13/04/11 13:13:33 CEST
Yes, email works for other Automatic responses.
So I'm trying to use that default/ prebuilt Automatic Response "RSD: Query New Rogue Detection" to deploy the agent, OR email, THAT is not working.
I created a custom query to look at detections, they stay "New=yes" if the task is disabled, change to "New=no" after a few minutes if the task is enabled. So it looks as if the task does not actually trigger the actions it is supposed to, but thinks it has. The other tasks I have dried in that area do work.
I'm not clear on the alternative approach you are taking.
Can you step through the menu items and elements you use as an alternative?
1 of 1 people found this helpful
Unfortunately we use ePo 4.5 and have only a test ePO 4.6 but I suppose no relevant behaviour change has happened in the new version.
So we have a few default AR which are disabled and we have basically two types of RSD-related AR of the following types:
- RSD exclusions. Whenever we detect a non-Windows machine we add it to the RSD exclusions (do not detect again)
- Agent deployment: we use our naming convention as a basis in the filter condition (This might change in your case). We do not use "New detection=yes" or anything else.
With these two rules I'd expect that eventually the second AR won't trigger on non-Windows detection.
I suggest you try to take this approach, too.First please try to finetune a basic AR rule with no filtering and email sending as the only action (i.e. will trigger on any detection and notifies you of it). Use every email variables that you think could be useful source of information abut the found item.
Also make sure you use such email variables, too, that you can match fields with in the AR rule Filtering section (like OS platform, name, IP). Troubleshoot email sending this way as primary goal. As far as I remember use orion.log to find out about sending failures.
When you have collected enough non-windows client types names etc. you can define the second rule for the RSD exclusion rule that you use for excluding these from further detections and use these collected data in the filter condition of this second rule. The action would be "Exclude from detection".
Now you can focus on the first rule which triggers only on Windows detections and insert the agent deployment option, now with focus on server.log. Whenever now this rule triggers please check server.log (or orion.log) for the success or failure of agent push.
I hope I could "visually" describe my thinking and you forgive me the missing actual menu item references.
Many thanks for your assistance with a workaround.
Just for info, and to assist others,
McAfee Tier 2 support have confirmed there are known problems with their function of automatic responses based on new detections;
No reaction is triggered. I don't know if it's only after an upgrade, or always.
Escalated into USA, solution awaited.
Not that this helps the OP in anyway but I have been fighting the Automatic Response issue from day 1 with EPO 4.5. I have an open case with McAfee on this and its been over a week since I have heard any response from support. I have emailed support twice for follow up with no response as well.
This first started with threat events. We were not getting all threat alerts but it turned out that there were some old VSE installations "clogging" up the Events folder and the Events Parser could not read those events. Once we removed those clients the threat events are regular. Sometimes it will lag behind meaning there is a definite difference from when the detection and the event were sent and when the e-mail was received. I have to restart the Event Parser to it get going again.
I am having the exact problem you are describing with the RSD detections. The Detected Systems tab shows the "rogue" but it seems random on whether or not we will get an e-mail alert on that. Unfortunately the last two times it decided to NOT alert us were real rogue systems (not an inactive agent). We were not amused to find that out by stumbling across the detection.
I was hoping upgrading to EPO 4.6 might solve the issue but after seeing this post why bother???
Not that I am trying to hijack this post but I figured if we get enough people to rally behind this issue then MAYBE McAfee will recognize the problem and do something about it.
1 of 1 people found this helpful
Further info to assist others:
New detection is only new until a second detection recurs, then it is no nonger new, so filter based on new=true may fail, if time interval between processing of new detections is too long.
A query on detections shows a separate entry for detections of the same system from each sensor, and for each detection method (dhcp and broadcast traffic), with a possible status of new=true or false on each one. That explains a LOT of unexpected behaviour of RSD.
The processing of these multiple detections of the same system is not documented, clear or proven.
So for new=true, multiple sensors and detection methods on a subnet may actually be a bad idea!
Design recommendations from McAfee would help here.
Other oddities: Filters on "managed=false" seems to give less results than "managed not = true" The second seems more reliable. Strange.
On my particular problem (after upgrade from 4.5 to 4.6), automatic emails have started to work after deleting the RSD extension from EPO and re-adding it. Again, strange. But the Automatic responses category of system events are still called slightly different than a clean install of 4.6.
Now, though emails work, auto deployment of agents fails. I have to manually select the rogues in "Detected Systems" and choose "deploy agent", which works. It seems different processing is invoked. Tier 2 of McAfee are still chasing a resolution of that one.
"Now, though emails work, auto deployment of agents fails. I have to manually select the rogues in "Detected Systems" and choose "deploy agent", which works."
McAfee Platinum support have replicated the problem/bug. There is a workaround.
Instead of running the three EPO 4.6 services under the local "system" account, configure them to run using a "Domain Admin" account using domain\username and password. It should not be needed, but hey, it works.