McAfee ESM, Version 9.1.0
Local Receiver-ELM & ACE (9.1.0).
Everything works properly, but I can't understand why don't work the rules of the correlation. As not ready, not created by me. Not simple, not complicated.
For example, one event :
Create simple correlation rule :
Enabled rule on Default Policy - Correlation Engine. Rollout.
Then create simple alarm.
Create event again and wait the alarm, but nothing happens. I tried different variants.
What could be wrong ?
Added Normalization Rule, but it didn't alarm of this rule correlation to work. Even if just to leave only "Event Subtype" IN "success".
The impression that the ACE module doesn't work, although there are no errors.
What can I do ? Guru SIEM provide assistance. Thanks.
Give me 1 Event so i can import it and i'll let you know what's the problem.
Just select one authentication event against the ssh on that ftp server.Then from the packet tab copy the text and paste it here or in file and then attach it.
As configured, your alarm will never trigger. You've configured the alarm to trigger from a specific sig ID (47-600007). This is the sig ID of your correlation rule, which is generated from your Correlation Engine. However, you've tied the alarm to the Web_Ftp data source. Since Web_ftp doesn't generate the correlated events, your conditions for triggering this alarm will never occur. You should change your alarm so it's tied to your correlation engine instead of Web_Ftp.
But I'm not convinced that's the only problem, since it doesn't look like your rule is firing either. I'd like to see a screenshot of the detailed configuration of your filter element...there are a few items in there that don't show up in the screenshots you've provided.
One thing that hits me is that you're keying off of the "AppID" field. My test environment is version 9.4, not 9.1, and I don't have this field. I do have "Application", which is what I've incorporated into the screenshot below (similar in alexander_h's example above):
I'm not sure if "AppID" and "Application" are simply 2 different labels that refer to the same DB field...just different ESM versions...or if they're different fields altogether. I'd look hard at your filter and see if you have perhaps chosen the wrong field to trigger your correlation rule. One good way to test a rule like this is to re-create the filter in a query on the ESM. Enter "sshd" in AppID query filter (right-hand filter panel) and "success" in Event Subtype filter, and see what shows up in your view. If nothing, (and you're sure the events are there in the ESM) then you know that your filter needs to be adjusted.
Also, I would take a hard look at time stamps across the board. Look at your ACE, REC, and ESM and make sure they are all in agreement about current time, and all are correctly configured for GMT. Look at the events that are coming in from your data source, and ensure that they're properly
Another common issue is that the rule is not enabled on your Correlation Engine policy. I can see that's not the case for you. However, it's always worth doing a policy rollout just to ensure that things have been pushed out properly.
AppID and Application are the same thing, I've checked CustomTypesDefinition.ini and the first possition is AppID and no record of Application where in the interface is the opposite.
If icehot can give me event copy i'll guide him how to do it.
A few thing that you could check:
- Is the correlation engine configured to use event data? (it should be)
- Is historical correlation enablled? (disable it)
- Has a new ssh logon occurred after you created and enabled the correlation rule? if not, create an event or upload an event at the data source level.
- are there any distinct values defined in the match component? If so, deselect the option.
- Are events or flows selected in the match component? (should be events)
You simply need to include the Correlation Engine in the Alarm device selection. Since the event you want to trigger this alarm is coming from a correlated rule, the event source will be from the ACE.
One more comment on this type of alarm... In version 9.4 of the SIEM platform we introduced the concept of a 'real-time alarm' to reduce the timeframe between receiving an event and generating an alarm based on that occurrence. Simply put, if the alarm conditions you are evaluating exist as multiple conditions in a single event then you no longer need to use a correlated event to generate the alarm - you can define those conditions in an alarm using the 'Field Match' option.
Notice that with the new Field Match condition you can specify multiple conditions to look for in a single event. Similar to the correlation engine, you can use Boolean operators to evaluate several pieces of context. This alarm definition is then pushed down to every Receiver so that events are analyzed at the time of collection. When this event context is seen the Receiver generates an immediate alarm within the ESM Alarm interface.
Configuring real-time alarming in this manner shortcuts the ESM->Receiver polling process AND the ESM->ACE->ESM cycles, dramatically shortening the time it takes to generate an alarm.
Hope this helps.
Friends, thank you very much for your help in resolving this issue.
This rule began to work as all the previously created after:
- Removed all Risk Managers on ACE;
- Include the Correlation Engine in the Alarm device selection.
After that all the correlation rules are working correctly.