[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]
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 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
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]
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
Follow us @CISecurity
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]