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 https://github.com/defpoint/threat_note/issues/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 https://github.com/defpoint/threat_note/issues/137#issuecomment-183799563 .

[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 https://github.com/defpoint/threat_note/issues/137#issuecomment-183805951 .