Hi Jon
-
Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times,
ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc.. You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact
efficient messages due to high volume.
This is what I personally (speaking as myself) think of when I think of a Sighting. A description of an Observable Instance with some
basic extra context.
-
Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been
matched (or sighted).
To me this is no different to the first case. If an Indicator has been matched then a new Sighting object will be created under the
namespace of the Organization. The Organization will then share that Sighting object back to the ISAC/ISAO (if the Org wants to) along with a Relationship object (also under the namespace of the Org) that maps the ISAC Indicator to the Org’s Sighting Object.
This can potentially be accompanied with an Incident object or Report object to give extra context if required.
-
Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above
examples.
In my personal opinion it is up to consumers to use the collected data to make their own decisions. Every Organization has their own
institutional idea of trust. They alone know which sources of information make sense for them, their management’s risk appetite, the verticals they operate in and so forth. The analysis that one Organization performs to come to the conclusion of ‘High’ risk
may actually be a ‘Low’ risk in another organization. Each Org must be ultimately responsible for its own analysis.
But, that’s not to say that they can’t outsource that function to other organizations. Dedicated third-parties specializing in analyzing
Sightings to extract TTPs and match those to Campaigns and Actors will become more prevalent. These third-party analysis services will provide analysis customized to the Organization’s structure/vertical/risk appetite which will help them extract the ‘why
and ‘how’ from the ‘what’.
I believe that the separate top-level Sighting object will provide us with the basic structure to begin the higher level analysis.
I believe that this will then help third-parties to generate more ‘upper-level’ STIX data – Threat Actors, Campaigns and higher-order TTP in particular.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Baker, Jon
Sent: Saturday, 24 October 2015 2:10 AM
To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting
The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the
related sightings use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.
At a high-level I think that we can talk about sightings in several ways:
There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case) each of the different
kinds of sightings and that we independently flesh out the information requirements.
At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us
to focus on developing a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting
what people already do today.
Thanks,
Jon
============================================
Jonathan O. Baker
J83D - Cyber Security Partnerships, Sharing, and Automation
The MITRE Corporation
Email:
bakerj@mitre.org
I definitely like the “state the use case first” approach here. We can’t implement a data design until we know what we plan on doing with it.
On the simplicity suggestion – YES!! Simple, simple, simple. We can always add fields later. Let’s just get this implemented, baked into our products,
and then we can see what we are missing.
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references
something and adds context like who saw it, date, etc…) or have a combined object that carries a count. The former will offer more flexibility, but will mean more object instances. The later is really just a summary of the former, which will be much smaller
from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
Personally, I favor flexibility. We can solve the size issue with technical implementation.
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.
1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff. Perhaps as I start documenting an issue I am seeing in my network
it could show a list of potential IOCs that match it. I could then:
a) click a button that says "share a sighting" or
b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.
2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then
query the repo to see if the IOC is already known. In either case, the device could emit a sighting.
While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object.. It is always easy to add stuff,
but it is really hard to take it away.
I would argue that the bare minimum we need is:
1) Reference to what it is we are sighting
2) The person / organization that is making the sighting
3) A count of the number of times it was seen.
Now yes, there is a LOT more things that COULD be added, and all of them could be added over time. For example (yes this will rub people the wrong way), data markings. I would personally leave them out for now. I would
love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.
By taking the minimalistic approach we can more quicker and get people using it.
"id": "foo.com:sighting-1234-1234-1234-1234",
"idref": "abc.com:indicator-4321-4321-4321-4321",
"producer": "tom and jerry"
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is
a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email
and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.