[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: IC-SC already exits
I do think we need to have a meeting because I think we are talking past
each other.
But since we don't have a meeting, I'll do my best via email.
I deleted the LSC off the email since I think this is an IS-SC
discussion.
Adam Bradbury gave a live demonstration at the face to face of a live
production system using prototype OpenC2. In that system multiple
vendors were involved. I believe that system used https api's. Mike
Stair described a system AT&T has operational (proof of concept but real
analysts are actually using it) that also has multiple vendors
interworking over OpenDxl.
I propose it is worthwhile to have a standard way to use openc2 over
https api's. I propose it is also worthwhile to have a standard way to
use openc2 over OpenDxl and over OpenDSS and over other pub sub
standards. These are all for use cases within a single enterprise. I
suspect, but I won't presume to speak for them, that there are some
people who feel openc2 over STIX/TAXII could also be used within a
single enterprise. I'd also guess there is a larger crowd that feel
openc2 over STIX/TAXII could be used between enterprises. I feel it is
worthwhile to standardize each of those architectures. I do not think we
need to pick just one of them to allow interoperatibility. I don't think
forcing enterprises to change their architectures will be successful. I
think supporting their existing architectures so that they can use
openc2 will be more useful. If we had to pick one, I'd pick https api's
since that is what the vast majority of security devices use today. But
I don't think picking multiple will cause 'no random two vendors will be
able to communicate'. I think any vendor that supports https api will
interoperate with others that also support https api's - given we spec
it. I think any vendor that supports OpenDxl will interoperate with any
other vendor that supports opendxl to our IC-SC spec. Yes vendors that
only support https api's will not interoperate with vendors that only
support OpenDxl. That is no different than today and I consider that a
specious argument. And note even if an enterprise that did have the
problem that they wanted to interwork 'across' those two spaces - the
openc2 JSON would remain unchanged and it's just a normal http api to
opendxl conversion problem. We could even write a spec on the standard
way to do it if it's a realistic problem someone would have. Ditto any
other pair of transport protocols (eg OpenDDS and STIX).
Can you give an example of where you see the problem is? Ie give an
example of what can't interwork in a realistic architecture,
particularly one that you have an interest in (ie an IBM architecture or
an architecture of an IBM customer).
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: Re: [openc2-imple] RE: IC-SC already exits
From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Date: Mon, January 29, 2018 2:33 pm
To: duncan@sfractal.com
Cc: "openc2-lang" <openc2-lang@lists.oasis-open.org>,
openc2-imple@lists.oasis-open.org
The problem is as Allen has pointed out - OpenC2 working over many
different protocols is not actually meaningful, because it will do
nothing for interoperability because no random two vendors will be able
to communicate.
There has to be a standard protocol over which OpenC2 is interchanged -
if there isn't, then it's not really going to lead to interoperability,
as nothing can talk unless they just randomly decided to implement the
same carrier protocol in exactly the same way.
Sent from IBM Verse
duncan@sfractal.com --- [openc2-imple] RE: IC-SC already exits ---
From:duncan@sfractal.comTo:"Jason Keirstead"
<Jason.Keirstead@ca.ibm.com>Cc:"openc2-lang"
<openc2-lang@lists.oasis-open.org>,
openc2-imple@lists.oasis-open.orgDate:Mon, Jan 29, 2018 2:22
PMSubject:[openc2-imple] RE: IC-SC already exits
Since we have existence proofs of openc2 working over existing transport
protocols, I had envisioned it was more of specifying all the details
instead of inventing a new protocol. Although if we did need to invent
one for some use case I haven't thought of, I read the charter as it is
within scope as part of 'message transport'. The charter has "The SC
will leverage preexisting standards to the greatest extent practical and
it is within scope of this SC to identify gaps as they pertain to
command and control of cyber defense technologies". My recollection is
that wording was chosen specifically for this discussion - ie use
existing protocols if you can, but id gap if they don't meet the needs.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: [openc2-lang] Re: [openc2-imple] IC-SC already exits
From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Date: Mon, January 29, 2018 2:09 pm
To: duncan@sfractal.com
Cc: "openc2-lang" <openc2-lang@lists.oasis-open.org>,
openc2-imple@lists.oasis-open.org
Hey Duncan;
The problem is, from my experience, developing a protocol was never part
of that subcommittee's mandate. If it was, it is not in the charter.
Developing a protocol is a big deal and should be the primary job of
whatever subcommittee it is under. It is far more reaching than an
implementation consideration.
Sent from IBM Verse
duncan@sfractal.com --- [openc2-imple] IC-SC already exits ---
From:duncan@sfractal.comTo:"openc2-lang"
<openc2-lang@lists.oasis-open.org>,
openc2-imple@lists.oasis-open.orgDate:Mon, Jan 29, 2018 2:05
PMSubject:[openc2-imple] IC-SC already exits
Wrt Jason's comment:
> 'I 100% support the creation of any kind of subcommittee focused on the implementation of a standard protocol for OpenC2.'
Just to be clear - the IC-SC already exists. IC stands for
Implementation Considerations. Transport of openc2 is explicitly one of
it's mandates. The IC-SC stopped having meetings because there were
complaints of too many meetings and nothing to discuss. I was against
stopping but outvoted. 1 hour a month for this topic may have been too
much (I personally don't think so) but never is definitely too
infrequent. As I stated in my other email, I think the IC-SC should
reconvene.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: RE: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source]
RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp,
sender
From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Date: Mon, January 29, 2018 1:46 pm
To: "Kemp, David P" <dpkemp@radium.ncsc.mil>
Cc: 'Allan Thomson' <athomson@lookingglasscyber.com>, 'Bret
Jordan' <Bret_Jordan@symantec.com>, "duncan@sfractal.com"
<duncan@sfractal.com>, "Brule, Joseph M"
<jmbrule@radium.ncsc.mil>, openc2-lang
<openc2-lang@lists.oasis-open.org>, Sridhar Jayanthi
<sridhar@polylogyx.com>
I 100% support the creation of any kind of subcommittee focused on the
implementation of a standard protocol for OpenC2... this has long been
the #1 gap I have seen in OpenC2, as a language without a standard
protocol to transmit it over is not going to go very far to encourage
interoperability. I am very excited that it sounds like we will have
forward momentum!
On the topic of Open DXL.. I always feel compelled to point out that
OpenDXL is currently a closed protocol. The one and only implementation
of it is closed source - including the linked docker image (it is a
compiled binary-only distributable that is distributed under a special
McAfee license). I've seen reference that McAfee plans to fully open
the protocol, however until such a thing is completed and available to
all under a standard open source license, I do not believe it is
appropriate for any OASIS-created standard to have references to said
protocol.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
From: "Kemp, David P" <dpkemp@radium.ncsc.mil>
To: 'Allan Thomson' <athomson@lookingglasscyber.com>, 'Bret
Jordan' <Bret_Jordan@symantec.com>, Sridhar Jayanthi
<sridhar@polylogyx.com>
Cc: "Brule, Joseph M" <jmbrule@radium.ncsc.mil>,
"duncan@sfractal.com" <duncan@sfractal.com>, openc2-lang
<openc2-lang@lists.oasis-open.org>
Date: 01/29/2018 01:20 PM
Subject: RE: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD
Source] RE: [openc2-lang] mandatory vs optional, Header, id, version,
timestamp, sender
Sent by: <openc2-lang@lists.oasis-open.org>
I agree. The working title is "Transport Implementation Considerations"
(https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1Bz-5FWXOiYc9vmMS8rNEP1-2DZZgPzdeGoZMN6W5W9GSmdU_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=6IyVD_1ml2WOEtY8q0pZbBb1leFZ6ktAr9anVp_gFjM&e=)
and it will initially contain at least two transport protocols
(https/ajax and a pub/sub such as MQTT or OpenDXL*). It couldn't hurt
to define a TAXII binding as well.
There is no dearth of options for bundling headers and messages together
in a document (for use outside of a protocol); JWS (RFC 7515) bundles
Unprotected Headers, Protected Headers, Payload and Signature fields; it
can be used with a "none" signature algorithm and an empty signature
value (RFC 7518 Section 3.6) if integrity protection is not needed at
the document layer.
Dave
* For those who will ask, there is now an OpenDXL broker packaged as a
docker container:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_opendxl_opendxl-2Dbroker&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=i7U9t4sF-zFaeuaV0kbNq33zZQwI9QxN7fdDec8kzyI&e=.
-----Original Message-----
From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
Sent: Monday, January 29, 2018 11:33 AM
To: Kemp, David P <dpkemp@radium.ncsc.mil>; 'Bret Jordan'
<Bret_Jordan@symantec.com>; Sridhar Jayanthi <sridhar@polylogyx.com>
Cc: Brule, Joseph M <jmbrule@radium.ncsc.mil>; duncan@sfractal.com;
openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source]
RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp,
sender
I wasn't suggesting we reuse Bundle for OpenC2 objects.
I was suggesting conceptually that including header information that
comes with payload is a common concept that is helpful/useful in system
exchange and interoperability.
A couple of examples where header information is exchanged as part of
the protocol:
IPFIX
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=vye40KgawTF9bfgK8QTYb1ozN1psdkC8S8kd9ma_eQI&e=
HTTP
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7230&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=_XklyDamvyCOpONQt_MsG3rYEHIGXYbSRMyU3F3XlYI&e=
If OpenC2 is just a language then I would suggest we need to start
working on a protocol spec cause that’s what we need for products to
implement OpenC2.
Allan
On 1/29/18, 8:06 AM, "Kemp, David P" <dpkemp@radium.ncsc.mil> wrote:
You left out:
"Bundle is not a STIX object... Bundle is transient and
implementations should not assume that other implementations will treat
it as a persistent object."
I'm all for re-using stuff that has already been written. Package
up OpenC2 messages in a STIX Bundle.
If for some reason STIX Bundle couldn't be used for OpenC2, we could
define an OpenC2 container that bundles together OpenC2 messages and
header info.
Dave
-----Original Message-----
From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
Sent: Monday, January 29, 2018 11:01 AM
To: Kemp, David P <dpkemp@radium.ncsc.mil>; 'Bret Jordan'
<Bret_Jordan@symantec.com>; Sridhar Jayanthi <sridhar@polylogyx.com>
Cc: Brule, Joseph M <jmbrule@radium.ncsc.mil>; duncan@sfractal.com;
openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD
Source] RE: [openc2-lang] mandatory vs optional, Header, id, version,
timestamp, sender
Dave - Strictly not true in all cases.
A bundle object is one of the primary containers that is used to
exchange objects for STIX via collections and it has the spec version in
it.
See Section 5: Bundle in the core spec for STIX 2.0.
The intent of the Bundle object was to identify a 'packaged' set of
STIX objects and includes the version.
Allan
On 1/29/18, 7:45 AM, "openc2-lang@lists.oasis-open.org on behalf of
Kemp, David P" <openc2-lang@lists.oasis-open.org on behalf of
dpkemp@radium.ncsc.mil> wrote:
This really shouldn't be so difficult to understand for people
familiar with CTI.
TAXII is a transport protocol. It can transmit STIX objects.
The Version of the STIX object is not contained in the STIX object, it
is contained in the TAXII Accept header. Section 3 Core Concepts:
GET ...
Accept: application/vnd.oasis.stix+json; version=2.0
If TAXII or any other HTTP-based transport protocol is used to
carry OpenC2 messages, the OpenC2 version would likewise be carried in
the Accept header.
Dave
-----Original Message-----
From: openc2-lang@lists.oasis-open.org
[mailto:openc2-lang@lists.oasis-open.org] On Behalf Of Bret Jordan
Sent: Sunday, January 28, 2018 2:15 PM
To: Sridhar Jayanthi <sridhar@polylogyx.com>
Cc: Brule, Joseph M <jmbrule@radium.ncsc.mil>;
duncan@sfractal.com; openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD
Source] RE: [openc2-lang] mandatory vs optional, Header, id, version,
timestamp, sender
I think this is the heart of my frustration with this TC. I
agree with you, that there needs to be some sort of initialization
process. Otherwise how is a server to even know what it is you are
sending.
Some people are so worried about drawing an artificial line they
are forgetting about interoperability. Any two vendors, under the
current specification design, will be able to be fully compliant with
the conformance clauses and will have no guarantee that they will be
able to talk to or work with anyone else.
I find that to be a fundamental problem. There is currently no
guarantee for any vendor or device manufacturer that their
implementation they build will ever work with anyone else’s solution.
For example a network device or firewall vendor could go off and
build a solution based on all the verbs in OpenC2 and depending on how
they implement it, it is possible that no one else will be able to talk
to their equipment other than themselves.
Building standards is hard. And the longer we hold off on
discussing the purple elephants in the room, the more likely this will
never get adopted in mass.
Bret
Sent from my Commodore 64
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415
0050
On Jan 27, 2018, at 1:49 PM, Sridhar Jayanthi
<sridhar@polylogyx.com <mailto:sridhar@polylogyx.com> > wrote:
Bret,
My understanding of network protocols is very
limited. However, I am assuming I will have widespread agreement that
our language specs needs to be independent of the protocol. To achieve
this independence, we need some initialization language to help
establish an "OpenC2 connection" between devices/systems. Isn't this the
common thinking in the group? I am new to the group and may not have the
history of where exactly we are trying to fit in the stack, so I am
stating based on my understanding. Let me know if I am making a bad
assumption here.
Sridhar
--------------------------------------
Sridhar Jayanthi
Chief Executive Officer
PolyLogyx LLC.
Transforming Cyber Security
www.polylogyx.com<">https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_a_1_Q0zYrBWEYFkbKF31GtI8O-2D9cn3Ba6GDcuvbOO7QpNUQ-3D-3Fd-3DJtx4Y1xT8xGfwjHwOG0jO-2DCWSYI2nvaM-2DuliHiQuSs5eGqbWQ0-2DavCZRSBDpCHdVUzBuOvxUZMf8DSavxoyQB2I07OZRKps18hTGyKiBqXdfA2AgXMnSV7AunFncMY521tqRStNNlufQoHDnfJIPX0P5OUTaDO-2DdAS0nV20hfC6cAjxOymA5Gi5VYyvtM8H5muHkSN8kobzDj2sqqGKg3cGogXOcTGKS18b1vvbNnAsQsK5FbvQO3XZlVFc39cxx3IRJSc99UGYE0RbANWr-2DzAz5xOGWmBxJ8ZyQ61r7Kwpzt7a-2DLLzID5prpUXteMvme3YTG-2DG2tZ4ItirgdPSioqXKgSvXt-2Dg-2DrQlqdQ6iJ-2DGo8pz-2DIgLWCe5dzCMFWB2hDq-5FNaaDSDv7FJKyansLs0-5FskBmMsLQ9-5FVo70sy990GcCMhjXtN4lAXxX6dACu9g5w9sI7Pj33dvAYCqVNTl3S2pvvI6-2DYWLdzlySb-5Fzq4vsSPg-253D-253D-26u-3Dhttp-253A-252F-252Fwww.polylogyx.com&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=isQRaTKicBF57GETeH7GbS9wxKrujLbSyAhgBccEKMI&e=>;
Cell: +1-858-205-2252
On Fri, Jan 26, 2018 at 1:08 PM, Bret Jordan
<Bret_Jordan@symantec.com <mailto:Bret_Jordan@symantec.com> > wrote:
I would like to dig a bit
deeper here...
So are you suggesting that
OpenC2 have some sort of channel binding with the protocol that is
carrying it? Or are you suggesting that OpenC2 build in its own
negotiation protocol that sits on top of the transport ?
Bret
________________________________
From: Sridhar Jayanthi
<sridhar@polylogyx.com <mailto:sridhar@polylogyx.com> >
Sent: Friday, January 26, 2018
1:12:30 PM
To: Bret Jordan
Cc: Brule, Joseph M;
duncan@sfractal.com <mailto:duncan@sfractal.com> ; openc2-lang
Subject: Re: [openc2-lang] Re:
[EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs
optional, Header, id, version, timestamp, sender
Bret,
I can see the "handshake" word
may be misleading. I meant whatever initialization kicks off a
connection between two OpenC2-compliant systems. No matter what
carrier/protocol the OpenC2 command is riding on, the OpenC2 systems
need to identify each other and register the connection - that's a good
time to exchange these once-per-session fields. In some ways we may make
better progress on this if we get started with the threads (use cases).
Sridhar
--------------------------------------
Sridhar Jayanthi
Chief Executive Officer
PolyLogyx LLC.
Transforming Cyber Security
www.polylogyx.com<">https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_a_1_-2D6Dv3h8tLUHl-5FnfTjd9PBLzKajSIb1Ksn5Vcd2o9JKY-3D-3Fd-3D-5FjUTT4qxCwq-5FM3ECVhAAjvwRDDIOnU-5FfQG-2DU1BwWwQgYs6sHwU8otjv9DkK1h8S7VOm5GcxROY3VPjvxzOL1Rm3D0vlLzOZ3Db5DtBPop0ySxJuF313LfZEWH-2DHWrieOKP-5FcfFvuG9tAzMCcXZT6pNcPsD35L9ZvLx8zHNCXovofj9tg8tavFAM5JkO26O6pvYjln52IG1bvzWmFMidYvzQjQk3i9WwdL5gNLBYiAmCviB3H-2DR4fBJlcxHFu0sKZ7uHzNy9-5FvC63xL1K-2DppD-2Dt9AAt9xbepGe2LQcVDTXrr1CxSkNWFB9lJvDcy5bVnrzIuKkl45ihp6KF4ONGLpITVLNv2CVCjDywjhd29rFvQro2dNN0C2jvt-5F9JQvaHmkqN3X-5FNv8lmyZzkJBZkd-5FJhttWNISVICaGmDcTaRtnoQm9j4ahgBVm6L6km-2Dw3LB1qm71abyQgfucuk0FNGhx8KYp-2DRQZtwhuIcNPHpoY9r1Gdg-253D-253D-26u-3Dhttp-253A-252F-252Fwww.polylogyx.com&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=FmXCaAdnlcMdGWMTi7X4JmvbBSB47yYVRs-TvcebFNw&e=>;
Cell: +1-858-205-2252
<tel:(858)%20205-2252>
On Fri, Jan 26, 2018 at 12:05
PM, Bret Jordan <Bret_Jordan@symantec.com
<mailto:Bret_Jordan@symantec.com> > wrote:
OpenC2 is not
a protocol. So how do you expect to do this during the handshake? Do
we need to make OpenC2 a protocol?
Bret
________________________________
From: Sridhar
Jayanthi <sridhar@polylogyx.com <mailto:sridhar@polylogyx.com> >
Sent:
Thursday, January 25, 2018 10:36:01 PM
To: Bret
Jordan
Cc: Brule,
Joseph M; duncan@sfractal.com <mailto:duncan@sfractal.com> ; openc2-lang
Subject: Re:
[openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE:
[openc2-lang] mandatory vs optional, Header, id, version, timestamp,
sender
I concur with
Duncan and Joe about the need to make these fields optional. However, we
need to make sure identification-related fields including versions and
sender can be established during initial handshake. I am not
overthinking this at this time since there could be nuances that will
become clear during our use-case exercises. As has been said by many
before me, we may end up correcting our decision in some cases when we
work through the use cases.
--------------------------------------
Sridhar
Jayanthi
Chief
Executive Officer
PolyLogyx
LLC.
Transforming
Cyber Security
www.polylogyx.com<">https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_a_1_-2DaKK5uImR6XL3nK8kA3rEsIJCffU4I8BhOwvytiWEFM-3D-3Fd-3Dsv7tsOLRgHSu0VhEMnOVOJNoR9UoYBCRAbxh5kds64eY0I36RiQpoNjY06gSqI0pZf9ZyldNIEvTx4DksLvIi9cxr7WTFLtO5LK7pnQ9RFdPsA8dayM2E33-2Dw3O2WDw8FYGWIr7ayTdC-5FA3Ox7DxNItMyrGJD1E88LzhK9RT0TTYwwrDhJ6ezXpJMPhXYpGMR-5F6AaFDoiOOcU0wosM67ap4C-2DrZK38rU5eZE5mBjLc9QO6IGsgavv0WRHq3eHKkx7p7-2DYRHoabjP36mO5NO88ox4lM3DvhGxU1N4EOgcAjZ-5FG656xAzXFafUaeOBTAmr9w-5FGz-2DLX83rS-2D6LwszgcxiJqd9pYTu2GhNsamKJiQePftzd4H52yliEnPIncVk6BnplPLF9FBekVtbm3JhgQH9kRKAiRRRj5eycwTIRai-2D9R4po1GClQAKKagGhCFa75IWV99y7lXhMbp12Xrub8W2k3uRkPsexJVRoUT8aDxSPg-26u-3Dhttp-253A-252F-252Fwww.polylogyx.com&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=F3CHGwWcIMr5BUlw46d8qIXGptx7kyy5wT-BOXBZsyM&e=>;
Cell:
+1-858-205-2252 <tel:(858)%20205-2252>
On Thu, Jan
25, 2018 at 12:29 PM, Bret Jordan <Bret_Jordan@symantec.com
<mailto:Bret_Jordan@symantec.com> > wrote:
So Duncan and Joe are against it. Allan, Bret, and Dave are for it.
Bret
________________________________
From: openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org>
<openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org> > on behalf of Brule, Joseph M
<jmbrule@radium.ncsc.mil <mailto:jmbrule@radium.ncsc.mil> >
Sent: Thursday, January 25, 2018 9:58:53 AM
To: 'duncan@sfractal.com <mailto:duncan@sfractal.com> '; openc2-lang
Subject: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang]
mandatory vs optional, Header, id, version, timestamp, sender
Speaking as an OpenC2 TC member representing DOD and not as chair;
I agree with Duncan.
The focus of OpenC2 has been on unambiguous M2M exchanges and
we have always strived to be low overhead and agnostic of other
functional blocks. These (and other) principles and assumptions have
been in place since the TC’s inception.
Any analysis for the inclusion (or exclusion) of a particular
feature should be optimized for operations rather than development.
Though I can appreciate the challenges that product developers face, as
a representative of an agency that is a non-trivial consumer of IT and
security products, we are interested in operations.
The cost of additional fields is more than ‘a few bytes’.
Need to consider complexity. Vulnerabilities can be a function on the
order or 2^complexity. Integration costs increase with complexity.
Simplicity and low overhead is beneficial when one considers
the environment, such as the verbosity of the C2, heterogeneity of the
environment, the number of connected devices which is growing
exponentially. BTW I acknowledge that ‘exponential growth’ is
arguably the most abused cliché ever but is OK in this context.
There has been some discussion of ‘headers vs options field’
and ‘metadata vs header’. I fail to understand why one needs to
have some options in header fields and other options in an option field
or some hybrid where we have optional headers and optional options. Is
there a compelling reason to have ‘metadata’ type of options in one
field and different options in other fields? I took the liberty of
googling IPV6. Some of the IPV6 options (in the options field) include
routing, fragmentation, security payload header, authentication header,
host identity protocol and others. IPV6 will probably succeed ;-)
despite the fact that different types of options were in the same
‘options’ field….
In the context of particular options:
Command-id: A valuable option and likely to be used widely, but
not mandatory. There are use cases (interdomain effects based comes to
mind) where the id is not needed and there are others where it is
critical. Of all the options discussed, id is the option that one could
make the strongest case for making mandatory, but at this point I
consider it optional.
Version: We certainly need to know the version and the versions
have to be compatible, but is it necessary to include on each and every
message? Can the version be determined at initialization, or during a
negotiation procedure? One could contrive a possible scenario where a
product has multiple capabilities and some of the capabilities are on
version 1 and others are on a different version, so having the version
on each and every message could be a useful option. Having said that,
this is a hypothetical argument for an option not a mandatory header.
Timestamp: A nice option, but clearly can be treated as an
external dependency. In addition to Duncan’s points, there are
numerous other protocols that address logging, audit etc. thus a
‘mandatory’ timestamp on every command is not needed for a wide
range of use cases/ environments.
Sender: OpenC2 is at the application layer. Lower on the stack
there are multiple fields that could be used for purposes of identifying
the sender. At this point, I do not see sender as a particularly
useful option, let alone ‘mandatory’ for each and every command,
however this can be revisited once the use cases are brought to the LSC.
VR
Joe Brule
From: openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org>
[mailto:openc2-lang@lists.oasis-open.org<mailto:openc2-lang@lists.oasis-open.org>
] On Behalf Of duncan@sfractal.com <mailto:duncan@sfractal.com>
Sent: Wednesday, January 24, 2018 11:08 PM
To: openc2-lang <openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org> >
Subject: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional,
Header, id, version, timestamp, sender
Allan,
We can agree to disagree. Your opinions are based on your 'experience
of protocol and product development making it easier to develop and
debug production code.'. Mine is based on my experience doing the same.
I'm guessing, but I don't know, that I put less emphasis than you do on
'design/debug' and more about steady state operations.
If there are architectures/transport protocols/actuators where they
are mandatory, then make them mandatory in those specs - not in the
language. I've explained my reasons why I don't think they should be
mandatory in the Language Spec for every command every time in all
architectures/transports/actuators. You disagree. Our views cancel each
other out. Let's hear from others.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: Re: [openc2-lang] mandatory vs optional,
Header, id, version,
timestamp, sender
From: Allan Thomson <athomson@lookingglasscyber.com
<mailto:athomson@lookingglasscyber.com> >
Date: Wed, January 24, 2018 6:24 pm
To: "duncan@sfractal.com
<mailto:duncan@sfractal.com> " <duncan@sfractal.com
<mailto:duncan@sfractal.com> >, openc2-lang
<openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org> >
Duncan et al –
The suggestion to add these parameters was based on
experience of protocol and product development making it easier to
develop and debug production code. I agree in some use cases these
parameters might not be needed when things just work or everything is
homogenous environment but we are designing a specification for a
protocol that must support different tools, different versions,
different environments and therefore we need to design the protocol for
those cases. Including these fields is not a major problem for *any*
programming environment. All of the data is known by the programming and
environment that any tool will be deployed in. What harm exists if these
parameters mandatory? The # of bytes added to the message is minimal.
That is not a strong argument for making them optional.
Command-Id -> there is no reason why this can’t be
mandatory. This is a common construct across many protocols and
applications using those protocols. Optionality just introduces
complexity when implementations can easily support creating such a
parameter. This parameter is useful for tracking and also matching up
responses to commands. It allows products to show to users that commands
have been received correctly and what their responses were. If a use
case does not require this capability then just set the command-id to an
incrementing number and ignore the response’s value returning it.
Version -> A version of protocol/schema being used
to construct a message is 100% always known. Programmers that write code
have to know what version of the protocol they’re writing to.
Including this parameter in the messages is useful for compatibility
checking, verification that one system is talking to another that is
compatibility and is just common sense for debugging problems. If there
are problems connecting systems together this will be one of the first
questions a developer will want on why the commands are not executing
correctly. For systems that don’t care about this checking then just
hard-code the value and ignore compability checks.
Timestamp -> Same rationale as version. Every
logging function on the planet generates log messages with timestamps.
Time is known when a message is created. It is easily available to be
included in messages. Its useful for debugging and cross-correlation
across systems. If a system doesn’t care about it then just ignore its
value. Mandating that the field be filled in is hardly a problem for any
programmer to include a timestamp.
Allan Thomson,
CTO, Lookingglass Cyber Solutions
<">https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_a_1_ML2Z6Jn9Hoe2B8yMwjYTgBjWiP64DvXPTB1-2DbPKi1Rk-3D-3Fd-3Doab0Np-2DpNxsUQWO8f74TxTvjCl9tW-5FcS0RjQ7Q4oh4qZl4mmjuQfIYakCB-5FkaemvaguuQgYlNAxGFE-5Fba-2DIBcJVMCFUjdzGEUOWcy2E5pGwzPqrWhgsMg1oHBgMSetzLGTD-5FRtpR9CD3p61IWrJk7dANVoyiSpUHhcWqbx4GKvHjdUwOEWh1RyNuRW2Kofj7hbbPjwbiYb2jZL4QMpZbupYHQEV9rNxanpOTz0lRVnH2rplUP7dEbkRvZgSArXwANznv1TnaBo2HTtGlXOXbPCsrdTzOGDduzDhPxkniqsy7OC21YSiIg4weXh2zQBAKHEOA-5FXZH-2DvXN7YoY77f3pWOODjYWwBhG9ZXrxrW-2DukmPVEQ2giHRFxoD-2DXtFH6TVJH2Sbaeb2tGbnFKddz2ELMnMFWJY6XijEDMvTmvaCY-2D-2DSD-5Fox5vSuMU0-2DJ-5F2uC-5FF7t-2DroXpalFYWFiVHF8ea0BZCteKsPRMeThUzelIR9T3xDLlGLisJttoaY6hIu-5F9pXhAgflxvu8t4S2nbZQdbaZOs8YG2q5m9w8k2eKCPevWXiA-253D-253D-26u-3Dhttp-253A-252F-252Fwww.lookingglasscyber.com-252F&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=30JCoKDgBJ9LYaxqh1T84N2P4p917Rgixs1FFIFq0h4&e=>;
This electronic message transmission contains
information from LookingGlass Cyber Solutions, Inc. which may be
attorney-client privileged, proprietary and/or confidential. The
information in this message is intended only for use by the
individual(s) to whom it is addressed. If you believe that you have
received this message in error, please contact the sender, delete this
message, and be aware that any review, use, disclosure, copying or
distribution of the contents contained within is strictly prohibited
From: <openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org> > on behalf of
"duncan@sfractal.com <mailto:duncan@sfractal.com> " <duncan@sfractal.com
<mailto:duncan@sfractal.com> >
Date: Wednesday, January 24, 2018 at 6:51 AM
To: openc2-lang <openc2-lang@lists.oasis-open.org
<mailto:openc2-lang@lists.oasis-open.org> >
Subject: [openc2-lang] mandatory vs optional,
Header, id, version, timestamp, sender
I’m sending this email as sFractal Consulting, not
as LSC cochair, as a followup to yesterday’s discussions at the LSC.
Optional/Mandatory -
Language/Actuator/Implementation
There was discussion of whether a field should be
mandatory or optional. I think we need to take into account the
mandatory/optional decision is made in several places. If we make a
field mandatory in the language specification then it is mandatory in
all implementations in all architectures for all profiles. We should
remember that a field can be optional in the language specification but
required by either a profile (eg all firewalls SHALL implement
COMMAND-ID per language spec blah blah) or by an implementation
specification (eg all OpenDSS OC2 implementations SHALL implement
COMMAND-ID ...). I say this so you have context for what follows in the
email. In the LSC, we can only determine the optional/mandatory for the
Language Specification and will leave it to the AP-SC for profiles and
IC-SC for implementation.
COMMAND-ID
Yesterday at the LSC I think we reached consensus
among those present that a COMMAND-ID capability should go in the
language. I propose the field name be “id”, not “command-id”. I
am distinguishing between what we humans refer to the field (COMMAND-ID
in upper case) vs the ascii string that goes in the JSON (“id” in
lower case). I think it’s important to remember there is hierarchical
context within the JSON and we don’t need to burden the field names
with information humans need when discussing it. “id” would be
unambiguous in the JSON to both machines and humans.
In the case of COMMAND-ID, my gut says it should be
optional in the language specification but I could be convinced to make
it mandatory. In my use cases, I need it sometimes and not others. Ie I
have use cases where I don’t need it but I don’t see it as an burden
to add it for those use cases.
HEADER, VERSION, TIMESTAMP, SENDER
Where I feel more strongly is in the discussions of
other field we lumped with COMMAND-ID. For the benefit of those not
present at the discussion (and to record it for posterity since it’s
bound to resurface) there is a proposal on the table to distinguish
between two types of fields that are currently lumped under
COMMAND-OPTIONS. The proposal was made to pull out what (I think it was
Allan) called ‘HEADER’ or (I think it was Danny) called
‘METADATA’. I.e. they aren’t really options in the sense that they
are part of executing the command like the ‘DELAY’ option is. I
believe the “options” that got lumped in the HEADER category include
VERSION, TIMESTAMP, SENDER, and COMMAND-ID.
Although I maybe could be convinced to make
COMMAND-ID mandatory, I feel strongly that VERSION, TIMESTAMP, SENDER
should be optional in the Language Spec. One suggestion was to make
HEADER optional - but, if included, then ID, VERSION, TIMESTAMP, SENDER
are mandatory. I disagree with that approach - i.e. I would like to
optionally use ID without being forced to include the others.
SENDER
In my use cases, I only send commands over a secure,
mutually-authenticated communications channel. I personally would never
recommend executing a security command based on the SENDER field - I’d
need something more for authentication, and if I had it - then I
wouldn’t need the SENDER field. I’d welcome someone documenting a
use case, that they need and would implement, where SENDER is needed. I
recognize I don’t know everything, but I would insist someone pull out
their black pen and document that they will use it (i.e. I personally
won’t be swayed by hypothetical, but I would agree based on a stated
need by a member that they need it and would use it). In the past, it
seems to come up in discussions where STIX COA use cases are mentioned.
Maybe I just don’t understand that use case and I’d welcome someone
documenting it. Assuming such a use case gets documented, I’d agree to
it as an option but not as mandatory. This might get us into the 80/20
discussions of which uses are more common (with implication that if 80%,
make it mandatory). But I feel those arguments belong in AP-SC and IC-SC
since I feel they will be actuator and architecture dependent.
TIMESTAMP
In my use cases, I at the moment only send commands
point-to-point between a security orchestrator (SO) and an actuator (A)
over mutually authenticated (read the use case for details of CSA SPA
used) link carrying an API. In my use cases I do not need a TIMESTAMP in
the sense of ‘when was the command sent?’. As shown in my use cases,
I do need (as an option, i.e. not on every command, but sometimes) the
COMMAND-OPTION of allowing for the command to have a duration associated
with it (i.e. ‘classic’ command options). I recognize in the future
my security orchestrator may receive commands from ‘elsewhere’ (eg
if the Small Business Administration offered a STIX/TAXII feed with COA
in it, or my cloud providers, Amazon and/or RackSpace, send me openc2
about stuff they found). So I will distinguish between the SO-A and
SO-SO and confess I don't have fleshed out SO-SO use cases and maybe
TIMESTAMP makes sense there. If someone were to submit a black pen use
case that they need the HEADER TIMESTAMP, I’d agree to it as an option
but not as mandatory.
I’ll use a fictitious example to make my point on
language-optional, implementation-mandatory. Maybe the pubsub
implementors all feel TIMESTAMP is required on all OpenDSS
implementations (this is for explanatory purposes, I don’t know
OpenDSS well enough to know it this is true); then the OC2-on-OpenDSS
spec by the IC-SC could make TIMESTAMP mandatory while at the same time
their HTTPS-API spec specifies it SHALL NOT be used (again for
illustrative purposes). My point is it should be optional (if exists at
all - someone supply a use case) not mandatory in the Language
Specification.
VERSION
Although I do agree we should future proof the
language specification to the extent possible, I don’t feel we need to
go overboard on future proofing. My use cases are all software in the
cloud so are less constrained then those dealing with hardware or less
updatable software. I feel that since no one implements OC2 yet, it's
not unreasonable to assume future implementations will have updatable
software. All my use cases are API’s. I believe API versioning is
dependent on language versioning and will suffice for all my needs. Ie
the language does not need to include a version in every command since
the API will. I will defer to what the IC-SC decides for OC2-on-API but
I will recommend in that group that the version be part of the URL (as
opposed to a passed parameter) - ie it will be mandatory. I recognize
there are other architectures than https API. Assuming such a use case
where VERSION is needed gets documented, I’d agree to VERSION as an
option but not as mandatory.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
<a target="_blank"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=ZXxPeZtkHJZJm7Gm8MX8mgVkjtnEF05YPcqnn-QXDv4&e=";>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=58GIaCAHEiuaDAjDNjNNdV0tQn-UHdKKisva8m8mo40&s=ZXxPeZtkHJZJm7Gm8MX8mgVkjtnEF05YPcqnn-QXDv4&e=<https://clicktime.symantec.com/a/1/ejNqXPWYM5L8lslAzQ-_t5VfxMtHYuRxyGFFsmE2pFU=?d=oab0Np-pNxsUQWO8f74TxTvjCl9tW_cS0RjQ7Q4oh4qZl4mmjuQfIYakCB_kaemvaguuQgYlNAxGFE_ba-IBcJVMCFUjdzGEUOWcy2E5pGwzPqrWhgsMg1oHBgMSetzLGTD_RtpR9CD3p61IWrJk7dANVoyiSpUHhcWqbx4GKvHjdUwOEWh1RyNuRW2Kofj7hbbPjwbiYb2jZL4QMpZbupYHQEV9rNxanpOTz0lRVnH2rplUP7dEbkRvZgSArXwANznv1TnaBo2HTtGlXOXbPCsrdTzOGDduzDhPxkniqsy7OC21YSiIg4weXh2zQBAKHEOA_XZH-vXN7YoY77f3pWOODjYWwBhG9ZXrxrW-ukmPVEQ2giHRFxoD-XtFH6TVJH2Sbaeb2tGbnFKddz2ELMnMFWJY6XijEDMvTmvaCY--SD_ox5vSuMU0-J_2uC_F7t-roXpalFYWFiVHF8ea0BZCteKsPRMeThUzelIR9T3xDLlGLisJttoaY6hIu_9pXhAgflxvu8t4S2nbZQdbaZOs8YG2q5m9w8k2eKCPevWXiA%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php>;
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
<a target="_blank"
href="https://clicktime.symantec.com/a/1/ejNqXPWYM5L8lslAzQ-_t5VfxMtHYuRxyGFFsmE2pFU=?d=oab0Np-pNxsUQWO8f74TxTvjCl9tW_cS0RjQ7Q4oh4qZl4mmjuQfIYakCB_kaemvaguuQgYlNAxGFE_ba-IBcJVMCFUjdzGEUOWcy2E5pGwzPqrWhgsMg1oHBgMSetzLGTD_RtpR9CD3p61IWrJk7dANVoyiSpUHhcWqbx4GKvHjdUwOEWh1RyNuRW2Kofj7hbbPjwbiYb2jZL4QMpZbupYHQEV9rNxanpOTz0lRVnH2rplUP7dEbkRvZgSArXwANznv1TnaBo2HTtGlXOXbPCsrdTzOGDduzDhPxkniqsy7OC21YSiIg4weXh2zQBAKHEOA_XZH-vXN7YoY77f3pWOODjYWwBhG9ZXrxrW-ukmPVEQ2giHRFxoD-XtFH6TVJH2Sbaeb2tGbnFKddz2ELMnMFWJY6XijEDMvTmvaCY--SD_ox5vSuMU0-J_2uC_F7t-roXpalFYWFiVHF8ea0BZCteKsPRMeThUzelIR9T3xDLlGLisJttoaY6hIu_9pXhAgflxvu8t4S2nbZQdbaZOs8YG2q5m9w8k2eKCPevWXiA%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php";>https://clicktime.symantec.com/a/1/ejNqXPWYM5L8lslAzQ-_t-Your
data has been truncated.
<a target="_blank"
href="https://clicktime.symantec.com/a/1/ejNqXPWYM5L8lslAzQ-_t5VfxMtHYuRxyGFFsmE2pFU=?d=oab0Np-pNxsUQWO8f74TxTvjCl9tW_cS0RjQ7Q4oh4qZl4mmjuQfIYakCB_kaemvaguuQgYlNAxGFE_ba-IBcJVMCFUjdzGEUOWcy2E5pGwzPqrWhgsMg1oHBgMSetzLGTD_RtpR9CD3p61IWrJk7dANVoyiSpUHhcWqbx4GKvHjdUwOEWh1RyNuRW2Kofj7hbbPjwbiYb2jZL4QMpZbupYHQEV9rNxanpOTz0lRVnH2rplUP7dEbkRvZgSArXwANznv1TnaBo2HTtGlXOXbPCsrdTzOGDduzDhPxkniqsy7OC21YSiIg4weXh2zQBAKHEOA_XZH-vXN7YoY77f3pWOODjYWwBhG9ZXrxrW-ukmPVEQ2giHRFxoD-XtFH6TVJH2Sbaeb2tGbnFKddz2ELMnMFWJY6XijEDMvTmvaCY--SD_ox5vSuMU0-J_2uC_F7t-roXpalFYWFiVHF8ea0BZCteKsPRMeThUzelIR9T3xDLlGLisJttoaY6hIu_9pXhAgflxvu8t4S2nbZQdbaZOs8YG2q5m9w8k2eKCPevWXiA%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php";>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]