Iâm moving a specific suggestion from larger TC list to the ICSC list. I circulated a bunch of ITU work to TC mainly to spur language and AP efforts. But this is a separate proposal. The ITU makes recommendations (standards) on interworking and intends to adopt
OpenC2. Recs are the hardest to get politically but Iâm sure OpenD2 will go thru since they are anxious to get it. But I also recommend we send them some proposed Committee Notes (our side) to turn into Technical Reports (their side). CTI chose to do their
use cases as recommendation. I think weâd get less objection if we proposed our use cases as Technical Reports (TR) instead. TRâs require less formality and approval and are just as good at getting the word out. Note I still feel OpenC2 Specs should be ITU
Recs. Itâs just the use cases (and how we relate to other SG17 recs) that would make easy TRâs. We could do one for each of the relevant technologies from the ITU view (ie how we relate with STIX/fgati, how we relate with malware sandboxes, how we relate
with DLT/distributed-ledger-technology-aka-blockchain, how we relate to identity systems, how we relate with 5G, how we relate to secure-multilocation-computing, how we relate to quantum, etc). Obviously the STIX/threat-intel is the main topic â and might
be multiple TRâs â but we can also get in on the ground floor of the other technologies and develop our Committee Note/TR on topic even before we get the details of language/AP finalized for the tech. This would both be consistent with our âuse cases firstâ
philosophy and might solve the Joe/Duncan âabstractionâ philosophical discussion (ie we probably agree on any particular use case when we are using actual use cases â itâs generalizing where we tend to get into angels-on-head-of-the-pin differences). In the
longer run, if we play our cards correctly, the TRâs will set the stage for eventually modifying the relevant ITU specs (on sandboxes, DLT, idam, 5D, SMC, quantum, etc) to recommend OpenC2 for command and control. Admittedly we are a couple of years away from
that but we need to set the stage now.
So my suggestion is to get IC-SC to develop the Committee Notes/TRâs I mention above â ie we make Committee Notes designed to be ITU TRâs on relevance of OpenC2 to the work the ITU is currently doing. We should start with obvious ones (packet filtering, endpoint,
malware sandbox, âcomply to connectâ, â) but we should also do the more esoteric ones to get them from âbeyond our headlightsâ into âshining light on themâ. Iâd be happy to be a co-editor on any/all of these, but hopefully others can help as well.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
Might not have been best one to start with. Hopefully todays rdmase has more meat in it of relevance to OpenC2. If nothing else, they should spark thoughts on what they should have had in them.
Suggestions on improving the English would be welcome. Developing more concrete use cases (especially if used OpenC2 ð )
would also be welcome.
Back in the day most ITU recs were written in either French or English with some Japanese, but now the Chinese contribute more than everyone else combined, with Korea in second place. I consider us lucky we still meet and draft in English.
Some of the awkwardness is 2nd-language issues. Some is trying to do too much with too little effort - and therefore not doing good quality control. But some is compromised wording. I just was on a call that agreed to really horrible awkward
title as a compromise (allowed both sides to have their way â so its effectively meaningless to anyone not present. I made that point to no avail). âA camel is the compromise of a committee trying to design a horseâ. Outside eyes without baggage help â ie
comments welcome.
I talked one group today into letting me put their work on github so we could track issues and do better change control. They are letting me try as an experiment. Hopefully that will catch on and make stuff like this easier in future. Of course that means I
need to do the work to get it on github. ð
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I took the time to read this on Friday. It's relatively high level, so I don't see a lot of potential to extract use cases from it.
Also, based on the Chinese authors I presume this is English as a 2nd language, but it got me wondering if many ITU documents are as repetitive as this.
HII Mission Driven Innovative Solutions (HII-MDIS) â formerly G2, Inc.
Technical Solutions Division
302 Sentinel Drive | Annapolis Junction, MD 20701
Work: 301-575-5190 | Mobile: 240-938-9350
Submitter's message
This proposed ITU recommendation X.fgati "Framework and Guidelines for Applying Threat Intelligence in Telecom Network Operation" is from ITU SG17 mtg 3/2020. OC2 members should be pleased to note that our OpenC2 specs are referenced, included in the figure
7-1 as the interface to firewalls, ids, anti-ddos, etc. Of special interest, note the wording near the end of section 7 that states "Security command and control is recommended to use OASIS OpenC2 specifications". "is recommended" is less strong than "is required"
but is still pretty good. It means OC2 is the preferred approach but you are allowed to use other interfaces. Members of OC2 TC may want to review this document for use cases we have not yet covered so we can further expand our language, actuator profiles,
and transport specs to meet all needs.
-- Mr. Duncan Sparrell
|
Document Name: X.fgati
Description
A proposed ITU recommendation X.fgati "Framework and Guidelines for
Applying Threat Intelligence in Telecom Network Operation" from ITU SG17
mtg 3/2020
Download Latest Revision
Public Download Link
Submitter: Mr. Duncan Sparrell
Group: OASIS Open Command and Control (OpenC2) TC
Folder: Documents
Date submitted: 2020-03-20 01:33:29
|