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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-taxii] TAXII Use Cases


In the public sharing use case, there are a set of knows and unknown that we need to discuss and investigate.  For the intra eco-system / vertical I think we have a better understanding of our confidence in certain things.  Due to politics and legal requirements public sharing may not have the same amount of detail as one might find inside an eco-system boundary.

Bret 

Sent from my Commodore 64

On Jul 23, 2015, at 2:06 PM, Ron Williams <Ron.Williams@us.ibm.com> wrote:

One challenge with +/- on observables is context. A 'known' bad IP for retail may be irrelevant to finance, because the reason it's 'bad' retail targeted malware source, whatever.

+/- on observables (industry targeted malware site, regional campaign, etc. ) may be useful if provided in the context of industry/geography, etc - but by itself?

Cheers!

~r

ron.williams@us.ibm.com | stsm, ibm master inventor | principal architect, x-force exchange | divisional idt lead | ibm | mobile +1.512.633.7711 | ofc +1.720.349.2236

"It is much less dangerous to think like a man of action, than to act like a man of thought."
- Nicholas Nassim Taleb


<graycol.gif>Jason Keirstead---07/22/2015 11:42:37---Do you forsee the +/- existing at the Indicator/Observable level, or at the CybOX marking level? IE

From: Jason Keirstead/CanEast/IBM
To: Terry MacDonald <terry.macdonald@threatloop.com>
Cc: "Davidson II, Mark S" <mdavidson@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>, Ron Williams <Ron.Williams@us.ibm.com>
Date: 07/22/2015 11:42
Subject: Re: [cti-taxii] TAXII Use Cases




Do you forsee the +/- existing at the Indicator/Observable level, or at the CybOX marking level?

IE can I disagree with only part of an indicator? Or do I have to disagree with the whole thing?
-
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>Terry MacDonald ---2015/07/21 08:33:22 PM---I'd like to add some additional entries to Mark's Use Cases list: - Sending only the part of an obje

From: Terry MacDonald <terry.macdonald@threatloop.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Davidson II, Mark S" <mdavidson@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>, Ron Williams <Ron.Williams@us.ibm.com>
Date: 2015/07/21 08:33 PM
Subject: Re: [cti-taxii] TAXII Use Cases
Sent by: <cti-taxii@lists.oasis-open.org>




I'd like to add some additional entries to Mark's Use Cases list:

- Sending only the part of an object that has changed (increased efficiency)
- Sending just an agreement or disagreement with another organisation's assertion of a relationship (i.e. [+1] or [-1])
- Sending just an agreement or disagreement with another organisation's data in an object i.e. [+1] or [-1])

Cheers

Terry MacDonald
| STIX, TAXII, CybOX Consultant

M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com



Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 21 July 2015 at 03:38, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
    - One thing I would add to the drawing - Organization 2 also talking to the Threat Exchange.

    - RE Storing - One "why" I could give for storage is for resiliency. Without storage of messages on the TAXIi server, if I ever do not have a connection to the server when an important sighting or indicator is shared, I will never receive that message. IE, one can not assume that all consumers are "live".

    - RE Querying - The "why" here hinges on who we would rather be the logical owner of the database of record of threat data, the server or the client. If you want to have a centralized database of record, then the client should be able to query that database. If there is no querying in the protocol and the sever in fact has no database of record (and is simply assumed to be a broker), then client systems will have to build up a copy of the database of record and query it locally instead. In a way this decision is analogous to if you want to do distributed or centralized source control.


    -
    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>"Davidson II, Mark S" ---2015/07/20 02:26:03 PM---Jason, Thank you for posting this. I'd like to highlight one of your paragraphs, as I see it as prob

    From:
    "Davidson II, Mark S" <mdavidson@mitre.org>
    To:
    "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA
    Cc:
    Ron Williams <Ron.Williams@us.ibm.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
    Date:
    2015/07/20 02:26 PM
    Subject:
    RE: [cti-taxii] TAXII Use Cases




    Jason,


    Thank you for posting this. I’d like to highlight one of your paragraphs, as I see it as probably the most important perspective this group should have:
            > When considering development of TAXII 2.0, I feel like this is an opportunity to do things well, and in order to do that, we need to get back to root principals. What are the things TAXII wants to do, what is it trying to solve? Only when your end goal is understood in a clear and concise way can one hope to create a standard that enables that goal.

    With that, I’ll hit on some other points from the thread.


    # Architecture
    This is a bit of a tangent, and forgive the ugliness, but I’ve attempted to draw the architecture Jason described (perhaps with my own un-noticed biases). I used PlantUML[1] (Note: SourceForge is currently down), and I’ve attached my source file in case anyone is interested. I find PlantUML to be pretty useful for quickly whiteboarding ideas.


    Notional Architecture:



    # Use Cases
    Focusing on back on use cases (the subject of this thread), I think what we have is a good starting point, and eventually we’ll need to increase the level of abstraction for the use cases offered so far. Fortunately, there is a very easy process for raising a use-case’s level of abstraction:
    Ask Why. Ask why until the use case is sufficiently high level.
    I’ll pick on the use case of: “storing messages and allowing querying”. I personally – with the information provided – do not have enough information to determine whether I think message storage/query is something that TAXII 2.0 should support. So I’ll ask
    why. Why do we need storage and query? I’ll note that this is not Bret’s question alone to answer – anyone who has any answer should feel compelled to provide it. Multiple answers will provide a greater selection of use cases and perspectives.
    I’ll also note that this message is meant to encourage contribution of all use cases, no matter how high or low level. It’s an easy and useful process to turn a low-level use case into a high-level use case. It’s easy because we just ask “why?”; it’s useful because we might get unanticipated answers that help make TAXII better (e.g., I won’t know what you’re thinking if you don’t say it). More use cases are always better than less use cases, because more use cases gives you more to work with. So please do not hesitate to offer your thoughts on use cases.


    As for my own contribution of use cases, I’ll offer these:
            · Send an Indicator
            ·
            Send a Sighting

    I think many of you who have read this far will be asking: “Why?”


    Thank you.
    -Mark


    [1]
    http://plantuml.sourceforge.net/
            From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Jordan, Bret
            Sent:
            Friday, July 17, 2015 5:54 PM
            To:
            Jason Keirstead <Jason.Keirstead@ca.ibm.com>
            Cc:
            Ron Williams <Ron.Williams@us.ibm.com>; cti-taxii@lists.oasis-open.org
            Subject:
            Re: [cti-taxii] TAXII Use Cases

            Great ideas, Jason thanks for posting. Everything should be on the table at this point. Meaning I do not see any reason why TAXII could not have TLP information in it. And yes TAXII 2.0 needs authentication!!!!


            Some use case ideas at an even higher level will be.


            1) storing messages and allowing query


            2) send on a channel and forget. Meaning if you are listening you get it, if not then you miss it


            Bret

            Sent from my Commodore 64

            On Jul 17, 2015, at 12:01 PM, Jason Keirstead <
            Jason.Keirstead@ca.ibm.com> wrote:
                    I am not referring to services, but use cases

                    Are their specific Protocol Deficiencies with respect to 4 & 5 you've identified?


                    Yep that is what I am asking specifically. (4) and (5) can not be properly handled with TAXII 1.X. I am asking to brainstorm to try to solve these problems under TAXII 2.0, and asiking if this can even be solved soley in the TAXII realm (I am not sure it can since STIX currently handles the TLP).

                    -
                    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>
                    Ron Williams---2015/07/17 02:30:54 PM---So we have 5 TAXII Services, Discovery, Poll, Collection Information, Collection Management, and Inb

                    From:
                    Ron Williams/Austin/IBM
                    To:
                    "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
                    Cc:
                    cti-taxii@lists.oasis-open.org
                    Date:
                    2015/07/17 02:30 PM
                    Subject:
                    Re: [cti-taxii] TAXII Use Cases




                    So we have 5 TAXII Services, Discovery, Poll, Collection Information, Collection Management, and Inbox.

                    For your case 5, isn't this the Inbox Protocol (combined with CMS and CIS as approrpriate)? I don't see TAXII as unable to address 1-5, but rather that the currently deployed services that use the protocol don't yet implement these use cases. Are their specific Protocol Deficiencies with respect to 4 & 5 you've identified? Or is a matter than no one has deployed the services on TAXII that represent them?

                    Cheers!


                    ~r


                    ron.williams@us.ibm.com | stsm, ibm master inventor | chief architect, infrastructure protection | divisional idt lead | ibm | mobile +1.512.633.7711 | ofc +1.720.349.2236
                    "It is much less dangerous to think like a man of action, than to act like a man of thought."
                    - Nicholas Nassim Taleb



                    <graycol.gif>
                    "Jason Keirstead" ---07/17/2015 11:56:11---Hello all; I was engaging with Bret yesterday on some items and he correctly suggested we should sha

                    From:
                    "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
                    To:
                    cti-taxii@lists.oasis-open.org
                    Date:
                    07/17/2015 11:56
                    Subject:
                    [cti-taxii] TAXII Use Cases
                    Sent by:
                    <cti-taxii@lists.oasis-open.org>





                    Hello all; I was engaging with Bret yesterday on some items and he correctly suggested we should share this with the whole group.

                    When considering development of TAXII 2.0, I feel like this is an opportunity to do things well, and in order to do that, we need to get back to root principals. What are the things TAXII wants to do, what is it trying to solve? Only when your end goal is understood in a clear and concise way can one hope to create a standard that enables that goal.

                    The way I see the landscape evolving, there are five main classes of TAXII usage. Some products may support multiple classes, some may only support one.. but these are the five main interaction paradigms at play.

                                    1) TAXII clients who act as producers of threat information. One example of this may be a layer 7 firewall that has a rule that publishes responses via TAXII to another product, or an analyst manually submitting a research product via a tool.

                                    2) TAXII clients who act as consumers of threat information. One example of this may, again, be a layer 7 firewall that consumes threat information (observables) and uses the information to create rules, or an analyst reading a threat feed either manually or via a tool.

                                    3) TAXII servers who act as message brokers within an organization (an enterprise/governmental entity/user group). These servers federate the information between the (1) and the (2) TAXII clients within the organization.

                                    4) TAXII servers who act as message brokers among other TAXII servers (an example of this would be FS-ISAC). This is the point where data authorization starts becoming important. For example, say I publish a package to my local TAXII server with several components, some of which I want to be available to be brokered to everyone in the group, and some of which I only want to be available to select entities in the group with whom I have a trust relationship, or those with specific rights. Obviously, this has to tie into authorization.

                                    5) TAXII servers who act as public or subscription based threat exchanges that allow publish and subscription to feeds. This is not the same use-case as (4) because of the fact that it is a public threat exchange, anyone may be contributing - thus, authentication and authorization to data is paramount. For example, say I create an account on a public exchange claiming to represent Company A or Entity A - how can that exchange validate that I am allowed to speak with authority for that company? Furthermore

                    Traditionally, I feel like TAXII (and STIX as well) have been focused on 1-3, while neglecting 4 and 5. The problem is, 4 and 5 are what is going to get STIX wide adoption.

                    Once you get into (4) and (5) there is a whole set of use cases that TAXII 1.X has not tacked, that I have brought up on the MITRE lists many times... issues with authentication, authorization, validation of chains of authority, public registries, etc etc... the list goes on.

                    I am not sure which CTI group this effort belongs in but TAXII feels like it may be the best fit... although it also ties into the TLP mechanism in STIX, which needs re-thought to deal with these issues.

                    I am wondering what the thoughts are in the group around these issues of not just authentication, but also authorization and trust chains... do these belong in a TAXII 2.0, and if not, how can we enable these above use cases.

                    -
                    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

                    [attachment "notional_architecture.txt" deleted by Jason Keirstead/CanEast/IBM]



GIF image

Attachment: 4B314059.gif
Description: 4B314059.gif



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]