openc2 — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Re: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
I added Option 4 to the wiki.
Allan Thomson,
CTO,
Lookingglass Cyber Solutions
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:
"Waltermire, David A. (Fed)" <[email protected]>
Date: Thursday, September 7, 2017 at 12:29 PM
To: Allan Thomson <[email protected]>, "Brule, Joseph M" <[email protected]>, Bret Jordan <[email protected]>, "[email protected]" <[email protected]>, TC OpenC2 <[email protected]>
Subject: RE: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
Right. My option allows for multiple targets to be provided. While it is derived from option 2, it is more than any of the other options since it provides support for multiple
targets. From the link you sent around, my option is the only solution that has been suggested that allows multiple targets to be expressed. I believe it should be added as an option 4.
Here is the approach aligned with the text of your wiki options:
{
"action": {
"type": "
one of 33 actions
",
"options": {
one or more of the six legacy modifiers
}
},
"targets": [
// first target
{
"type" : “
from target data model
",
"specifiers: {
IAW the property tables or schema
},
"options": {
IAW the property tables or schema
}
},
// additional targets can also be added
{
“type” : “
from target data model
”,
“specifiers: {
IAW the property tables or schema
},
“options: {
IAW the property tables or schema
}
}
]
}
Hope this helps.
Regards,
Dave
From:
Allan Thomson [mailto:[email protected]]
Sent: Thursday, September 07, 2017 2:23 PM
To: Brule, Joseph M <[email protected]>; Waltermire, David A. (Fed) <[email protected]>; Bret Jordan <[email protected]>; [email protected]; TC OpenC2 <[email protected]>
Subject: Re: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
Joe – the proposal by David where the targets are a flat array works. On the wiki you capture my input as ‘nested’. I was pointing out a problem with the flat design that needs
to be resolved.
We don’t need nested. We just need unambiguity of the JSON fields. Otherwise you have a broken spec.
Allan Thomson,
CTO,
Lookingglass Cyber Solutions
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:
"Brule, Joseph M" < [email protected]
>
Date: Thursday, September 7, 2017 at 11:08 AM
To: "Waltermire, David" < [email protected] >, Allan Thomson < [email protected] >, Bret Jordan < [email protected] >,
" [email protected] " < [email protected] >, TC OpenC2 < [email protected]
>
Subject: RE: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
All,
I am in the process of gleaning the relevant items from this thread (and other sources such as slack) so that we could move this to a wiki. A wiki will provide
a more concise and organized collection of the points and counterpoints.
I think if we work on our OASIS wiki, we will be able to provide the points, counterpoints and discussion in a single and easy to navigate location. This can
provide background and context to the discussion(s).
Does it make sense to use the email distro as a means for communicating resolutions and other media (such as wiki) for deliberation? I am concerned that some
of the context and discussion will get obfuscated in a sea of email….
https://wiki.oasis-open.org/openc2/EncodingStyle
From:
[email protected] [ mailto:[email protected] ]
On Behalf Of Waltermire, David A. (Fed)
Sent: Wednesday, September 6, 2017 2:20 PM
To: Allan Thomson < [email protected] >; Bret Jordan < [email protected] >;
[email protected] ; TC OpenC2 < [email protected]
>
Subject: [Non-DoD Source] RE: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
Multiple targets could be represented like this:
{
"action": {
"type": "copy",
"options": {}
},
"targets": [
{
"type" : "file",
"specifiers: {},
"options": {}
},
{
“type” : “registry-key”,
“specifiers: {},
“options: {}
}
]
}
A single target could be represented as a single array member.
Thoughts?
Regards,
Dave
From:
Allan Thomson [ mailto:[email protected] ]
Sent: Wednesday, September 06, 2017 1:51 PM
To: Waltermire, David A. (Fed) < [email protected] >; Bret Jordan < [email protected] >;
[email protected] ; TC OpenC2 < [email protected]
>
Subject: Re: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
The only issue I see with Option 1 is that if there is an intention to have multiple targets in the same target specification.
For example with Option 1 the following would * not * be possible as specifiers and options are now ambiguous.
Option 1:
{
"action": {
"type": "copy",
"options": {}
},
"target": {
"type" : "file",
"specifiers: {},
"options": {}
“type” : “registry-key”,
“specifiers: {},
“options: {}
}
}
Whereas with Option 2 (the specifiers and options are not ambiguous):
Option 2:
{
"action": {
"copy": {
"options": {}
}
},
"target": {
"file": {
"specifiers: {},
"options": {}
},
“registry-key” : {
"specifiers: {},
"options": {}
}
}
}
So if having multiple targets in the same target specification is not needed then it’s a non-issue.
If multiple targets are needed then this problem needs a solution.
Therefore I have a slight preference for Option 2 (*if* multiple targets are needed).
Allan
p.s. Option 1 could be solved by naming the specifiers and options as “file-specifier” and “file-options” but that is not ideal.
From:
< [email protected]
> on behalf of "Waltermire, David A. (Fed)" < [email protected]
>
Date: Wednesday, September 6, 2017 at 9:39 AM
To: Bret Jordan < [email protected] >, " [email protected] " < [email protected] >, TC OpenC2 < [email protected]
>
Subject: [openc2] RE: [EXT] [openc2] Modifier to become Action-Option
I have a preference for option 1 largely because I believe the BNF can be made more simple around this syntax, without having to account for specific target types. Enforcement
of specific target types and type specific options can then be handled post-parse by business logic enforcing content co-constraints.
Regards,
Dave
From:
[email protected] [ mailto:[email protected] ]
On Behalf Of Bret Jordan
Sent: Wednesday, September 06, 2017 11:17 AM
To:
[email protected] ; TC OpenC2 < [email protected]
>
Subject: [openc2] Re: [EXT] [openc2] Modifier to become Action-Option
Yes, I fully support this change. In addition to this we have design issue with our current structure. Today we have:
{
"action": {
"type": "copy",
"options": {}
},
"target": {
"file": {
"specifiers: {},
"options": {}
}
}
}
This represents a bad form with its design. The action property is flat while the target is nested. We should do one or the other. There are two real options here, and they both
have the same semantic meaning. Personally, flat designs are generally more preferable, and they represent a good design principle (flatter is better than nested). The advantage of nested is you can quickly make parsing decisions about which struct to unmarshal
content in to based on the key name. So I can go either way, but we should pick one style of encoding.
Option 1:
{
"action": {
"type": "copy",
"options": {}
},
"target": {
"type" : "file",
"specifiers: {},
"options": {}
}
}
Option 2:
{
"action": {
"copy": {
"options": {}
}
},
"target": {
"file": {
"specifiers: {},
"options": {}
}
}
}
Bret
From:
[email protected] < [email protected]
> on behalf of
[email protected] < [email protected]
>
Sent: Monday, September 4, 2017 3:18:37 PM
To: TC OpenC2
Subject: [EXT] [openc2] Modifier to become Action-Option
An issue was discussed and resolved at the last Language Subcommittee
that the Modifier field move under Action and be action-option. Since
this is a relatively major change, it is being communicated to the the
TC mailing list.
A wiki page was created for this issue at
https://clicktime.symantec.com/a/1/4ZB73huEVk4m4G4BVhqWi7fMUB0u1Oc_vLzhEIH4Qr8=?d=lgF3yCMdJLpr2hoS6bxs4YL-vUnzWGbkKQEzB2bgA_H5mbF_oFvunb9iw0XNrDodmItASA4L3KRPul2fmVkB74LP2gBcgZRiTA4mpq_PESfctOcLwm9LDtlauaaYY8oL3vVIq3fkEqEs9IYXuI3tFnAmdE2M8qSUgk5a3ZY6P4zZJej-ZSP8VamePJyrY9yJkSEuJTr63eRaeHzIBx0R4N1GA8Zy9QY2RVWdF2bXWm3QmJz94qdql27QkX09F7SPJn-2l61rhwh8RdeWnYTR5iZx41tT1YrBTn7kimp3M41Jl7vRgzyGo3hqh45e9QwK36pQTtzJY91NCdq7FP-zA0gUPhKwcRmJdjoWXk8ojA8lGd0iM3dMW1N0xOPUvADrwK6dz7f7rW4SZSu6gKs9DBKMCAyvr4kpjShh0BEi-OB7almext8XHOClGRH7-_aFMqz7rslqaa_zi9YJxajl56ANUeRrw1cO0ipBXM4kYOk%3D&u=https%3A%2F%2Fwiki.oasis-open.org%2Fopenc2%2FModifierOnAction
but the content will
be repeated here:
"The language specification previously defined the openc2 command as
having 4 components:
+ action (mandatory)
+ target (mandatory)
+ actuator (optional)
+ modifier (optional)
At the 29-Aug-2017 Language Subcommittee meeting, Allan Thomson of
Looking Glass raised the issue of whether 'modifier' belonged as a peer
to action or as part of action. Targets have target-specifiers and
target-options and the issue was whether modifier was really an
action-option. Bret Jordan of Symantec supported this view with the
argument it would be easier for vendors to adopt openc2 since it would
be easier to understand. The issue was raised by DuncanSparrell
(speaking as sFractal Consulting and software developer of ocas, not as
co-chair) that this was a significant change to something that has been
stable for 2 years and that any software already written would have to
be changed. It was observed that the purpose of the SC was to get input
and that changes were to be expected.
The argument that it would increase vendor adoption was significant as
everyone agreed that increased vendor adoption would be beneficial.
Consensus was reached that modifier would move to action-option. The
changes to the Language Specification that result from this will be
reviewed at the next meeting."
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://clicktime.symantec.com/a/1/Km-wOTq-1nndQkBooSUDh3NIDtFY7FPX5qgQs5818tI=?d=lgF3yCMdJLpr2hoS6bxs4YL-vUnzWGbkKQEzB2bgA_H5mbF_oFvunb9iw0XNrDodmItASA4L3KRPul2fmVkB74LP2gBcgZRiTA4mpq_PESfctOcLwm9LDtlauaaYY8oL3vVIq3fkEqEs9IYXuI3tFnAmdE2M8qSUgk5a3ZY6P4zZJej-ZSP8VamePJyrY9yJkSEuJTr63eRaeHzIBx0R4N1GA8Zy9QY2RVWdF2bXWm3QmJz94qdql27QkX09F7SPJn-2l61rhwh8RdeWnYTR5iZx41tT1YrBTn7kimp3M41Jl7vRgzyGo3hqh45e9QwK36pQTtzJY91NCdq7FP-zA0gUPhKwcRmJdjoWXk8ojA8lGd0iM3dMW1N0xOPUvADrwK6dz7f7rW4SZSu6gKs9DBKMCAyvr4kpjShh0BEi-OB7almext8XHOClGRH7-_aFMqz7rslqaa_zi9YJxajl56ANUeRrw1cO0ipBXM4kYOk%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]
| [Month Index]
| [List Home]