[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard
A recommended read, interesting from multiple point of views for CTI, but in the context of this thread, mainly regarding these points: Message-oriented Architecture Resource-Oriented Architecture https://tools.ietf.org/html/draft-ietf-mile-rolie-01 NB: You could also find interesting elements for TAXII 2015-12-12 9:51 GMT+03:00 Jerome Athias <athiasjerome@gmail.com>: > Attached is an OLD draft (so not updated and with errors) diagram from 2012. > (This is a good one in case it helps https://github.com/google/capirca ) > > NB: Mitigation is not Remediation > > (PS: and really far from me to say that it matters in any way! > But, because we don't share our resumes. I would just say that I am a > 36 years old Otaku/Hacker [1] who started manipulating computers 25+ > years ago, and who probably spent in average 8 plenty hours a day > (including week-ends and vacations) on these automatons during the > past 10/15 years) > > > [1] 1. A person who enjoys exploring the details of programmable > systems and how to stretch their capabilities, as opposed to most > users, who prefer to learn only the minimum necessary. RFC1392, the > Internet Users' Glossary, usefully amplifies this as: A person who > delights in having an intimate understanding of the internal workings > of a system, computers and computer networks in particular. > 2. One who programs enthusiastically (even obsessively) or who enjoys > programming rather than just theorizing about programming. > 3. One who enjoys the intellectual challenge of creatively overcoming > or circumventing limitations. > > > 2015-12-01 3:46 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>: >> Nice diagram. One thing I am working on internal to BC is to get it so you >> can send your STIX indicator / CybOX object to the Solera Security Analytics >> device and do automatic retrospective analysis. This will allow you to see >> if you have seen said object before. This would fit in to this work flow >> nicely, I believe. Another area would be in automatic remediation, aka >> sent a STIX indicator / CybOX object with a Coarse of Action to your Proxy >> and tell it to block that traffic. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> On Nov 30, 2015, at 17:41, Patrick Maroney <Pmaroney@Specere.org> wrote: >> >> re: " Now lets talk about work flow and how this information is going to >> flow around the network, how it is going to flow in to vendor tools, " >> >> Here is one Reference Implementation for consideration/discussion: >> >> <6DB53CE0-AB02-4DDD-ABB7-4A2A7FCD92B2.png> >> >> Patrick Maroney >> Office: (856)983-0001 >> Cell: (609)841-5104 >> >> <C690F973-64C5-4C00-889B-C1A5BB4A2A0B[6].png> >> >> President >> Integrated Networking Technologies, Inc. >> PO Box 569 >> Marlton, NJ 08053 >> >> From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan >> <bret.jordan@bluecoat.com> >> Date: Monday, November 30, 2015 at 7:25 PM >> To: Terry MacDonald <terry@soltra.com> >> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Richard Struse >> <Richard.Struse@HQ.DHS.GOV>, "cti-stix@lists.oasis-open.org" >> <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard >> >> You are correct, some organizations will do it in-house, some will >> outsource, and I will add that some will just not care. We have an amazing >> group that does APT research and has a massive amount of internal data >> mining tools to find this sort of stuff. We help a lot of the biggest >> companies and governments solve these problem, every day. >> >> Some organizations that outsource or do things internally MAY share >> sightings or things back within their eco-systems, or they may even share >> with certain government groups. But their own legal departments and general >> councils will dictate what they can share and with whom they can share it. >> >> Remember getting a huge repo of STIX data, in your Soltra Edge device is NOT >> going to magically make you any more secure. You need vendor products that >> sit inline in your network that can actually DO something with that data. >> Those products typically only understands what we call CybOX objects. They >> do NOT understand nor care about higher level things. We humans and >> analysts and big data intelligence platforms do care about higher level >> things. It helps us figure out what is going on, and REALLY helps in >> retrospective analysis of an attack. >> >> Lets put this in real world terms... Government or vendor XYZ discovers >> that threat actor Ivan is launching an attack against executives of high >> tech companies in Silicon Valley. They believe Ivan is going to use Whale >> Phishing based on the latest Audi and BMW cars. >> >> This is great information. Now lets talk about work flow and how this >> information is going to flow around the network, how it is going to flow in >> to vendor tools, how it is going to flow in to user awareness programs and >> training programs. >> >> And maybe, just maybe, some organizations might send some data back or share >> pieces of information that they learn. We do this today. We have >> interconnections with lots of groups where we share data back and forth. >> This is not new. We have been doing this for 14 years. >> >> Lets focus on workflow and how we can make an analysts life easier and make >> vendor product use and understand the data they can. >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> On Nov 30, 2015, at 17:09, Terry MacDonald <terry@soltra.com> wrote: >> >> Bret, >> >> I foresee that Organizations will share data between their own internal >> tools (to understand threats and look for indicators of that threats) most >> often. It’s not all about sharing that information with external parties. An >> Organization needs to do both in order to make best use of Threat >> Intelligence. They need to join those two processes together. Threat >> Intelligence and Incident Response. >> >> Now a lot of Organizations will not have the ability or the inclination to >> do the Threat Intelligence gathering/sifting/etc required to build up a >> picture of the threats relevant to their Organization profile, but that’s >> not a problem. They’ll just outsource it. >> >> Organizations will outsource their threat intelligence function to third >> parties who will look for threat intelligence that matches the Organizations >> risk profile on their behalf. The organizations will then just get feeds of >> Indicators customized to their Organization, and will then feedback >> sightings they see. They will also push up any interesting observations they >> notice, and the Threat Intelligence providers will use that data to discern >> any new Threat Actors/Campaigns/malware families as needed. >> >> It doesn’t matter if the threat analysis is done in house, or is outsourced >> – the deep research still needs to be done in order to discover new >> Indicators, and to track the changes that take place over time. Without the >> deep analysis, the Indicators will soon lose their accuracy. And without the >> real-world feedback, the Threat Intelligence modelling will become less >> accurate. >> >> Each process makes the other one stronger. >> >> One thing I would like to point out is the need to move away from ‘dumb’ >> Indicator feeds, where the recipient gets a hug wall of Indicators that >> contain every bad things that the world has seen over the last 3 months. >> This won’t scale, and all it does is increase the cost to Organizations as >> they have to increase infrastructure and personnel resources to cope with >> the increased workload. Higher chances of false positives and less >> understanding of what the really important indicators are. >> >> By using Threat intelligence and an understanding of our adversaries , we >> will know who is likely to target us, and we can look for the things they >> do. We have less noise to contend with, and we spend our precious >> infrastructure and personnel resources looking for things that matter to us. >> >> Cheers >> >> Terry MacDonald >> Senior STIX Subject Matter Expert >> SOLTRA | An FS-ISAC and DTCC Company >> +61 (407) 203 206 | terry@soltra.com >> >> >> From: Jordan, Bret [mailto:bret.jordan@bluecoat.com] >> Sent: Tuesday, 1 December 2015 9:45 AM >> To: Terry MacDonald <terry@soltra.com> >> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Richard Struse >> <Richard.Struse@HQ.DHS.GOV>; cti-stix@lists.oasis-open.org; Wunder, John A. >> <jwunder@mitre.org> >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard >> >> Re: It’s a symbiotic relationship! >> >> It is only a symbiotic relationship, if the two organizations are >> communicating. We make a LOT of assumptions that people and organizations >> are going to do anything more than just process indicators (meaning block >> them on their firewall or proxy). Most, honestly, do not care. They may >> share sighting information back to their own internal tools. But I doubt >> many will share sightings back to the larger community. The general >> council's of most organizations will prohibit that for many years to come. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> >> On Nov 30, 2015, at 14:02, Terry MacDonald <terry@soltra.com> wrote: >> >> “There is no actual reason that indicator or sighting messages need to be a >> layer on top of the ontology. They are for totally different use cases and >> can be developed completely independently.” >> >> There needs to be a relationship between the Indicators and sightings that >> are exchanged and the higher-order threat intelligence that is exchanged, or >> there is no way to relate the two levels together. The key important part in >> all of this is to be able to maintain relationships from one to the other. >> Without that ability then there is no way to do the analysis. >> >> Frode Hommedal put it best in his presentation to FIRST: >> http://frodehommedal.no/presentations/first-tc-oslo-2015. I implore you to >> read it if you haven’t already. Especially this slide. >> >> As I see it the two camps fall into these broad groups: >> · All of STIX: Threat Intelligence group >> o “We need to track everything otherwise we won’t be able to understand >> the bad guys” >> o “Everything is related to everything” >> · Indicators and Sightings: Incident Response group >> o “We don’t need to understand them, we just need to detect them damn it” >> o “I only care about Indicators and Sightings” >> >> The thing that not many people realize is that you need both, and you need a >> way of crossing from one to the other. I think this diagram I created >> (©Threatloop.com) demonstrates why: >> >> <image001.png> >> >> The Incident Response process needs to know what Indicators are the ones >> that your Organization needs to look for. At present monitoring and >> detection systems are struggling to operate with the number of indicators >> they need to be looking for. The Threat intelligence process knows what >> threats are most likely…. So wouldn’t it be sensible to use the Threat >> Intelligence process to generate/filter the Indicators so that the Incident >> Response process has a far smaller number of things and more important >> things to look for? >> >> And the Threat Intelligence process need to know what the Incident Response >> process is seeing. Maybe there is a new Threat Actor in town? Maybe an >> existing Threat Actor is starting a new campaign? Threat Intelligence >> processes need to be able to record what is happening to be able to generate >> Indicators that make sense and follow what the real risks to the >> Organization are. >> >> It’s a symbiotic relationship! Both are equally important, and in fact are >> critical to improving Organization’s abilities to protect themselves. >> >> You MUST be able to map from one process to another. >> >> Cheers >> >> Terry MacDonald >> Senior STIX Subject Matter Expert >> SOLTRA | An FS-ISAC and DTCC Company >> +61 (407) 203 206 | terry@soltra.com >> >> >> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] >> On Behalf Of Jordan, Bret >> Sent: Tuesday, 1 December 2015 4:35 AM >> To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> >> Cc: Richard Struse <Richard.Struse@HQ.DHS.GOV>; >> cti-stix@lists.oasis-open.org; Wunder, John A. <jwunder@mitre.org> >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard >> >> I agree with Jason. >> >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can >> not be unscrambled is an egg." >> >> >> On Nov 30, 2015, at 08:35, Jason Keirstead <Jason.Keirstead@ca.ibm.com> >> wrote: >> >> Precisely. >> >> If we can agree on the below.. then work on the standardization of messages >> can be done independently of the underlying model. >> >> RE @Sean: However, I do not view these message specifications as an >> alternative or independent thing from the model/ontology. I would view them >> as a layer on top of the model/ontology that allows focused and explicit >> representation of a small subset of information from the model/ontology that >> is relevant for a given exchange use case. >> >> I disagree here - this is why we are having such a hard time with the >> current paradigm. >> >> There is no actual reason that indicator or sighting messages need to be a >> layer on top of the ontology. They are for totally different use cases and >> can be developed completely independently. >> >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - Unknown >> >> >> <graycol.gif>"Struse, Richard" ---11/30/2015 11:04:55 AM---So, what I think >> I’m hearing is that we envision a world where we define a serialization for >> STIX & >> >> From: "Struse, Richard" <Richard.Struse@HQ.DHS.GOV> >> To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A." <jwunder@mitre.org> >> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> >> Date: 11/30/2015 11:04 AM >> Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard >> ________________________________ >> >> >> >> So, what I think I’m hearing is that we envision a world where we define a >> serialization for STIX & CybOX (let’s assume in JSON) and implementations >> can exchange “documents” using the serialization of the complete data model >> (e.g. for communicating a new TTP for an existing threat actor). However, >> in addition to this, we might define/standardized specialized message >> exchanges for a set of common use-cases such as indicator or >> indicator-sighting exchange. This would allow appliances, for example, to >> simply implement the use-case-specific message exchanges that make sense >> without having to implement the full STIX model. >> >> As a result, I foresee implementations asserting what exchanges they >> support, perhaps as follows: >> CTI-O-MATIC Threat Analysis Platform >> STIX Exchange: SUPPPORTED >> Indicator Exchange: SUPPORTED >> Indicator-Sighting Exchange: SUPPORTED >> Etc. >> >> ACME IDS 9000 Appliance >> STIX Exchange: NOT SUPPORTED >> Indicator Exchange: SUPPORTED >> Indicator-Sighting Exchange: SUPPORTED >> >> Does this make sense? >> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] >> On Behalf Of Jason Keirstead >> Sent: Monday, November 30, 2015 9:47 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard >> "What about a new TTP for an existing threat actor? I would not want to have >> to do an RDF-based exchange to share that type of information (still holding >> out hope for a reasonable JSON-LD approach) but I’m also not sure we can >> build messages to cover those use cases." >> >> I believe you would indeed do a complex exchange for that. This is not a >> "messaging" use case, it is a "document share" use case. The difference in >> complexity between sharing TTP information to sighting information is >> similar to emailing a word document vs. engaging in an IM session. It's not >> the same. >> >> My point is that the huge amount of third party vendors who want to "speak >> STIX" to communicate and/or absorb indicators, observables, and sightings, >> are not interested in use cases like "TTP for an existing threat actor". >> They don't have that information, and they can't act on that information. >> You aren't going to get TTP information out of an IPS, and you aren't going >> to send TTP information to an IDS or Firewall. But you will get Indicators >> and sightings from an IPS, and you will want to send observables to an IDS >> or Firewall. >> >> These are the two different use cases - one that lends itself to a semantic >> model, and one that lends itself to a compact and coherent messaging format. >> >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - Unknown >> >> >> <graycol.gif>"Wunder, John A." ---11/30/2015 10:04:36 AM---So to be honest >> I’m not yet as convinced on this approach as all of you (sorry). I can >> definitely se >> >> From: "Wunder, John A." <jwunder@mitre.org> >> To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> >> Date: 11/30/2015 10:04 AM >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard >> Sent by: <cti-stix@lists.oasis-open.org> >> ________________________________ >> >> >> >> >> So to be honest I’m not yet as convinced on this approach as all of you >> (sorry). I can definitely see the value of messages at the level of >> sightings and indicators but it seems to me like there’s a giant middle >> ground of use cases where we don’t want to define tightly-scoped messages >> but the document-based approach would still be a burden. For these cases I >> was hoping the JSON serialization of the full model would be used. >> >> For example, would we have a message to represent a new incident? What would >> the message semantics be? What about a new TTP for an existing threat actor? >> I would not want to have to do an RDF-based exchange to share that type of >> information (still holding out hope for a reasonable JSON-LD approach) but >> I’m also not sure we can build messages to cover those use cases. >> >> Jason, Jon, Mark…what do you all think about that? Would we define messages >> for that? Would we have third-party messages (i.e. my app can define a >> non-standard CTI message based on the data model)? Would we just use RDF? >> >> John >> On Nov 30, 2015, at 8:42 AM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM> >> wrote: >> +1 to all below recommendations... exactly my line of thinking. >> >> It may or may not be more work to undertake these two parallel efforts - but >> I believe that it would allow both efforts to more forward in a faster and >> more coherent way than the current methodology. >> >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - Unknown >> >> >> <graycol.gif>"Baker, Jon" ---11/30/2015 09:36:44 AM---+1 Thanks for thinking >> through the underlying issues that might be making it so hard to achieve >> cons >> >> From: "Baker, Jon" <bakerj@mitre.org> >> To: Jason Keirstead/CanEast/IBM@IBMCA, "cti-stix@lists.oasis-open.org" >> <cti-stix@lists.oasis-open.org> >> Date: 11/30/2015 09:36 AM >> Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard >> Sent by: <cti-stix@lists.oasis-open.org> >> ________________________________ >> >> >> >> >> +1 >> >> Thanks for thinking through the underlying issues that might be making it so >> hard to achieve consensus. I completely agree that by trying to develop a >> messaging standard and a document standard in one effort is a significant >> source of frustration for this group. This is how I have thought about this >> issue: >> >> >> STIX has two primary use cases >> • UC1: Holistic cyber threat analysis >> • UC2: Exchange cyber threat information >> Requirements for UC1 are not always conducive to effective information >> exchange >> >> My basic recommendation would be as follows: >> >> Differentiate analysis and sharing requirements >> • avoid overloading analysis model with exchange requirements >> • avoid overloading exchange with analysis requirements >> Develop a high level model of cyber threat intelligence for analysis >> • initially in UML, but a semantic representation can be developed >> Develop messages tailored to information exchange needs >> • each exchange has a formal specification >> • ensure messages are compatible with the analysis model >> • allow protocol and serialization to be dictated by information exchange >> needs >> • initially specify only a few well known and well defined messages >> • plan for many messages, but add messages over time as real needs are >> understood >> >> Thanks, >> >> Jon >> >> ============================================ >> Jonathan O. Baker >> J83D - Cyber Security Partnerships, Sharing, and Automation >> The MITRE Corporation >> Email: bakerj@mitre.org >> >> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] >> On Behalf Of Jason Keirstead >> Sent: Thursday, November 26, 2015 8:47 AM >> To: cti-stix@lists.oasis-open.org >> Subject: [cti-stix] STIX: Messaging Standard vs. Document Standard >> When I originally started this message, I had started it with a "here is why >> I am against JSON-LD" stance, but then decided to take a step FAR BACK and >> try to figure out / tease apart the fundamental reasons why people are both >> for and against JSON-LD. As a result of my analysis, I think am starting to >> figure out why there are two diametrically opposed camps here. >> >> The root I believe is that there is a fundamental disconnect between an >> ideal messaging standard and a document standard, yet STIX is trying to >> serve both masters. I am not sure that it can, and keep everyone happy. At >> any rate, I hope if everyone can read through the below, it will at least >> help each camp start to see the other's point of view. >> >> Things desired in a document standard: >> - Clarity of the source and meaning of the data >> - Readability by humans can sometimes be a factor depending on use cases >> - Byte-efficiency is a secondary or tertiary concern (disk is cheap) >> >> In a document standard, it is now the standard practice that the schema >> accompanies the document. This is the core tenant of JSON-LD and other >> related semantic technologies - that your data is annotated in a way such >> that it can be linked back to the schema that defined it, which then also >> allows you to infer the semantic meaning behind fields in the document. This >> lets people and systems cross-correlate and search documents of different >> types that contain fields that are related semantically, without having to >> have standard-specific code written for them. >> Things desired in a messaging standard: >> >> - Maximum byte efficiency (bandwidth is not cheap) >> - Absolutely zero ambiguity >> - Readability by humans is a secondary (or tertiary) concern, sometimes not >> a concern at all >> In a messaging standard, the schema has no reason to accompany the message, >> because anyone who implements it would have zero ambiguity anyway, and doing >> so greatly inflates the size of the messages. You also don't have to infer >> meaning of a field in a messaging standard, because the meaning is fixed and >> is not open to any interpretation. As such, semantic technologies are not >> required in a messaging standard, because they aren't even applicable to the >> use case. >> The root of our problem here and I believe why we can not come to consensus, >> is we are trying to come up with one standard that does both things, which >> are actually philosophically opposed to each-other. There is an extremely >> large community of people and systems who want to "speak STIX", but they >> have no plans to STORE STIX, and this could not care less about semantic >> representations. Similarly, there is a large community of people and systems >> who want to (and already have) systems with large STIX warehouses, and very >> much care about semantic representations, so that they can tie that data to >> other systems. >> >> Maybe we should take a step back and look at this more critically. If you >> look at what people care about from a "frequently messaged" perspective >> (namely of indicators and observable occurrences) maybe that should be moved >> under TAXII? Currently, TAXII is just a transit protocol and the standard of >> the messages is simply " a STIX document". I am starting to think that this >> is not enough and it's part of why we can't reach any consensus. There is no >> reason that there could not be a messaging format in TAXII to communicate >> indicators and observables that was an offshoot of STIX but not STIX >> itself... meanwhile there could continue to be a channel for full/complete >> "STIX documents" which are transmitted with much less frequency. >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - Unknown >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]