CTI STIX Subcommittee

 View Only
  • 1.  Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1

    Posted 11-14-2017 16:49
    My opinion is Option #1. I think it is fairly obvious to all that Infrastructure is a needed capability, the only question was "when" - but I do not think that making Cyber Observables TLOs is a way to do that. An observable is something that is static, that is a fact at a point in time, that never changes, and that can observed - that thing would *point* at Infrastructure, it is not the infrastructure itself. Making Cyber Observables TLOs would not solve the use case properly - most of the requirements for Infrastructure Jane has below,  would not be solved by this at all. They would require an actual Infrastructure object. I have yet to see someone present a concrete use case for why we should make cyber observables a TLO. It has been proposed multiple times in the past and debated to death - it is perhaps the second-most debated subject in the TC (after timestamps).  I am all for the idea of "fixing what is broken" in STIX, as Brett says, but to me if we are going to re-open topics that have been extensively debated and yet voted on in another direction, there is a significant burden on the proposer as to why it should be re-opened. I don't see that burden being met here. What are the specific modeling problem(s) that would be solved by making cyber observables top level objects, that can not be solved in any other fashion? - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Sean Barnum <sean.barnum@FireEye.com> To:         Bret Jordan <Bret_Jordan@symantec.com>, "Katz, Gary CTR DC3DCCI" <Gary.Katz.ctr@dc3.mil> Cc:         JG on CTI-TC <jg@ctin.us>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:         11/14/2017 12:11 PM Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1 Sent by:         <cti-stix@lists.oasis-open.org> Speaking for myself specifically and for FireEye, we very strongly agree with Jane’s overall perspective and with each and every one of the motivating arguments she has taken the time to outline for us.   We also very strongly agree with Gary’s perspective that addressing the issue of infrastructure should begin with making Cyber Observables top level objects. Forcing observables to exist only within an Observed Data wrapping artificially constrains observables to a context and use that is artificially constrained to a single temporal context of observation. As Gary points out these observables in reality exist and are useful in numerous and varied contexts beyond simply a single temporal context of observation. By breaking them out into top level objects they may be expressed in a consistent form without unnecessary duplication (across temporal observations) or semantic gymnastics (for situations like infrastructure that are other than a simple observation) and the specific context for any use of the observable can, as Gary describes, be expressed within the relationships of that observable to other content. We agree with Gary and Bret that this change should be made and now is the time to do it rather than later when the impact will likely be far greater not only as a breaking change to existing implementations but also due to other ongoing language design decisions that are made based on the current structure.   We do diverge with the rest of Gary’s opinions on the options he presented. We would strongly disagree with Option 2 which we view as perpetuating and exacerbating a flawed design and would represent some very confusing and invalid semantic gymnastics to use a temporally constrained observation construct to attempt to represent a non-temporally constrained concept like Infrastructure.   We also believe that while Option 3 is urgently necessary, it by itself is still not a full adequate solution for infrastructure. It should be combined with Option 1. I think this is what Bret is suggesting in his second paragraph below. Bret, feel free to correct me if I am mistaken. We believe the ideal solution is an independent Infrastructure SDO that can represent an aggregate infrastructure whether simple or complex that can then be associated with appropriate ThreatActors, Campaigns, Malware, IntrusionSets, etc in a clean, clear and unambiguous way to support many of the use cases Jane outlines. This Infrastructure SDO can also be associated with any number of top level Cyber Observable objects to characterize any simple or complex infrastructure. This could include clean, clear and unambiguous relationships between Cyber Observables within this infrastructure. It also enables the characterization of cyber observables that exist within multiple infrastructures (a common occurrence) in a clean, efficient and pivotable manner. We would assert that this approach offers the cleanest model where each concept is distinct and clearly understood, granular and inherently linkable to support effective graph-based analysis and visualization, and straightforward to implement in code without unnecessary convolutions, conflations or complex interdependencies.       Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com   From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Date: Monday, November 13, 2017 at 7:26 PM To: "Katz, Gary CTR DC3DCCI" <Gary.Katz.ctr@dc3.mil> Cc: JG on CTI-TC <jg@ctin.us>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   I agree with Gary and Jane on the need for a solution to infrastructure for 2.1.  In my opinion I do not think we should ship 2.1 without it.  Infrastructure and Malware are the two biggest missing parts that are preventing adoption.   I agree with Gary’s other points as well, though I would add a 4th option of make cyber observable TLOs and add a meta data object called infrastructure so you can record higher level information about how the threat actor is using the infrastructure.  All of the IPs and such would link to it via real relationships and we could then use the relationship dates to establish validity.   Bret     Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Nov 14, 2017, at 4:10 AM, Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil > wrote: 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 This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


  • 2.  Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1

    Posted 11-14-2017 23:51
    Jason Keirstead wrote this message on Tue, Nov 14, 2017 at 16:48 +0000: > I have yet to see someone present a concrete use case for why we should > make cyber observables a TLO. It has been proposed multiple times in the > past and debated to death - it is perhaps the second-most debated subject > in the TC (after timestamps). I am all for the idea of "fixing what is > broken" in STIX, as Brett says, but to me if we are going to re-open > topics that have been extensively debated and yet voted on in another > direction, there is a significant burden on the proposer as to why it > should be re-opened. I don't see that burden being met here. > > What are the specific modeling problem(s) that would be solved by making > cyber observables top level objects, that can not be solved in any other > fashion? I agree. There is lots of talk, but little documentation on why the change should be done, what it will look like, how it will be used, etc. Yes, people have bits and pieces throughout emails, but there is not a document that even a majority of the proponets of the concept even agree upon things should look like. -- John-Mark


  • 3.  Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1

    Posted 11-15-2017 03:35



    We should probably get people together to talk about and discuss.  This will help us know for sure if a change is needed and to what extent that change is needed. 


    What we really need is people that have started writing code for this.  This discussion is not about theory, or perceived goodness or badness, but what have people seen in working code.



    Bret 

    Sent from my Commodore 128D


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


    On Nov 15, 2017, at 7:51 AM, John-Mark Gurney < jmg@newcontext.com > wrote:



    Jason Keirstead wrote this message on Tue, Nov 14, 2017 at 16:48 +0000:
    I have yet to see someone present a concrete use case for why we should


    make cyber observables a TLO. It has been proposed multiple times in the


    past and debated to death - it is perhaps the second-most debated subject


    in the TC (after timestamps).  I am all for the idea of "fixing what is


    broken" in STIX, as Brett says, but to me if we are going to re-open


    topics that have been extensively debated and yet voted on in another


    direction, there is a significant burden on the proposer as to why it


    should be re-opened. I don't see that burden being met here.




    What are the specific modeling problem(s) that would be solved by making


    cyber observables top level objects, that can not be solved in any other


    fashion?


    I agree.  There is lots of talk, but little documentation on why the
    change should be done, what it will look like, how it will be used, etc.

    Yes, people have bits and pieces throughout emails, but there is not a
    document that even a majority of the proponets of the concept even agree
    upon things should look like.

    --
    John-Mark









  • 4.  RE: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1

    Posted 11-15-2017 22:36
    Jason,     I’ll try to provide a couple of reasons for making cyber observables TLOs but I’d be interested in others providing their thoughts.   1.        Removes graphs-within-graphs problem:  Currently the Cyber Observables can link to each other within an Observed Data object but cannot be directly linked to.  This creates a subgraph within the larger STIX graph and creates unnecessary processing issues. 2.        Encourages inefficiencies for analysts: While a system could hide the Observed Data and Infrastructure objects from the user, most implementers will probably just follow the STIX structure.  Currently if an analyst were to manually want to say that they observed an IP they need to create an Observed Data object and then link that object to an IP address.  This requires the creation of 2 objects rather than one, or in the case of viewing, they would see two objects instead of 1, creating unnecessary clutter. 3.        Infrastructure and Observed Data provide context about the Cyber Observables.  Elsewhere within STIX we use relationship information (links) to capture context.  By making Cyber Observables TLOs we would follow the same model as the rest of STIX. 4.        Analysts are used to it.  If you review current cyber intelligence platforms, Maltego, TrueStar, Threat Connect, Anomali, etc. Cyber Observables are directly shown on the graphs (note: in general their models are less detailed than STIX, so I am not suggesting we just adopt their level of detail, second note: my knowledge may be dated, I have not reviewed these platforms too recently).  Analysts are used to working in that paradigm, why confuse them? 5.        Lastly, I do not believe we would have chosen this design if we were not starting out with Cybox being separated from STIX and with organizations (me!) pushing for cybox to remain separate so it could easily be used in other schemas.  Cybox has been fully integrated as a part of STIX, so this original reason for calling it out separately no longer applies.   My 2 cents.    -Gary   From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com] Sent: Tuesday, November 14, 2017 11:49 AM To: Sean Barnum <sean.barnum@FireEye.com> Cc: Bret Jordan <Bret_Jordan@symantec.com>; cti-stix@lists.oasis-open.org; Katz, Gary CTR DC3DCCI <Gary.Katz.ctr@dc3.mil>; JG on CTI-TC <jg@ctin.us> Subject: Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   My opinion is Option #1. I think it is fairly obvious to all that Infrastructure is a needed capability, the only question was "when" - but I do not think that making Cyber Observables TLOs is a way to do that. An observable is something that is static, that is a fact at a point in time, that never changes, and that can observed - that thing would *point* at Infrastructure, it is not the infrastructure itself. Making Cyber Observables TLOs would not solve the use case properly - most of the requirements for Infrastructure Jane has below,  would not be solved by this at all. They would require an actual Infrastructure object. I have yet to see someone present a concrete use case for why we should make cyber observables a TLO. It has been proposed multiple times in the past and debated to death - it is perhaps the second-most debated subject in the TC (after timestamps).  I am all for the idea of "fixing what is broken" in STIX, as Brett says, but to me if we are going to re-open topics that have been extensively debated and yet voted on in another direction, there is a significant burden on the proposer as to why it should be re-opened. I don't see that burden being met here. What are the specific modeling problem(s) that would be solved by making cyber observables top level objects, that can not be solved in any other fashion? - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Sean Barnum <sean.barnum@FireEye.com> To:         Bret Jordan <Bret_Jordan@symantec.com>, "Katz, Gary CTR DC3DCCI" <Gary.Katz.ctr@dc3.mil> Cc:         JG on CTI-TC <jg@ctin.us>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:         11/14/2017 12:11 PM Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1 Sent by:         <cti-stix@lists.oasis-open.org> Speaking for myself specifically and for FireEye, we very strongly agree with Jane’s overall perspective and with each and every one of the motivating arguments she has taken the time to outline for us.   We also very strongly agree with Gary’s perspective that addressing the issue of infrastructure should begin with making Cyber Observables top level objects. Forcing observables to exist only within an Observed Data wrapping artificially constrains observables to a context and use that is artificially constrained to a single temporal context of observation. As Gary points out these observables in reality exist and are useful in numerous and varied contexts beyond simply a single temporal context of observation. By breaking them out into top level objects they may be expressed in a consistent form without unnecessary duplication (across temporal observations) or semantic gymnastics (for situations like infrastructure that are other than a simple observation) and the specific context for any use of the observable can, as Gary describes, be expressed within the relationships of that observable to other content. We agree with Gary and Bret that this change should be made and now is the time to do it rather than later when the impact will likely be far greater not only as a breaking change to existing implementations but also due to other ongoing language design decisions that are made based on the current structure.   We do diverge with the rest of Gary’s opinions on the options he presented. We would strongly disagree with Option 2 which we view as perpetuating and exacerbating a flawed design and would represent some very confusing and invalid semantic gymnastics to use a temporally constrained observation construct to attempt to represent a non-temporally constrained concept like Infrastructure.   We also believe that while Option 3 is urgently necessary, it by itself is still not a full adequate solution for infrastructure. It should be combined with Option 1. I think this is what Bret is suggesting in his second paragraph below. Bret, feel free to correct me if I am mistaken. We believe the ideal solution is an independent Infrastructure SDO that can represent an aggregate infrastructure whether simple or complex that can then be associated with appropriate ThreatActors, Campaigns, Malware, IntrusionSets, etc in a clean, clear and unambiguous way to support many of the use cases Jane outlines. This Infrastructure SDO can also be associated with any number of top level Cyber Observable objects to characterize any simple or complex infrastructure. This could include clean, clear and unambiguous relationships between Cyber Observables within this infrastructure. It also enables the characterization of cyber observables that exist within multiple infrastructures (a common occurrence) in a clean, efficient and pivotable manner. We would assert that this approach offers the cleanest model where each concept is distinct and clearly understood, granular and inherently linkable to support effective graph-based analysis and visualization, and straightforward to implement in code without unnecessary convolutions, conflations or complex interdependencies.       Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com   From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Date: Monday, November 13, 2017 at 7:26 PM To: "Katz, Gary CTR DC3DCCI" <Gary.Katz.ctr@dc3.mil> Cc: JG on CTI-TC <jg@ctin.us>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   I agree with Gary and Jane on the need for a solution to infrastructure for 2.1.  In my opinion I do not think we should ship 2.1 without it.  Infrastructure and Malware are the two biggest missing parts that are preventing adoption.   I agree with Gary’s other points as well, though I would add a 4th option of make cyber observable TLOs and add a meta data object called infrastructure so you can record higher level information about how the threat actor is using the infrastructure.  All of the IPs and such would link to it via real relationships and we could then use the relationship dates to establish validity.   Bret     Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Nov 14, 2017, at 4:10 AM, Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil > wrote: 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 This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. Attachment: smime.p7s Description: S/MIME cryptographic signature


  • 5.  Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1

    Posted 11-15-2017 23:59
    Hi Gary, These all seem to relate to the data as it sits in a TIP -i.e. where analysts will be playing with it. It doesn't seem to relate so much to moving threat intelligence from one place to another, which is what STIX is all about. STIX does make a nice basis for a graph model , but its not a graph model out of the box. Too often I think we all slip into the mindset of thinking that STIX is a model for representing data, when it is a way of codifying it so we can transfer it from one system to another. A TIP will always need additional objects within it's database/graph to be able to actually use the STIX it receives. Yes, the data structure will most likely be STIX-like (as that makes sense if everyone is sharing with STIX/TAXII) but the data structure won't be STIX. Additionally, each TIP will contain substantially different information in it. It is up to each Organisation to decide which threat intelligence 'assertions' they receive they consider to be 'the truth'. Each Organisation will have a different level of comfort over what they will consider to be the truth, and therefore some organisations will admin intel into their TIPs that others do not. In addition, Organisations will have access to intel that others don't. Organisaions will share with others in their industry vertical to get more relevant intel. All of this contributes to my belief that each Organisation's TIP will have substantially different information within it compared to another Organisation's TIP. This in turn feeds my belief that threat intel sharing will be made up of Organisations only sharing parts of their knowledge graph with others during an investgation, and that each TIP acts as a gatekeeper, only allowing the threat intel that the ORganisation wants into it's knowledge graph. With that backdrop, I'll provide my thoughts. 1.         Removes graphs-within-graphs problem:  Currently the Cyber Observables can link to each other within an Observed Data object but cannot be directly linked to.  This creates a subgraph within the larger STIX graph and creates unnecessary processing issues. There is no graphs within graphs. There is just one graph, and newly shared information is processed from STIX into whatever format it needs to be in order for the TIP to assimilate it into the knowledge graph.  Any TIP worth its salt will add an extra internal node in the graph that represents the 'IP address 1.1.1.1' when it receives an Observed Data object containing the  IPv4 address  1.1.1.1. Then whenever it receives someone else's Observed Data object containing  the  IPv4 address  1.1.1.1, it can internally relate that new ObservedData object with the one it received earlier via that internal 'IP address 1.1.1.1' node in the graph. But the important point here is that the  IP address 1.1.1.1 node is local to this TIP. It has a particular unique identifier,  and this TIP knows that it's the only one it's got. In diagram form it looks like this: If we made Cyber Observables a TLO, then all we do is allow everyone to create many different Cyber Observable objects that all can represent the same  'IP address 1.1.1.1'. For example, if Org A created  'IP address 1.1.1.1'  with ID of 123456 in one sharing community, and Org B created  'IP address 1.1.1.1'  with ID of 345678 in another sharing community, and OrgC was part of both sharing communities, then Org C would still be faced with receiving two objects representing  'IP address 1.1.1.1'. OrgC's TIP would still need to create it's own internal representation of  'IP address 1.1.1.1', and now would need to associate the two different Cyber Observables objects it received as well, which is extra work over what it had to do before. Having Observables as TLOs seems to just muddy the waters as long as anyone can create an Observable and that Observable can be a different object. This would only work if there was one official object worldwide for each observable that we wanted to represent.... which doesn't seem workable to me.  2.         Encourages inefficiencies for analysts: While a system could hide the Observed Data and Infrastructure objects from the user, most implementers will probably just follow the STIX structure.  Currently if an analyst were to manually want to say that they observed an IP they need to create an Observed Data object and then link that object to an IP address.  This requires the creation of 2 objects rather than one, or in the case of viewing, they would see two objects instead of 1, creating unnecessary clutter. This is an implementation problem. It is up to the implementation as to how it will show you the information. It could expose the internal graph representation to you directly if it chose to. Or it could just chose to show you the 'Internal Observable Node' that I've shown in my diagram, and yet allow you to click on it to open up the times that it's been seen (the information from the imported ObservedData objects). It's completely up to the implementation how it wishes to show you this information. 3.         Infrastructure and Observed Data provide context about the Cyber Observables.  Elsewhere within STIX we use relationship information (links) to capture context.  By making Cyber Observables TLOs we would follow the same model as the rest of STIX. I don't understand this comment I'm afraid. Are you meaning that we should be using relationships to link observables to infrastructure and observeddata (and therefore also Indicator patterns)? If so, I'm not so sure. ObservedData in my mind was a holder for 'things that have been observed in the past'. Its a container for cyber observables to be placed in to describe what's been seen. With ObservedData we have observed it, so its a fact. A relationship is for things that may be unknown. If we've observed something then it's been seen, and so a relationship isn't the best option for this. 4.         Analysts are used to it.  If you review current cyber intelligence platforms, Maltego, TrueStar, Threat Connect, Anomali, etc. Cyber Observables are directly shown on the graphs (note: in general their models are less detailed than STIX, so I am not suggesting we just adopt their level of detail, second note: my knowledge may be dated, I have not reviewed these platforms too recently).  Analysts are used to working in that paradigm, why confuse them? Analysts won't be working directly with the graph, but a representation of the data within that graph. As mentioned earlier it is up to the implementation to decide how best to display this information to the user. It may be through a series of lists that you click through. It may be via a graph-like representation of the data that uses the internal representation of STIX data and other internal extracted data and additional internal only nodes to show you the data. The point is that the analyst will see a carefully crafted interface representing the data housed within. The upper diagram I have represented will provide the same help to the Analyst as the second, only with less complication. 5.         Lastly, I do not believe we would have chosen this design if we were not starting out with Cybox being separated from STIX and with organizations (me!) pushing for cybox to remain separate so it could easily be used in other schemas.  Cybox has been fully integrated as a part of STIX, so this original reason for calling it out separately no longer applies.   CybOX for sure has had an impact on the design of STIX. I agree that this separation no longer exists, but I also caution rushing in to adding it as a TLO.  Thanks for listening, and apologies for the length of the post. Cheers Terry MacDonald   Chief Product Officer M:   +64 211 918 814 E:   terry.macdonald@cosive.com W:   www.cosive.com On Thu, Nov 16, 2017 at 11:35 AM, Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil > wrote: Jason,     I’ll try to provide a couple of reasons for making cyber observables TLOs but I’d be interested in others providing their thoughts.   1.        Removes graphs-within-graphs problem:  Currently the Cyber Observables can link to each other within an Observed Data object but cannot be directly linked to.  This creates a subgraph within the larger STIX graph and creates unnecessary processing issues. 2.        Encourages inefficiencies for analysts: While a system could hide the Observed Data and Infrastructure objects from the user, most implementers will probably just follow the STIX structure.  Currently if an analyst were to manually want to say that they observed an IP they need to create an Observed Data object and then link that object to an IP address.  This requires the creation of 2 objects rather than one, or in the case of viewing, they would see two objects instead of 1, creating unnecessary clutter. 3.        Infrastructure and Observed Data provide context about the Cyber Observables.  Elsewhere within STIX we use relationship information (links) to capture context.  By making Cyber Observables TLOs we would follow the same model as the rest of STIX. 4.        Analysts are used to it.  If you review current cyber intelligence platforms, Maltego, TrueStar, Threat Connect, Anomali, etc. Cyber Observables are directly shown on the graphs (note: in general their models are less detailed than STIX, so I am not suggesting we just adopt their level of detail, second note: my knowledge may be dated, I have not reviewed these platforms too recently).  Analysts are used to working in that paradigm, why confuse them? 5.        Lastly, I do not believe we would have chosen this design if we were not starting out with Cybox being separated from STIX and with organizations (me!) pushing for cybox to remain separate so it could easily be used in other schemas.  Cybox has been fully integrated as a part of STIX, so this original reason for calling it out separately no longer applies.   My 2 cents.    -Gary   From: Jason Keirstead [mailto: Jason.Keirstead@ca. ibm.com ] Sent: Tuesday, November 14, 2017 11:49 AM To: Sean Barnum <sean.barnum@FireEye.com> Cc: Bret Jordan < Bret_Jordan@symantec.com >; cti-stix@lists.oasis-open.org ; Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil >; JG on CTI-TC < jg@ctin.us > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   My opinion is Option #1. I think it is fairly obvious to all that Infrastructure is a needed capability, the only question was "when" - but I do not think that making Cyber Observables TLOs is a way to do that. An observable is something that is static, that is a fact at a point in time, that never changes, and that can observed - that thing would *point* at Infrastructure, it is not the infrastructure itself. Making Cyber Observables TLOs would not solve the use case properly - most of the requirements for Infrastructure Jane has below,  would not be solved by this at all. They would require an actual Infrastructure object. I have yet to see someone present a concrete use case for why we should make cyber observables a TLO. It has been proposed multiple times in the past and debated to death - it is perhaps the second-most debated subject in the TC (after timestamps).  I am all for the idea of "fixing what is broken" in STIX, as Brett says, but to me if we are going to re-open topics that have been extensively debated and yet voted on in another direction, there is a significant burden on the proposer as to why it should be re-opened. I don't see that burden being met here. What are the specific modeling problem(s) that would be solved by making cyber observables top level objects, that can not be solved in any other fashion? - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Sean Barnum <sean.barnum@FireEye.com> To:         Bret Jordan < Bret_Jordan@symantec.com >, "Katz, Gary CTR DC3DCCI" < Gary.Katz.ctr@dc3.mil > Cc:         JG on CTI-TC < jg@ctin.us >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date:         11/14/2017 12:11 PM Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1 Sent by:         < cti-stix@lists.oasis-open. org > Speaking for myself specifically and for FireEye, we very strongly agree with Jane’s overall perspective and with each and every one of the motivating arguments she has taken the time to outline for us.   We also very strongly agree with Gary’s perspective that addressing the issue of infrastructure should begin with making Cyber Observables top level objects. Forcing observables to exist only within an Observed Data wrapping artificially constrains observables to a context and use that is artificially constrained to a single temporal context of observation. As Gary points out these observables in reality exist and are useful in numerous and varied contexts beyond simply a single temporal context of observation. By breaking them out into top level objects they may be expressed in a consistent form without unnecessary duplication (across temporal observations) or semantic gymnastics (for situations like infrastructure that are other than a simple observation) and the specific context for any use of the observable can, as Gary describes, be expressed within the relationships of that observable to other content. We agree with Gary and Bret that this change should be made and now is the time to do it rather than later when the impact will likely be far greater not only as a breaking change to existing implementations but also due to other ongoing language design decisions that are made based on the current structure.   We do diverge with the rest of Gary’s opinions on the options he presented. We would strongly disagree with Option 2 which we view as perpetuating and exacerbating a flawed design and would represent some very confusing and invalid semantic gymnastics to use a temporally constrained observation construct to attempt to represent a non-temporally constrained concept like Infrastructure.   We also believe that while Option 3 is urgently necessary, it by itself is still not a full adequate solution for infrastructure. It should be combined with Option 1. I think this is what Bret is suggesting in his second paragraph below. Bret, feel free to correct me if I am mistaken. We believe the ideal solution is an independent Infrastructure SDO that can represent an aggregate infrastructure whether simple or complex that can then be associated with appropriate ThreatActors, Campaigns, Malware, IntrusionSets, etc in a clean, clear and unambiguous way to support many of the use cases Jane outlines. This Infrastructure SDO can also be associated with any number of top level Cyber Observable objects to characterize any simple or complex infrastructure. This could include clean, clear and unambiguous relationships between Cyber Observables within this infrastructure. It also enables the characterization of cyber observables that exist within multiple infrastructures (a common occurrence) in a clean, efficient and pivotable manner. We would assert that this approach offers the cleanest model where each concept is distinct and clearly understood, granular and inherently linkable to support effective graph-based analysis and visualization, and straightforward to implement in code without unnecessary convolutions, conflations or complex interdependencies.       Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com   From: < cti-stix@lists.oasis-open.org > on behalf of Bret Jordan < Bret_Jordan@symantec.com > Date: Monday, November 13, 2017 at 7:26 PM To: "Katz, Gary CTR DC3DCCI" < Gary.Katz.ctr@dc3.mil > Cc: JG on CTI-TC < jg@ctin.us >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   I agree with Gary and Jane on the need for a solution to infrastructure for 2.1.  In my opinion I do not think we should ship 2.1 without it.  Infrastructure and Malware are the two biggest missing parts that are preventing adoption.   I agree with Gary’s other points as well, though I would add a 4th option of make cyber observable TLOs and add a meta data object called infrastructure so you can record higher level information about how the threat actor is using the infrastructure.  All of the IPs and such would link to it via real relationships and we could then use the relationship dates to establish validity.   Bret     Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Nov 14, 2017, at 4:10 AM, Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil > wrote: 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 This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


  • 6.  RE: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1

    Posted 11-16-2017 16:34
    I just wanted to clarify the graphs within graphs and Infrastructure vs Malware vs Observed Data problem.  The primary issue here is not that it forces backend systems to store multiple levels of graphs, but that it causes complications when converting a STIX document that includes these to an internal system and back to STIX.  Consider the attached fairly simple example where two sources feed an internal system.  The sources are as follows and can be modeled in the following ways:     The second states that a file uses an IP address.  Each of these can be modeled in the following ways: 1.        An Intrusion set owns an IP address. a.        The IP can be stored as an infrastructure object b.        The IP can be stored in an observed data object 2.        A piece of malware the beacons to an IP Address a.        The IP and File can be placed directly with the cybox block in the Malware object b.        The File can be placed in a Malware object that is linked to an infrastructure object c.        The File and IP can be placed in an observed data object.   Once this is ingested the information can be aggregated, but once it is how there are more than 6 ways to export it back out again.  At which point you run into the issue that there is no good way to ensure that when someone ingests your data that any intelligence they share based on it will be at all similar to what you originally produced.     Jeffrey Mates, Civ DC3/DCCI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Scientist Defense Cyber Crime Institute jeffrey.mates@dc3.mil 410-694-4335   From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald Sent: Wednesday, November 15, 2017 6:59 PM To: Katz, Gary CTR DC3DCCI <Gary.Katz.ctr@dc3.mil> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Sean Barnum <sean.barnum@fireeye.com>; Bret Jordan <Bret_Jordan@symantec.com>; cti-stix@lists.oasis-open.org; JG on CTI-TC <jg@ctin.us> Subject: Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   Hi Gary,   These all seem to relate to the data as it sits in a TIP -i.e. where analysts will be playing with it. It doesn't seem to relate so much to moving threat intelligence from one place to another, which is what STIX is all about.   STIX does make a nice basis for a graph model , but its not a graph model out of the box. Too often I think we all slip into the mindset of thinking that STIX is a model for representing data, when it is a way of codifying it so we can transfer it from one system to another. A TIP will always need additional objects within it's database/graph to be able to actually use the STIX it receives. Yes, the data structure will most likely be STIX-like (as that makes sense if everyone is sharing with STIX/TAXII) but the data structure won't be STIX.   Additionally, each TIP will contain substantially different information in it. It is up to each Organisation to decide which threat intelligence 'assertions' they receive they consider to be 'the truth'. Each Organisation will have a different level of comfort over what they will consider to be the truth, and therefore some organisations will admin intel into their TIPs that others do not. In addition, Organisations will have access to intel that others don't. Organisaions will share with others in their industry vertical to get more relevant intel. All of this contributes to my belief that each Organisation's TIP will have substantially different information within it compared to another Organisation's TIP. This in turn feeds my belief that threat intel sharing will be made up of Organisations only sharing parts of their knowledge graph with others during an investgation, and that each TIP acts as a gatekeeper, only allowing the threat intel that the ORganisation wants into it's knowledge graph.   With that backdrop, I'll provide my thoughts.   1.         Removes graphs-within-graphs problem:  Currently the Cyber Observables can link to each other within an Observed Data object but cannot be directly linked to.  This creates a subgraph within the larger STIX graph and creates unnecessary processing issues. There is no graphs within graphs. There is just one graph, and newly shared information is processed from STIX into whatever format it needs to be in order for the TIP to assimilate it into the knowledge graph.    Any TIP worth its salt will add an extra internal node in the graph that represents the 'IP address 1.1.1.1' when it receives an Observed Data object containing the IPv4 address 1.1.1.1. Then whenever it receives someone else's Observed Data object containing the IPv4 address 1.1.1.1, it can internally relate that new ObservedData object with the one it received earlier via that internal 'IP address 1.1.1.1' node in the graph. But the important point here is that the IP address 1.1.1.1 node is local to this TIP. It has a particular unique identifier,  and this TIP knows that it's the only one it's got. In diagram form it looks like this:     If we made Cyber Observables a TLO, then all we do is allow everyone to create many different Cyber Observable objects that all can represent the same 'IP address 1.1.1.1'. For example, if Org A created 'IP address 1.1.1.1' with ID of 123456 in one sharing community, and Org B created 'IP address 1.1.1.1' with ID of 345678 in another sharing community, and OrgC was part of both sharing communities, then Org C would still be faced with receiving two objects representing 'IP address 1.1.1.1'. OrgC's TIP would still need to create it's own internal representation of 'IP address 1.1.1.1', and now would need to associate the two different Cyber Observables objects it received as well, which is extra work over what it had to do before. Having Observables as TLOs seems to just muddy the waters as long as anyone can create an Observable and that Observable can be a different object. This would only work if there was one official object worldwide for each observable that we wanted to represent.... which doesn't seem workable to me.    2.         Encourages inefficiencies for analysts: While a system could hide the Observed Data and Infrastructure objects from the user, most implementers will probably just follow the STIX structure.  Currently if an analyst were to manually want to say that they observed an IP they need to create an Observed Data object and then link that object to an IP address.  This requires the creation of 2 objects rather than one, or in the case of viewing, they would see two objects instead of 1, creating unnecessary clutter.   This is an implementation problem. It is up to the implementation as to how it will show you the information. It could expose the internal graph representation to you directly if it chose to. Or it could just chose to show you the 'Internal Observable Node' that I've shown in my diagram, and yet allow you to click on it to open up the times that it's been seen (the information from the imported ObservedData objects). It's completely up to the implementation how it wishes to show you this information.   3.         Infrastructure and Observed Data provide context about the Cyber Observables.  Elsewhere within STIX we use relationship information (links) to capture context.  By making Cyber Observables TLOs we would follow the same model as the rest of STIX.   I don't understand this comment I'm afraid. Are you meaning that we should be using relationships to link observables to infrastructure and observeddata (and therefore also Indicator patterns)? If so, I'm not so sure. ObservedData in my mind was a holder for 'things that have been observed in the past'. Its a container for cyber observables to be placed in to describe what's been seen. With ObservedData we have observed it, so its a fact. A relationship is for things that may be unknown. If we've observed something then it's been seen, and so a relationship isn't the best option for this.   4.         Analysts are used to it.  If you review current cyber intelligence platforms, Maltego, TrueStar, Threat Connect, Anomali, etc. Cyber Observables are directly shown on the graphs (note: in general their models are less detailed than STIX, so I am not suggesting we just adopt their level of detail, second note: my knowledge may be dated, I have not reviewed these platforms too recently).  Analysts are used to working in that paradigm, why confuse them?   Analysts won't be working directly with the graph, but a representation of the data within that graph. As mentioned earlier it is up to the implementation to decide how best to display this information to the user. It may be through a series of lists that you click through. It may be via a graph-like representation of the data that uses the internal representation of STIX data and other internal extracted data and additional internal only nodes to show you the data. The point is that the analyst will see a carefully crafted interface representing the data housed within. The upper diagram I have represented will provide the same help to the Analyst as the second, only with less complication.   5.         Lastly, I do not believe we would have chosen this design if we were not starting out with Cybox being separated from STIX and with organizations (me!) pushing for cybox to remain separate so it could easily be used in other schemas.  Cybox has been fully integrated as a part of STIX, so this original reason for calling it out separately no longer applies.   CybOX for sure has had an impact on the design of STIX. I agree that this separation no longer exists, but I also caution rushing in to adding it as a TLO.    Thanks for listening, and apologies for the length of the post. Cheers   Terry MacDonald   Chief Product Officer     M:   +64 211 918 814 E:   terry.macdonald@cosive.com W:   www.cosive.com         On Thu, Nov 16, 2017 at 11:35 AM, Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil > wrote: Jason,     I’ll try to provide a couple of reasons for making cyber observables TLOs but I’d be interested in others providing their thoughts.   1.        Removes graphs-within-graphs problem:  Currently the Cyber Observables can link to each other within an Observed Data object but cannot be directly linked to.  This creates a subgraph within the larger STIX graph and creates unnecessary processing issues. 2.        Encourages inefficiencies for analysts: While a system could hide the Observed Data and Infrastructure objects from the user, most implementers will probably just follow the STIX structure.  Currently if an analyst were to manually want to say that they observed an IP they need to create an Observed Data object and then link that object to an IP address.  This requires the creation of 2 objects rather than one, or in the case of viewing, they would see two objects instead of 1, creating unnecessary clutter. 3.        Infrastructure and Observed Data provide context about the Cyber Observables.  Elsewhere within STIX we use relationship information (links) to capture context.  By making Cyber Observables TLOs we would follow the same model as the rest of STIX. 4.        Analysts are used to it.  If you review current cyber intelligence platforms, Maltego, TrueStar, Threat Connect, Anomali, etc. Cyber Observables are directly shown on the graphs (note: in general their models are less detailed than STIX, so I am not suggesting we just adopt their level of detail, second note: my knowledge may be dated, I have not reviewed these platforms too recently).  Analysts are used to working in that paradigm, why confuse them? 5.        Lastly, I do not believe we would have chosen this design if we were not starting out with Cybox being separated from STIX and with organizations (me!) pushing for cybox to remain separate so it could easily be used in other schemas.  Cybox has been fully integrated as a part of STIX, so this original reason for calling it out separately no longer applies.   My 2 cents.    -Gary   From: Jason Keirstead [mailto: Jason.Keirstead@ca.ibm.com ] Sent: Tuesday, November 14, 2017 11:49 AM To: Sean Barnum <sean.barnum@FireEye.com> Cc: Bret Jordan < Bret_Jordan@symantec.com >; cti-stix@lists.oasis-open.org ; Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil >; JG on CTI-TC < jg@ctin.us > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   My opinion is Option #1. I think it is fairly obvious to all that Infrastructure is a needed capability, the only question was "when" - but I do not think that making Cyber Observables TLOs is a way to do that. An observable is something that is static, that is a fact at a point in time, that never changes, and that can observed - that thing would *point* at Infrastructure, it is not the infrastructure itself. Making Cyber Observables TLOs would not solve the use case properly - most of the requirements for Infrastructure Jane has below,  would not be solved by this at all. They would require an actual Infrastructure object. I have yet to see someone present a concrete use case for why we should make cyber observables a TLO. It has been proposed multiple times in the past and debated to death - it is perhaps the second-most debated subject in the TC (after timestamps).  I am all for the idea of "fixing what is broken" in STIX, as Brett says, but to me if we are going to re-open topics that have been extensively debated and yet voted on in another direction, there is a significant burden on the proposer as to why it should be re-opened. I don't see that burden being met here. What are the specific modeling problem(s) that would be solved by making cyber observables top level objects, that can not be solved in any other fashion? - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Sean Barnum <sean.barnum@FireEye.com> To:         Bret Jordan < Bret_Jordan@symantec.com >, "Katz, Gary CTR DC3DCCI" < Gary.Katz.ctr@dc3.mil > Cc:         JG on CTI-TC < jg@ctin.us >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date:         11/14/2017 12:11 PM Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1 Sent by:         < cti-stix@lists.oasis-open.org > Speaking for myself specifically and for FireEye, we very strongly agree with Jane’s overall perspective and with each and every one of the motivating arguments she has taken the time to outline for us.   We also very strongly agree with Gary’s perspective that addressing the issue of infrastructure should begin with making Cyber Observables top level objects. Forcing observables to exist only within an Observed Data wrapping artificially constrains observables to a context and use that is artificially constrained to a single temporal context of observation. As Gary points out these observables in reality exist and are useful in numerous and varied contexts beyond simply a single temporal context of observation. By breaking them out into top level objects they may be expressed in a consistent form without unnecessary duplication (across temporal observations) or semantic gymnastics (for situations like infrastructure that are other than a simple observation) and the specific context for any use of the observable can, as Gary describes, be expressed within the relationships of that observable to other content. We agree with Gary and Bret that this change should be made and now is the time to do it rather than later when the impact will likely be far greater not only as a breaking change to existing implementations but also due to other ongoing language design decisions that are made based on the current structure.   We do diverge with the rest of Gary’s opinions on the options he presented. We would strongly disagree with Option 2 which we view as perpetuating and exacerbating a flawed design and would represent some very confusing and invalid semantic gymnastics to use a temporally constrained observation construct to attempt to represent a non-temporally constrained concept like Infrastructure.   We also believe that while Option 3 is urgently necessary, it by itself is still not a full adequate solution for infrastructure. It should be combined with Option 1. I think this is what Bret is suggesting in his second paragraph below. Bret, feel free to correct me if I am mistaken. We believe the ideal solution is an independent Infrastructure SDO that can represent an aggregate infrastructure whether simple or complex that can then be associated with appropriate ThreatActors, Campaigns, Malware, IntrusionSets, etc in a clean, clear and unambiguous way to support many of the use cases Jane outlines. This Infrastructure SDO can also be associated with any number of top level Cyber Observable objects to characterize any simple or complex infrastructure. This could include clean, clear and unambiguous relationships between Cyber Observables within this infrastructure. It also enables the characterization of cyber observables that exist within multiple infrastructures (a common occurrence) in a clean, efficient and pivotable manner. We would assert that this approach offers the cleanest model where each concept is distinct and clearly understood, granular and inherently linkable to support effective graph-based analysis and visualization, and straightforward to implement in code without unnecessary convolutions, conflations or complex interdependencies.       Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com   From: < cti-stix@lists.oasis-open.org > on behalf of Bret Jordan < Bret_Jordan@symantec.com > Date: Monday, November 13, 2017 at 7:26 PM To: "Katz, Gary CTR DC3DCCI" < Gary.Katz.ctr@dc3.mil > Cc: JG on CTI-TC < jg@ctin.us >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1   I agree with Gary and Jane on the need for a solution to infrastructure for 2.1.  In my opinion I do not think we should ship 2.1 without it.  Infrastructure and Malware are the two biggest missing parts that are preventing adoption.   I agree with Gary’s other points as well, though I would add a 4th option of make cyber observable TLOs and add a meta data object called infrastructure so you can record higher level information about how the threat actor is using the infrastructure.  All of the IPs and such would link to it via real relationships and we could then use the relationship dates to establish validity.   Bret     Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 On Nov 14, 2017, at 4:10 AM, Katz, Gary CTR DC3DCCI < Gary.Katz.ctr@dc3.mil > wrote: 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 This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.   Attachment: STIX Duplication Example.png Description: PNG image Attachment: smime.p7s Description: S/MIME cryptographic signature