CTI STIX Subcommittee

As I followed the list traffic over the past week or so, I couldn’t help but feel like we’re at a level of abstraction lower than we need to be. Consider the very good IndicatorType / Vocabulary discussion – I spent some time thinking about how we’ll keep track of the discussion’s outcome and the many similarly scoped discussions (See: 154 open issues [1]) that will occur as we work toward the future. I think there’s such a volume of interdependent factors that we’ll have a hard time deciding any particular issue without also consider all other open issues – something that feels a bit insurmountable given the sheer volume of topics. (Note: This is in the context of STIX 2.0 - I feel that updating the vocab for STIX 1.2.1 is a separate discussion and I am not trying to make a statement about it).   With that in mind, I challenged myself to come up with a higher level topic that might help us move forward. I don’t particularly care if my topic gets picked or not, but I do think we need to be a level of abstraction higher to start. IMO, a good topic for discussion would be: What should the STIX 2.0 Architecture look like?   The architecture was touched on in a few of the earlier cti-stix discussions (Relationships, Sightings, Targeting), which IMO makes the architecture a good candidate for early discussion. I’ve thrown together a notional diagram containing STIX 1.2 components [2] and the top level objects that have been discussed so far (please let me know if I missed yours!).     My hope is that by raising this topic we can identify dependencies, preconditions, and differences of opinion. If we need to know more about relationships before we can move forward – what are those things? As with any early stage discussion, there will be open items that can only be resolved later on; my hope is that we can reach a common starting point.   Thank you. -Mark   P.S. In terms of following the process stated in STIX SC call, please consider this message my vote for the STIX architecture being the highest priority topic to work through.   [1] https://github.com/STIXProject/schemas/issues [2] http://stixproject.github.io/data-model/

I definitely agree Mark - One concern I have as we start to look at adding a few new objects in 2.0 is that STIX is beginning to look like a large list of “things” with no real purpose of cohesion.   I believe we can improve this situation with the use of “packages” (not to be confused with the Package object).  By looking at what we are trying to accomplish from a top-down perspective, these packages * should * start to materialize.  Or… we will find things that don’t belong and can be eliminated.   *side note – OpenTPX does this it seems, and if nothing else, it makes the spec MUCH easier to digest for newbies.   My personal challenge is that I don’t know what I would make the STIX packages. ·          Certainly DICTIONARY would be a package (at least it seems clear to me), with Observable and Indicator most likely going in there, but then what?  ·          Is Incident, and Sighting part of an EVENT package?  (I never thought of this before, but there might be some overlap between these 2 objects, no?) ·          Once we get to Campaign, TTP, ExploitTarget, and CourseOfAction, we seem to enter in a higher level of abstraction and analysis that I’m not sure people are even doing much with currently.  Perhaps they all go into an ANALYSIS package?   My lack of CTI expertise is starting to come out here, so if anyone is interested in exploring this more, I’m sure they will also have a better feel for what the packages should be.  If the interest isn’t there, so be it, but I feel there could be payoffs going forward if we bite this off now.  It could help us analyze proposals for other new objects to measure fit in our packages (and therefore cohesion to the STIX “mission”)   From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Davidson II, Mark S Sent: Monday, October 26, 2015 8:53 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] STIX 2.0 Architecture - Relationships, Sightings, and Targeting   As I followed the list traffic over the past week or so, I couldn’t help but feel like we’re at a level of abstraction lower than we need to be. Consider the very good IndicatorType / Vocabulary discussion – I spent some time thinking about how we’ll keep track of the discussion’s outcome and the many similarly scoped discussions (See: 154 open issues [1]) that will occur as we work toward the future. I think there’s such a volume of interdependent factors that we’ll have a hard time deciding any particular issue without also consider all other open issues – something that feels a bit insurmountable given the sheer volume of topics. (Note: This is in the context of STIX 2.0 - I feel that updating the vocab for STIX 1.2.1 is a separate discussion and I am not trying to make a statement about it).   With that in mind, I challenged myself to come up with a higher level topic that might help us move forward. I don’t particularly care if my topic gets picked or not, but I do think we need to be a level of abstraction higher to start. IMO, a good topic for discussion would be: What should the STIX 2.0 Architecture look like?   The architecture was touched on in a few of the earlier cti-stix discussions (Relationships, Sightings, Targeting), which IMO makes the architecture a good candidate for early discussion. I’ve thrown together a notional diagram containing STIX 1.2 components [2] and the top level objects that have been discussed so far (please let me know if I missed yours!).     My hope is that by raising this topic we can identify dependencies, preconditions, and differences of opinion. If we need to know more about relationships before we can move forward – what are those things? As with any early stage discussion, there will be open items that can only be resolved later on; my hope is that we can reach a common starting point.   Thank you. -Mark   P.S. In terms of following the process stated in STIX SC call, please consider this message my vote for the STIX architecture being the highest priority topic to work through.   [1] https://github.com/STIXProject/schemas/issues [2] http://stixproject.github.io/data-model/ DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

+1  Great graphic.  Helps with developing the new constructs and significant directions and opportunities. --tony On 2015-10-26 8:53 AM, Davidson II, Mark S wrote: The architecture was touched on in a few of the earlier cti-stix discussions (Relationships, Sightings, Targeting), which IMO makes the architecture a good candidate for early discussion. I’ve thrown together a notional diagram containing STIX 1.2 components [2] and the top level objects that have been discussed so far (please let me know if I missed yours!).     My hope is that by raising this topic we can identify dependencies, preconditions, and differences of opinion. If we need to know more about relationships before we can move forward – what are those things? As with any early stage discussion, there will be open items that can only be resolved later on; my hope is that we can reach a common starting point. -- ________________________________ Anthony Michael Rutkowski EVP, Industry Standards & Regulatory Affairs tony@yaanatech.com +1 703 999 8270 ________________________________ Yaana Technologies LLC 542 Gibraltar Drive Milpitas CA 95035 USA

Mark et al,


Victims/Targets as TLOs*  is a gaping hole in the current CTI Model.  Glad to see we are finally talking about these things in general (and hopefully soon in substance).


(*Note: along with their relations to everything else, including the missing concepts of White Hat TTPs)








Patrick Maroney
President
Integrated Networking Technologies, Inc.
Office:  (856)983-0001
Cell:      (609)841-5104










From: < cti-stix@lists.oasis-open.org > on behalf of Anthony Rutkowski < tony@yaanatech.com >
Organization: Yaana Technologies
Reply-To: Anthony Rutkowski < tony@yaanatech.com >
Date: Monday, October 26, 2015 at 11:47 AM
To: Mark Davidson < mdavidson@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] STIX 2.0 Architecture - Relationships, Sightings, and Targeting




+1 

Great graphic.  Helps with developing the
new constructs and significant directions
and opportunities.

--tony

On 2015-10-26 8:53 AM, Davidson II, Mark S wrote:


The architecture was touched on in a few of the earlier cti-stix discussions (Relationships, Sightings, Targeting), which IMO makes the architecture a good candidate for early discussion. I’ve thrown together a notional diagram containing
STIX 1.2 components [2] and the top level objects that have been discussed so far (please let me know if I missed yours!).

 

 
My hope is that by raising this topic we can identify dependencies, preconditions, and differences of opinion. If we need to know more about relationships before we can move forward – what are those things? As with any early stage discussion,
there will be open items that can only be resolved later on; my hope is that we can reach a common starting point.



--

________________________________

Anthony Michael Rutkowski

EVP, Industry Standards & Regulatory Affairs
tony@yaanatech.com
+1 703 999 8270


________________________________

Yaana Technologies LLC



542 Gibraltar Drive

Milpitas CA 95035 USA

On 26.10.2015 17:16:02, Patrick Maroney wrote: > > ...including the missing concepts of White Hat TTPs... > Hey, Pat - When you say, 'White Hat TTPs', do you mean sharing intelligence useful in identifying legitimate pen-tester activity? -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "Every networking problem always takes longer to solve than it seems like it should." --RFC 1925 Attachment: signature.asc Description: PGP signature

I guess so (Blue/Red teams), only covered, I would say by the 'exercise' flag but not in the vocabularies On Wednesday, 28 October 2015, Trey Darley < trey@soltra.com > wrote: On 26.10.2015 17:16:02, Patrick Maroney wrote: > > ...including the missing concepts of White Hat TTPs... > Hey, Pat - When you say, 'White Hat TTPs', do you mean sharing intelligence useful in identifying legitimate pen-tester activity? -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "Every networking problem always takes longer to solve than it seems like it should." --RFC 1925

In our World View and a majority of Use Cases, one needs to fully model all aspects of the Cyber-BattleSpace:



Adversaries

Adversary TTP*s (Black Hat)



Intermediaries 

Intermediary TTPs (Grey Hat)



Targets

Target TTPs (White Hat)



* TTPs include assets and infrastructure in this model.



Since we don't currently represent Targets and Intermediaries in the current CTI Model, then the proposed modeling of related "White/Grey Hat" TTP relations won't be as obvious






Patrick Maroney









From: Jerome Athias < athiasjerome@gmail.com >
Date: Wednesday, October 28, 2015 at 5:22 AM
To: Trey Darley < trey@soltra.com >
Cc: Patrick Maroney < Pmaroney@Specere.org >, Anthony Rutkowski < tony@yaanatech.com >, Mark Davidson < mdavidson@mitre.org >,
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] STIX 2.0 Architecture - Relationships, Sightings, and Targeting




I guess so (Blue/Red teams), only covered, I would say by the 'exercise' flag but not in the vocabularies

On Wednesday, 28 October 2015, Trey Darley < trey@soltra.com > wrote:

On 26.10.2015 17:16:02, Patrick Maroney wrote:
>
> ...including the missing concepts of White Hat TTPs...
>

Hey, Pat -

When you say, 'White Hat TTPs', do you mean sharing intelligence
useful in identifying legitimate pen-tester activity?

--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra An FS-ISAC & DTCC Company
www.soltra.com
--
"Every networking problem always takes longer to solve than it seems
like it should." --RFC 1925

On 28.10.2015 13:39:16, Patrick Maroney wrote: > In our World View and a majority of Use Cases, one needs to fully > model all aspects of the Cyber-BattleSpace: > > Adversaries > Adversary TTP*s (Black Hat) > > Intermediaries > Intermediary TTPs (Grey Hat) > > Targets > Target TTPs (White Hat) > > * TTPs include assets and infrastructure in this model. > > Since we don't currently represent Targets and Intermediaries in the > current CTI Model, then the proposed modeling of related "White/Grey > Hat" TTP relations won't be as obvious > Hi, Pat - Perhaps I'm just congenitally slow between the ears, but could you please explain to me in plain language exactly what problem(s) you're trying to solve with all the above? Using CTI to track blackhats, that I get. Using CTI to track pentesters (whitehats) you're presumably paying large sums of money to test your infrastructure seems to go against the entire purpose of hiring professional pentesters. As for what's a greyhat, well, that's basically identical to the attribution problem. Again, maybe I'm just being dense, but let's just focus on squelching the blackhats for now. That's the critical issue and we've a very long way yet to go. -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "It is always possible to add another level of indirection." --RFC 1925 Attachment: signature.asc Description: PGP signature

Could we think about building a very high level  conceptual model? There are free tools to do it collaboratively On Monday, 26 October 2015, Davidson II, Mark S < mdavidson@mitre.org > wrote: As I followed the list traffic over the past week or so, I couldn’t help but feel like we’re at a level of abstraction lower than we need to be. Consider the very good IndicatorType / Vocabulary discussion – I spent some time thinking about how we’ll keep track of the discussion’s outcome and the many similarly scoped discussions (See: 154 open issues [1]) that will occur as we work toward the future. I think there’s such a volume of interdependent factors that we’ll have a hard time deciding any particular issue without also consider all other open issues – something that feels a bit insurmountable given the sheer volume of topics. (Note: This is in the context of STIX 2.0 - I feel that updating the vocab for STIX 1.2.1 is a separate discussion and I am not trying to make a statement about it).   With that in mind, I challenged myself to come up with a higher level topic that might help us move forward. I don’t particularly care if my topic gets picked or not, but I do think we need to be a level of abstraction higher to start. IMO, a good topic for discussion would be: What should the STIX 2.0 Architecture look like?   The architecture was touched on in a few of the earlier cti-stix discussions (Relationships, Sightings, Targeting), which IMO makes the architecture a good candidate for early discussion. I’ve thrown together a notional diagram containing STIX 1.2 components [2] and the top level objects that have been discussed so far (please let me know if I missed yours!).     My hope is that by raising this topic we can identify dependencies, preconditions, and differences of opinion. If we need to know more about relationships before we can move forward – what are those things? As with any early stage discussion, there will be open items that can only be resolved later on; my hope is that we can reach a common starting point.   Thank you. -Mark   P.S. In terms of following the process stated in STIX SC call, please consider this message my vote for the STIX architecture being the highest priority topic to work through.   [1] https://github.com/STIXProject/schemas/issues [2] http://stixproject.github.io/data-model/