Re: Need for Investigation/Tag object?

[Jerome Athias <athiasjerome@gmail.com>]

my bad in "What is an Event in STIX?
Not defined."
To clarify, it is at CybOX level
https://stixproject.github.io/data-model/1.2/cybox/EventType/

2015-10-31 11:50 GMT+03:00 Jerome Athias <athiasjerome@gmail.com>:
> Gotcha
>
> now...
>
> What is an Event in STIX?
> Not defined.
>
> So for me at this stage, it is currently restricted to the Observation
> ('Observable patterning') of "something happened" (Indicator) to (e.g.
> change of the current state of) an Observable (instance).
>
> What is an Incident in STIX?
> "Incidents are discrete instances of Indicators"
> Ref. https://stixproject.github.io/data-model/1.2/incident/IncidentType/
> Meaning, 'something bad happened'
>
> Because of the use of the Indicator concept, basically STIX is
> focused/restricted on 'bad things/events'.
>
> So now, if you compare the STIX Incidents Status vocabulary:
> https://stixproject.github.io/data-model/1.2/stixVocabs/IncidentStatusVocab-1.0/
> to, for example, the "status" enumeration (for a document) in IODEFv2
> (RFC5070bis)
> https://www.ietf.org/id/draft-ietf-mile-rfc5070-bis-15.txt
>
>    status
>       Optional.  ENUM.  The status attribute conveys the state in a
>       workflow where the incident is currently found.  These values are
>       maintained in the "Incident-status" IANA registry per Table 1.
>       This attribute is defined as an enumerated list:
>
> <snip>
>
>       2.  in-progress.  The contents of this document are under
>           investigation.
>
> <snip>
>
> So, I do understand that you don't want to create an Incident while you're
> not sure that your Observation ('Observable patterning' <== change that
> please! Where is Event?...) is 'malicious'.
>
> So what you can do, with current version of STIX (so without the
> PackageIntentVocab because deprecated), is to specify "Observations"
> ("Report is intended to convey mainly information about instantial
> observations (cyber observables)." as the ReportIntent of a Report.
>
> Not convenient or clear? Yep, maybe.
> Does "in-progress" or "under investigation" at the Observation level would
> be better?
> I would think so.
> But now...
>
> What is an Observation in STIX?
>
>
>
> On Saturday, 31 October 2015, Terry MacDonald <terry@soltra.com> wrote:
>>
>> Hi Mark,
>>
>>
>>
>> Sure… although TBH I’m not that happy with the current STIX v2 Use Case
>> structure on the wiki. To my mind it focuses on STIX and the ways it can be
>> used, when we should actually be focussing on the way that Threat
>> Intelligence can be used and documenting those use cases at the CTI TC level
>> – then deriving STIX/TAXII/CybOX requirements from that as a separate step.
>> But that’s a different discussion…..
>>
>>
>>
>> THE USE CASE IN STIX USE CASE WIKI FORMAT
>>
>>
>>
>> STIX v2.0 Use Case: Performing an Investigation
>>
>>
>>
>> Relevant to which SCs (STIX/TAXII/CybOX): STIX
>>
>>
>>
>> Abstraction Level (High, Medium or Low): Yes?
>>
>>
>>
>> Related Use Cases: Um?
>>
>>
>>
>> Description:
>>
>> Incident Handlers and Security Operations Centre monitoring staff are
>> constantly looking for unusual/suspicious events. These suspicious events
>> are ‘odd things that require further investigation’. A large percentage of
>> the time the investigation shows that the events are false positives of some
>> kind. A JPEG with a series of 0x9090909090 within it may trigger a rule
>> looking for x86 NOOP slides. Multiple failed SSH attempts against your
>> internal Cisco terminal server may in fact be a misconfigured script
>> somewhere. Not everything is malicious.
>>
>>
>>
>> Incident Handlers often operate with the following workflow (cool ASCII
>> art!):
>>
>>
>>
>> event/alert raised -> investigation opened -> investigate/analyze ->
>> official incident opened -> IR process
>>
>>                                                        |
>>
>>                                                        V
>>
>>                                                false positive ->
>> investigation closed
>>
>>
>>
>> Often, as part of the ‘investigate/analyse’ step in the ASCII diagram
>> above we ask threat sharing groups if they have information that may help us
>> with our analysis. We try and find confirmation that something is bad is
>> happening – something that will require us to wake up 10 people in the
>> middle of the night to form the Virtual Incident Response Team. STIX would
>> be SOOOOOO much more useful if we had the ability to request information
>> about a sighting before we create an Incident and yet still allow us to
>> ‘track’ it somehow without us needing to declare a full official ‘Incident’.
>>
>>
>>
>> Incidents are only created when we have confirmed something is happening.
>>
>>
>>
>> That’s where the investigation/tag object comes in. Being able to link the
>> objects to the Investigation object would allow us to track the objects
>> related to the investigation when we are unsure if they are malicious, and
>> then easily create an Incident when we confirm that they are. This then also
>> means that the Incident can have a 1:1 relationship with the official
>> Incident in the Organizations ticketing system, making it far easier to
>> integrate STIX Incidents with the corporate ticketing system in the long
>> term.
>>
>>
>>
>> ----
>>
>>
>>
>> In addition, while doing the daily hunting through proxy logs looking for
>> weirdness, one could find a strange URL pattern that we’ve never seen
>> before. It could easily be Symantec’s live update doing some weird
>> liveupdate stuff, or it could be a new piece of malware. If we then search
>> and find 25 other hosts on the internal network with the same pattern, we
>> want a way to link those together. That’s where the investigation/tag object
>> comes in. We could share out the examples of 25 URLs we’ve found to our
>> community with a STIX request, and could receive 10 STIX responses back with
>> more details about others who have experienced the same problem. They may
>> have extra information about what they’ve found or not, but in either case
>> that information then helps us with our investigation. They may even send us
>> their own investigation object or Incident which can all help us in our
>> investigation.
>>
>>
>>
>> Stakeholders/Goals: To
>>
>>
>>
>> ·         Stakeholder: Incident Handlers
>>
>>
>>
>> o   Goal: Group together ‘possibly’ related STIX objects so that initial
>> triage can be done.
>>
>>
>>
>> Preconditions:
>>
>>
>>
>> ·         Depends on STIX v2 Sighting object
>>
>>
>>
>> Dependencies:
>>
>> ·         Depends on proposed STIX v2 Request object
>>
>> ·         Depends on proposed STIX v2 Response object
>>
>> ·         Depends on STIX v2 Sighting object
>>
>>
>>
>> Main Success Scenario:
>>
>> ·         Incident Handlers are able to perform investigations and send
>> out requests for more information about investigations before they turn into
>> official Incidents.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Terry MacDonald
>>
>> Senior STIX Subject Matter Expert
>>
>> SOLTRA | An FS-ISAC and DTCC Company
>>
>> +61 (407) 203 206 | terry@soltra.com
>>
>>
>>
>>
>>
>> From: Davidson II, Mark S [mailto:mdavidson@mitre.org]
>> Sent: Friday, 30 October 2015 10:24 PM
>> To: Jane Ginn - jg@ctin.us <jg@ctin.us>; Terry MacDonald
>> <terry@soltra.com>; Sarah.Kelley@cisecurity.org; Jerome Athias
>> <athiasjerome@gmail.com>; Bret Jordan <bret.jordan@bluecoat.com>
>> Cc: cti-stix@lists.oasis-open.org
>> Subject: RE: [cti-stix] Need for Investigation/Tag object?
>>
>>
>>
>> Terry, Jane, (and perhaps Jyoti),
>>
>>
>>
>> Would you be able to describe the use case a little more? I’m thinking
>> along the lines of what’s been started on the STIX use cases wiki [1] –
>> nominally including a description and a main success scenario. That would
>> help me understand who takes which actions when and in what order, which in
>> turn would help me form an opinion about how well proposed solutions meet
>> the use case.
>>
>>
>>
>> At the data model level, this sounds like a possible use of a top level
>> relationship object. Just throwing something against the wall here (I’m not
>> a cyber analyst and I don’t play one on TV), but could this use case be
>> accomplished by relating multiple objects to a campaign with a low
>> confidence?
>>
>>
>>
>> Thank you.
>>
>> -Mark
>>
>>
>>
>> [1] https://github.com/STIXProject/use-cases/wiki
>>
>>
>>
>> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
>> On Behalf Of Jane Ginn - jg@ctin.us
>> Sent: Thursday, October 29, 2015 4:53 PM
>> To: terry@soltra.com; Sarah.Kelley@cisecurity.org; Jerome Athias
>> <athiasjerome@gmail.com>; Bret Jordan <bret.jordan@bluecoat.com>
>> Cc: cti-stix@lists.oasis-open.org
>> Subject: Re: [cti-stix] Need for Investigation/Tag object?
>>
>>
>>
>> Terry & All:
>>
>> This is an actual Use Case that I've seen operationally in one of the
>> ISAOs I participate in. It is not theoretical. .. and the real-time nature
>> of this helps the non-targeted members of the ISAO to take proactive actions
>> in response to what is known (shared) about the Threat Actor, the IoCs, and
>> the TTPs. Offensive countermeasures in action.
>>
>> I could see this Use Case evolving into a very important one for driving
>> adoption of threat intel platforms... especially if the CybOX objects are
>> extracted, used in other tools for enrichment, then reconstructed as STIX
>> again. Thus later permutation aligns with the Use Case Jyoti introduced in
>> the CybOX Subcommittee call today.
>>
>> Jane Ginn, MSIA, MRP
>> Cyber Threat Intelligence Network, Inc.
>> jg@ctin.us
>>
>>
>>
>> -------- Original Message --------
>> From: Terry MacDonald <terry@soltra.com>
>> Sent: Tuesday, October 27, 2015 01:03 PM
>> To: Sarah Kelley <Sarah.Kelley@cisecurity.org>,Unknown Unknown
>> <athiasjerome@gmail.com>,"Jordan, Bret" <bret.jordan@bluecoat.com>
>> Subject: [cti-stix] Need for Investigation/Tag object?
>> CC: "Baker, Jon" <bakerj@mitre.org>,"Jonathan Bush (DTCC)"
>> <jbush@dtcc.com>,Cory Casanave
>> <cory-c@modeldriven.com>,"cti-stix@lists.oasis-open.org "
>> <cti-stix@lists.oasis-open.org>
>>
>> Hi All,
>>
>>
>>
>> Sarah’s email below reminded me of some thoughts that have been bubbling
>> around for a while.
>>
>>
>>
>> I think there is a need for us to support describing and sharing Threat
>> intelligence while it is still under investigation. Historically STIX has
>> been used by Organizations who are generally sharing information about
>> attacks after they have finished. It seems to me that we are rapidly moving
>> towards an automated future where Organizations are sharing information
>> about attacks while they are happening. This change is a subtle one, but one
>> that has implications for STIX.
>>
>>
>>
>> At present we have no way for an Organizations to temporarily ‘group’
>> different STIX objects together. When one is conducting an investigation
>> into a series of suspicious events prompted by your Organization’s
>> monitoring processes, we often want to tag/relate these events together,
>> without actually creating an official ‘Incident’ (as we’re not sure anything
>> has actually happened yet). The Incident object is where one would put the
>> information when it is confirmed there is a problem, but I believe we at
>> least need a way of ‘tagging’ and ‘grouping’ potentially related items
>> together.
>>
>>
>>
>> Does anyone else see the need for something like this?
>>
>>
>>
>> Cheers
>>
>>
>>
>> Terry MacDonald
>>
>> Senior STIX Subject Matter Expert
>>
>> SOLTRA | An FS-ISAC and DTCC Company
>>
>> +61 (407) 203 206 | terry@soltra.com
>>
>>
>>
>>
>>
>> From: Sarah Kelley [mailto:Sarah.Kelley@cisecurity.org]
>> Sent: Tuesday, 27 October 2015 10:18 PM
>> To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret
>> <bret.jordan@bluecoat.com>
>> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>;
>> Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave
>> <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org
>> Subject: Re: [cti-stix] Conceptul model for sighting
>>
>>
>>
>> I am a huge proponent of letting (almost) anything link to anything. In
>> fact, limiting what can have an association/link/relationship with what is
>> my current biggest frustration with Stix (we use workarounds to get around
>> this limitation).
>>
>>
>>
>> I would add the possible use cases:
>>
>>
>>
>> My org observed 3 instances of this threat actor hitting our network
>>
>> My org observed 12 instances of the Poison Ivy TTP on our network
>>
>> Or even (though weaker):
>>
>> My org was hit by this particular campaign 27 times
>>
>>
>>
>>
>>
>>
>>
>> Sarah Kelley
>>
>> Senior CERT Analyst
>>
>> Center for Internet Security (CIS)
>>
>> Integrated Intelligence Center (IIC)
>>
>> Multi-State Information Sharing and Analysis Center (MS-ISAC)
>>
>> 1-866-787-4722 (7×24 SOC)
>>
>> Email: cert@cisecurity.org
>>
>> www.cisecurity.org
>>
>> Follow us @CISecurity
>>
>>