- try to map as many fields from that log to the exisiting CDM entities
- if a field does not map to an exisiting CDM, see if other log sources have similar values that could be possible to create a new CDM entity. additionally, it may be possible due to limit of the backend database or source where field can not be renamed then skip this.
- if not enough for number 2 or the possibility that no other log source would ever have those values THEN a sub CDM (aka a CDM specific to that log source) should be created and documented for that log source. if that log source has values specific to itself, but those values are across multiple data/logs - then a sub entity (sub cdm) should be created. aka a custom entity for that log.
what is the purpose of OSSEM? are we still aligning to this? https://github.com/hunters-forge/OSSEM#goals