openc2-lang message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
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>
- To: "Kemp, David P" <dpkemp@radium.ncsc.mil>
- Date: Mon, 29 Jan 2018 18:46:59 +0000
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: 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: 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-_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>
- References:
- RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: <duncan@sfractal.com>
- Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: Sridhar Jayanthi <sridhar@polylogyx.com>
- Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: Bret Jordan <Bret_Jordan@symantec.com>
- Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: Sridhar Jayanthi <sridhar@polylogyx.com>
- Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: Bret Jordan <Bret_Jordan@symantec.com>
- Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: Sridhar Jayanthi <sridhar@polylogyx.com>
- Re: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: Bret Jordan <Bret_Jordan@symantec.com>
- RE: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: "Kemp, David P" <dpkemp@radium.ncsc.mil>
- RE: [openc2-lang] Re: [EXT] [openc2-lang] RE: [Non-DoD Source] RE: [openc2-lang] mandatory vs optional, Header, id, version, timestamp, sender
- From: "Kemp, David P" <dpkemp@radium.ncsc.mil>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]