Evolutionary Requirements Development for HTTPS REST API use case

I probably should be more semantically pedantic to avoid confusion. Agile is most commonly associated with development of the software - and we are developing a specification. There are 3 styles of agile software development (iterative, incremental, evolutionary - see https://dzone.com/articles/3-styles-agile-iterative) and in two (iterative, incremental) of the 3, the requirements are still done 'all up front' and it's just the software development that is agile. I fully expect most vendors would not implement OpenC2 interfaces until the spec was complete enough to provide value to their customers and stable enough to avoid having to continually update their software as the specification evolves.

Having said that, I still argue for doing the specification development using the evolutionary agile approach. Some/most vendors can wait to implement, but the prototyping community can use evolutionary software development. That is why I advocated moving from 'incremental by section' to 'incremental by thread' in the LSC. Once a single thread is complete, prototyping (and production for the brave or those with most to gain), development can be done. I maintain this will create a better specification sooner. It does recognize we may not get it right on the early threads and have to make 'breaking' changes. It's possible STIX might have uncovered some of 1.0/2.0 changes sooner if this approach had been used. But probably not, because STIX was a green field since the threat information exchange concept was new. So for STIX in early days it would have been hard to do evolutionary. OpenC2 is quite different since zillions of vendor api's already exist so we are just proposing changing stuff instead of creating stuff that never existed. As shown by Zepko and AT&T, users can put OpenC2 interfaces on products without the vendor even knowing. And as shown by the JHU/APL studies, there are huge gains to be made (reduced by two orders of magnitude the time the attacker was in the system). These are huge gains and I think play well with the evolutionary specification development approach (ie incentive to try less-complete stuff earlier). Hence why I advocate using it.

Note I'm not saying we make a CS per month. I'm just saying we develop WD's using threads (end to end slices thru the system that are more breadth-first than depth-first), and do 'frequent' (time tbd, probably based on when we reach agreement on something that allows a thread to be prototyped) validation with the TC by submitting CSD's. Ie submit partials as we go rather than wait for finished product.

To reach the same level of depth and breadth, evolutionary agile generally takes longer than waterfall. However I believe there is general industry agreement that (1) you get something usable sooner with evolutionary agile (it's usable for some threads but not others) and (2) when you do reach the depth/breadth target (ie 'complete' by the waterfall definition), that evolutionary agile has a higher probability of being what is needed (because you got something-partial in users hands sooner and discovered what needed to change).

I won't be able to make the next IC-SC meeting so discuss it and I'll live with whatever you decide.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

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

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

From: Bret Jordan <>

Date: Sat, March 17, 2018 4:40 pm

To: "" <>

Cc: ""

<>

     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