Notes from 28 August Working Call

Hey all,

Here are the raw notes from the call today. Thanks for attending!

If you think I captured something incorrectly or missed something please respond and correct it.

John

Participants

==================

- Rich Struse

- Sarah Kelley

- Allan Thomson

- Chris Ricard

- Drew Varner

- Gary Katz

- Ivan Kirillov

- Jason Keirstead

- John-Mark Gurney

- Richard Struse

- Sean Barnum

- Trey Darley

- Jeff Mates

Notes

==================

- Update on WD03

- Question from Bret: Wanted to clarify that we're only rolling back the changes to the properties (confirmed by Sarah)

- Point from Bret: We're not pointing to any particular profile of the RFC for language codes. He will be making a suggestion in the document.

- Update on TAXII. CSD ballot will be opened at the same time as the STIX CSD ballot

- Question from Trey: What's the status of pagination in WD03. Bret: pagination is removed, will be resolved in WD04. Trey suggests that we note status of pagination in ballot text.

- Jason: commented because he wasn't sure that pagination was removed and wanted to confirm. Bret confirmed.

- Infrastructure

- Sarah reviewed the agenda and started walking through the Infrastructure use cases doc

- Walking through the types of intel products that reference infrastructure

- Allan: we should stop calling things automated vs. not automated. We should just focus on the data and whether it's automated is redundant.

- Several people concurred

- Sean: Was wondering why we were calling things products rather than use cases. We clarified a bit, perhaps some imprecise usage of terms.

- Allan: The intent is to capture use cases to help us make sure we do what we need to. So, these might not be exhaustive but should be representative.

- Walking through use cases

- Bret: need to add a use case for classifying/altering things by those other than the original producer

- It needs to be relationships to other stix objects vs. a lot being embedded

- Infrastructure types

- (no comments)

- Discussion questions

- Sarah asked Bret to clarify what he means by level of maliciousness

- Bret: was really meant to capture how bad it is

- Trey: commented that maliciousness could leverage assertion

- Allan: maliciousness may be a function of what the infrastructure is used for

- John: need to make sure we can also capture some conception of whether it's our infrastructure or theirs

- Rich: it gives him pause, because he worries about straying into asset management. It may be useful to represent, but is it useful for us to do that in STIX.

- Sean: Thinks that yes, it probably does, in particular because you want to share targeting information for shared blue assets.

- Gary: agrees with both Sean and Rich. Wants to make sure we're not overengineering for the initial release, but also covers these important use cases. When we talk about level of maliciousness, etc. we get into some level of time analysis.

- Sean: there's value in doing the blue side, but some of these things (level of maliciousness, temporality, etc.) should be done via relationships

- Bret: doesn't want to get into the information model but it may come by default w/ the assertion object, timestamps added to relationship object, relationships to observed data, etc.

- Sean: thinks it's important to think of a separation between the actual thing, what it's built up to, and what it's being used for / who's using it. Things can change over time. It's important to note that the abstraction of what infrastructure is may change over time (IPs go in and out, bots go in and out)

- Sarah: this also relates to the question about whether an end-to-end infrastructure is just one big lump or is distinct pieces

- Sean: it's not a black and white decision - but there are ways to lump things together

- Sarah: also applies when you try to link it to other objects - which part of the infrastructure are they linked to

- Bret/Sean: we need to make sure we allow people to do what they need - can't prevent people from doing dumb things

- Proposal walkthrough

- Sarah walked through stuff from the playground

- Sarah brought up the description saying that it's explicitly malicious infrastructure

- Bret: can probably just soften the language

- Sean: doesn't make sense to have kill chain phases included here. Really it's an actor using it in some certain way.

- Jeff: in favor of keeping kill chain phases in. If we externalize observed data, because you can then create relationships where those phases are correct

- Sean: but then you lose the ability to tell how it's real - what it was used for by which party

- Jeff: disagrees...you can record first/last time to scope to kill chain phase. Then link to owner via relationship.

- Sean: first/last seen is the infrastructure overall...not the specific usage of that infrastructure for some purpose

- Jeff: or is it describing first/last seen _for this purpose_

- Gary: these seem like two different concepts of how infrastructure can be used. If infrastructure object encodes the purpose itself, it changes the need to externalize some aspects of this via relationships

- Jason: he's in the same camp as Jeff. In that the key difference between infrastructure and observation is that the infrastructure is the meta-level object that describes what's behind the IP

- Trey: if you have external references to observed data then you have potentially 10 parties saying this IP was XYZ.

- Bret: doesn't agree with observable details being embedded in the object

- Allan: conceptually, the sighting object provides a good structure for this. A pointer to observations, first seen/last seen, name. It also has a relationship to indicators, which depending on the kill chain and when you observed it you may want to have associated indicators. Doesn't think we need to re-use the actual object, just pattern this one off of that one.

- Sean: now totally confused. are people proposing that there's no infrastructure object?

- Allan: no, misunderstood. We should use the same pattern as we used for sighting for this. Or add a property to sighting to say that the sighting is an infrastructure

- Sarah: but sightings are a relationship object

- Allan: gets that but thinks we can still use it

- Sean: doesn't really see the overlap with sighting

- Jason: needs to think about it more. you have sightings of infrastructure, so how can infrastructure be a sighting.

- Allan: sighting provides optionality for observation and pointers to indicators/etc. The key point is you can just use the required stuff (ignore optional) and use that object.

- Bret: likes what Jeff said and how Gary phrased it. Historically when we've gotten into the mud it's been best to model this out in STIX and figure out where things fall.

- Sarah: we've added timestamps to relationships, so we now have that ability e.g. for use relating it to observed data

- Vocab topics

- Bret: pick top 5-8 that we need. we can add more later.

- Relationship topics

- Sean: doesn't understand how infrastructure targets vulnerabilities

- Jeff: could be valid...e.g. and IP address doing scanning or sending malicious packets

- Sean: but the infrastructures not targeting it, some software is

- Jeff: but what if you don't know what the software is

- Bret: make suggestions in document please

- Rich

- Thanks everyone for the turnout, tone, respect, etc.

Chatlog

==================

From Jason Keirstead to Everyone: (03:07 PM)

We're rolling back the optional property change so we can get CSD01 out, and continue to figure out what we want to do for the use cases in CSD02, right?

From Me to Everyone: (03:08 PM)

Yes

Sorry, that was meant for Jason

From Drew Varner to Everyone: (03:10 PM)

Item based pagination was removed from this version of the specification

Under â1.7.1â TAXII 2.1 Major Changes and Additions

From Sarah Kelley to Everyone: (03:15 PM)

https://docs.google.com/document/d/10j6BKbGb38UhDEh4QdmQfFCnZhQgeRMcAa20IqejbGQ/edit#heading=h.xfx90dck7dn5

From Jason Keirstead to Everyone: (03:18 PM)

DGA as would be communicated would be the algorithm not the domain list

From Sarah Kelley to Everyone: (03:18 PM)

but how would you capture that? Patterning?

From Jason Keirstead to Everyone: (03:18 PM)

But I am not sure how we would capture it

outside plain text

From Allan Thomson to Everyone: (03:19 PM)

actor X used DGA domain efefeijfiejfiejf to send a spear-phishing campaign YYY

From Jason Keirstead to Everyone: (03:23 PM)

@atslack Yeah but DGA domains change every minute/hour. What you'd want to share is the algorithm.

From Allan Thomson to Everyone: (03:23 PM)

if you knew it

in some cases you might now know it but you know that its a DGA

From Jason Keirstead to Everyone: (03:23 PM)

True.

From Allan Thomson to Everyone: (03:23 PM)

not know it

From Jason Keirstead to Everyone: (03:24 PM)

I am not even sure DGA is "infrastructure"

DGA would be a fancy indicator

From Allan Thomson to Everyone: (03:24 PM)

its both

but infrastructure is actually that in many cases not just DGA

From Jason Keirstead to Everyone: (03:24 PM)

Well the infrastructure is not the domain its the thing behind it.

From Allan Thomson to Everyone: (03:25 PM)

its a good reminder to be clear on what is being conveyed by infrastructure cause other things âcouldâ convey some of it.

From Trey Darley to Everyone: (03:25 PM)

If you knew the algorithm and were willing to share it. I could also see intel providers sharing potential domains from a DGA apart from the actual algorithm to protect their sources and methods.

From Allan Thomson to Everyone: (03:26 PM)

agreed

From Trey Darley to Everyone: (03:26 PM)

Congratulations, Gary!

From Jason Keirstead to Everyone: (03:27 PM)

I am just struggling with the value of sharing specific domains from a DGA as they literally have a shelf life of hours... its like the very bottom tier of the pyramid.

From Trey Darley to Everyone: (03:28 PM)

A list of potential DGA domains is more actionable for low-maturity orgs than the actual DGA algorithm.

From Jason Keirstead to Everyone: (03:28 PM)

BY the time the org gets the domain and blocks it or searches for it, its now going to be something else

From jordan to Everyone: (03:30 PM)

But you could do retrospective analysis to see if any of your machine have talked to it

From Jason Keirstead to Everyone: (03:33 PM)

I suppose..

From jordan to Everyone: (03:34 PM)

We do this today and have tools to do it. :)_

From Jason Keirstead to Everyone: (03:34 PM)

We do it too... but we also have the ML based DGA detection which is way better :P

From Allan Thomson to Everyone: (03:35 PM)

i do stupid things all the time :-)

From Me to Everyone: (03:39 PM)

Thatâs a really good point Sean - agree that kill chain phases doesnât belong on the object directly.

From sean.barnum to Everyone: (03:39 PM)

I agree that the relationships to observables should be external

From jordan to Everyone: (03:47 PM)

I see infrastructure more like malware than anything else

From Jeff Mates to Everyone: (03:49 PM)

I see similarities in terms of properties, but it gives direct context at a time without relating to another object.

From Gary to Everyone: (03:49 PM)

does anyone else feel that we may need a theologian to help with this discussion?

From Gary to Everyone: (03:50 PM)

does the infrastructure exist if there is no sighting of it? I think therefore I am

From Allan Thomson to Everyone: (03:51 PM)

thats kinda my point

theyâre interrelated

From Jason Keirstead to Everyone: (03:51 PM)

If an infrastructure falls over in the woods and there is no sighting of it, does it make a sound?

Wait...

From Trey Darley to Everyone: (03:54 PM)

Gary, is FireEye currently recruiting a theologian? If so, I may be able to refer a few candidates. 👻

From Me to Everyone: (03:55 PM)

We really need to get more likeâuser storiesâfor how folks are using infrastructure. Take the use cases down a level of abstraction. The problem with modeling real reports is that theyâre all static, so we can start w/ those but Iâm not sure itâs sufficient to just take some PDFs and STIXify them

From jordan to Everyone: (03:55 PM)

Lets just add the top 5-8 that we absolutely know we need

And then just add more later on

From jordan to Everyone: (03:56 PM)

@John that is what we would do in the product space, but consensus based bodies have a hard time understanding user stories

User stories usually depend on how a users is going to use a product.

cti message