Re: EXT :Re: Initial impressions: OCSF vs. OpenC2 data types

Also, if we’re going to talk about JADN and NIEM, this page may be of particular interest:

https://www.niem.gov/strategic-initiatives/niem-metamodel-and-common-model-format

This is a brief high-level explanation of the new NIEM metamodel and Common Model Format (CMF). It describes the relations between runtime data, development-time data models, and the data model for those data models (known as the metamodel) and lists the anticipated benefits of this new modeling approach.

Dave

__________________

David Lemire
IA Systems Engineer
Mission Technologies
(301) 575-5190 (o) (240) 938-9350 (m)
HII.com

From: Lemire, Dave (HII-Mission Technologies)
Sent: Wednesday, August 24, 2022 9:51 AM
To: 'duncan sfractal.com' <duncan@sfractal.com>; TC OpenC2 <openc2@lists.oasis-open.org>
Subject: RE: EXT :Re: Initial impressions: OCSF vs. OpenC2 data types

Duncan,

We can look at that; Mike is supportive. I was refreshing my NIEM knowledge starting w/Wikipedia, which includes this in the up-front material:

NIEM is currently transitioning to an OASIS Open Project. This initiative will formalize NIEM's designation as an official standard in national and international policy and procurement. The transition is in the early stages with completion anticipated at the end of 2023.

I don’t know what’s involved in that transition, but 18 months seems like quite a long time. More reading is required.

My first encounter was when I attended a knowledge session about NIEM some years ago and at the time it was being presented as mandatory for use within USG agencies, but I don’t see anything about that today. The NIEM About page emphasizes “NIEM can save organizations time and money by providing consistent, reusable, and repeatable data terms, definitions, and processes.” I’ve never actually encountered a project that was (to my knowledge) actually using it.

Dave

__________________

David Lemire
IA Systems Engineer
Mission Technologies
(301) 575-5190 (o) (240) 938-9350 (m)
HII.com

From: duncan sfractal.com <duncan@sfractal.com>
Sent: Tuesday, August 23, 2022 6:02 PM
To: Lemire, Dave (HII-Mission Technologies) <david.lemire@hii-tsd.com>; TC OpenC2 <openc2@lists.oasis-open.org>
Subject: EXT :Re: Initial impressions: OCSF vs. OpenC2 data types

CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

DaveL,

Thank you for your excellent work. Would it be possible to also look at NIEM Cyber Domain at the same time. Although ignorant in this area, my gut is NIEM should get a higher priority than OCSF since NIEM is now an OASIS project with path to standardization while OCSF is a github project (albeit with some big players supporting) without a clear path to standardization (albeit I hope they become an OASIS project as well).

DaveK,

Do either OCSF or NIEM lend themselves better to JADN? Would JADN be useful to help with the type of analysis DaveL is doing?

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info [vsre.info]/

From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> on behalf of Lemire, Dave (HII-Mission Technologies) <david.lemire@hii-tsd.com>
Date: Tuesday, August 23, 2022 at 10:47 PM
To: TC OpenC2 <openc2@lists.oasis-open.org>
Subject: [openc2] 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/ [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:

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: john_doe@example.com.

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.
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 [github.com], it does invoke file_name_t.
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 [hii.com]

openc2 message