[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2] 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 typesAt 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]Â
Â
ChetÂEnsignChief Technical Community Steward OASIS Open | Â | Â | Â |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]