OASIS Open Command and Control (OpenC2) TC

 View Only

  • 1.  New work product? CACAO & OpenC2

    Posted 13 days ago

    TC Members:  Those who attended this morning's TC Meeting session heard Duncan and I briefly discuss a candidate work product proposal that I elected to defer pending future discussion. I realized that it would benefit any future discussion to share the background and my current uncertain thinking, in preparation for the discussion I've placed on the agenda for next Wednesday's working meeting.

     

    At the 27 March working meeting we talked a lot about the relationship between CACAO and OpenC2. I mentioned several issues I'd created in the CACAO GH Repo after a careful read of the CACAO v2.0 spec, particularly:

    • #6: OpenC2 Support Should Be Updated (particularly, stale HTTP transfer info and no mention of pub/sub messaging)
    • #7: Practicalities of CACAO / OpenC2 Integration (basically, how do you connect an action-oriented tech like OpenC2 to a somewhat less dynamic tech like playbooks?)

     

    The CACAO TC leadership's response boils down to "tell us what we should do", and they suggested defining an OpenC2 extension for CACAO as a new OpenC2 TC work product, similar to the Layout Extension that the CACAO Roaster folks created. I took an action to define what an OpenC2 Extension work product might look like, gave it some thought, and came up with the following:

     

    Title: CACAO OpenC2 Extension

     

    Abstract:  Collaborative Automated Course of Action Operations (CACAO) is a schema and taxonomy for cyber security playbooks. The CACAO specification describes how these playbooks can be created, documented, and shared in a structured and standardized way across organizational boundaries and technological solutions. This extension builds on existing CACAO OpenC2 features to improve modularity and utilize the current OpenC2 Transfer Specifications for MQTT (v1.0) and HTTPS (v1.1).

     

    Objectives:

    • Define standardized CACAO MQTT and HTTPS Agents for OpenC2 message transfers

    • Define an updated CACAO OpenC2 Command Type not bound to a specific transfer mechanism (extending the command-type-ov defined in section 5.2 of the CACAO v2.0 spec)

    • Identify CACAO control flow capabilities needed for OpenC2 (e.g., await Consumer response) that may be missing from v2.0 spec.

     

    Having done that, and then worked on a CACAO playbook for the CASP Village demo where I created notional (but possibly wrong) solutions for some of these items, I'm on the fence whether it's premature to actually hold a TC vote on adopting this as a new work product. I guess I'm not sure that we're really smart enough about CACAO (yet) to do this work. And with the release of SOARCA there's an opportunity to see how someone else decided to make OpenC2 / CACAO integration work.

     

    There's an OpenC2 playbook on this page on the SOARCA site (https://cossas.github.io/SOARCA/docs/core-components/modules/), about 3/4 of the way down. I noted that both the SOARCA example and my demo playbook for the village used CACAO Agents for transfer capabilities and CACAO Targets for OpenC2 APs. I don't know if that's correct but at least two parties independently selected the same approach.

     

    Dave

    __________________

    David Lemire
    IA Systems Engineer
    Mission Technologies
    (301) 575-5190 (o)    (240) 938-9350 (m)
    HII.com

     

     



  • 2.  RE: New work product? CACAO & OpenC2

    Posted 13 days ago

    My two cents is we should establish the work item.

     

    There are three possibilities:

    1. We establish the work item, learn CACAO, create the extension, put it out for comment with hopefully some OC2 experts attending CTI and pointing it out to them, and then either we standardize the extension or they take our work and incorporate into their standard
    2. We establish the work item, learn CACAO, start creating the extension and get far enough that we/they then decide the work is better done in CTI and we move the work over.
    3. We try to get them establish the work item, get "them" to learn OC2, they write the extension, ...

     

    IMHO the only way #3 would work is if "we" (ie the experts of our TC) attend their TC and effectively do #1 anyway but over there. My opinion is having these OpenC2 extensions would benefit OC2 awareness and adoption. I also think us learning CACAO would benefit OpenC2 because we could then make playbooks for OpenC2 usecases. I don't see the CTI crowd (ie those not also in the OpenC2 crowd) thinking OpenC2 is valuable enough that they will take the trouble to learn OpenC2. This is especially true since we don't actually have the actuator profiles they will need and they won't be OpecC2 savy enough to hand wave it. I think if we did the work, made playbooks using the new extensions (maybe even finalized some AP's in conjunction with what is needed), that they would then see the value. I just don't seem them seeing it a priori – or they would have done this task already.

     

     

    -- 

    Duncan Sparrell

    sFractal Consulting

    iPhone, iTypo, iApologize

    I welcome VSRE emails. Learn more at http://vsre.info/

     

     




    Original Message


  • 3.  RE: New work product? CACAO & OpenC2

    Posted 10 days ago
    I agree with establishing the work item, presumably along path 2: we do the work and standardize it within CTI since that's where their other extension(s) exist.

    One thing I'm wondering about is MQTT.  We find it easier than HTTP because we can do remote testing without having to open firewall holes or synchronize availability.  When we had the OpenC2 workshop at Dreamport/UMBC, people preferred MQTT even within a local environment, but as I remember the issue with HTTP was sending message attributes as HTTP headers instead of in OpenC2 Messages.

    Presumably in a CACAO environment the playbook engine/orchestrator would always be running in the same administrative network as the actuators, so the firewall hole problem goes away.  If the CACAO OpenC2 message type always used OpenC2 Message over HTTP instead of naked Command and Response then there would be no (immediate) need for an extension.

    BUT, at another OpenC2 forum, perhaps Arizona, Bret pointed out other problems with HTTP, like long-running commands timing out between command and response.  Web Sockets was suggested, but Bret didn't think it solved the timeout problem.  If the other CACAO message types use only HTTP, they would have the same problem if they were ever long-running.  So it would be worth validating two assumptions in the CACAO WG:
    1. orchestrator can always contact actuator (OpenC2 or not) directly using HTTP
    2. TCP timeouts are not a problem for CACAO actions (OpenC2 or not)

    If both are true, I'm not sure an extension for OpenC2 over MQTT is necessary at this time.  If 2 is false, then CACAO itself will need a mechanism for long-lived/asynchronous operations regardless of whether they use OpenC2.



    Original Message


  • 4.  RE: New work product? CACAO & OpenC2

    Posted 9 days ago
     The CACAO extensions are on the GitHub of the cacao TC and basically are kept separately from the CTI/STIX extensions. They are different work products.

    I would go for "Duncan option number 2". Were

    If you need any help to get started, let's schedule a meeting.

    Best,
    Vasileios

    On Apr 20, 2024 20:26, David Kemp via OASIS <Mail@mail.groups.oasis-open.org> wrote:
    I agree with establishing the work item, presumably along path 2: we do the work and standardize it within CTI since that's where their other... -posted to the "OASIS Open Command and Control (OpenC2) TC" community

    OASIS Open Command and Control (OpenC2) TC

    Post New Message
    Re: New work product? CACAO & OpenC2
    Reply to Group Reply to Sender via Email
    Apr 20, 2024 2:25 PM
    David Kemp
    I agree with establishing the work item, presumably along path 2: we do the work and standardize it within CTI since that's where their other extension(s) exist.

    One thing I'm wondering about is MQTT.  We find it easier than HTTP because we can do remote testing without having to open firewall holes or synchronize availability.  When we had the OpenC2 workshop at Dreamport/UMBC, people preferred MQTT even within a local environment, but as I remember the issue with HTTP was sending message attributes as HTTP headers instead of in OpenC2 Messages.

    Presumably in a CACAO environment the playbook engine/orchestrator would always be running in the same administrative network as the actuators, so the firewall hole problem goes away.  If the CACAO OpenC2 message type always used OpenC2 Message over HTTP instead of naked Command and Response then there would be no (immediate) need for an extension.

    BUT, at another OpenC2 forum, perhaps Arizona, Bret pointed out other problems with HTTP, like long-running commands timing out between command and response.  Web Sockets was suggested, but Bret didn't think it solved the timeout problem.  If the other CACAO message types use only HTTP, they would have the same problem if they were ever long-running.  So it would be worth validating two assumptions in the CACAO WG:
    1. orchestrator can always contact actuator (OpenC2 or not) directly using HTTP
    2. TCP timeouts are not a problem for CACAO actions (OpenC2 or not)

    If both are true, I'm not sure an extension for OpenC2 over MQTT is necessary at this time.  If 2 is false, then CACAO itself will need a mechanism for long-lived/asynchronous operations regardless of whether they use OpenC2.
      Reply to Group via Email   Reply to Sender via Email   View Thread   Recommend   Forward  

    Original Message



     
    You are subscribed to "OASIS Open Command and Control (OpenC2) TC" as vasileim@ifi.uio.no. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.





  • 5.  RE: New work product? CACAO & OpenC2

    Posted 8 days ago

    So far: 3 votes in favor and one abstention (my original message). BTW, I've put this item on the agenda at this week's working meeting for discussion (maybe we won't really need it by then).

     

    Vasileios: noted that this is a CACAO extension, not a STIX extension, and under the purview of the CACAO TC, not CTI (I don't think my original post ever implied anything different). WRT to a meeting to get started, my preference would for that to be preceded by a knowledgeable review of our plugfest playbook and feedback on the rightness or wrongness of the general approach taken there. I'll note that when I looked at SOARCA's OpenC2 example (bottom of this page), they seem to have taken a similar approach as the one I hit on.

     

    DaveK: I believe the major issue with HTTP at the first plugfest was a combination of the challenges of getting certificate authentication working and the challenge of pushing in through a firewall to reach the OC2 Consumer. The former is why the v1.1 spec explicitly has a non-secure test mode. It's also true that HTTP was the first transfer spec because of the protocol's ubiquity but my sense is that a pub/sub solution always seemed to be the general preference for efficiency reasons: if you're commanding large number of consumers at once, you send one command rather than 10s/100s/1000s.

     

    Dave

    __________________

    David Lemire
    (301) 575-5190 (o)    (240) 938-9350 (m)
    HII.com

     

     




    Original Message


Related Content