CTI STIX Subcommittee

Jane, Gary, et al, This (infrastructure SDO) might be something you want to give as an issue for the OASIS Standards Council. I believe they were chartered to provide a way for users to stay abreast and influence where needed, without getting involved in all the day-to-day details of the many TC's. Their scope says: Provide OASIS cybersecurity TCs with a direct mechanism for obtaining user feedback on technical disputes . Sounds like Infrastructure SDO is the kind of issue that might be right up their alley to get you more data to break your tie. Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize

I think the user’s council can give 30,000 foot guidance on you should consider doing x or y. But for the actual design elements and how it would be done, they would need to be members of the actual TC to not have IPR considerations.


Bret 

Sent from my Commodore 128D


PGP
Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE  7415
0050


On Nov 14, 2017, at 4:29 AM, " duncan@sfractal.com " < duncan@sfractal.com > wrote:




Jane, Gary, et al,

This (infrastructure SDO) might be something you want to give as an issue for the OASIS Standards Council. I believe they were chartered to provide a way for users to stay abreast and influence where needed, without getting involved in all the day-to-day
details of the many TC's.


Their scope says:
"Provide OASIS cybersecurity TCs with a direct mechanism for obtaining user feedback on technical disputes".

Sounds like Infrastructure SDO is the kind of issue that might be right up their alley to get you more data to break your tie.



Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize





Original Message --------
Subject: [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for
an Infrastructure SDO for STIX 2.1
From: "Katz, Gary CTR DC3\DCCI" < Gary.Katz.ctr@dc3.mil >
Date: Mon, November 13, 2017 3:09 pm
To: JG on CTI-TC < jg@ctin.us >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >



Jane,
   Sorry for taking a long time to respond.  Since it seemed you put considerable amount of time into your email, I wanted to make sure
I had time to put some thought into the problem before providing a response.  I agree that we need a way to represent malicious infrastructure within 2.1 although I believe there are multiple ways we can achieve this goal.
 
There are three options that I believe are possible

(4 if you include not doing anything about infrastructure in 2.1, which I do not believe is an option)
 
Option 1: Create a New Infrastructure Object
Option 2: Modify the Observed Data TLO to also model Infrastructure
Option 3: Make Cyber Observables Top Level Objects
 
There are Pros and Cons to each of these, and I’d be interested in hearing everyone’s inputs.  My personal order of preference is Option
3, then Option 2, then Option 1.  My personnel opinion is we should not release 2.1 without a way to handle Infrastructure. 

 
I think some of you will find it ironic that I would push for option 3, since I was one of those that fought against making cyber observables
top level objects, but the reasons for keeping them separated no longer exist.  Cybox has been integrated into STIX, there is not a reason in my mind to keep them non-TLOs any longer.  The main disadvantage to making Cyber Observables TLOs is that it is a
major breaking change from STIX 2.0.  We can debate how big a deal this is, but I’d rather rip the bandaid off now rather than having this issue long term. 

 
From a model standpoint, embedding cyber observables within Observed Data results in graphs within graphs, which are in themselves difficult
to deal for systems receiving STIX data.  Making Cyber Observables TLOs would fix this issue and simplify the model.
 
From an analyst standpoint.  I spent (parts of) the last several days manually ingesting text documents into our own cyber analytic
system.  The model we use is a graph and is based closely on the STIX model.  I modeled a custom malware analysis report, an internal incident/event report, a short external government finished intelligence reporting of an event, and a longer external government
intelligence reporting of multiple events.  I manually ingested a variety of reports to form my own options about how I think about the data and would like to model it, what is useful and what information cluttered the graph. 

 
In the end, it did not matter to me if an object represented an IP address that was seen in a malware object or it was observed on my
network or it was infrastructure found through other methods.  That context was contained in the linkages.  An IP address, is an IP address, is an IP address and storing it within Observed Data or an Infrastructure object did not make too much sense to me. 
 The fact that the IP was infrastructure used by the adversary was shown in my link types, not in the object itself.  For example, some IP address may relate to adversary infrastructure because the adversary had taken over the system for a time and then at
a later time another adversary started using it.  It was infrastructure for both adversaries at different times, which is shown through the links and the time attached to those links, not through the IP address itself.
 
If we decide not to make Cyber Observables TLOs, my second option would be to extend the Observed Data TLO to meet the Infrastructure
needs.  This would mean vastly increasing the number of relationship types assigned to Observed Data and adding on some extra properties.  One could be a Boolean stating whether the Cyber Observables were observed on your network or some other fashion.  By
not creating an Infrastructure object, we avoid having one organization model the data using the Observed Data object and another organization use the Infrastructure object or the worst case scenario where an analyst feels they need to model it as Observed
Data and Infrastructure, leading to them being extremely frustrated with us and receiving analysts seeing 4 objects in their system for every IP (one Observed Data object, one embedded IP address object in the OD, one Infrastructure Object and one IP address
object in the Infrastructure object (yes some systems could optimize how this data is viewed, but some will not)).  I understand that we will be bastardizing the Observed Data object by doing this, but that’s another reason why making Cyber Observables TLOs
is a better option in my view.
 
Lastly, I would suggest an Infrastructure object.  It would be similar to an Observed Data object but with more relationships associated
with it.  This would still allow us  to complete the initial STIX model and provide the functionality that many users would expect to see within the model. 

 
I agree with Bret, Jane and many others on the crucial need to model infrastructure, but I wanted to provide some additional options
for how we can meet that need.
 
Apologies for the long email,
   -Gary
 
 
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of JG on CTI-TC
Sent: Tuesday, November 7, 2017 7:19 PM
To: cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1


 

At present the CTI TC does not appear to be of one mind on the need for an Infrastructure SDO for 2.1. After months of debate in Slack and on the email list, after two intense working sessions at both the Bethesda, MD and Austin, TX face-to-face meetings,
and after numerous discussions during working meetings and review of the working draft developed by Richard Struse and Bret Jordan, a Straw Man poll at Austin led to an almost even tie on whether or not to include an Infrastructure SDO in 2.1. I'm writing
today to outline eight reasons why I believe we should seriously consider including an Infrastructure SDO for the STIX 2.1 release. Note that my view on the topic is as a threat hunter, educator, and analyst; therefore, I'll be relying on insights from the
programmers, data architects, and MRTI aficionados to actually make it work. It will make the human-to-machine interface more effective during this period of rapid ecosystem expansion, ISAO/ISAC build-out, market/product definition and trust-building between
private sector entities and law enforcement for critical infrastructure protection.
1.       
An argument has been made that the Indicator SDO could serve as a series of interconnected buckets for a malicious infrastructure, and that specific Cyber Observables could be linked to such Indicator to define a malicious infrastructure with a Boolean
property indicating the goodness or badness of a set of interconnected Indicators. I believe this would not be a suitable approach for the following reasons: 1) it would overload the Indicator SDO which already suffers from overuse and misunderstanding; 2)
relationships would have to be drawn through the Observed Data SDO to the specific Cyber Observables.  Given how timestamps are handled this would add a layer of complexity that we could avoid with carefully designed properties on the Infrastructure SDO.

2.       
A wide range of SDOs and Cyber Observables will need to be strung together in an interrelated complex of potentially rapidly changing data elements by producers seeking to convey rich detail about observations, sightings, TTPs, malware, network effects,
and cyber observables operating as a single unified entity with a single purpose. Once issued by a Producer, sightings of one or more SDOs or cyber observables associated with this multi-headed Hydra will enable other members of a sharing community to quickly
assess kill chain phases  or other clues on their own networks that may help expedite discovery. And when operating within a truly effective and skilled sharing community this could also lead to more rapid crowdsourced threat analysis with accompanying remediation
recommendations.
3.       
Foundational literature on tradecraft in cyber threat analysis includes an Infrastructure vertex as part of the analytical toolset. I'm referring here to the Diamond Model (Caltagirone, 2013) which directly juxtaposes threat actor capabilities to the
infrastructure he uses. The origins and utility of the Diamond Model within the analyst community stands on its own merits, regardless of the fact that the STIX2 data model has moved on from this foundational concept.

4.       
Advanced NoSQL graph database techniques are well suited to visualizing the interconnectedness of a malicious infrastructure expediting pattern recognition by human analysts seeking to perform higher level analysis and synthesis of STIX2 data. The power
of this type of tooling should not be underestimated as we look towards the future of CTI and sharing communities. Indeed, such notable companies as OpenDNS (acquired by OASIS member CISCO) have used such visualizations to great success. Further, the use of
data visualization techniques for enabling higher-order pattern recognition as a tool for analysis has been well documented by Tufte (2001), among others. Importantly, we need to build the Infrastructure SDO with sufficient metadata properties to enable these
higher-order analytics.  For example, it will be important to link back to Threat Actor SDOs within a boxed time-frame to move closer to attribution. 

5.       
The larger global community of network defenders and cyber threat analysts are developing siloed versions of classification and enumeration systems for infrastructure as they are seeing it. However, we do not have a generally agreed upon system as we
do have for malware (MAEC), exposures and vulnerabilities (CVE), and attack patterns (ATT&CK). By creating an Infrastructure SDO in STIX 2.1 we might be able to kick-start such a development.

6.       
One of the key insights gleaned during the Austin, TX face-to-face meeting was the need for more effective outreach and marketing to the broader CTI community, beyond those actively participating in OASIS. The addition of Infrastructure SDO will send
a positive market signal to this broader community which may speed adoption. This is because the inclusion of such an object, in conjunction with the fully vetted Malware object, will convey a level of maturity of the STIX2 data model that heretofore has been
lacking. The perception of a data model that is actually reflective of reality will greatly enhance the reputation build of this phase of the market innovation, adoption, diffusion and transformation cycle.

7.       
In research presented at the ENISA CTI Bonding event in Rome, Italy (ENISA, 2017) an analyst from CyberDefCon reported that the worst performing ASNs from its Shadowserver Foundation (2017) database over a multi-year period were AS29182 ISPSYSTEM (located
in RU) and AS5577 ROOT (located in LU). This exemplifies how longitudinal data aggregated from proprietary and open sources can demonstrate that the
Infrastructure of a large-scale operation can be used to identify bad actors at the Regional Registry level.  Since one of the stated objectives of CTI is to facilitate public/private sharing this example shows how the research community can provide
evidence that can be used by the jurisdictional law enforcement authorities for enforcement action.  With an explicit “Infrastructure SDO” the evidentiary quality of the data for law enforcement can be improved.

8.       
During a Sports-ISAO sponsored Internship program run during the World Championship games in London in August 2017 a group of 60+ Interns from over 30 Universities across the U.S. working to support the program identified the “digital exhaust” of multiple
attack patterns targeting sports organizations and the related sponsors of such.  As a trainer for these novice threat hunters it was useful to provide visualizations of attack infrastructures to help them wrap their minds around the ideas of threat actors,
campaigns, intrusion sets, indicators, cyber observables and other concepts we tried to capture in STIX2.  I am able to generate such visualizations from several sources other than STIX.  However, if I had had tangible evidence stemming from an Infrastructure
SDO in STIX 2.X, the learning curve pedagogy would have been more streamlined. In summary, I needed the Infrastructure SDO in order to tie all of the pieces of the puzzle together. 


If any of these arguments, make sense to you please let your voice be heard so that we can expedite the build towards consensus before an official Ballot on STIX 2.1. Also note that I recognize that the STIX Subcommittee is seeking a more orderly scheduling
of discussions around Version 2.1 SDOs.  Therefore, I’m requesting that we reopen discussions on this object when it would fit into the existing schedule and SDO priorities. 


 _______________________________________________________________________

References:

Caltagirone, S., Pendergast, A., Betz, C. (2013, July 5). The Diamond Model of Intrusion Analysis.

http://www.dtic.mil/get-tr-doc/pdf?AD=ADA586960

ENISA (2017).
https://www.enisa.europa.eu/events/cti-eu-event/enisa-cti-eu-event

Hutchins, E., Cloppert, M., Amin, R. (2011).  Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. Lockheed Martin.

Shadowserver (2017).
https://www.shadowserver.org/wiki/pmwiki.php/Main/HomePage  

Tufte, E.R. (2001). The Visual Display of Quantitative Information (2 nd Ed.). Graphics Press: Cheshire, CT.
--
Jane Ginn, MSIA, MRP
CTI TC Secretary, OASIS
Co-Founder of Cyber Threat Intelligence Network, Inc.
jg@ctin.us



--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:

https://clicktime.symantec.com/a/1/XmqGHYhyzbsdTgmlLUZa-1Ydiu0JzQQzf5JY-z3Wv1g=?d=jAjc4sDYmaktqDw9PWCZiA93JwfqslsFiGKRwLcpiPTPa9SeIELhrytPoJe-Uo7B1x6IA-G4yFcjM3gBa7buFDF6c5rKQuOgZUEcW_smrB-amEv4kAV5U_j1qpN_1SfRVEqWxOEB9PdMt6nluYJ8ENcGH8_i0VgvBU_Duz4Loxiv8aT1iXws1owDZ_f7oCJe0ha5wPvYZsyOJlxdkY0_e8wjF3joXNGW-LtZxV5WE79Dn4ddlbyXAQyvYcDGexEqQye0iUZG80UbUVRzj5-k8qr1cXSJEdNl4J9PLmxgl2hmwcHA1ZD3pYzn_MewbckTrMCHg3x7ar1tbVBNR4W_9mHZ-nT3LJYt_QvU543FmpyFa51AqsJ3bEyBYigGzkG1_Bn8uTAUsHvpZfJ6OoKqdkgvZuU7KygtG6aWzithXCRcrbslL7tXl_Sxm3es368P6wMMFJH8Xd2Kk6e5dJQJWRQvmesy_vXR_qqXKK5_9tczuAgWK8g7TFJ5PQEdr6G_F3y2GzQIWRonMaBCxQZi&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php

Bret, I feel I t would be a good test case as Council gears up. I agree decisions would get made in TC not Council. But Council could liason with TC to provide input to members of the TC. Or members of the Council may choose to join the TC for a bit to participate in this issue. So I do think it would be worthwhile to bring it to them. The role of the Council got debated a lot prior to its formation and these kind of issues (ie TC has decision making power) were raised and that resulted in the scope being worded as it was. Joerg: what are your thoughts as Council Chair? Would this be within scope to bring up to Council? Carol: as you were involved in setting up the Council, what are your thoughts on whether it would be within scope? Can you also comment on Bret’s IPR concern? I thought Council had same IPR rules as TC. If IPR gets in the way of Council ability to interact with TC’s, then some thought should be put into what Council’s charter really is. iPhone, iTypo, iApologize Duncan Sparrell sFractal Consulting, LLC The closer you look, the more you see _____________________________ From: Bret Jordan < bret_jordan@symantec.com > Sent: Tuesday, November 14, 2017 4:40 PM Subject: Re: [EXT] [cti-stix] Re: Eight Arguments for an Infrastructure SDO for STIX 2.1 To: < duncan@sfractal.com > Cc: < cti-stix@lists.oasis-open.org >, Joerg < je@cybersecurityscout.eu > I think the user’s council can give 30,000 foot guidance on you should consider doing x or y. But for the actual design elements and how it would be done, they would need to be members of the actual TC to not have IPR considerations. Bret  Sent from my Commodore 128D PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE  7415 0050 On Nov 14, 2017, at 4:29 AM, duncan@sfractal.com < duncan@sfractal.com > wrote: Jane, Gary, et al, This (infrastructure SDO) might be something you want to give as an issue for the OASIS Standards Council. I believe they were chartered to provide a way for users to stay abreast and influence where needed, without getting involved in all the day-to-day details of the many TC's. Their scope says: Provide OASIS cybersecurity TCs with a direct mechanism for obtaining user feedback on technical disputes . Sounds like Infrastructure SDO is the kind of issue that might be right up their alley to get you more data to break your tie. Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize
Original Message -------- Subject: [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1 From: Katz, Gary CTR DC3\DCCI < Gary.Katz.ctr@dc3.mil > Date: Mon, November 13, 2017 3:09 pm To: JG on CTI-TC < jg@ctin.us >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Jane,    Sorry for taking a long time to respond.  Since it seemed you put considerable amount of time into your email, I wanted to make sure I had time to put some thought into the problem before providing a response.  I agree that we need a way to represent malicious infrastructure within 2.1 although I believe there are multiple ways we can achieve this goal.   There are three options that I believe are possible (4 if you include not doing anything about infrastructure in 2.1, which I do not believe is an option)   Option 1: Create a New Infrastructure Object Option 2: Modify the Observed Data TLO to also model Infrastructure Option 3: Make Cyber Observables Top Level Objects   There are Pros and Cons to each of these, and I’d be interested in hearing everyone’s inputs.  My personal order of preference is Option 3, then Option 2, then Option 1.  My personnel opinion is we should not release 2.1 without a way to handle Infrastructure.    I think some of you will find it ironic that I would push for option 3, since I was one of those that fought against making cyber observables top level objects, but the reasons for keeping them separated no longer exist.  Cybox has been integrated into STIX, there is not a reason in my mind to keep them non-TLOs any longer.  The main disadvantage to making Cyber Observables TLOs is that it is a major breaking change from STIX 2.0.  We can debate how big a deal this is, but I’d rather rip the bandaid off now rather than having this issue long term.    From a model standpoint, embedding cyber observables within Observed Data results in graphs within graphs, which are in themselves difficult to deal for systems receiving STIX data.  Making Cyber Observables TLOs would fix this issue and simplify the model.   From an analyst standpoint.  I spent (parts of) the last several days manually ingesting text documents into our own cyber analytic system.  The model we use is a graph and is based closely on the STIX model.  I modeled a custom malware analysis report, an internal incident/event report, a short external government finished intelligence reporting of an event, and a longer external government intelligence reporting of multiple events.  I manually ingested a variety of reports to form my own options about how I think about the data and would like to model it, what is useful and what information cluttered the graph.    In the end, it did not matter to me if an object represented an IP address that was seen in a malware object or it was observed on my network or it was infrastructure found through other methods.  That context was contained in the linkages.  An IP address, is an IP address, is an IP address and storing it within Observed Data or an Infrastructure object did not make too much sense to me.   The fact that the IP was infrastructure used by the adversary was shown in my link types, not in the object itself.  For example, some IP address may relate to adversary infrastructure because the adversary had taken over the system for a time and then at a later time another adversary started using it.  It was infrastructure for both adversaries at different times, which is shown through the links and the time attached to those links, not through the IP address itself.   If we decide not to make Cyber Observables TLOs, my second option would be to extend the Observed Data TLO to meet the Infrastructure needs.  This would mean vastly increasing the number of relationship types assigned to Observed Data and adding on some extra properties.  One could be a Boolean stating whether the Cyber Observables were observed on your network or some other fashion.  By not creating an Infrastructure object, we avoid having one organization model the data using the Observed Data object and another organization use the Infrastructure object or the worst case scenario where an analyst feels they need to model it as Observed Data and Infrastructure, leading to them being extremely frustrated with us and receiving analysts seeing 4 objects in their system for every IP (one Observed Data object, one embedded IP address object in the OD, one Infrastructure Object and one IP address object in the Infrastructure object (yes some systems could optimize how this data is viewed, but some will not)).  I understand that we will be bastardizing the Observed Data object by doing this, but that’s another reason why making Cyber Observables TLOs is a better option in my view.   Lastly, I would suggest an Infrastructure object.  It would be similar to an Observed Data object but with more relationships associated with it.  This would still allow us  to complete the initial STIX model and provide the functionality that many users would expect to see within the model.    I agree with Bret, Jane and many others on the crucial need to model infrastructure, but I wanted to provide some additional options for how we can meet that need.   Apologies for the long email,    -Gary       From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of JG on CTI-TC Sent: Tuesday, November 7, 2017 7:19 PM To: cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   At present the CTI TC does not appear to be of one mind on the need for an Infrastructure SDO for 2.1. After months of debate in Slack and on the email list, after two intense working sessions at both the Bethesda, MD and Austin, TX face-to-face meetings, and after numerous discussions during working meetings and review of the working draft developed by Richard Struse and Bret Jordan, a Straw Man poll at Austin led to an almost even tie on whether or not to include an Infrastructure SDO in 2.1. I'm writing today to outline eight reasons why I believe we should seriously consider including an Infrastructure SDO for the STIX 2.1 release. Note that my view on the topic is as a threat hunter, educator, and analyst; therefore, I'll be relying on insights from the programmers, data architects, and MRTI aficionados to actually make it work. It will make the human-to-machine interface more effective during this period of rapid ecosystem expansion, ISAO/ISAC build-out, market/product definition and trust-building between private sector entities and law enforcement for critical infrastructure protection. 1.        An argument has been made that the Indicator SDO could serve as a series of interconnected buckets for a malicious infrastructure, and that specific Cyber Observables could be linked to such Indicator to define a malicious infrastructure with a Boolean property indicating the goodness or badness of a set of interconnected Indicators. I believe this would not be a suitable approach for the following reasons: 1) it would overload the Indicator SDO which already suffers from overuse and misunderstanding; 2) relationships would have to be drawn through the Observed Data SDO to the specific Cyber Observables.  Given how timestamps are handled this would add a layer of complexity that we could avoid with carefully designed properties on the Infrastructure SDO. 2.        A wide range of SDOs and Cyber Observables will need to be strung together in an interrelated complex of potentially rapidly changing data elements by producers seeking to convey rich detail about observations, sightings, TTPs, malware, network effects, and cyber observables operating as a single unified entity with a single purpose. Once issued by a Producer, sightings of one or more SDOs or cyber observables associated with this multi-headed Hydra will enable other members of a sharing community to quickly assess kill chain phases  or other clues on their own networks that may help expedite discovery. And when operating within a truly effective and skilled sharing community this could also lead to more rapid crowdsourced threat analysis with accompanying remediation recommendations. 3.        Foundational literature on tradecraft in cyber threat analysis includes an Infrastructure vertex as part of the analytical toolset. I'm referring here to the Diamond Model (Caltagirone, 2013) which directly juxtaposes threat actor capabilities to the infrastructure he uses. The origins and utility of the Diamond Model within the analyst community stands on its own merits, regardless of the fact that the STIX2 data model has moved on from this foundational concept. 4.        Advanced NoSQL graph database techniques are well suited to visualizing the interconnectedness of a malicious infrastructure expediting pattern recognition by human analysts seeking to perform higher level analysis and synthesis of STIX2 data. The power of this type of tooling should not be underestimated as we look towards the future of CTI and sharing communities. Indeed, such notable companies as OpenDNS (acquired by OASIS member CISCO) have used such visualizations to great success. Further, the use of data visualization techniques for enabling higher-order pattern recognition as a tool for analysis has been well documented by Tufte (2001), among others. Importantly, we need to build the Infrastructure SDO with sufficient metadata properties to enable these higher-order analytics.  For example, it will be important to link back to Threat Actor SDOs within a boxed time-frame to move closer to attribution.  5.        The larger global community of network defenders and cyber threat analysts are developing siloed versions of classification and enumeration systems for infrastructure as they are seeing it. However, we do not have a generally agreed upon system as we do have for malware (MAEC), exposures and vulnerabilities (CVE), and attack patterns (ATT&CK). By creating an Infrastructure SDO in STIX 2.1 we might be able to kick-start such a development. 6.        One of the key insights gleaned during the Austin, TX face-to-face meeting was the need for more effective outreach and marketing to the broader CTI community, beyond those actively participating in OASIS. The addition of Infrastructure SDO will send a positive market signal to this broader community which may speed adoption. This is because the inclusion of such an object, in conjunction with the fully vetted Malware object, will convey a level of maturity of the STIX2 data model that heretofore has been lacking. The perception of a data model that is actually reflective of reality will greatly enhance the reputation build of this phase of the market innovation, adoption, diffusion and transformation cycle. 7.        In research presented at the ENISA CTI Bonding event in Rome, Italy (ENISA, 2017) an analyst from CyberDefCon reported that the worst performing ASNs from its Shadowserver Foundation (2017) database over a multi-year period were AS29182 ISPSYSTEM (located in RU) and AS5577 ROOT (located in LU). This exemplifies how longitudinal data aggregated from proprietary and open sources can demonstrate that the Infrastructure of a large-scale operation can be used to identify bad actors at the Regional Registry level.  Since one of the stated objectives of CTI is to facilitate public/private sharing this example shows how the research community can provide evidence that can be used by the jurisdictional law enforcement authorities for enforcement action.  With an explicit “Infrastructure SDO” the evidentiary quality of the data for law enforcement can be improved. 8.        During a Sports-ISAO sponsored Internship program run during the World Championship games in London in August 2017 a group of 60+ Interns from over 30 Universities across the U.S. working to support the program identified the “digital exhaust” of multiple attack patterns targeting sports organizations and the related sponsors of such.  As a trainer for these novice threat hunters it was useful to provide visualizations of attack infrastructures to help them wrap their minds around the ideas of threat actors, campaigns, intrusion sets, indicators, cyber observables and other concepts we tried to capture in STIX2.  I am able to generate such visualizations from several sources other than STIX.  However, if I had had tangible evidence stemming from an Infrastructure SDO in STIX 2.X, the learning curve pedagogy would have been more streamlined. In summary, I needed the Infrastructure SDO in order to tie all of the pieces of the puzzle together.  If any of these arguments, make sense to you please let your voice be heard so that we can expedite the build towards consensus before an official Ballot on STIX 2.1. Also note that I recognize that the STIX Subcommittee is seeking a more orderly scheduling of discussions around Version 2.1 SDOs.  Therefore, I’m requesting that we reopen discussions on this object when it would fit into the existing schedule and SDO priorities.   _______________________________________________________________________ References: Caltagirone, S., Pendergast, A., Betz, C. (2013, July 5). The Diamond Model of Intrusion Analysis. http://www.dtic.mil/get-tr-doc/pdf?AD=ADA586960 ENISA (2017). https://www.enisa.europa.eu/events/cti-eu-event/enisa-cti-eu-event Hutchins, E., Cloppert, M., Amin, R. (2011).  Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. Lockheed Martin. Shadowserver (2017). https://www.shadowserver.org/wiki/pmwiki.php/Main/HomePage   Tufte, E.R. (2001). The Visual Display of Quantitative Information (2 nd Ed.). Graphics Press: Cheshire, CT. -- Jane Ginn, MSIA, MRP CTI TC Secretary, OASIS Co-Founder of Cyber Threat Intelligence Network, Inc. jg@ctin.us --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://clicktime.symantec.com/a/1/XmqGHYhyzbsdTgmlLUZa-1Ydiu0JzQQzf5JY-z3Wv1g=?d=jAjc4sDYmaktqDw9PWCZiA93JwfqslsFiGKRwLcpiPTPa9SeIELhrytPoJe-Uo7B1x6IA-G4yFcjM3gBa7buFDF6c5rKQuOgZUEcW_smrB-amEv4kAV5U_j1qpN_1SfRVEqWxOEB9PdMt6nluYJ8ENcGH8_i0VgvBU_Duz4Loxiv8aT1iXws1owDZ_f7oCJe0ha5wPvYZsyOJlxdkY0_e8wjF3joXNGW-LtZxV5WE79Dn4ddlbyXAQyvYcDGexEqQye0iUZG80UbUVRzj5-k8qr1cXSJEdNl4J9PLmxgl2hmwcHA1ZD3pYzn_MewbckTrMCHg3x7ar1tbVBNR4W_9mHZ-nT3LJYt_QvU543FmpyFa51AqsJ3bEyBYigGzkG1_Bn8uTAUsHvpZfJ6OoKqdkgvZuU7KygtG6aWzithXCRcrbslL7tXl_Sxm3es368P6wMMFJH8Xd2Kk6e5dJQJWRQvmesy_vXR_qqXKK5_9tczuAgWK8g7TFJ5PQEdr6G_F3y2GzQIWRonMaBCxQZi&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php

I threw this one over the wall to Chet, and here's his take: ---- I don't think the question of IPR mode applies here. My read on Bret's comment is that he wants to be sure the detailed solutions are done by the CTI members who are obligated by the TC's IPR mode. That can be addressed easily enough by having t he Council draft whatever they want to send over, then approve submitting it to the CTI TC's comment mailing list. That would allay any concern of IPR concerns.  The questions being asked, I think, are (a) whether or not the Council can get down into the technical weeds in its feedback and (b) whether or not they can, should they.  I don't know whether the question being debated is an in-the-weeds technical discussion or not and I don't have a position on whether the Council should wade in. They'll have to decide on that. I note that in their scope statement, one of its goals is to "Provide OASIS cybersecurity TCs with a direct mechanism for obtaining user feedback on technical disputes." So this ongoing debate would seem to fall right under that clause and so long as they don't cross the provision that "The User Council ... will not develop any Standards Track Work product materials" (that is, Committee Specs), I don't see the problem with them taking up the discussion. Especially if it is proving to be a difficult topic for the TC members to reach consensus. Vender/user feedback would seem to be ideal in that case.  Perhaps the way for the Council to approach it would be to say something like "we need whatever solution y'all come up with to meet the following objectives (or solve the following problems or...)" rather than getting into something that sounds like "well, we vote for that technical solution." In other words, have the Council address the parameters of the problem rather than get into the debates about how to solve it.  I think the Council has a broad scope to do whatever could help here. I personally think they do want to stay out of the truly technical debate but that's my opinion.  ---- Hope that helps, Carol On Tue, Nov 14, 2017 at 5:21 PM, Duncan < duncan@sfractal.com > wrote: Bret, I feel I t would be a good test case as Council gears up. I agree decisions would get made in TC not Council. But Council could liason with TC to provide input to members of the TC. Or members of the Council may choose to join the TC for a bit to participate in this issue. So I do think it would be worthwhile to bring it to them. The role of the Council got debated a lot prior to its formation and these kind of issues (ie TC has decision making power) were raised and that resulted in the scope being worded as it was. Joerg: what are your thoughts as Council Chair? Would this be within scope to bring up to Council? Carol: as you were involved in setting up the Council, what are your thoughts on whether it would be within scope? Can you also comment on Bret’s IPR concern? I thought Council had same IPR rules as TC. If IPR gets in the way of Council ability to interact with TC’s, then some thought should be put into what Council’s charter really is. iPhone, iTypo, iApologize Duncan Sparrell sFractal Consulting, LLC The closer you look, the more you see _____________________________ From: Bret Jordan < bret_jordan@symantec.com > Sent: Tuesday, November 14, 2017 4:40 PM Subject: Re: [EXT] [cti-stix] Re: Eight Arguments for an Infrastructure SDO for STIX 2.1 To: < duncan@sfractal.com > Cc: < cti-stix@lists.oasis-open.org >, Joerg < je@cybersecurityscout.eu > I think the user’s council can give 30,000 foot guidance on you should consider doing x or y. But for the actual design elements and how it would be done, they would need to be members of the actual TC to not have IPR considerations. Bret  Sent from my Commodore 128D PGP Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE  7415 0050 On Nov 14, 2017, at 4:29 AM, " duncan@sfractal.com " < duncan@sfractal.com > wrote: Jane, Gary, et al, This (infrastructure SDO) might be something you want to give as an issue for the OASIS Standards Council. I believe they were chartered to provide a way for users to stay abreast and influence where needed, without getting involved in all the day-to-day details of the many TC's. Their scope says: "Provide OASIS cybersecurity TCs with a direct mechanism for obtaining user feedback on technical disputes". Sounds like Infrastructure SDO is the kind of issue that might be right up their alley to get you more data to break your tie. Duncan Sparrell sFractal Consulting LLC iPhone, iTypo, iApologize
Original Message -------- Subject: [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1 From: "Katz, Gary CTR DC3\DCCI" < Gary.Katz.ctr@dc3.mil > Date: Mon, November 13, 2017 3:09 pm To: JG on CTI-TC < jg@ctin.us >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Jane,    Sorry for taking a long time to respond.  Since it seemed you put considerable amount of time into your email, I wanted to make sure I had time to put some thought into the problem before providing a response.  I agree that we need a way to represent malicious infrastructure within 2.1 although I believe there are multiple ways we can achieve this goal.   There are three options that I believe are possible (4 if you include not doing anything about infrastructure in 2.1, which I do not believe is an option)   Option 1: Create a New Infrastructure Object Option 2: Modify the Observed Data TLO to also model Infrastructure Option 3: Make Cyber Observables Top Level Objects   There are Pros and Cons to each of these, and I’d be interested in hearing everyone’s inputs.  My personal order of preference is Option 3, then Option 2, then Option 1.  My personnel opinion is we should not release 2.1 without a way to handle Infrastructure.    I think some of you will find it ironic that I would push for option 3, since I was one of those that fought against making cyber observables top level objects, but the reasons for keeping them separated no longer exist.  Cybox has been integrated into STIX, there is not a reason in my mind to keep them non-TLOs any longer.  The main disadvantage to making Cyber Observables TLOs is that it is a major breaking change from STIX 2.0.  We can debate how big a deal this is, but I’d rather rip the bandaid off now rather than having this issue long term.    From a model standpoint, embedding cyber observables within Observed Data results in graphs within graphs, which are in themselves difficult to deal for systems receiving STIX data.  Making Cyber Observables TLOs would fix this issue and simplify the model.   From an analyst standpoint.  I spent (parts of) the last several days manually ingesting text documents into our own cyber analytic system.  The model we use is a graph and is based closely on the STIX model.  I modeled a custom malware analysis report, an internal incident/event report, a short external government finished intelligence reporting of an event, and a longer external government intelligence reporting of multiple events.  I manually ingested a variety of reports to form my own options about how I think about the data and would like to model it, what is useful and what information cluttered the graph.    In the end, it did not matter to me if an object represented an IP address that was seen in a malware object or it was observed on my network or it was infrastructure found through other methods.  That context was contained in the linkages.  An IP address, is an IP address, is an IP address and storing it within Observed Data or an Infrastructure object did not make too much sense to me.   The fact that the IP was infrastructure used by the adversary was shown in my link types, not in the object itself.  For example, some IP address may relate to adversary infrastructure because the adversary had taken over the system for a time and then at a later time another adversary started using it.  It was infrastructure for both adversaries at different times, which is shown through the links and the time attached to those links, not through the IP address itself.   If we decide not to make Cyber Observables TLOs, my second option would be to extend the Observed Data TLO to meet the Infrastructure needs.  This would mean vastly increasing the number of relationship types assigned to Observed Data and adding on some extra properties.  One could be a Boolean stating whether the Cyber Observables were observed on your network or some other fashion.  By not creating an Infrastructure object, we avoid having one organization model the data using the Observed Data object and another organization use the Infrastructure object or the worst case scenario where an analyst feels they need to model it as Observed Data and Infrastructure, leading to them being extremely frustrated with us and receiving analysts seeing 4 objects in their system for every IP (one Observed Data object, one embedded IP address object in the OD, one Infrastructure Object and one IP address object in the Infrastructure object (yes some systems could optimize how this data is viewed, but some will not)).  I understand that we will be bastardizing the Observed Data object by doing this, but that’s another reason why making Cyber Observables TLOs is a better option in my view.   Lastly, I would suggest an Infrastructure object.  It would be similar to an Observed Data object but with more relationships associated with it.  This would still allow us  to complete the initial STIX model and provide the functionality that many users would expect to see within the model.    I agree with Bret, Jane and many others on the crucial need to model infrastructure, but I wanted to provide some additional options for how we can meet that need.   Apologies for the long email,    -Gary       From: cti-stix@lists.oasis- open.org [ mailto:cti-stix@lists.oasis- open.org ] On Behalf Of JG on CTI-TC Sent: Tuesday, November 7, 2017 7:19 PM To: cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   At present the CTI TC does not appear to be of one mind on the need for an Infrastructure SDO for 2.1. After months of debate in Slack and on the email list, after two intense working sessions at both the Bethesda, MD and Austin, TX face-to-face meetings, and after numerous discussions during working meetings and review of the working draft developed by Richard Struse and Bret Jordan, a Straw Man poll at Austin led to an almost even tie on whether or not to include an Infrastructure SDO in 2.1. I'm writing today to outline eight reasons why I believe we should seriously consider including an Infrastructure SDO for the STIX 2.1 release. Note that my view on the topic is as a threat hunter, educator, and analyst; therefore, I'll be relying on insights from the programmers, data architects, and MRTI aficionados to actually make it work. It will make the human-to-machine interface more effective during this period of rapid ecosystem expansion, ISAO/ISAC build-out, market/product definition and trust-building between private sector entities and law enforcement for critical infrastructure protection. 1.        An argument has been made that the Indicator SDO could serve as a series of interconnected buckets for a malicious infrastructure, and that specific Cyber Observables could be linked to such Indicator to define a malicious infrastructure with a Boolean property indicating the goodness or badness of a set of interconnected Indicators. I believe this would not be a suitable approach for the following reasons: 1) it would overload the Indicator SDO which already suffers from overuse and misunderstanding; 2) relationships would have to be drawn through the Observed Data SDO to the specific Cyber Observables.  Given how timestamps are handled this would add a layer of complexity that we could avoid with carefully designed properties on the Infrastructure SDO. 2.        A wide range of SDOs and Cyber Observables will need to be strung together in an interrelated complex of potentially rapidly changing data elements by producers seeking to convey rich detail about observations, sightings, TTPs, malware, network effects, and cyber observables operating as a single unified entity with a single purpose. Once issued by a Producer, sightings of one or more SDOs or cyber observables associated with this multi-headed Hydra will enable other members of a sharing community to quickly assess kill chain phases  or other clues on their own networks that may help expedite discovery. And when operating within a truly effective and skilled sharing community this could also lead to more rapid crowdsourced threat analysis with accompanying remediation recommendations. 3.        Foundational literature on tradecraft in cyber threat analysis includes an Infrastructure vertex as part of the analytical toolset. I'm referring here to the Diamond Model (Caltagirone, 2013) which directly juxtaposes threat actor capabilities to the infrastructure he uses. The origins and utility of the Diamond Model within the analyst community stands on its own merits, regardless of the fact that the STIX2 data model has moved on from this foundational concept. 4.        Advanced NoSQL graph database techniques are well suited to visualizing the interconnectedness of a malicious infrastructure expediting pattern recognition by human analysts seeking to perform higher level analysis and synthesis of STIX2 data. The power of this type of tooling should not be underestimated as we look towards the future of CTI and sharing communities. Indeed, such notable companies as OpenDNS (acquired by OASIS member CISCO) have used such visualizations to great success. Further, the use of data visualization techniques for enabling higher-order pattern recognition as a tool for analysis has been well documented by Tufte (2001), among others. Importantly, we need to build the Infrastructure SDO with sufficient metadata properties to enable these higher-order analytics.  For example, it will be important to link back to Threat Actor SDOs within a boxed time-frame to move closer to attribution.  5.        The larger global community of network defenders and cyber threat analysts are developing siloed versions of classification and enumeration systems for infrastructure as they are seeing it. However, we do not have a generally agreed upon system as we do have for malware (MAEC), exposures and vulnerabilities (CVE), and attack patterns (ATT&CK). By creating an Infrastructure SDO in STIX 2.1 we might be able to kick-start such a development. 6.        One of the key insights gleaned during the Austin, TX face-to-face meeting was the need for more effective outreach and marketing to the broader CTI community, beyond those actively participating in OASIS. The addition of Infrastructure SDO will send a positive market signal to this broader community which may speed adoption. This is because the inclusion of such an object, in conjunction with the fully vetted Malware object, will convey a level of maturity of the STIX2 data model that heretofore has been lacking. The perception of a data model that is actually reflective of reality will greatly enhance the reputation build of this phase of the market innovation, adoption, diffusion and transformation cycle. 7.        In research presented at the ENISA CTI Bonding event in Rome, Italy (ENISA, 2017) an analyst from CyberDefCon reported that the worst performing ASNs from its Shadowserver Foundation (2017) database over a multi-year period were AS29182 ISPSYSTEM (located in RU) and AS5577 ROOT (located in LU). This exemplifies how longitudinal data aggregated from proprietary and open sources can demonstrate that the Infrastructure of a large-scale operation can be used to identify bad actors at the Regional Registry level.  Since one of the stated objectives of CTI is to facilitate public/private sharing this example shows how the research community can provide evidence that can be used by the jurisdictional law enforcement authorities for enforcement action.  With an explicit “Infrastructure SDO” the evidentiary quality of the data for law enforcement can be improved. 8.        During a Sports-ISAO sponsored Internship program run during the World Championship games in London in August 2017 a group of 60+ Interns from over 30 Universities across the U.S. working to support the program identified the “digital exhaust” of multiple attack patterns targeting sports organizations and the related sponsors of such.  As a trainer for these novice threat hunters it was useful to provide visualizations of attack infrastructures to help them wrap their minds around the ideas of threat actors, campaigns, intrusion sets, indicators, cyber observables and other concepts we tried to capture in STIX2.  I am able to generate such visualizations from several sources other than STIX.  However, if I had had tangible evidence stemming from an Infrastructure SDO in STIX 2.X, the learning curve pedagogy would have been more streamlined. In summary, I needed the Infrastructure SDO in order to tie all of the pieces of the puzzle together.  If any of these arguments, make sense to you please let your voice be heard so that we can expedite the build towards consensus before an official Ballot on STIX 2.1. Also note that I recognize that the STIX Subcommittee is seeking a more orderly scheduling of discussions around Version 2.1 SDOs.  Therefore, I’m requesting that we reopen discussions on this object when it would fit into the existing schedule and SDO priorities.   _____________________________ ______________________________ ____________ References: Caltagirone, S., Pendergast, A., Betz, C. (2013, July 5). The Diamond Model of Intrusion Analysis. http://www.dtic.mil/ get-tr-doc/pdf?AD=ADA586960 ENISA (2017). https://www.enisa.europa.eu/ events/cti-eu-event/enisa-cti- eu-event Hutchins, E., Cloppert, M., Amin, R. (2011).  Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. Lockheed Martin. Shadowserver (2017). https://www.shadowserver.org/ wiki/pmwiki.php/Main/HomePage   Tufte, E.R. (2001). The Visual Display of Quantitative Information (2 nd Ed.). Graphics Press: Cheshire, CT. -- Jane Ginn, MSIA, MRP CTI TC Secretary, OASIS Co-Founder of Cyber Threat Intelligence Network, Inc. jg@ctin.us ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://clicktime.symantec. com/a/1/XmqGHYhyzbsdTgmlLUZa- 1Ydiu0JzQQzf5JY-z3Wv1g=?d= jAjc4sDYmaktqDw9PWCZiA93Jwfqsl sFiGKRwLcpiPTPa9SeIELhrytPoJe- Uo7B1x6IA- G4yFcjM3gBa7buFDF6c5rKQuOgZUEc W_smrB-amEv4kAV5U_j1qpN_ 1SfRVEqWxOEB9PdMt6nluYJ8ENcGH8 _i0VgvBU_ Duz4Loxiv8aT1iXws1owDZ_ f7oCJe0ha5wPvYZsyOJlxdkY0_ e8wjF3joXNGW- LtZxV5WE79Dn4ddlbyXAQyvYcDGexE qQye0iUZG80UbUVRzj5- k8qr1cXSJEdNl4J9PLmxgl2hmwcHA1 ZD3pYzn_ MewbckTrMCHg3x7ar1tbVBNR4W_ 9mHZ-nT3LJYt_ QvU543FmpyFa51AqsJ3bEyBYigGzkG 1_ Bn8uTAUsHvpZfJ6OoKqdkgvZuU7Kyg tG6aWzithXCRcrbslL7tXl_ Sxm3es368P6wMMFJH8Xd2Kk6e5dJQJ WRQvmesy_vXR_qqXKK5_ 9tczuAgWK8g7TFJ5PQEdr6G_ F3y2GzQIWRonMaBCxQZi&u=https% 3A%2F%2Fwww.oasis-open.org% 2Fapps%2Forg%2Fworkgroup% 2Fportal%2Fmy_workgroups.php -- Carol Geyer Senior Director, OASIS Borderless Cyber Conference and Technical Symposium http://eu17.first-oasis-conference.org/en/

On 16.11.2017 08:25:41, Carol Geyer wrote: > > Perhaps the way for the Council to approach it would be to say > something like "we need whatever solution y'all come up with to meet > the following objectives (or solve the following problems or...)" > rather than getting into something that sounds like "well, we vote > for that technical solution." In other words, have the Council > address the parameters of the problem rather than get into the > debates about how to solve it. > All - There's broad consensus within the CTI TC that we *need* an Infrastructure SDO in STIX. There's just a lot of work ahead of us to define the object's properties and relationships. Unless the Council are able to do that work for us, it's unclear to me how their input will help accelerate our velocity. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "There are two types of people: those who fit into my taxonomy and those who do not." --anonymous Attachment: signature.asc Description: Digital signature

Duncan/Carol & All: My take on this debate is that it would be premature for the Council to take up an issue like this.  I think Duncan keyed off of my statement in an earlier email about a tie vote from a Straw Man poll we took at the F2F on the Infrastructure SDO.  That poll was non-binding and unofficial and not necessarily indicative of the view of the entire TC membership.  We would need to do a Ballot to gauge that; and I think it would be premature for a Ballot on this topic as well. As Sarah Kelley noted in her briefing on the status of the STIX 2.1 data objects during our full TC calls yesterday, we have not even had 1 of 3 focused, time-boxed calls within the TC on the potential for an Infrastructure SDO for 2.1.  We should take those steps next.  It has been my observation that the CTI TC is actually quite effective at working through a process of reasoned debate to come to some agreement on a path forward.  I see this proposed SDO as no different from any of the others that we've already worked through. There does seem to be some conflation of the idea of an Infrastructure SDO with a re-examination of the structure of the Observed Data SDO/STIX Cyber Observables (SCOs) relative to the other SDOs.  But, I believe, the debate that has commenced on this topic is quite healthy.  It is helping people to separate their thinking about STIX 2.x as an interchange graph-based model from the idea of a database that would be used as part of a product implementation.  Once we all align our thinking on this matter, I think the separation of these two topics (i.e., 1. adding an Infrastructure SDO to 2.1 and 2. elevating SCOs to top-level citizens) will be made. Then, the path forward to an Infrastructure SDO for 2.1 will be easier to see as a Crawl, Walk, Run approach.  I think we need to separate these issues.  An Infrastructure SDO solves an immediate implementation problem.  The structure of SCOs within the STIX 2.x graph model is a systemic issue that should be debated solely on its own merits. My 2 cents. Jane Ginn On 11/17/2017 9:22 AM, Trey Darley wrote: > On 16.11.2017 08:25:41, Carol Geyer wrote: >> Perhaps the way for the Council to approach it would be to say >> something like "we need whatever solution y'all come up with to meet >> the following objectives (or solve the following problems or...)" >> rather than getting into something that sounds like "well, we vote >> for that technical solution." In other words, have the Council >> address the parameters of the problem rather than get into the >> debates about how to solve it. >> > All - > > There's broad consensus within the CTI TC that we *need* an > Infrastructure SDO in STIX. There's just a lot of work ahead of us to > define the object's properties and relationships. Unless the Council > are able to do that work for us, it's unclear to me how their input > will help accelerate our velocity. > -- Jane Ginn, MSIA, MRP CTI TC Secretary, OASIS Co-Founder of Cyber Threat Intelligence Network, Inc. jg@ctin.us

I completely agree with Jane. This CTI TC is quite effective at eventually coming to agreement on topics after debating the issues - and generally we get to a consensus where everyone is equally unhappy :). I think the system operates well enough - although I would like to see some 'design principles' discussed and agreed to by the CTI TC to help compare and contrast competing proposals to help speed decision making.. Here's my ' starter for 10 ': Cheers Terry MacDonald   Chief Product Officer M:   +64 211 918 814 E:   terry.macdonald@cosive.com W:   www.cosive.com On Sat, Nov 18, 2017 at 8:14 AM, JG on CTI-TC < jg@ctin.us > wrote: Duncan/Carol & All: My take on this debate is that it would be premature for the Council to take up an issue like this.  I think Duncan keyed off of my statement in an earlier email about a tie vote from a Straw Man poll we took at the F2F on the Infrastructure SDO.  That poll was non-binding and unofficial and not necessarily indicative of the view of the entire TC membership.  We would need to do a Ballot to gauge that; and I think it would be premature for a Ballot on this topic as well. As Sarah Kelley noted in her briefing on the status of the STIX 2.1 data objects during our full TC calls yesterday, we have not even had 1 of 3 focused, time-boxed calls within the TC on the potential for an Infrastructure SDO for 2.1.  We should take those steps next.  It has been my observation that the CTI TC is actually quite effective at working through a process of reasoned debate to come to some agreement on a path forward.  I see this proposed SDO as no different from any of the others that we've already worked through. There does seem to be some conflation of the idea of an Infrastructure SDO with a re-examination of the structure of the Observed Data SDO/STIX Cyber Observables (SCOs) relative to the other SDOs.  But, I believe, the debate that has commenced on this topic is quite healthy.  It is helping people to separate their thinking about STIX 2.x as an interchange graph-based model from the idea of a database that would be used as part of a product implementation.  Once we all align our thinking on this matter, I think the separation of these two topics (i.e., 1. adding an Infrastructure SDO to 2.1 and 2. elevating SCOs to top-level citizens) will be made. Then, the path forward to an Infrastructure SDO for 2.1 will be easier to see as a Crawl, Walk, Run approach.  I think we need to separate these issues.  An Infrastructure SDO solves an immediate implementation problem.  The structure of SCOs within the STIX 2.x graph model is a systemic issue that should be debated solely on its own merits. My 2 cents. Jane Ginn On 11/17/2017 9:22 AM, Trey Darley wrote: > On 16.11.2017 08:25:41, Carol Geyer wrote: >> Perhaps the way for the Council to approach it would be to say >> something like "we need whatever solution y'all come up with to meet >> the following objectives (or solve the following problems or...)" >> rather than getting into something that sounds like "well, we vote >> for that technical solution." In other words, have the Council >> address the parameters of the problem rather than get into the >> debates about how to solve it. >> > All - > > There's broad consensus within the CTI TC that we *need* an > Infrastructure SDO in STIX. There's just a lot of work ahead of us to > define the object's properties and relationships. Unless the Council > are able to do that work for us, it's unclear to me how their input > will help accelerate our velocity. > -- Jane Ginn, MSIA, MRP CTI TC Secretary, OASIS Co-Founder of Cyber Threat Intelligence Network, Inc. jg@ctin.us ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php Attachment: STIX Core Design Principles.jpg Description: JPEG image

I agree with Jane 


Bret 

Sent from my Commodore 128D


PGP
Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


On Nov 18, 2017, at 3:15 AM, JG on CTI-TC < jg@ctin.us > wrote:



Duncan/Carol & All:

My take on this debate is that it would be premature for the Council to
take up an issue like this.  I think Duncan keyed off of my statement in
an earlier email about a tie vote from a Straw Man poll we took at the
F2F on the Infrastructure SDO.  That poll was non-binding and unofficial
and not necessarily indicative of the view of the entire TC membership. 
We would need to do a Ballot to gauge that; and I think it would be
premature for a Ballot on this topic as well. As Sarah Kelley noted in
her briefing on the status of the STIX 2.1 data objects during our full
TC calls yesterday, we have not even had 1 of 3 focused, time-boxed
calls within the TC on the potential for an Infrastructure SDO for 2.1. 
We should take those steps next. 

It has been my observation that the CTI TC is actually quite effective
at working through a process of reasoned debate to come to some
agreement on a path forward.  I see this proposed SDO as no different
from any of the others that we've already worked through. There does
seem to be some conflation of the idea of an Infrastructure SDO with a
re-examination of the structure of the Observed Data SDO/STIX Cyber
Observables (SCOs) relative to the other SDOs.  But, I believe, the
debate that has commenced on this topic is quite healthy.  It is helping
people to separate their thinking about STIX 2.x as an interchange
graph-based model from the idea of a database that would be used as part
of a product implementation.  Once we all align our thinking on this
matter, I think the separation of these two topics (i.e., 1. adding an
Infrastructure SDO to 2.1 and 2. elevating SCOs to top-level citizens)
will be made. Then, the path forward to an Infrastructure SDO for 2.1
will be easier to see as a Crawl, Walk, Run approach. 

I think we need to separate these issues.  An Infrastructure SDO solves
an immediate implementation problem.  The structure of SCOs within the
STIX 2.x graph model is a systemic issue that should be debated solely
on its own merits.


My 2 cents.

Jane Ginn


On 11/17/2017 9:22 AM, Trey Darley wrote:
On 16.11.2017 08:25:41, Carol Geyer wrote:


Perhaps the way for the Council to approach it would be to say



something like "we need whatever solution y'all come up with to meet



the following objectives (or solve the following problems or...)"



rather than getting into something that sounds like "well, we vote



for that technical solution." In other words, have the Council



address the parameters of the problem rather than get into the



debates about how to solve it.






All -



There's broad consensus within the CTI TC that we *need* an

Infrastructure SDO in STIX. There's just a lot of work ahead of us to

define the object's properties and relationships. Unless the Council

are able to do that work for us, it's unclear to me how their input

will help accelerate our velocity.




--
Jane Ginn, MSIA, MRP
CTI TC Secretary, OASIS
Co-Founder of Cyber Threat Intelligence Network, Inc.
jg@ctin.us

No worries, I withdraw the request. You all are in much better position to tell if you need a broader user input to resolve this issue.  Jane is correct that I was keying off the ‘tie’ aspect of her email. I was combining it with the expressed worry that some of members were not engaging as much as previously. It was my understanding some CTI members had ‘moved’ to Standards Council because they didn’t want to be involved in all the day to day, but did want to be appraised when user (what they call non-vendor) input was desired. At least that was what several people said about CTI at the NYC Borderless Cyber meeting setting up the User’s Council. Since there hadn’t been any CTI/Council interaction as yet, I thought this might be a way to re-engage the lost sheep. But I defer to your judgement on whether you need a broader swath of user input to resolve this particular issue. iPhone, iTypo, iApologize Duncan Sparrell sFractal Consulting, LLC The closer you look, the more you see On Fri, Nov 17, 2017 at 2:15 PM -0500, JG on CTI-TC < jg@ctin.us > wrote: Duncan/Carol & All: My take on this debate is that it would be premature for the Council to take up an issue like this.  I think Duncan keyed off of my statement in an earlier email about a tie vote from a Straw Man poll we took at the F2F on the Infrastructure SDO.  That poll was non-binding and unofficial and not necessarily indicative of the view of the entire TC membership.  We would need to do a Ballot to gauge that; and I think it would be premature for a Ballot on this topic as well. As Sarah Kelley noted in her briefing on the status of the STIX 2.1 data objects during our full TC calls yesterday, we have not even had 1 of 3 focused, time-boxed calls within the TC on the potential for an Infrastructure SDO for 2.1.  We should take those steps next.  It has been my observation that the CTI TC is actually quite effective at working through a process of reasoned debate to come to some agreement on a path forward.  I see this proposed SDO as no different from any of the others that we've already worked through. There does seem to be some conflation of the idea of an Infrastructure SDO with a re-examination of the structure of the Observed Data SDO/STIX Cyber Observables (SCOs) relative to the other SDOs.  But, I believe, the debate that has commenced on this topic is quite healthy.  It is helping people to separate their thinking about STIX 2.x as an interchange graph-based model from the idea of a database that would be used as part of a product implementation.  Once we all align our thinking on this matter, I think the separation of these two topics (i.e., 1. adding an Infrastructure SDO to 2.1 and 2. elevating SCOs to top-level citizens) will be made. Then, the path forward to an Infrastructure SDO for 2.1 will be easier to see as a Crawl, Walk, Run approach.  I think we need to separate these issues.  An Infrastructure SDO solves an immediate implementation problem.  The structure of SCOs within the STIX 2.x graph model is a systemic issue that should be debated solely on its own merits. My 2 cents. Jane Ginn On 11/17/2017 9:22 AM, Trey Darley wrote: > On 16.11.2017 08:25:41, Carol Geyer wrote: >> Perhaps the way for the Council to approach it would be to say >> something like we need whatever solution y'all come up with to meet >> the following objectives (or solve the following problems or...) >> rather than getting into something that sounds like well, we vote >> for that technical solution. In other words, have the Council >> address the parameters of the problem rather than get into the >> debates about how to solve it. >> > All - > > There's broad consensus within the CTI TC that we *need* an > Infrastructure SDO in STIX. There's just a lot of work ahead of us to > define the object's properties and relationships. Unless the Council > are able to do that work for us, it's unclear to me how their input > will help accelerate our velocity. > -- Jane Ginn, MSIA, MRP CTI TC Secretary, OASIS Co-Founder of Cyber Threat Intelligence Network, Inc. jg@ctin.us --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php