OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Face to Face - RM4 - Prop 9 relationships




Yep, I totally support this idea.  Anything where we can start to get some consistency is a good thing.  Too many threat repositories and other systems have a million ways of describing the same thing.  Anything which we can all use as a group is great, especially when it comes to linking and tracking all of the bad behaviour that is out there.


Everyone has a different way to write a TTP, Campaign or Threat Actor, bring some similarity into the picture is a good thing.






From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Friday, 15 January 2016 10:39 AM
To: Mark Clancy; cti@lists.oasis-open.org
Subject: [cti] RE: Face to Face - RM4 - Prop 9 relationships


This is exactly the idea behind the ID format that we proposed in the TWIGS specification. Organizations would be able to produce easy to remember objects that would be used as ‘library objects’ that others would be able to use and reference. In this way, we could create a list of common Attack-Pattern objects based on CAPEC, and they would just be available for use by anyone.


We could then over time build up a picture of which threat actors use which attack patterns in a way that allows us to easily traverse the graph relationships between them thanks to the ‘shared’ library objects that link them.




Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com



From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Mark Clancy
Sent: Friday, 15 January 2016 7:45 AM
To: cti@lists.oasis-open.org
Subject: [cti] Face to Face - RM4 - Prop 9 relationships


So one thought I want to inject which is hard to do on the phone.  We should also talk about the use of Reference Data as binding glue when dealing with relationships.  For example why does everyone on the planet need to create their own STIX object in their own namespace for a "spear phishing" TTP. So that Org1 and Org2 "Spear phishing" TTPs are different things as they are unique STIX objects when in fact they really should have been the same. Yes there are variants of Spear Phishing which may also be generic TTP like say Whaling and others that are specific to a Threat Actor which will related to Spear Phishing are really more unique.





Mark Clancy

Chief Executive Officer

SOLTRA | An FS-ISAC and DTCC Company

+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535  UK mobile

mclancy@soltra.com | soltra.com


One organization's incident becomes everyone's defense.


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Alexander Foley <alexander.foley@bankofamerica.com>
Sent: Thursday, January 14, 2016 3:03 PM
To: cti@lists.oasis-open.org
Subject: [cti] Groups - OASIS CTI TC F2F - STIX 1b.pdf uploaded


Document Name: OASIS CTI TC F2F - STIX 1b.pdf

Strawman #2 (Sean Barnum + Group)
Download Latest Revision
Public Download Link

Submitter: Alexander Foley
Group: OASIS Cyber Threat Intelligence (CTI) TC
Folder: Calendar Documents
Date submitted: 2016-01-14 12:03:07


This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]