CTI STIX Subcommittee

Expand all | Collapse all

Need for Investigation/Tag object?

  • 1.  Need for Investigation/Tag object?

    Posted 10-27-2015 20:04
    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  


  • 2.  RE: Need for Investigation/Tag object?

    Posted 10-27-2015 21:30
      Hi!,   I totally support this idea as we are always running intelligence data through our environment and we don’t know whether or not we have something at the initial point.  Our final goal is to have a bi-directional relationship with our tooling and our CTI data repository so that as things happen they are being logged in our system.  If they turn out to be a dead-end, they are, otherwise they are fully qualified.  The intended result is that if we discover something and can share it (next to real-time), it helps those that are listening to our feed to be aware of the situation and monitor for it in their own environment.   I am thinking of things like telemetry from our DDoS probes, network abnormality systems and so forth.   Regards,   Dean   From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald Sent: Wednesday, 28 October 2015 7:04 AM To: Sarah Kelley; Unknown Unknown; Jordan, Bret Cc: Baker, Jon; Jonathan Bush (DTCC); Cory Casanave; cti-stix@lists.oasis-open.org Subject: [cti-stix] Need for Investigation/Tag object?   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   This e-mail and any attachments to it (the Communication ) is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together ANZ ). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.


  • 3.  Re: Need for Investigation/Tag object?

    Posted 10-27-2015 21:57
    Yes, this is vital and one of the key use cases we have identified for TAXII 2.0.  We need a way for researchers intra-org and inter-org to communicate what they are seeing and what they think before they actually know .  This is done today via email and IM, but it would be nice if STIX and TAXII could support this so APPs could be written to do it.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems 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.   On Oct 27, 2015, at 13:03, Terry MacDonald < terry@soltra.com > wrote: 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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail


  • 4.  Re: Need for Investigation/Tag object?

    Posted 10-28-2015 02:32
    The abstraction (construct) for Relationship discussed in github will help. The clarification of CybOX instances vs patterns also (observations of events without full context yet) I think On Wednesday, 28 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: Yes, this is vital and one of the key use cases we have identified for TAXII 2.0.  We need a way for researchers intra-org and inter-org to communicate what they are seeing and what they "think" before they actually "know".  This is done today via email and IM, but it would be nice if STIX and TAXII could support this so APPs could be written to do it.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems 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."  On Oct 27, 2015, at 13:03, Terry MacDonald < terry@soltra.com > wrote: 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


  • 5.  RE: Need for Investigation/Tag object?

    Posted 10-28-2015 10:42
    Not sure if this is the same thing, but could a similar use-case in TAXII 2.0 be for inquiries?  For example, “Have you (the target) seen this IP address?” (implying that I think it might be bad)  It isn’t about an event, but about something that the sender is concerned is about to be an event.   From: Jordan, Bret [mailto:bret.jordan@bluecoat.com] Sent: Tuesday, October 27, 2015 5:57 PM To: Terry MacDonald Cc: Sarah Kelley; Unknown Unknown; Jon Baker - MITRE; Bush, Jonathan; Cory Casanave; cti-stix@lists.oasis-open.org Subject: Re: Need for Investigation/Tag object?   Yes, this is vital and one of the key use cases we have identified for TAXII 2.0.  We need a way for researchers intra-org and inter-org to communicate what they are seeing and what they "think" before they actually "know".  This is done today via email and IM, but it would be nice if STIX and TAXII could support this so APPs could be written to do it.    Thanks,   Bret       Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems 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."    On Oct 27, 2015, at 13:03, Terry MacDonald < terry@soltra.com > wrote:   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   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.


  • 6.  Re: [cti-stix] Need for Investigation/Tag object?

    Posted 10-29-2015 20:53
    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


  • 7.  RE: [cti-stix] Need for Investigation/Tag object?

    Posted 10-30-2015 11:24




    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






  • 8.  RE: [cti-stix] Need for Investigation/Tag object?

    Posted 10-30-2015 23:22




    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






  • 9.  Re: Need for Investigation/Tag object?

    Posted 10-31-2015 08:50
    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


  • 10.  Re: Need for Investigation/Tag object?

    Posted 10-31-2015 08:55
    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 >> >> >> >>


  • 11.  Re: [cti-stix] Need for Investigation/Tag object?

    Posted 11-01-2015 22:55
    Terry, I really like this and it follows my mental model of how I do investigations.  Thanks for putting it to paper.  This type of use case that is grounded in real workflow is very helpful. Bret  Sent from my Commodore 64 On Oct 30, 2015, at 6:22 PM, 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


  • 12.  Re: [cti-stix] Need for Investigation/Tag object?

    Posted 11-06-2015 19:46
    Hi Terry, Apologize for jumping in late. The email got buried and I just got to it. Thanks for putting together the use case. +1 on the cool ASCII art!  The 'investigation’ object for grouping related information during the investigation process makes complete sense. In fact this was exactly what I was envisioning in my mind and I’m glad you called it out that way. This would help automate the journal entry process that analysts need to maintain on a day to day basis. I would like to add a few points here: Investigation is done during in the detection phase to determine if there has been a breach A series of Investigative actions are done during the incident response process to gather further information on the  affected assets such as WhoIs (the user for the asset), geolocation information, other assets of the user, who all did the asset communicate with etc. This information helps  determine the response actions needed. After incident response, some monitoring/investigation is done to determine if the response worked as desired before the incident is closed.  The investigation activities during and post  IR could either be captured in the ‘investigation’ object or be used to enrich the incident  object. Thoughts? Thanks, Jyoti From: < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Date: Friday, October 30, 2015 at 3:22 PM To: "Davidson II, Mark S" < mdavidson@mitre.org >, "Jane Ginn - jg@ctin.us " < jg@ctin.us >, " Sarah.Kelley@cisecurity.org " < Sarah.Kelley@cisecurity.org >, Jerome Athias < athiasjerome@gmail.com >, Bret Jordan < bret.jordan@bluecoat.com > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Need for Investigation/Tag object? 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


  • 13.  Re: [cti-stix] Need for Investigation/Tag object?

    Posted 11-20-2015 05:41
    in case it could help to illustrate the topic: http://blog.sqrrl.com/the-threat-hunting-reference-model-part-3-the-hunt-matrix /JA "Education is the most powerful weapon which you can use to change the world.", Nelson Mandela 2015-11-06 22:46 GMT+03:00 Jyoti Verma (jyoverma) <jyoverma@cisco.com>: > Hi Terry, > > Apologize for jumping in late. The email got buried and I just got to it. > Thanks for putting together the use case. +1 on the cool ASCII art! > The 'investigation’ object for grouping related information during the > investigation process makes complete sense. In fact this was exactly what I > was envisioning in my mind and I’m glad you called it out that way. This > would help automate the journal entry process that analysts need to maintain > on a day to day basis. I would like to add a few points here: > > Investigation is done during in the detection phase to determine if there > has been a breach > A series of Investigative actions are done during the incident response > process to gather further information on the affected assets such as WhoIs > (the user for the asset), geolocation information, other assets of the user, > who all did the asset communicate with etc. This information helps > determine the response actions needed. > After incident response, some monitoring/investigation is done to determine > if the response worked as desired before the incident is closed. > > > The investigation activities during and post IR could either be captured in > the ‘investigation’ object or be used to enrich the incident object. > Thoughts? > > > Thanks, > > Jyoti > > > From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald > <terry@soltra.com> > Date: Friday, October 30, 2015 at 3:22 PM > To: "Davidson II, Mark S" <mdavidson@mitre.org>, "Jane Ginn - jg@ctin.us" > <jg@ctin.us>, "Sarah.Kelley@cisecurity.org" <Sarah.Kelley@cisecurity.org>, > Jerome Athias <athiasjerome@gmail.com>, Bret Jordan > <bret.jordan@bluecoat.com> > Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > > Subject: RE: [cti-stix] Need for Investigation/Tag object? > > 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 > > > >


  • 14.  Re: [cti-stix] Need for Investigation/Tag object?

    Posted 11-01-2015 17:36
    Mark & All: OK, I took a first cut at it at the LOW level of abstraction Use Case for the Machine-to-Human interface.  Here is a link the textual description on the Wiki.  https://github.com/STIXProject/use-cases/wiki/Use-Case:-Analyzing-Cyber-Threats-in-Real-Time-----Machine-to-Human I'll also put together a Use Case Diagram to supplement the Use Case Description and upload it there.  Edits and refinements welcome. Jane Ginn jg (at) ctin.us CTIN On 10/30/2015 4:24 AM, Davidson II, Mark S wrote: 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