[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] Re: Re: Re: [cti-stix] RE https://github.com/oasis-tcs/cti-stix2/issues/28
As always, it is a matter of who is going to do the work and can it be done, tested, verified, within the next month? We are still waiting on people and yourself to finish the patterning changes we have ear marked for inclusion in 2.1.
Adding something else big at this stage is a lot of work. So I am not against doing this, but I feel like this would represent a significant risk at
this stage of the release. Maybe we could target this for STIX 2.2?
But as always, it would help to see a full proposal for this. Maybe if a full proposal was done and we could see what that would mean, it would make it easier for people to understand the scope of the changes.
Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Wednesday, June 12, 2019 8:38:40 AM To: Allan Thomson Cc: cti-stix@lists.oasis-open.org Subject: [EXT] Re: Re: Re: [cti-stix] RE https://github.com/oasis-tcs/cti-stix2/issues/28 It is not "multiple" in my proposal - its plain SCO pattern. You just allow the optional use of external syntaxes for the observation _expression_.
- Jason Keirstead Lead Architect - IBM Security Connect www.ibm.com/security "Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure." - Thomas J. Watson From: Allan Thomson <athomson@lookingglasscyber.com> To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/12/2019 11:23 AM Subject: [EXTERNAL] Re: Re: [cti-stix] RE https://github.com/oasis-tcs/cti-stix2/issues/28 I disagree that it needs to be deprecated.
You could easily just add an enum that says the string contains multiple in future for combinational language strings and define rules on how you qualify the content as have been suggested to do that.
I just don’t think we should be doing that as step1 which is what you are suggesting.
Allan
From:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
"So if someone wants to add an IP address to a signature in Snort then they would just do that. They wouldn’t
update the Snort signature to combine with STIX2."
Jason – I think we understood that you were suggesting combination capability to combine both Snort + STIX2 or Yara + STIX2….etc.
My point was that if a product already supports Snort or Yara then its likely much (but not all) of the capabilities would be defined in the single language itself and not a combination of languages.
So if someone wants to add an IP address to a signature in Snort then they would just do that. They wouldn’t update the Snort signature to combine with STIX2.
Now I can see future cases where something is not possible to define holly in Snort2 or YARA and therefore you need additional capabilities. But that seems like a running step when we’re barely crawling with pattern grammar use.
If you want to combine languages then I suggest we target that capability beyond 2.1.
Allan
From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
I want to reply to Allans comment in the working call meeting notes as I was not present:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]