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


It's probably slightly better described as having the ability to send relationships independently from the 'data' objects themselves. This gives people who weren't the original producers of the STIX objects the ability to say we think there is a relationship between these two STIX objects. It allows them to say we also think there is a relationship here... Kind of a +/-1 for any relationship. It makes it much simpler for third parties to find and report new relationships, and for third parties to show that they also agree about a relationship that others have reported.

I would see this applying at STIX and CybOX level as relationships are required between objects. And giving TAXII the ability to convey the relationship only is IMHO very important.

Cheers
Terry MacDonald

On 23 Jul 2015 2:42 am, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:

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


Inactive hide details for Terry MacDonald ---2015/07/21 08:33:22 PM---I'd like to add some additional entries to Mark's Use CasTerry 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


    Inactive hide details for "Davidson II, Mark S" ---2015/07/20 02:26:03 PM---Jason, Thank you for posting this. I'd like to high"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]





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