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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[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]