Recorded Demo of EventSource Integrator ESI
I didn't see this listed anywhere, so I thought I'd mention it: there is a flash demo of the ESI tool available at http://www.rsa.com/experience/envision/esi/index.html. The demo walks through two common use cases: adding a new event source, and generating a new report.
Just an observation, but in the second part of the video the report is delivered with a column URL.
In this column called URL the same information as the ClientIP is displayed.
When I look back to the ESI tool an actual url something.jpg is selected, why is the ESI tool or the Envision not finding the right information in the input data?
Secondly if you watch closely you will find that this column when scrolled down contains one entry "geoloc4.geovisite.com (82)" which is not really an URL since the postfixed " (82)" would not be a valid URL. This means the failure to match is not consistent within the same input domain, why is this?
With this information I would conclude that :
- Definition in ESI and Envision are not consistent or have issues
- Failure is not consistent so I would need a large corpus of testdata to determine the quality of the matcher.
It's not that the ESI tool is inconsistent - it is parsing exactly as it was devloped.
The particular event you mention appears to contain an extra bit of data that the others don't. This is not an uncommon discovery after developing an event source - after developing from a small sample, you will often find deviations.
When this occurs, you can always go back into the ESI Tool and update the XML to be able to process an alternative version of the event.
Your second conclusion is spot-on: the better the sample set you develop from, the less likely you will be to find such deviations later.
As a side note, is it possible to develop inefficient device parsers with ESI tool?
Meaning the EPS limits of the Envision can not be achieved with "bad" device parsers.
If this is the case how does RSA do performance benchmarks for device parsers?
The collector only uses the XML to initially identify the device type the first time an event type from a new IP address is seen - not to do full parsing.
Thanks for the heads-up. I was mixing the collector, which among other things handles the EPS limit, with RealTime alerting.
That last one might not see all the events, just the events that are necessary to fullfill the requirements of the views and the rules within those views that you have defined as operator/admin.