Table Structure
Contents
Table Structure¶
Tables are documented in YAML
format, and are the source files for every table documentationin the common data model. These source files can be used to define the logic behind each table and automate the creation of field names and documentation. Tables are objects that group several entities together creating relationships among them to standardize diverse datasets that share a common definition. For example, the NetworkSession
table leverages entities such as http
, url
, network
, etc.
Example:
name: NetworkSession
id: 189BC2EE-44BF-4A8A-A257-5521C67D457B
description: Event fields used to define network sessions in an endpoint.
entities:
- hash
- user
- name: file
prefix:
- file
attributes:
- name
- path
- name: custom
entities:
- name: threat
attributes:
- name: name
type: string
description: The name of the threat or malware identified
sample_value: 'Win32.Small.ahif(90603579)'
Table Definitions¶
name: network_session
id: 189BC2EE-44BF-4A8A-A257-5521C67D457B
description: Event fields used to define network sessions in an endpoint.
name: Name of the current table.
Name must be lower case
Multiple words in an entity name must be separated by an underscore (i.e
user_agent
)
id: Unique identifier for the current entity (i.e
035E058E-5405-4B3B-9288-E78A63B40DAA
)You can generate an ID value by running the following command
uuidgen
in macOS.
description: Description of the current table.
Entities¶
entities:
- hash
- user
- name: file
prefix:
- file
attributes:
- name
- path
- name: custom
entities:
- name: threat
prefix:
- threat
attributes:
- name: name
type: string
description: The name of the threat or malware identified
sample_value: 'Win32.Small.ahif(90603579)'
As mentioned before, we can define tables by grouping more than one pre-defined entity.
Entities that form a table are added under the
entities
property.The
entities
property expects a list ofstrings
ordictionaries
Strings
are used to directly call an entity and all its attributes.They must be lower case (Following the same guidelines defined in the
Entity Structure
documentation)
Dictionaries
can be used for two things:
You can use a dictionary to define what specific attributes you want from existing entities.
- name: file
prefix:
- file
attributes:
- name
- path
We define the name of the entity and the valid prefix for the entity.
We define the entity to be flexible and be able to be very specific when pulling field names (prefix + attribute) from our already defined entities.
All we do next is just take the
prefix
, append it to theattribute
and compare it with attributes in our official entities list. If we find a match then we add it to the table.
A table would end up with the following attributes from the
file
entityfile_name
file_path
You can also use a dictionary to introduce custom entities with custom attributes that do not exist currently in the common data model. This is good for collaboration purposes.
Custom
dictionaries contain a list of dictionaries.Each dictionary is a custom/new entity
Each entity name follows the same guidelines defined in the
Entity Structure
documentation.Each entity has a
prefix
property (same to the entity concepts in this common data model)
Each dictionary/entity has an
attributes
property that allows users to introduce new attributes to the common data modelEach attribute contains the usual properties (
name
,type
,description
,sample_value
)Each attribute name follows the same guidelines defined in the
Entity Structure
documentation.