Document toolboxDocument toolbox

Devo Cyber Data Model (DCDM)

What is the Devo Cyber Data Model? 

The Devo Cyber Data Model (DCDM) is a semantic model for normalizing data across multiple logging sources into well defined tables with identical field names for the same data across tables and a well structured field naming convention. DCDM is provided as the based data model for unifying types of security data sources into a single table, making use cases and threat detections.

Currently, this model has been only applied to union tables in Devo. Common parsers will be added to the model in future releases.

What are the main benefits of DCDM? 

Introducing DCDM to the data stored within Devo provides Devo users with a number of positive benefits.  Implementing DCDM will help ensure that everyone and everything across Devo uses a uniform language when describing cyber and IT data, making it easier to share, contextualize, and analyze information. The goal of the Devo Cyber Information Model is to improve the Devo user experience and create consistency for all end users.

The major benefits are as follows: 

  • Easily understood field names that spell out the complete word and no longer uses abbreviations that vary based on vendor.

  • A single field nomenclature where each field is named similarly across multiple tables. 

  • With consistent field names across tables querying and threat hunting across multiple tables is simplified to a single field for the same value across all tables. 

  • With the consistent naming and single vendor category union table, customers can focus on creating threat detection content on a single use case and then apply it across all of their technologies.

Detailed DCDM Changes

Field naming

Fields in the updated tables now contain descriptive names that spell out details of many fields and use an underbar to separate those words for improved readability.

For example, here’s a before-and-after of the web view for popular union table auth.all. Note the improved readability of field names in the table, e.g., esoteric field names like “srcIp” are now named “source_ip”, while the previously vague “domain” field has been clarified as “user_domain” to distinguish the field from a web domain name.  In summary, all new fields will be in snake case format and there will no longer be any abbreviated fields.

Additionally, old column names are hidden from the DataSEarch view but they are not removed, they are simply aliased to the new column names.  The aliasing allows all content and queries to continue to work, while providing the consistent naming to customers.  If a query is in production using both naming conventions for a column, then the query would have an issue.

Field naming consistency

With the changes in the above field naming, the same fields across different tables will also be named the same as it was before. 

Detailed DCDM changes

  • Existing alerts on the tables will not be impacted as old field names are aliases to the new field names.

  • It is encouraged that all new content be written using the new field names.

  • Field naming and renaming adheres to the new model for all new parsers that are created and existing union tables and parsers will be converted over time.

  • Existing alerts on the mentioned tables will not be impacted as old field names are aliases to the new field names.