Skip to content

Instantly share code, notes, and snippets.

@neu5ron

neu5ron/ossem_guidelines.md

Last active July 16, 2020 21:22
Show Gist options
  • Save neu5ron/bbae0ec83a5ac434c40e6da8b1801b3f to your computer and use it in GitHub Desktop.
Save neu5ron/bbae0ec83a5ac434c40e6da8b1801b3f to your computer and use it in GitHub Desktop.
Download ZIP
OSSEM
Raw
ossem_guidelines.md

onboarding data sets, events, and logs

  1. try to map as many fields from that log to the exisiting CDM entities
  2. 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.
  3. 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.

notes #TODO:organize

what is the purpose of OSSEM? are we still aligning to this? https://github.com/hunters-forge/OSSEM#goals

we already have what we are discussing.. we just don't have a "CIM" for data dictionaries. but we basically describe a CIM for data dictionaries in this qoute "The difference between the Common Information Model folder and the data dictionaries is that in the CIM the field definitions are more general whereas in a data dictionary, each field name definition is unique to the specific event log.

what is the purpose of OSSEM? are we still aligning to this? https://github.com/hunters-forge/OSSEM#goals the second bullet point "Define and share data structures and relationships identified in security events logs" is important...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment