Post 1.0 Issue - Stix 2.1 Use Case has Pattern

[sparrell]

Use cases were copied from the examples in the WD being added by STIX for COA's in STIX 2.1 https://github.com/oasis-tcs/openc2-lsc-usecases/tree/master/STIX.

The threads contain multiple targets in an 'or' - ie delete file with hash=has1 or hash=hash2.

OpenC2 could handle this as:

• two commands (delete hash1, delete hash2)
• via extension to STIX (delete stix refid=n)
• adding patterns to OpenC2 targets

The first (2 commands) is supported by the language today. The second (stix extension) will hopefully be the next version of the spec (there is agreement to do extension, details still being worked).

The issue is should patterns be added to OpenC2 targets in v1?

[jmbrule]

Should 'patterns be added to OpenC2 targets in version 1.0?' Given that we have two existing ways to accommodate (two atomic commands or extend the target space with the stix observables) then it seems like adding patterns to OpenC2 targets is not necessary.

[sparrell]

Since LS has ways to accomplish without adding patterns directly to OpenC2, this will be deferred until after 1.0. Title was changed to reflect it is post 1.0, but is being kept opent to be revisted once 1.0 is complete

[jmbrule]

We have two means to addressing the issue (two atomic commands or import a target), we have not seen a compelling reason or use case that indicates we must have this and there is the potential ambiguity (multiple means to accomplish the same effect). For these reasons, suggest closing this issue.

[dlemire60]

STIX v2.1 CS01 was approved in March of 2020. Lacking any use cases to support adding patterns to OpenC2, I recommend closing this issue.

[Vasileios-Mavroeidis]

STIX 2.1 is an approved standard as of 10 June 2021. The STIX patterning language has evolved a lot and it is used by STIX shifter for retrieving and transforming data/info to cyber observables. The ER AP has a similar discussion to adopt the STIX patterning language when we develop the analytics AP. Just wanted to bring this info also into this thread. Im ok with closing this issue.

[sparrell]

I think it is premature to close. Several things would need to be discussed and separate issues made before I would agree to close this issue. We kicked the 'compound command' issue down the road and we are now down the road and should discuss again, particularly in the context that STIX 2.1 is standard and CACAO exists. These would probably lead to sticking with atomic commands (no compound commands) but I think it may still be too early to make that decision. We need more actual playbooks using OpenC2 to make the trade off between multiple ways to do something versus ease of playbook creation/implementation. But a bigger reason to consider STIX patterning is for PACE PES analytical commands and similar analytical commands in ER, IDS, ...

[dlemire60]

Discussed at triages, leave as future, need use case & proposal, probably address in an AP first.

[sparrell]

I’m against closing this issue, at least not until the PACE PES OpenC2 interface is better defined. My belief is STIX patterning language is a leading contender for attribute analytic interface. I also agree with Vasileos that it would be needed in an analytics AP. iPhone, iTypo, iApologize

…

________________________________ From: Vasileios Mavroeidis ***@***.***> Sent: Friday, March 11, 2022 6:04:28 AM To: oasis-tcs/openc2-oc2ls ***@***.***> Cc: duncan sfractal.com ***@***.***>; Author ***@***.***> Subject: Re: [oasis-tcs/openc2-oc2ls] Post 1.0 Issue - Stix 2.1 Use Case has Pattern (#66) STIX 2.1 is an approved standard as of 10 June 2021. The STIX patterning language has evolved a lot and it is used by STIX shifter for retrieving and transforming data/info to cyber observables. The ER AP has a similar discussion to adopt the STIX patterning language when we develop the analytics AP. Just wanted to bring this info also into this thread. Im ok with closing this issue. — Reply to this email directly, view it on GitHub<#66 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANEXDY7TNFBKUIOBXIF3WLU7MSDZANCNFSM4ET5BVOQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>