cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cti-stix] Re: [EXT] Re: [cti-stix] Possible solution to conundrum of how to do patterns for Infrastructure and Malware
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Struse, Richard" <Richard.Struse@HQ.DHS.GOV>
- Date: Fri, 26 May 2017 08:50:34 -0300
The other issue raised is that it will
become a large headache to keep the indicators in sync with the objects.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
Without data, all you are is just another person with an opinion - Unknown
From:
"Struse, Richard"
<Richard.Struse@HQ.DHS.GOV>
To:
Terry MacDonald <terry.macdonald@cosive.com>,
"Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Cc:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>,
"Kirillov, Ivan A." <ikirillov@mitre.org>, Trey Darley
<trey@kingfisherops.com>
Date:
05/25/2017 05:39 PM
Subject:
RE: [cti-stix]
Re: [EXT] Re: [cti-stix] Possible solution to conundrum of how to do patterns
for Infrastructure and Malware
Sent by:
<cti-stix@lists.oasis-open.org>
Terry,
There was a long discussion
about whether having information such as adversary C2 IPs in an infrastructure
object and then having indicators that detect on those same IPs was confusing
and/or duplicative. I don’t believe it is either but some have concerns
that people will just create infrastructure objects and then do detection
directly off of that rather than creating indicators. I’ve volunteered
to work with others to try to articulate the “why” behind Infrastructure
to see if we can move forward. Looking for help from anyone interested.
Thanks,
Rich
From: cti-stix@lists.oasis-open.org
[mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Terry MacDonald
Sent: Thursday, May 25, 2017 3:56 PM
To: Bret Jordan (CS)
Cc: Jason Keirstead; cti-stix@lists.oasis-open.org; Kirillov, Ivan
A.; Trey Darley
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Possible solution
to conundrum of how to do patterns for Infrastructure and Malware
Hi all,
Having missed the f2f, can someone
please give an overview of why STIX patterning is being added to malware
and infrastructure objects?
I thought infrastructure and malware
objects were for recording information about things that have been seen.
And that indicators were for things you want to match. I'm very interested
in understanding more about why we would need STIX patterning in the malware
and infrastructure objects, as it seems to conflate both the 'record the
past' and the 'match against the future' items into single entities when
we spent so long making sure they were broken apart.
Once we make this design decision
then we need to write it down and agree it as a design decision, so that
the design pattern is allowed to be used elsewhere to. We spend so long
changing our minds all the time, that we need to come up with some architecture
rules that we can apply to our new objects/changes so we follow the same
architectural structure.
Cheers
Terry MacDonald
Cosive
On 26/05/2017 06:00, "Bret
Jordan" <Bret_Jordan@symantec.com>
wrote:
Agreed. I see Jason's point
and I think it is valid. We really need to figure out and solve the malware
and infrastructure objects so that we will better know if there are changes
that need to be made to patterning or the STIX data model or both.
Bret
Sent from my Commodore 64
PGP Fingerprint: 63B4 FC53 680A
6B7D 1447 F2C0 74F8 ACAE 7415 0050
On May 25, 2017, at 1:48 PM, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
wrote:
If you have to create indicators for those
cases, then you are back to the problems I outlined in my original email...
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
Without data, all you are is just another person with an opinion - Unknown
From: "Kirillov,
Ivan A." <ikirillov@mitre.org>
To: Jason Keirstead
<Jason.Keirstead@ca.ibm.com>
Cc: "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>,
"Trey Darley" <trey@kingfisherops.com>
Date: 05/25/2017
02:24 PM
Subject: Re:
[cti-stix] Possible solution to conundrum of how to do patterns for Infrastructure
and Malware
I replied with some clarifications after re-reading the proposal. I still
don’t think this is a good idea. I also just don’t really think that
we’ll be trying to match against instantial observation data contained
within a Malware or Infrastructure SDO, particularly because the semantics
of this are undefined (do you match against all of the properties, i.e.,
as a logical AND? or do you treat all properties as an OR?). Instead I
think we should strongly encourage the creation of formal Indicators for
such cases.
-Ivan
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, May 25, 2017 at 11:15 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>,
Trey Darley <trey@kingfisherops.com>
Subject: Re: [cti-stix] Possible solution to conundrum of how to do
patterns for Infrastructure and Malware
We're not dictating which parts of the model we are matching *against*
- we are *sourcing* the thing we want to match - from STIX itself.
It is a lot like my external reference proposal - instead of pulling from
an external list though, you are pulling it from STIX itself.
> How are you supposed
to convert STIX Patterns to other _expression_ such as YARA or SIEM correlation
rules if the pattern is intrinsically tied to the data model?
The same as external reference.... you look up the previous STIX object
you presumably received, and/or you query your TAXII server, and source
the data from there.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
Without data, all you are is just another person with an opinion - Unknown
From: "Kirillov,
Ivan A." <ikirillov@mitre.org>
To: Trey Darley
<trey@kingfisherops.com>,
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date: 05/25/2017
02:08 PM
Subject: Re:
[cti-stix] Possible solution to conundrum of how to do patterns for Infrastructure
and Malware
Sent by: <cti-stix@lists.oasis-open.org>
To be honest, this doesn’t make sense to me – STIX Patterns should not
dictate which parts of the STIX data model (if any) they should match against.
The core semantics of STIX Patterns are based on matching on specific artifacts,
wherever they may be found – in a STIX SDO, in a PCAP, on an endpoint,
etc. How are you supposed to convert STIX Patterns to other _expression_
such as YARA or SIEM correlation rules if the pattern is intrinsically
tied to the data model? If a matching Object (File in this case) is contained
in an Observed Data blob, then you can match against that, and similarly
if it’s encompassed inside of the sample_metadata property of a Malware
SDO.
I think it would be much more sensible to keep patterns data-model agnostic
and instead include language that encourages indicators to be created when
necessary for SDOs like Malware and Infrastructure that may include instantial
Cyber Observable data.
-Ivan
On 5/25/17, 10:41 AM, "Trey Darley" <cti-stix@lists.oasis-open.orgon behalf of trey@kingfisherops.com>
wrote:
On 25.05.2017 08:25:35, Jason Keirstead wrote:
> Sorry I wrote that pattern before I had coffee.. it makes no
sense.
>
> This is what the pattern would be with my proposal.... you
are
> looking for the hash contained inside a specific object...
>
> [file:hashes.“SHA-256" =
> stix-object:malware-12345-aaaaa-bbbbb-ccccc.sample_metadata[*].hashes.“SHA-256"]
>
Good thinking, Jason! I think this approach solves many of the
challenges we discussed yesterday around Malware and Infrastructure
vis-a-vis Indicators.
--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8
6C1D
++--------------------------------------------------------------------------++
--
"Any sufficiently complex input format is indistinguishable
from
bytecode." -- Bratus, Patterson, & Shubina
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]