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] Proposal - Top Level Relationship Object


Not necessarily Bret. It may be an 'hypothesis' that someone is wanting to share - to 'put it out there' to see if anyone agrees with it. Being able to mark something (using the Information reliability scale I posted earlier) as '3 - Possibly True' or '4 - Doubtfully True' then allows consumers to determine what level of confidence they want to assign to the information. 

Ultimately each organization has its own criteria for determining what believes the truth to be. Information provided over STIX is just someones opinion. They are not facts (ok maybe some cybox objects are) but are reflections of conclusions that someone has decided upon. It's up to the consuming organization to decide what it thinks is the truth. 

Consumers need to ask the following for each bit of information they receive:
  1. How reliable is the information source that gave me this data (source reliability)
  2. How reliable does the source think the data is (information reliability)
In my opinion as a consumer I should be collecting everyone's opinions, hypotheses and guesses, no matter how mad - and making my own determination as to what I think. I should be crowdsourcing everyones opinions. All information is important in gaining insight even if it's seemingly nonsense at the time. The important thing is to give people a way of [+1] or [-1] on other people's relationships so that bad relationships are downvoted and become less important, and good relationships are upvoted and become more important. This will allow consumers to adjust what they think is true over time, and reflect the true nature of intelligence gathering - trying to make sense of rumour and gossip. It also will allow people over time to determine which organizations they should be listening to, and which ones they should ignore. Kind of like how stackoverflow does things :).


Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




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 30 July 2015 at 08:57, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
I will choose to argue that if you have any level of context, then by definition you have some level of Reliability / Confidence / or what ever end up calling it.  


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 Jul 29, 2015, at 16:39, Patrick Maroney <Pmaroney@Specere.org> wrote:

Re: "One comment, if you have no confidence in the accuracy of something, meaning you have not done any due diligence on your end, should you really be sharing it? Isn't this the whole problem with the Internet today? People spewing forth crap that is just wrong, and then it gets archived in Google as Gospel. "

Sharing unfiltered, unvetted intelligence on Emerging Threats/Previously Unrecognized Threats is extremely valuable in many of the communities I participate in.  The critical element is to properly mark it.  For example one community uses "Investigating" to flag something as preliminary (say I've analyzed 100% 0Day APT Malware, and I run Strings on the binary and get 50 IP Addresses and Domains.  Yet the Malware was only observed to attempt communication with 6/50.  By sharing this type of intelligence [WITH CONTEXT] with the community others can be aware and say, Hey!!!  I didn't see the vectors you did, but I did see a different subset of 6 out of your 50.  We ran it in an air gapped sandbox and when the test access to Google.com failed the Malware beaconing switched to these different IPs and Ports.  Let's mark these 6 new IOCs as actionable and let everyone know the malware may behave differently in different environments and to keep an eye out for the other 38 IOCs."

Capturing and retaining properly marked indicators has also revealed key discoveries years later:  for example: "Hey we were investigating something else and our search revealed APT Actor "X" was indeed using nameyourfavoritecommoditybotnet back in 2011!!!!  We didn't realize we had actionable indicators at the time.  Thanks for posting those informational Strings back in 2011!!!!!

Filtering Intelligence will significantly impede detection of multi-Stage exploitation and variants of RATs deployed in the Entrenchment phase of lateral movement once adversary has established their initial beachhead and begins deploying.  The key is to ensure you convey all of the context you've developed (and "show your work" to back any of your assertions).  

Understand in these assertions that, as always, other world views/use cases, methods are equally valid.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org




On Wed, Jul 29, 2015 at 3:06 PM -0700, "Terry MacDonald" <terry.macdonald@threatloop.com> wrote:

I was thinking back to the Admiralty Code (https://en.wikipedia.org/wiki/Admiralty_code) regarding reliability and credibility when I wrote that.  The idea was if someone had learned from a 3rd party that there was a relationship between Threat Group A and Threat Group B, but had not yet been able to determine the reliability/truthfulness of what that third party had said. They may want to send out that relationship, as kind of a 'something we've heard but not had a chance to verify ourselves'. That's where I was headed with the Unknown option.

Maybe it would be better to use the terms from Information Reliability instead of Confidence when describing relationships within STIX? (https://en.wikipedia.org/wiki/Intelligence_source_and_information_reliability)
Rating Description
1 Confirmed Logical, consistent with other relevant information, confirmed by independent sources.
2 Probably true Logical, consistent with other relevant information, not confirmed.
3 Possibly true Reasonably logical, agrees with some relevant information, not confirmed.
4 Doubtfully true Not logical but possible, no other information on the subject, not confirmed.
5 Improbable Not logical, contradicted by other relevant information.
6 Cannot be judged The validity of the information can not be determined.

Just a thought.

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




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 30 July 2015 at 07:12, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

What is the use case where someone is asserting something with no information behind it though? I am kind of lost on that. Why would it be being asserted?

-
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/29 06:03:11 PM---I think there is a difference: 0 confidence = I have checked this information and I do not have any



From: Terry MacDonald <terry.macdonald@threatloop.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Wunder, John A." <jwunder@mitre.org>, Aharon Chernin <achernin@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "Chris O'Brien" <COBrien@cert.gov.uk>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, JG on CTI-TC <jg@ctin.us>
Date: 2015/07/29 06:03 PM
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
Sent by: <cti-stix@lists.oasis-open.org>





I think there is a difference:

0 confidence = I have checked this information and I do not have any faith that it is true.
Unknown = There is no information to say if this is true or not true. We have no way to infer anything at present.

---

I'd also say that there is the potential here for using something like the Admiralty code as a replacement for confidence.....https://en.wikipedia.org/wiki/Admiralty_code:

Reliability of Source
A - Completely reliable

B - Usually reliable
C - Fairly reliable
D - Not usually reliable
E - Unreliable
F - Reliability cannot be judged

Accuracy of data (Credibility)
1 - Confirmed by other sources

2 - Probably True
3 - Possibly True
4 - Doubtful
5 - Improbable
6 - Truth cannot be judged

Maybe that makes sense more so than Confidence?

---

I also believe that we need to keep each relationship as a single direction relationship, to enable someone to discern a 'hierarchy' from the relationships they receive, rather than just a 'group' (as highlighted by others on the thread). If we combine all the relationships into a pool, we lose the ability of separating those relationships back out. I would like to keep the Source_ID and Target_ID separation.
    • ID [1] [Required]: The ID of the relationship
    • Version [1] [Required]: The version of the relationship; a simple number to be used with the ID for version control (instead of timestamp)
    • Type [1] [Required]: The “type” of relationship being expressed.  (Not sure of how this works yet)
    • Description [0..N] [Optional]: Words about the relationship.
    • Source_ID [1] [Required] : The ID of one or more source entities in the relationship as a URI (not QName)
    • Target_ID [1..N] [Required]: The ID of one or more targets in the relationship as a URI (not QName)
    • Start_Time [0..1] [Required]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
    • End_Time [0..1] [Required]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
    • Confidence [1] [Required]: A measure of confidence in the relationship.  (or should we look at Reliability/Credibility as discussed above?)
    • Timestamp [0..1] [Required]: A timestamp in UTC stating when the relationship object was created.
 

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 30 July 2015 at 05:25, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
    Well... 0 would be exactly what it says... zero confidence, aka "no confidence".

    Is there a difference between "no confidence" and "unknown confidence"? To me they're the same thing... if you don't know, you don't know.

    -
    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." ---2015/07/29 04:23:55 PM---I don't know, what does a confidence of 0 mean? To me the statement that the confidence is unknown i

    From:
    "Wunder, John A." <jwunder@mitre.org>
    To:
    Jason Keirstead/CanEast/IBM@IBMCA
    Cc:
    "Jordan, Bret" <bret.jordan@bluecoat.com>, Aharon Chernin <achernin@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, JG on CTI-TC <jg@ctin.us>, "Chris O'Brien" <COBrien@cert.gov.uk>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Date:
    2015/07/29 04:23 PM
    Subject:
    Re: [cti-stix] Proposal - Top Level Relationship Object





    I don't know, what does a confidence of 0 mean?


    To me the statement that the confidence is unknown is quite different from the statement that the confidence very low.


    From:
    <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead
    Date:
    Wednesday, July 29, 2015 at 3:19 PM
    To:
    "Wunder, John A."
    Cc:
    "Jordan, Bret", Aharon Chernin, Jon Baker, JG on CTI-TC, Chris O'Brien, "cti-stix@lists.oasis-open.org"
    Subject:
    Re: [cti-stix] Proposal - Top Level Relationship Object

    What is the difference between having confidence be optional or "unknown" and assigning a value of 0?


    -
    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." ---2015/07/29 03:10:51 PM---I agree with you on reducing optionality but to me these "unknown" values are just hiding optionalit


    From:
    "Wunder, John A." <jwunder@mitre.org>
    To:
    "Jordan, Bret" <bret.jordan@bluecoat.com>, Aharon Chernin <achernin@soltra.com>
    Cc:
    "Baker, Jon" <bakerj@mitre.org>, JG on CTI-TC <jg@ctin.us>, "Chris O'Brien" <COBrien@cert.gov.uk>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Date:
    2015/07/29 03:10 PM
    Subject:
    Re: [cti-stix] Proposal - Top Level Relationship Object
    Sent by:
    <cti-stix@lists.oasis-open.org>





    I agree with you on reducing optionality but to me these "unknown" values are just hiding optionality rather than eliminating it.

    If anything it seems like having the field not present vs. a special "unknown" value is more obvious and explicit because it makes it clear that it's a special case. Otherwise you're going to have a lot of "if val == 'unknown'" code paths, and hardcoded strings with special meanings are bad.

    John


    From:
    "Jordan, Bret"
    Date:
    Wednesday, July 29, 2015 at 1:55 PM
    To:
    Aharon Chernin
    Cc:
    Jon Baker, "Wunder, John A.", JG on CTI-TC, Chris O'Brien, "cti-stix@lists.oasis-open.org"
    Subject:
    Re: [cti-stix] Proposal - Top Level Relationship Object

    It has to be that way... Confidence has to be required, even if the the value is "unknown". We need to reduce the optionality and make code decision trees easier.


    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 Jul 29, 2015, at 08:57, Aharon Chernin <achernin@soltra.com> wrote:

                    Have you considered the case where an analyst wants to simply say that this collection of objects seems to be related?


                    Wouldn't this just be a low confidence relationship?


                    Aharon Chernin
                    CTO

                    SOLTRA
                    | An FS-ISAC & DTCC Company
                    18301 Bermuda green Dr
                    Tampa, fl 33647
                    813.470.2173 |
                    achernin@soltra.com
                    www.soltra.com




                    From:
                    cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Baker, Jon <bakerj@mitre.org>
                    Sent:
                    Wednesday, July 29, 2015 8:37 AM
                    To:
                    Wunder, John A.; Jordan, Bret
                    Cc:
                    JG on CTI-TC; Chris O'Brien; cti-stix@lists.oasis-open.org
                    Subject:
                    RE: [cti-stix] Proposal - Top Level Relationship Object

                    John,

                    Have you considered the case where an analyst wants to simply say that this collection of objects seems to be related?

                    Imagine a case where you think that a bunch of things (incidents/observables/etc) are related, but you have not yet done the in depth analysis to understand the nature of their relationship. I had this sort of generic grouping of things in mind for a top level relationship object. In this case, I don’t think you could always have a From and To IDREF. You might just have a collection of IDREFs.

                    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 Wunder, John A.
                    Sent:
                    Tuesday, July 28, 2015 4:15 PM
                    To:
                    Jordan, Bret <bret.jordan@bluecoat.com>
                    Cc:
                    JG on CTI-TC <jg@ctin.us>; Chris O'Brien <COBrien@cert.gov.uk>; cti-stix@lists.oasis-open.org
                    Subject:
                    Re: [cti-stix] Proposal - Top Level Relationship Object

                    Sure...personally I would do this, which is almost identical to what we do now (other than being at the top level rather than within an object):

                    Relationship
                    ID (for the relationship) [required]
                    From IDREF [required]
                    To IDREF [required]
                    Relationship Qualifier [required]
                    Confidence [optional]

                    I'm undecided on whether information source information belongs in the STIX data model at all. By virtue of being in the data model it means someone is asserting it so it's impossible to verify. Digital signatures or something else out of the data model (relying on TAXII, etc.) seem like a better approach to me. But I don't have strong opinions on this and if we do include information source in the data model I would add that here.

                    John


                    From:
                    "Jordan, Bret"
                    Date:
                    Tuesday, July 28, 2015 at 4:05 PM
                    To:
                    "Wunder, John A."
                    Cc:
                    JG on CTI-TC, Chris O'Brien, "cti-stix@lists.oasis-open.org"
                    Subject:
                    Re: [cti-stix] Proposal - Top Level Relationship Object

                    Great... Now we are discussing it... Please spell out what that would look like.


                    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 Jul 28, 2015, at 13:51, Wunder, John A. <jwunder@mitre.org> wrote:

                                    No directionality or description/qualifier? It seems like you want to be able to say *what* a relationship is describing and also which direction it goes in.

                                    I.e. TTP malware "is variant of" other TTP malware
                                    vs. TTP malware "is same as" other TTP malware given a different name by a different vendor


                                    From:
                                    <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
                                    Date:
                                    Tuesday, July 28, 2015 at 3:41 PM
                                    To:
                                    JG on CTI-TC
                                    Cc:
                                    Chris O'Brien, "cti-stix@lists.oasis-open.org"
                                    Subject:
                                    Re: [cti-stix] Proposal - Top Level Relationship Object

                                    I see the relationship object being pretty simple and straight forward:


                                    Relationship
                                    IDREF (1-n)
                                    Source
                                    Confidence


                                    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 Jul 28, 2015, at 13:16, JG on CTI-TC <jg@ctin.us> wrote:

                                                    Chris:

                                                    You are not going insane...we are all dealing with these same issues.

                                                    Some of the more recent discussions (after you made this post) with
                                                    respect to 'Sightings' seem to make a lot of sense to me...that is, to
                                                    push the Sighting functionality further down in the data model...That
                                                    is, down to the CybOX level...

                                                    And I think we need to think about the Relationship object with respect
                                                    to 'Communities of Interest'... For example, a malware research
                                                    Community of Interest that is using Indicator, Observable, TTP and
                                                    ExploitTarget may seek to express Relationships in a way that shows the
                                                    Static and Behavioral characteristics of the malware (deep in the data
                                                    model and at a very refined level of granularity)

                                                    ...Whereas an Incident Response Community of Interest that is using
                                                    Indicator, Incident and CourseOfAction may need the Relationship object
                                                    defined in a separate way.... that is, one that is more tied to
                                                    "actionable intelligence" which may then tie into ExploitTarget,
                                                    ThreatActor, and Campaign...which then becomes of interest to a law
                                                    enforcement Community of Interest.

                                                    Of course... handling this may take us back into the debate on Profiles...

                                                    Jane Ginn
                                                    CTIN

                                                    On 7/27/2015 3:44 AM, Chris O'Brien wrote:
                                                                    For what it's worth, from me, I think this would be pretty huge (coupled with the sightings object as well). As an analyst trying to identify useful data for my customers on large data sets, I'm interested in being able to produce top-level, automated assessments on data quality of feeds/dbs of stix data, and one of the ways that I'd suggest that a specific data point is of a 'high quality' is if it has multiple relationships and/or sightings. Add in to that the ability to rank producers, and even analytical assertion confidence, and you've got all the makings of a an algorithm for a heuristic grading scheme that could feed something even more awesome...like a machine learning project that can conduct threat pattern detection... As you say, Bret, this also gives scope for those relationships to have their own concept of 'quality' based on their related analytical assertions / confidence.

                                                                    I'd perhaps throw in to the discussion that it may not need to be a standalone object in its own right - we're currently experimenting with using the existing stix architecture relationships (with a little extra meta data) to achieve the desired effect, but it gets messy quickly and direct references to the relationships are by-way-of the object that they sit on (then you ask...which end of the relationship is the 'master' for that relationship, or must they both be updated when a change is made...what happens if one of them isn't in your namespace, etc, etc). Jimmy-rigging solutions to those issues feels feasible, but messy, prescriptive and makes anyone with a coding background have a little cry to themselves. It's something we're having to think about here at the moment - just wanted to mention that it's still possible and would be less impactful to existing deployments.

                                                                    Cheers,
                                                                    cob

                                                                    PS: If anyone else is looking in to this sort of heuristic / predictive / minority report-esque implementation, it'd be good to hear from you. If only to confirm that I'm not going completely insane.


                                                                    -----Original Message-----
                                                                    From:
                                                                    cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
                                                                    Sent: 24 July 2015 22:57
                                                                    To:
                                                                    cti-stix@lists.oasis-open.org
                                                                    Subject: [cti-stix] Proposal - Top Level Relationship Object

                                                                    I would like to see a top level relationship object that just contains references to the times that are related. This needs its own ID so people can reference it and disagree with it or sight it or enrich it with other data.

                                                                    Bret

                                                                    Sent from my Commodore 64
                                                                    ---------------------------------------------------------------------
                                                                    To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:

                                                                    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

                                                    --
                                                    Jane Ginn, MSIA, MRP
                                                    Cyber Threat Intelligence Network, Inc.

                                                    jg@ctin.us



                                                    ---------------------------------------------------------------------
                                                    To unsubscribe from this mail list, you must leave the OASIS TC that
                                                    generates this mail. Follow this link to all your TCs in OASIS at:

                                                    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



    [attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]












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