search

STIXProject / schemas

STIX Schema Development
http://stixproject.github.io/
76 stars 21 forks source link

Abstract Source to top-level construct rather than embedded only within other constructs #233

Open sbarnum opened 9 years ago

sbarnum commented 9 years ago

This would like involve abstracting InformationSource data to a top-level construct and leveraged where appropriate.

Below is from Byron Collie: We are not leaving Source as a technical attribute in packaging in our extended STIX implementation. To me/us the packaging is purely that, delivery metadata and should reference, not describe information report, collection or source reporting.

Metadata around Source (referred to as pedigree or provenance) reliability and credibility using the Admiralty Scale http://en.wikipedia.org/wiki/Admiralty_code is also critical to tracking reliability and potential ROI of a source, particularly commercial providers, over time.

Concepts (and illustrative examples only) below.

· First Order Object – Source § SANS Internet Storm Center Handlers Diary – B2 § FS-ISAC Cyber Intelligence Email list – B2 § CrowdStrike – Aggregated A1 § Verisign iDefense – Aggregated A1 § Internal Forensic Analysis – A1 § …n o Second Order Object – Information Collection § Verisign iDefense – (Averaged
· Daily IP Reputation Feed – B2 · Daily Threat Indicator Feed – A1 · Weekly Malware Report – B2 · Advanced Threat Research Report XXXXXXXX · …n

§ Third Order Object- Information Report ·
· STIX Object o Object Reliability/Credibility (Admiralty Scale) · STIX Object o Object Reliability/Credibility (Admiralty Scale) · ……n

athiasjerome commented 8 years ago

The source is basically an Asset https://github.com/STIXProject/schemas/issues/234 and so, yes, should be referenced by an 'Asset GUID'

athiasjerome commented 8 years ago

Admiralty Scale should be managed internally. While it could be shared between parties, I don't think it should or would be shared via STIX.

jordan2175 commented 8 years ago

I also really like this idea as it will enable well known producers to have defined source objects that do not need to be included with every object or package. Think of a big-data analytics systems that is producing 100 million indicators day, it would be great for it to just include a reference to some source object.. - But this will add a requirement to TAXII to make sure you can go ask a TAXII server for the rest of the object, if you do not have it. -

A few comments:

1) I would like more information and examples of what you have in mind for the relationship_nature object. And does it really need to be a nested object or can it be flat?

2) Per my other email, we should fix the timestamp object and make it flat

3) Are the field values "from" and "to" the right names here?

4) Instead of calling the object type "related-source" should it not just be a "relationship" or are you envisioning multiple relationship type objects?