Write up for Supported Logs

[jasonbreimer]

Not sure how or if this should be merged with our formal docs. However we discussed this question of how to determine if a log is supported the other day.

Here is my attempt to describe a process to determine if a log is supported. I would call this 'ocsf data onboarding'. I think it could use additional details on navigating the schema, different attribute types, using profiles, etc.

+++++++++
How to determine if a Log or Event is support by OCSF?

Target data is supported in OCSF when the sample matches an appropriate Category/Event Class as well as contains all required attributes. If the sample does not contain required fields, and required value data can not be constructed at parse time, the log is unsupported.

1. Obtain JSON sample & any available documentation.
2. Review Category descriptions and select a match to the sample.
3. Review Event Class descriptions and select a match to the sample.
4. After selecting an appropriate Category and Event class identify "required" attributes.
5. Drill down into nested Objects within Event class and identify any additional "required" attributes.
6. If using the OCSF Sever, leverage the Schema and Sample button (top right) to better understand the standard.
7. If the sample does not contain required attributes, determine if they can be generated or derived. If a required attribute is not contained in raw data and can't be generated by "source" the log can not be supported for the given Category/Event Class. Restart analysis and find a better matching Category/Event Class.
8. Create a matrix of attribute types:
   a. required OCSF attributes.
   b. attributes within raw data that can be mapped to OCSF
   c. attributes calculated/derived from raw data
   d. attributes that can not be mapped by the standard. See unmapped.
   e. additional attributes included with data that provide additional context or metadata. See enrichments.
9. Determine any conditional logic that maybe required at the parsing level based upon data sample attribute value. *Logic that determines one Object or another based upon sample data value.
10. Generate a converted sample. Either manually or create a script for parsing based upon these steps.
11. Determine a validation mechanism. If using the OCSF Server review the 'validate' API endpoint.
12. Optional: Automate steps to generate sample raw data, generate OSCF output, and validate.
13. Optional: Based upon steps design an implementation parsing process. Include data format, include raw & parsed events, and transfer mechanism based upon the target technology.

FAQ

1. How exactly is "supported logs" determined?
   A: Sample must contain required fields.

2. What can I do if the log is unsupported?
   A: Work with source data provider and/or OCSF community to add support.

3. What are some example parsed/translated samples for known data?
   A: Sysmon or other common event translated to OCSF <>.

4. What data format should I use for OCSF?
   A. That is an implementation detail that depends upon the target technology. Different vendors might have different format or transfer mechanisms. Work with that vendor to determine.