Add Aliases Field

[sroberts]

So I hate making DB changes, but I think it'd be nice to have a method to track aliases for actors. Between CrowdStrike animal names, APT[0-40] Mandiant/FireEye names, something clever from Kaspersky, common names, internal names, etc it becomes really hard to keep track.

I actually think this might be most easily done as a foreign key to a secondary table and only exposing it for actors. Thoughts?

[swannysec]

I think this makes sense. Adding it for Campaigns would probably be wise as
well.
On Feb 13, 2016 10:09 AM, "Scott J. Roberts" notifications@github.com
wrote:

So I hate making DB changes, but I think it'd be nice to have a method to
track aliases for actors. Between CrowdStrike animal names, APT[0-40]
Mandiant/FireEye names, something clever from Kaspersky, common names,
internal names, etc it becomes really hard to keep track.

I actually think this might be most easily done as a foreign key to a
secondary table and only exposing it for actors. Thoughts?

—
Reply to this email directly or view it on GitHub
#137.

[alxhrck]

Seems like it's time for a few database changes. It would also be good to move Relationships to its own table and add a field to Indicators that can hold additional attributes.

[sroberts]

@alxhrck I agree more. Maybe we should talk through a new DB schema, all get into agreement, so we can make a unified set of changes that meet everyone's needs instead of breaking it multiple times.

[brianwarehime]

I agree as well. I'm all for a little round table discussion on this to lay out the plans.

On Sat, Feb 13, 2016 at 6:13 PM -0800, "Scott J. Roberts" notifications@github.com wrote:

@alxhrck I agree more. Maybe we should talk through a new DB schema, all get into agreement, so we can make a unified set of changes that meet everyone's needs instead of breaking it multiple times.

—
Reply to this email directly or view it on GitHub.

[swannysec]

One thing I've mentioned before is the concept of automatic indicator
population with automatic relationships. In essence, if you input an
indicator and an integration pulls back a slew of related hashes or pDNS
entries, allow the user to check a box or something similar and
"auto-create" those items as new indicators tied to the original entry.
I'm not really certain if this is feasible, but if so, it might be
something to consider as architectural changes are discussed.

On Sat, Feb 13, 2016 at 9:20 PM, Brian Warehime notifications@github.com
wrote:

I agree as well. I'm all for a little round table discussion on this to
lay out the plans.

On Sat, Feb 13, 2016 at 6:13 PM -0800, "Scott J. Roberts" <
notifications@github.com> wrote:

@alxhrck I agree more. Maybe we should talk through a new DB schema, all
get into agreement, so we can make a unified set of changes that meet
everyone's needs instead of breaking it multiple times.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#137 (comment)
.

[sroberts]

@swannysec So that one gets dangerous to me, and goes hand in hand with the idea of caching some of the enrichment stuff. Any time you look up an indicator with a 3rd party source you're leaking some amount of data (not to mention there may be quotas/timing such as VirusTotal). I think we need to be really careful automatically pulling data for folks.

That said I think the core idea and being able to pivot on data is key to the whole project. It just needs to be discussed/mapped.

[swannysec]

No argument there. I think adding a control on enrichment is wise! I'd
just like to see indicator creation from voluntary enrichment
semi-automated. I still think some way of allowing the user to choose
which enriched indicators to "auto-create" is important though. Could also
put them through some sort of filter if IPs/domains (Alexa Top X for
instance) before allowing auto-creation.

On Sat, Feb 13, 2016 at 9:46 PM, Scott J. Roberts notifications@github.com
wrote:

@swannysec https://github.com/swannysec So that one gets dangerous to
me, and goes hand in hand with the idea of caching some of the enrichment
stuff. Any time you look up an indicator with a 3rd party source you're
leaking some amount of data (not to mention there may be quotas/timing such
as VirusTotal). I think we need to be really careful automatically pulling
data for folks.

That said I think the core idea and being able to pivot on data is key to
the whole project. It just needs to be discussed/mapped.

—
Reply to this email directly or view it on GitHub
#137 (comment)
.