If you can't find ready-made TA's (which even if exist may be of varying quality), you have several areas to cover. Sometimes there are some choices you have to make on your own, sometimes those are just imposed on you. 1. Ingestion method. Obviously anything that doesn't require writing own code, handling authentication and checkpoints like syslog is preferred over API-based methods provided you can get the same data both ways. 2. Basic parsing - event breaking, timestamp assignment. That should be pretty straightforward. Can get tricky if the same data stream (see p.1; can happen with multiple different "kinds" of data sent over a single syslog stream or written to the same file). 3. Basic field parsing - if you have multiple available formats providing the same set of data you have to decide on the format which will be easy to parse and possibly not overly verbose so you don't waste too much license on non-essential stuff. So you might - for example - prefer json over XML and a well-defined format over CEF (don't touch CEF with a six-foot pole! it's gonna end in tears) 4. CIM-compliance. This is often the most tricky and labor-intensive part. The problem here is that often if you've already dealt with such technology before, you've probably done that for some particular customer (or employer) and are not at liberty to release it freely. Sometimes, some solutions use well-known formats or at least use standard open-source components which produce relatively standard logs. For example, many web-related components produce one of typical access_log formats (like access combined), and many soultions have some standard SMTP daemon embedded in them (often postfix). EDIT: Oh, and make sure _what_ you actually want to onboard. For example - Trellix (formerly FireEye) components have two separate event "streams" one is operational logs which are often overly "chatty" and not used very much in reality, another is security alerts which is probably what you'll wanna go for.
... View more
