As you can already see, there are a few different ways to achieve this goal. The above comments seem to rely on the use of ESA, which is certainly up to the task. I want to show a different approach using the decoder and reporting engine.
The rules you have created for yourself are fine, however may not achieve the goal in the reporting engine. However, if we modify rule 1 to just pull back ip.src, we can then take those results and populate a dynamic list in the reporting engine. Then, in rule 2, we can take the results that are in that newly populated dynamic list and feed ip.src.
First, we create the dynamic list. We will just populate it with a dummy value so that it will save.
Once our list is created, we create our modified Rule 1.
Here, I am only selecting ip.src meta which will then be used to populate the follow up rule for my report. Again, the where clause does not matter...it can be any legitimate query. In this case, it is finding some custom meta I have in my environment.
Once saved, I USE that rule in a new report and click SCHEDULE.
In the schedule options, I specifically pick the Dynamic List in the Output Actions.
If we look back into the dynamic list we created, we now see it populated with results.
Now that our list has data, we can use it in our second report rule. You can type out the list name manually, or you can use the LIST option in the lower right column and add it to your where clause.
We would do the same thing as we did for the first rule. We save the rule, then USE it in a new report. We can create a schedule and then run the report.
One important note about dynamic lists, however. Dynamic lists operate like a giant OR statement against a meta key. OR statements can take a lot longer to process through. One way around all of this is to go back and revisit what my use-case really is.
In rule 1, you have a where clause "event.desc contains "scanner" && device.class != 'Anti Virus' ". What I might do, is create a simple application rule and push it out to all my log decoders. That way, meta would be created at the point of capture. Now, rather than having to find all the source IP's in one query to be used in another, I could complete the task with one query "metakey = 'meta_value'" and return the values I am interest in (event.time, ip.src, country.src, ip.dst, ip.dstport, action, event.desc).
Again...a few different approaches to this. Hope this helps.
Chris
