In my data souce configuration I have noticed severial times that I have an option for a Data Source Model with and without an "(ASP)" on the end. For example, I have a Trend Micro Deep Security device. Both Deep Security and Deep Security (ASP) are listed as Data Souce Model options. How do I know which one to use and are there advantages/disadvantages of one over the other?
Second question: What does ASP stand for in this usage? I doubt it's the Association of Surfing Professionals.Message was edited by: rabremmer on 12/5/12 3:34:17 PM CST
This is a very good question indeed. I’ll start out bysaying ASP stands for Advanced Syslog Parser. The ASP parsers are rule-basedwhereas anything none-ASP is code based. The advantages for using ASP overnon-ASP would be performance and the usability.
For example: You set your data source up to use the non-ASPversion and you noticed that some of your logs don’t trigger events or maybesome of the events are mapping incorrectly. Since this is a code-based parseryou would be stuck with what is there until a new release is shipped with theenhancements for the parser.
With the ASP version this isn’t the case at all. Let’sassume your events aren’t mapping or maybe the mappings are incorrect. With theASP version you can log a Product Enhancement Request (https://mcafee.acceptondemand.com/index.jsp)and our rules team could, depeding on the request, correct the issue andrelease new or updated rules. The customer would then just need to get a rulesupdate and they would have the corrected rules in place. This is much fasterthan waiting for an actual code change to be released.
TheASP engine is also far faster when processing rules than the code basedparsers. So, If you ever have a choice between the none-ASP and ASP version,always choose the ASP version.
Time to revive an old thread...
Can you confirm that this is really the case?
I believe code-based parsers would be faster than ASP, being code based... The disadvantage would be that we can't customize our rules.
Can you please confirm that ASP is actually faster than code based? I always prefer ASP but I sometimes chose code-based parsers thinking they were binaries, and thus faster.
Data Source model ASP and none-ASP sometimes work in different way and parse different rules, so you have to try both of them before having the right choice.
Ok, but for a syslog data source, which one would be faster? Say you have 20 rules ASP, 20 rules code based, for the same logs? There should be a clear winner, but the post by Anthony infers that this would be the ASP parser, in terms of performance.
I do not know of a way to test parser performance directly...
in my opinion you should refer on EPS. If the receiver collects eg 5000 EPS, it will able to collect 5000 EPS indipendentemente on type of Data Source.
Reviving a very old thread again.
Hey does any one know if there is a way to write a custom code based parser?
I have tons of API based data sources and it sucks to have to use an intermediary server to collect the logs.
Code based parsers are the equivalent of compiled code, so probably no. What format are the API sources in? we can now read serval formats, such as JSON, etc
So I'm aware of the JSON, and XML log support, however, my issue is not the parsing it self but ingestion.
For example Proofpoint cloud, or Digital Shadows solution only export logs via API. I would have to write an app on another server have it pull out the events and than have the SIEM pull them in. That is very cumbersome.
Splunk on the other hang lets your write your own API connectors right on the indexers.
Or another one is when log sources send logs as an HTTP push, Not the HTTP get option that's currently supported.
Anything that's not syslog or a static log source is an issue making things more complicated than they need to.
I wonder how everyone else deals with this, or I am missing something.
More options are always better. I hoping/thinking we'll see something in 10.0 to help with this.
That being said, it's become more common to "front-end" log solutions (other vendors also) with syslog or message bus instances so there is extra flexibility in writing/routing logs.