[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX Indicator Proposal
-------- Original Message --------Subject: [cti-stix] STIX Indicator ProposalLocal Time: June 8, 2017 6:49 PMUTC Time: June 8, 2017 3:49 PMFrom: Gary.Katz.ctr@dc3.milTo: 'cti-stix@lists.oasis-open.org' <cti-stix@lists.oasis-open.org>I would like to provide another alternative to cover the issues associatedwith analysts creating indicators and the objects they are based upon.There are definitely some cons to this approach, but I believe it does meetthe core issue and at the least it should hopefully start some newdiscussion on the topic.Problem:Currently analysts need to capture an IP address, email address or otheratomic indicators in two ways, first as part of observed data orinfrastructure and then again as an indicator within a pattern. Not allIPs, FQDNs, email addresses, etc. are indicators but a large majority areand large volumes of these types of indicators are captured on a dailybasis. While individual products can be built to alleviate the extra workrequired to maintain this information in two locations (the indicator objectand in the analysis (i.e. observed data, infrastructure, etc.), STIX shouldbe designed to encourage good practices and minimize the need for systems tohide inefficiencies in the standard.Proposed Solution:This solution does leave the opportunity for indicators to be includedwithin a document in two ways, but encourages atomic indicators to berepresented in one way, while complex indicators to be represented inanother way. Many properties within objects can also be atomic indicators.This proposal suggests that any properties that are also an atomic indicatorhave an 'i_' in front of the property name, while if that property was notan indicator it would not have an 'i_'. The Indicator object would be usedto store complex indicators (i.e. patterns), although atomic indicatorscould still also be stored using this approach (hence the two ways torepresent an indicator).For example:{"type": "observed-data","id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf","created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff","created": "2016-04-06T19:58:16.000Z","modified": "2016-04-06T19:58:16.000Z","first_observed": "2015-12-21T19:00:00Z","last_observed": "2015-12-21T19:00:00Z","number_observed": 50,"objects": {"0": {"type": "email-addr","i_value": "badguy@harpoons.com","display_name": "Bad Guy"},"1": {"type": "email-addr","value": "victim@clicksonanything.com","display_name": "Vic"},}}Two email addresses are represented within the objects. badguy@harpoons.comis an indicator, while victim@clicksonanything.com is not an indicator.This allows users (or implementers) to easily create atomic indicatorswithout having to represent the email address within the context of theevent and then separately create an indicator object with the same emailaddress, linking the two together.In order for this approach to work, we would need to define how each datatype (including complex datatypes, such as windows-registry-value-type)would be used as an indicator. In most cases this would be simple, but incomplex datatypes such as windows-registry-value-type, we would need tospecify how the key and values are used to create an indicator.I do not believe this functionality would need to go in the 2.0 release ofSTIX. In my view, this does not break backwards compatibility, although itis a fairly significant change that would break forwards compatibility.It also is a little be it of a hack, which I'm not a fan of and puts extrawork onto the developer to support the capability. Truthfully, I'd ratherput more work on the developer to make things easier on the usersrather than making it easier on the developer to implement somethingthat puts the burden onto the user.Interested in everyone's thoughts,-Gary---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]