{"action":"created","issue":{"url":"https://api.github.com/repos/johnwunder/twigs/issues/3","labels_url":"https://api.github.com/repos/johnwunder/twigs/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/johnwunder/twigs/issues/3/comments","events_url":"https://api.github.com/repos/johnwunder/twigs/issues/3/events","html_url":"https://github.com/johnwunder/twigs/issues/3","id":119830002,"number":3,"title":"Return individual +1 sighting","user":{"login":"terrymacdonald","id":5721772,"avatar_url":"https://avatars.githubusercontent.com/u/5721772?v=3","gravatar_id":"","url":"https://api.github.com/users/terrymacdonald","html_url":"https://github.com/terrymacdonald","followers_url":"https://api.github.com/users/terrymacdonald/followers","following_url":"https://api.github.com/users/terrymacdonald/following{/other_user}","gists_url":"https://api.github.com/users/terrymacdonald/gists{/gist_id}","starred_url":"https://api.github.com/users/terrymacdonald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/terrymacdonald/subscriptions","organizations_url":"https://api.github.com/users/terrymacdonald/orgs","repos_url":"https://api.github.com/users/terrymacdonald/repos","events_url":"https://api.github.com/users/terrymacdonald/events{/privacy}","received_events_url":"https://api.github.com/users/terrymacdonald/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-12-01T23:10:43Z","updated_at":"2015-12-01T23:47:10Z","closed_at":null,"body":"When people have been discussing Sightings, they have been saying things like ‘this observation is a sighting of this Indicator’, or ‘ we sighted this indicator and this is the observation that matched’. In both cases, I saw the objects and relationships as ‘this observation is a sighting of this Indicator’\r\n\r\ni.e. In neo4j Cypher parlance = (observation) –[:sighting]-> (indicator)\r\n\r\nIn other words, even in a relationship between an Indicator and an Observation I still believe a relationship of the correct type is enough to describe it (i.e. relationship type: sighting).\r\n\r\nJohn proposed the following:\r\n\r\nI guess for this case you’d just omit the object on the observation? Would we allow that? It would look basically like this:\r\n\r\n* observation\r\n  * id\r\n  * timestamp\r\n  * producer\r\n  * object\r\n* relationship\r\n  * id\r\n  * producer\r\n  * timestamp\r\n  * value = matched\r\n  * from-ref = observation\r\n  * to-ref = indicator\r\n\r\nDefinitely a lot of markup for a simple +1. I don’t really have a problem with that, but those looking at huge volumes might? Maybe that means they should do counts though?"},"comment":{"url":"https://api.github.com/repos/johnwunder/twigs/issues/comments/161133788","html_url":"https://github.com/johnwunder/twigs/issues/3#issuecomment-161133788","issue_url":"https://api.github.com/repos/johnwunder/twigs/issues/3","id":161133788,"user":{"login":"terrymacdonald","id":5721772,"avatar_url":"https://avatars.githubusercontent.com/u/5721772?v=3","gravatar_id":"","url":"https://api.github.com/users/terrymacdonald","html_url":"https://github.com/terrymacdonald","followers_url":"https://api.github.com/users/terrymacdonald/followers","following_url":"https://api.github.com/users/terrymacdonald/following{/other_user}","gists_url":"https://api.github.com/users/terrymacdonald/gists{/gist_id}","starred_url":"https://api.github.com/users/terrymacdonald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/terrymacdonald/subscriptions","organizations_url":"https://api.github.com/users/terrymacdonald/orgs","repos_url":"https://api.github.com/users/terrymacdonald/repos","events_url":"https://api.github.com/users/terrymacdonald/events{/privacy}","received_events_url":"https://api.github.com/users/terrymacdonald/received_events","type":"User","site_admin":false},"created_at":"2015-12-01T23:47:10Z","updated_at":"2015-12-01T23:47:10Z","body":"The original diatribe that started this issue: \r\n\r\nI’ve been thinking about Aharon’s assertion that you should be able to ‘sight’ anything. It set me to thinking what that relationship is, and how it could work.\r\n\r\nWhat is a Sighting?\r\n------------------------\r\nThe dictionary definition of Sighting is ‘to see, glimpse, notice, or observe’. In this respect Aharon is right, a sighting is effectively saying ‘I’ve seen something that I noticed’. This potentially could be applied to any object that we have in STIX. \r\n\r\nIf an Organization has identified that the person behind their attacks is likely to the same Threat Actor APT99 they read about in a TrendMicro report, then they could conceivably want to ‘sight’ the fact they think they have a relationship between their Incident and the Threat Actor.  We already have a relationship type within STIX for that kind of relationship: RelatedThreatActor. The Organization can create a relationship object that connects the ThreatACtor APT99 with their Incident Object, and send that with their Incident object out to the community. Others then have the ability to recognize that Organizations assertion that the two are related. I believe this can be done without the need for a separate Sighting object; all it needs is a relationship object of the correct type for that relationship connection \r\n\r\ni.e. \r\nrelationship from ThreatActor to TTP should be of type ‘RelatedTTP’\r\nrelationship from ExploitTarget to COA should be of type ‘RelatedCOA’\r\n\r\nWhen most people have been talking about sightings, it has been in the context of establishing relationship between and Indicator and an Observable Instance. \r\n\r\nNow, just for clarity, I’ll point out I hate the use of Observables as both Instances and Patterns. It confuses the heck out of people. I too would like to only use Observables as Observable Instances, and handle patterns in their own way (as you have mentioned in your Open Questions  here: https://github.com/johnwunder/twigs\r\n\r\nFor the rest of this diatribe I will refer to Observable Instances as Observations.\r\n\r\nWhen people have been discussing Sightings, they have been saying things like ‘this observation is a sighting of this Indicator’, or ‘ we sighted this indicator and this is the observation that matched’. In both cases, I saw the objects and relationships as ‘this observation is a sighting of this Indicator’ \r\n\r\ni.e. In neo4j Cypher parlance  = (observation) –[:sighting]-> (indicator)\r\n\r\nIn other words, even in a relationship between an Indicator and an Observation I still believe a relationship of the correct type is enough to describe it (i.e. relationship type: sighting).\r\n\r\nMaybe what we need is actually to rename the relationship type to something else? Or maybe put it in the other direction?\r\ni.e. \t(observation) –[:matched]-> (indicator) ?\r\n(indicator) –[:observed]-> (observation)?\r\n\r\n\r\nIf we used a relationship type that’s not sighting then we bypass the whole ‘whats a sighting’ argument .\r\n\r\nWe could potentially do it this way:\r\n•\tRename TWIG Sighting Object  to TWIG Observation Object\r\n•\tUse the TWIG Observation object each time an Indicator is matched\r\n•\tUse individual relationships of type ‘Matched’ to link each Observation to the Indicator\r\n•\tThe Observation Object would have a timestamp recording when the Observation was made\r\n•\tThe related ‘Matched’ relationship Object would have a timestamp recording when the Observation was recognized as a triggering of the Indicator.\r\n•\tThe Indicator object could still contain a Observation_count to allow an overview of how common that Indicator has been detected if the consumers don’t need to know the full list of matching Observations.\r\n\r\n\r\nOther related things\r\n---------------------------\r\n\r\nWe need a way of:\r\n•\tSaying ‘this thing I have is related to those other things you asserted’ (can be done via relationship object linking two ‘data objects’)\r\n•\tSaying ‘these two things are related’ (can be done via relationship object linking two ‘data objects’)\r\n•\tSaying ‘we think that too’; Agreeing and Disagreeing (can’t be done at the moment)\r\n\r\nFor this last part, I envisaged we needed a way for a community member to disagree with an assertion that another community member has made. As an example if VendorA says ‘IP 8.8.8.8 is bad with a high confidence’ then we want the community to be able to say ‘no it isn’t’.\r\n\r\nIn my thinking on the subject I concluded that we needed a way of agreeing and disagreeing two different groups of things:\r\n1.\tWhether an assertion regarding an entity was correct\r\n2.\tWhether an assertion regarding the relationship between two entities was correct.\r\n\r\nThis was potentially going to be difficult, but with the acceptance of the top-level relationship object it became a whole lot easier. A relationship object will have an Object ID, just like the STIX data objects – meaning that any agree/disagree object would only need to refer to an Object ID in order to apply to it. This prompted the following proposal… the creation of the Opinion Object:\r\n\r\nopinion_object {\r\n\tid: QName # this id of this opinion\r\n\ttimestamp: # just so that this can be updated at a later date ()\r\n\tversion: # the version of this opinion object (e.g. '1')\r\n\tobject_ref: QName, # the id of the referred object.\r\n\tagreement: ['strongly agree', 'agree', 'undecided', 'disagree', 'strongly disagree', 'unknown'],\r\n\tdescription: StructureTextString,\r\n\tsource: InformationSourceType\r\n}\r\nPlease note this object is from the suggestion made within the ‘STIX Difficulties v1.4 Final.docx’ and hasn’t been modified at all to work with TWIGS. \r\n\r\nThis object will help people be able to disagree with relationships and with other ‘data node’ objects that others provide. The idea is that it explicitly applies to particular objects that people share, allowing anyone (except the original producer) to agree or disagree with the information in the original STIX Object. The original producer cannot agree or disagree with what they have already asserted by sending out their STIX Object. They can only modify their assertion by sending out a new replacement object; the producers opinion is always demonstrated through the publishing of the most current ‘version’ of the original object.\r\n"}}