cti-stix — archive

Proposal - Top Level Relationship Object

From: Jason Keirstead <[email protected]>
To: [email protected]
Date: Wed, 29 Jul 2015 15:04:00 -0000

Right - to be clear I am not endorsing any specific type of registry, just some way to look it up. In fact if this can be piggy-backed on existing infrastructure such as SSL authority or DNS-SEC authority, it would be a great way to get wide-spread adoption. (I actually think DNS-SEC might be a stellar way to go for this. IE you publish something with a ID of A82387FED.stix.soltra.com and use DNS-SEC to validate it) - 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 Aharon Chernin ---2015/07/29 11:55:20 AM---I like the idea of making TAXII handle all auth and passing it up the stack. I am not sold yet on a From: Aharon Chernin <[email protected]> To: Jason Keirstead/CanEast/IBM@IBMCA, "Jordan, Bret" <[email protected]> Cc: "Wunder, John A." <[email protected]>, JG on CTI-TC <[email protected]>, "Chris O'Brien" <[email protected]>, "[email protected]" <[email protected]> Date: 2015/07/29 11:55 AM Subject: Re: [cti-stix] Proposal - Top Level Relationship Object I like the idea of making TAXII handle all auth and passing it up the stack. I am not sold yet on a public registry of identifiers. TAXII could be used on networks where access to this registry is denied not to mention that a lot of good data purposely travels around anonymously. Why not include certificate encryption (PKI) in the TAXII spec? This would allow us to encrypt the data and give some semblance that the person who received the data is the person who should view it. Aharon Chernin CTO SOLTRA An FS-ISAC & DTCC Company 18301 Bermuda green Dr Tampa, fl 33647 813.470.2173 [email protected] www.soltra.com From: [email protected] <[email protected]> on behalf of Jason Keirstead <[email protected]> Sent: Wednesday, July 29, 2015 9:54 AM To: Jordan, Bret Cc: Wunder, John A.; JG on CTI-TC; Chris O'Brien; [email protected] Subject: Re: [cti-stix] Proposal - Top Level Relationship Object " One option is if we could get authentication channel-binding in place between TAXII and STIX and STIX and CybOX then we could do the authentication down in TAXII land and just pass that information up the stack. " I totally agree...! What I would like to see is common agreement at the CTI level as to what an "entity identifier" (where "entity" is a person, company, group, etc) looks like - be it a UUID, URL, URN, or whatever. Once that is agreed upon, we can then explore in TAXII how authentication protocol works, with the agreement that the artifact of authentication would be a collection of said entity identifiers for authorization (I authenticate and I get an identifier for myself and also one for each group I belong to). STIX can then use the entity identifier to enumerate access controls at the various object levels (I have an object and can tag it with "people with this identifier have read access, people with this identifier have read/write access)". This would go a long way to solve the TLP-originated deficiencies in STIX 1.X. And it also opens the door to having a public registry of these entity identifiers somewhere - that TAXII can presumably authenticate against. This then solves the "how do I know that this user actually belongs to the organization they claim to belong to" problem as well. - 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 "Jordan, Bret" ---2015/07/28 05:30:30 PM---Now we are designing and working together!!!! I like these ideas... One option is if we could get a From: "Jordan, Bret" <[email protected]> To: "Wunder, John A." <[email protected]> Cc: JG on CTI-TC <[email protected]>, "Chris O'Brien" <[email protected]>, "[email protected]" <[email protected]> Date: 2015/07/28 05:30 PM Subject: Re: [cti-stix] Proposal - Top Level Relationship Object Sent by: <[email protected]> Now we are designing and working together!!!! I like these ideas... One option is if we could get authentication channel-binding in place between TAXII and STIX and STIX and CybOX then we could do the authentication down in TAXII land and just pass that information up the stack. 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 14:15, Wunder, John A. < [email protected] > wrote: 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, " [email protected] " 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. < [email protected] > 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: < [email protected] > on behalf of "Jordan, Bret" Date: Tuesday, July 28, 2015 at 3:41 PM To: JG on CTI-TC Cc: Chris O'Brien, " [email protected] " 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 < [email protected] > 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.