← Prev in month ← Prev in thread

Initial impressions: OCSF vs. OpenC2 data types

From
David Lemire
Date
2022-08-23T20:48:00+00:00
ID
Thread
Initial impressions: OCSF vs. OpenC2 data types
At our last TC meeting we spend some time discussing the recently announced Open Cybersecurity Schema Framework (OCSF). Just to get a sense, I started looking at the data types defined in OCSF, viewing them  in their schema browser located at  https://schema.ocsf.io/

The data types, specifically, are at https://schema.ocsf.io/data_types?extensions=

I haven’t yet dived into a careful point-by-point comparison, but have some initial observations:

1.
We have defined many of our data types that have some structure via a reference, whereas OCSF applies a regular _expression_, e.g., :
·
OpenC2:  email (String)

Value must be an email address as defined in RFC5322, Section 3.4.
·
OCSF:  email_t (String)  ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$    Email address. For example:   .
2.
The layering of OCSF is going to make doing a thorough comparison a bit complicated, although I think a comparison of just their data types with ours is probably a useful start. There are only 22  base data types in OCSF, so that’s not terribly burdensome to examine. I think from there it’s probably best to move to their Attribute Dictionary, and then to Objects.
3.
I’m still puzzling over some of their constructs. For example, there’s a File Name data type (file_name_t) defined as a string with a regular _expression_ constraint. But the File observable object  has a Name field that’s only defined as of type String with not constraints. I would  have expected the object to invoke file_name_t but it doesn’t. Similarly, the object has a Path of type Path Name, which does correspond to a data type and so at least implicitly  invokes the path_t type. Some of this might be the browser, because if I dig into the schema repo and look at the  file object , it does invoke file_name_t.
4.
Assuming we find at least some discrepancies, we’ll have to discuss whether it’s worth adjusting any of our type definitions to improve their alignments with OCSF’s definitions.

Dave
__________________
David Lemire
IA Systems Engineer
Mission Technologies
(301) 575-5190 (o)

(240) 938-9350 (m)
HII.com
← Prev in month ← Prev in thread