RE: [Non-DoD Source] Re: [openc2-imple] Re: [EXT] [openc2-imple] HTTPS REST API use case

Dave,

 

I like your bullets from September 6, I think it is a good capture.  The last bullet I definitely agree with requiring multiple transports, but would certainly
 not preclude other transports.  

 

As far as does https fit the bill?  I think it will measure up well for a lot of the goals, but let’s put some black on white followed by red on black and see….

 

VR

 

Joe B

 

From:  [mailto:]
On Behalf Of Dave Lemire

Sent: Monday, March 19, 2018 1:42 PM

To: Bret Jordan <>

Cc: ; 

Subject: [Non-DoD Source] Re: [openc2-imple] Re: [EXT] [openc2-imple] HTTPS REST API use case

 

In my notes from the Sept. 6th IC-SC call, I have the following as a list of goals for a transfer solution:

Fast: work in semi-NRT

Secure:  authenticated

Ubiquitous transport; some instances might need multiple protocols or profiles (e.g., IoT world might need lighter weight transport)

Fidelity of information (along with secure / authenticated)

Easy to implement, to facilitate adoption

AVOID: Multiple transports for one class of devices (interoperability obstacle). Cloud service would be HTTPS type system, which might work for most (non-IoT) use cases.

It sure seems like an HTTPS-based solution scores well against that list of goals. And I certainly feel like we have a working consensus significantly beyond 1-2 people for moving forward with specifying an HTTPS solution.

 

Dave

 

On Mon, Mar 19, 2018 at 1:21 PM, Bret Jordan <> wrote:

While I like HTTP, I am not sure this is actually going to meet the requirements. I would further state that a short list from 1-2 people is not a list of requirements.  

 

The transport we end up picking may have implications on the information model, so we need to make sure we do this carefully. It is not just a matter of picking something.

 

Bret

From: Dave Lemire <>

Sent: Monday, March 19, 2018 9:27:17 AM

To: Bret Jordan

Cc: ;


Subject: Re: [openc2-imple] Re: [EXT] [openc2-imple] HTTPS REST API use case

 

Simply put: It seems pretty obvious to me that an HTTPS transfer solution would be widely applicable.

 

I'd also agree with Duncan that I think use cases exist.  I've been looking back of IC-SC meeting notes, and as Duncan has noted we agreed back in September that HTTPS would be one of the transfer solutions.

 

Dave

 

David P. Lemire, CISSP

  OpenC2 Technical Committee Executive Secretary

  OpenC2 Implementation Considerations SC Co-chair

  Contractor support to NSA

Email: 

Office: 301-575-5190 / Mobile:
240-938-9350 

 

On Sat, Mar 17, 2018 at 4:40 PM, Bret Jordan <> wrote:

Agile development works when you first understand what you are trying to build.  Without sufficient up front analysis from many different contributors we run the risk of using agile development to build something that does not meet our
 needs or does not work for the market.   

 

Bret 

 

Sent from my Commodore 128D 

 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Mar 17, 2018, at 2:36 PM, "" <> wrote:

Bret, et al,

Wrt to use cases for an HTTPS REST API use cases - I thought we had done

that already. 

I submitted a google doc to the IC-SC on Aug 2, 2017. Subsequently I

started using git hub and I would point to

https://clicktime.symantec.com/a/1/NFnt0U2e_KC4qxCkJCdBlHZIPEnhk6xVJKJFd3j-fvc=?d=DQ7Uj2q5BykOg7rB9_jlPB7w7ExgQxf3wRhm0gEDR3PMa72iYXx_Ppi0bYiKvFQhBNaR-rJeb3jcb1ZvBSOu04ZtaySN4oszwy6pJY9Z6cHBF4RXYDSFXC_qR14Jw4Plfe1wdTdAkzeVHG1pTW-rDhjJ04LrUnUAx6Fzn_XlDCLaysyr6O6JqF0dJ53CpgActaNgSgzOYp7KM1PiY5Hs2fkackSkjt8wIqcvk0qnAji4oiJFDwHnXyxQM_tnTDwQYR5qaqfzhOQVT05PiDp2pJoPv7tL3N8x4pBTqOJZxHnUoQ18Qvgl0l0BUKxb7F85iEOP3pFKI2JjrQZuzJAIBlEFsRyzgJLz00s1rq9X6rTj4p97-g1GngwUPKzJ0pO0NIjxUT2gOuXFvEsISugGu4gzg3ry3XdB8hn51v96l1MvIKpuVPLMYPll7O09vsCN7yCv1PXTkkK5FyNP7xd-Q6rCXDPDp6EohgLrUzjRLs7Iiw%3D%3D&u=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fopenc2-lsc-usecases%2Fblob%2Fmaster%2FsFractalConsulting%2F01.another_user.md

as an example use case for HTTPS REST API. In that particular use case

openc2 is used over an https rest api's to two different firewalls.

Sidenote: it's good sending this email caused me to reread that use case

because I caught a typo :-).

Wrt requirements I would propose an incremental agile approach over a

waterfall approach.

Note that in 
01.another_user.md that one of the firewalls is a CSA SDP

enabled firewall. My intent is to add code to the proposed

openc2-lycan-beam open source repository to put an https rest api openc2

interface to the code Mike Stair wrote and was just accepted by the

fwknop project in pull request 260

(https://clicktime.symantec.com/a/1/MpJGlz-f9dikbuiYnvVlSy7zTHKKoudsuJ7q_LYq1c4=?d=DQ7Uj2q5BykOg7rB9_jlPB7w7ExgQxf3wRhm0gEDR3PMa72iYXx_Ppi0bYiKvFQhBNaR-rJeb3jcb1ZvBSOu04ZtaySN4oszwy6pJY9Z6cHBF4RXYDSFXC_qR14Jw4Plfe1wdTdAkzeVHG1pTW-rDhjJ04LrUnUAx6Fzn_XlDCLaysyr6O6JqF0dJ53CpgActaNgSgzOYp7KM1PiY5Hs2fkackSkjt8wIqcvk0qnAji4oiJFDwHnXyxQM_tnTDwQYR5qaqfzhOQVT05PiDp2pJoPv7tL3N8x4pBTqOJZxHnUoQ18Qvgl0l0BUKxb7F85iEOP3pFKI2JjrQZuzJAIBlEFsRyzgJLz00s1rq9X6rTj4p97-g1GngwUPKzJ0pO0NIjxUT2gOuXFvEsISugGu4gzg3ry3XdB8hn51v96l1MvIKpuVPLMYPll7O09vsCN7yCv1PXTkkK5FyNP7xd-Q6rCXDPDp6EohgLrUzjRLs7Iiw%3D%3D&u=https%3A%2F%2Fgithub.com%2Fmrash%2Ffwknop%2Fpull%2F260)
 to be able to accomplish that

part of the use case. I also plan to add openc2 to the existing pfsense

https rest api

(https://clicktime.symantec.com/a/1/sWb5GVMwyNoLHv4RTlwOx18VwHTeryAunBmuspyvgII=?d=DQ7Uj2q5BykOg7rB9_jlPB7w7ExgQxf3wRhm0gEDR3PMa72iYXx_Ppi0bYiKvFQhBNaR-rJeb3jcb1ZvBSOu04ZtaySN4oszwy6pJY9Z6cHBF4RXYDSFXC_qR14Jw4Plfe1wdTdAkzeVHG1pTW-rDhjJ04LrUnUAx6Fzn_XlDCLaysyr6O6JqF0dJ53CpgActaNgSgzOYp7KM1PiY5Hs2fkackSkjt8wIqcvk0qnAji4oiJFDwHnXyxQM_tnTDwQYR5qaqfzhOQVT05PiDp2pJoPv7tL3N8x4pBTqOJZxHnUoQ18Qvgl0l0BUKxb7F85iEOP3pFKI2JjrQZuzJAIBlEFsRyzgJLz00s1rq9X6rTj4p97-g1GngwUPKzJ0pO0NIjxUT2gOuXFvEsISugGu4gzg3ry3XdB8hn51v96l1MvIKpuVPLMYPll7O09vsCN7yCv1PXTkkK5FyNP7xd-Q6rCXDPDp6EohgLrUzjRLs7Iiw%3D%3D&u=https%3A%2F%2Fgithub.com%2Fndejong%2Fpfsense_fauxapi%2Fblob%2Fmaster%2FREADME.md)
 but 

that is more challenging and further down the pike. 

Since you (Bret) work at Symantec, I thought I'd point out Symantec

Endpoint Protection Manager as a potential use case the group may want

to consider as well. I note the Phantom usecases do not include the

Symantec Endpoint Protection Manager by name in the use case they have

been focusing on but they do include it the 'all_actions_in_phantom' use

case (ie it's one of the hundreds we haven't gotten to yet - but it

shows it is of interest to their customers). Symantec has good

documentation for this REST API at

https://symwisedownload.symantec.com//resources/sites/SYMWISE/content/live/DOCUMENTATION/9000/DOC9447/en_US/REST_API_Ref_SEP14.pdf

and I would think would be a candidate for OpenC2. Even if we don't use

it as an use case, it is good as a reference for requirements we should

consider. In the Language SC the debate has been over how to do

versioning (among other things). The Symantec interface is a good

example of how the version is in the URL of each command (not in the

JSON) - search GET or POST in the document and you will see url's like

"GET /api/v1/policy-objects/fingerprints" which has v1 in the URL. I

personally recommend a similar

approach (ie version in the url) be specified in the Openc2 https rest

api.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

-------- Original Message --------

Subject: [openc2-imple] Re: [EXT] Re: [openc2-imple] HTTPS REST API

From: Bret Jordan <>

Date: Sat, March 17, 2018 5:10 am

To: Danny Martinez <>

Cc: Duncan Sparrell <>,

"" <>

Before we rush into picking a solution, we really need to spend the

time up front identifying the use cases and requirements.  

Bret 

Sent from my Commodore 128D 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Mar 16, 2018, at 9:10 PM, Danny Martinez <>

wrote:

 Duncan, 

I think that this would be a great use case to explore. I recently had a

conversation with Dave Lemire about this. 

Of particular interest are devices that are inaccessible by an

orchestrator, like devices that may be using NAT or behind a firewall

with no port fowarding. The "Polling" mode of initiation where an

actuator reaches out to an orchestrator in order to see if any actions

need to be carried out. 

This is not to omit the cases when the orchestrator does have access to

an actuator. This has merit as well.

However, HTTPS and REST API are known to work well in scenarios where

they are being queried at high volume and therefore I think that a

"polling" scenario would benefit from this type of transport mechanism,

specially if exposed to the internet such as IOT devices.

V/R

On Fri, Mar 16, 2018 at 4:18 PM, <> wrote:

  I personally think (and I believe IC-SC had previously agreed) that

one of the transport mechanisms be a HTTPS REST API. I recommend the

IC-SC begin to draft such a specification and I would agree to be a

co-editor of that spec if desired. 

I recommend the HTTPS REST API be specified using another existing

standard - OpenAPI (https://clicktime.symantec.com/a/1/G86C9_RT469ZSdONjkaMQ7-wU9Hm1JjapblOgJDEvSo=?d=DQ7Uj2q5BykOg7rB9_jlPB7w7ExgQxf3wRhm0gEDR3PMa72iYXx_Ppi0bYiKvFQhBNaR-rJeb3jcb1ZvBSOu04ZtaySN4oszwy6pJY9Z6cHBF4RXYDSFXC_qR14Jw4Plfe1wdTdAkzeVHG1pTW-rDhjJ04LrUnUAx6Fzn_XlDCLaysyr6O6JqF0dJ53CpgActaNgSgzOYp7KM1PiY5Hs2fkackSkjt8wIqcvk0qnAji4oiJFDwHnXyxQM_tnTDwQYR5qaqfzhOQVT05PiDp2pJoPv7tL3N8x4pBTqOJZxHnUoQ18Qvgl0l0BUKxb7F85iEOP3pFKI2JjrQZuzJAIBlEFsRyzgJLz00s1rq9X6rTj4p97-g1GngwUPKzJ0pO0NIjxUT2gOuXFvEsISugGu4gzg3ry3XdB8hn51v96l1MvIKpuVPLMYPll7O09vsCN7yCv1PXTkkK5FyNP7xd-Q6rCXDPDp6EohgLrUzjRLs7Iiw%3D%3D&u=https%3A%2F%2Fwww.openapis.org%2F).
 I believe we should use

OpenAPI V2 since V3 is still being worked (but switch to V3 once it is

available). OpenAPI specifications can written in JSON or YAML - I

recommend we use JSON since it would be weird (but I guess allowed) to

write a YAML spec on how to send JSON. Note code generation for OpenAPI

specified API's exist in over 40 languages, and OpenAPI is used in many

API specifications (Google's probably being the most well known - I am

at a conference at the moment, literally sitting in talk by Google on

their use of OpenAPI, which prompted me to sent these emails).

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/a2jDHa7iAvYSIkGKUmRT-9fK-QKSt1VW8bqgTPVwf_w=?d=DQ7Uj2q5BykOg7rB9_jlPB7w7ExgQxf3wRhm0gEDR3PMa72iYXx_Ppi0bYiKvFQhBNaR-rJeb3jcb1ZvBSOu04ZtaySN4oszwy6pJY9Z6cHBF4RXYDSFXC_qR14Jw4Plfe1wdTdAkzeVHG1pTW-rDhjJ04LrUnUAx6Fzn_XlDCLaysyr6O6JqF0dJ53CpgActaNgSgzOYp7KM1PiY5Hs2fkackSkjt8wIqcvk0qnAji4oiJFDwHnXyxQM_tnTDwQYR5qaqfzhOQVT05PiDp2pJoPv7tL3N8x4pBTqOJZxHnUoQ18Qvgl0l0BUKxb7F85iEOP3pFKI2JjrQZuzJAIBlEFsRyzgJLz00s1rq9X6rTj4p97-g1GngwUPKzJ0pO0NIjxUT2gOuXFvEsISugGu4gzg3ry3XdB8hn51v96l1MvIKpuVPLMYPll7O09vsCN7yCv1PXTkkK5FyNP7xd-Q6rCXDPDp6EohgLrUzjRLs7Iiw%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php
  

-- 

  Danny Martinez

Cybersecurity Engineer

G2, Inc.

302 Sentinel Drive, Suite 300

Annapolis Junction, MD 20701

Mobile: 407-257-0031

---------------------------------------------------------------------

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/a2jDHa7iAvYSIkGKUmRT-9fK-QKSt1VW8bqgTPVwf_w=?d=DQ7Uj2q5BykOg7rB9_jlPB7w7ExgQxf3wRhm0gEDR3PMa72iYXx_Ppi0bYiKvFQhBNaR-rJeb3jcb1ZvBSOu04ZtaySN4oszwy6pJY9Z6cHBF4RXYDSFXC_qR14Jw4Plfe1wdTdAkzeVHG1pTW-rDhjJ04LrUnUAx6Fzn_XlDCLaysyr6O6JqF0dJ53CpgActaNgSgzOYp7KM1PiY5Hs2fkackSkjt8wIqcvk0qnAji4oiJFDwHnXyxQM_tnTDwQYR5qaqfzhOQVT05PiDp2pJoPv7tL3N8x4pBTqOJZxHnUoQ18Qvgl0l0BUKxb7F85iEOP3pFKI2JjrQZuzJAIBlEFsRyzgJLz00s1rq9X6rTj4p97-g1GngwUPKzJ0pO0NIjxUT2gOuXFvEsISugGu4gzg3ry3XdB8hn51v96l1MvIKpuVPLMYPll7O09vsCN7yCv1PXTkkK5FyNP7xd-Q6rCXDPDp6EohgLrUzjRLs7Iiw%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php