oliverfriedrichs at gmail.com
Thu Feb 23 12:54:10 EST 2017
Since I’m on this list and rarely get to contribute it seems like a good time to jump in (although Phantom coincidentally almost started by focusing on offense – google “Phantom Access” if you are curious where the name came from): https://en.wikipedia.org/wiki/Phantom_Access. I’m sure Dave is happy about that since who needs more offense vendors. :-)
Obviously I am biased, but IMO automation and orchestraton is one of the few new technologies to arrive in our industry in quite some time. Is it new? Obviously not.. in fact back at McAfee in 1999 we tried to build something like this, funny enough it was covered in an article by Stuart McClure on Adaptive Security back then: https://books.google.com/books?id=2lEEAAAAMBAJ&pg=PA78.
That being said, the industry “forgot” about this stuff for almost 15 years. It took NSA and DHS to resurrect this through a project they funded at JHU APL called IACD: https://secwww.jhuapl.edu/iacdcommunityday/PreviousEventMaterial. At the same time, everyone was cobbling together scripts to do most of this themselves without much formality.
Anyways, enough of a history lesson. The fact is that everything has gotten worse to the point where automating standard operating procedures in order to augment human analysts is now a necessity.. no longer optional. Whether you do it by building or buying, it’s clear that tying together the hundreds of discrete security products into a cohesive system is an obvious and natural evolution of the industry.
We run into companies all of the time who are deciding to build or buy.. usually web scale companies decide to build, because they have the engineers to do so and can put a team together in days.. but most “normal” commercial enterprises don’t have this luxury. That being said, a COTS solution lets you get straight to building your Playbooks, and not becoming a plumber. Nothing again plumbers.. but who wants to write API integrations for hundreds of security products, maintain then, keep them up to date, etc. In addition there is all of this typical enterprise stuff: reporting, AD integration, secure credential storage, penetration testing the solution, scalability, auditing, out of the box connectors, RBAC, TFA integration, revision control, an IDE, human prompting,
After connecting with over 120 other security products now I found that most vendors are open and easy to deal with and dozens are now even writing Apps to contribute to the platform. Frankly I’ve only run into a few, who are also trying to build products this category, who are protective of their APIs (FireEye and Proofpoint). Their belief is that by being closed with their APIs they can somehow sell more product since open APIs make their products too replaceable. It’s interesting to see that behavior.. and the belief that protecting “APIs” is some kind of competitive advantage. In those cases it’s usually users who write the Apps to connect to their APIs anyways.. since the user is the one who needs it.
On 2/16/17, 10:49 AM, "J. Oquendo" <dailydave-bounces at lists.immunityinc.com on behalf of joquendo at e-fensive.net> wrote:
On Wed, 15 Feb 2017, Wim Remes wrote:
> Isn't this what Phantom and other "security orchestration" companies are
> pushing right now?
> The biggest roadblock is that every traditional security vendor is trying
> to be the "data hub", hoarding information. Badly constructed and horribly
> documented APIs, stupid myopic dashboards, rate limiting on APIs, etc. etc.
> are the trademarks of those data hoarders. I wonder how long it takes
> before they realize they're contributing more by becoming data providers.
> Hell, every RFP for security products should score their ability to provide
While bored (which is often) I rigged together quite a few
applications into a suite of my own to go out, aggregate,
then correlate, then go back out, and see what exactly are
threats, and what are not. E.g. How many of us have tried
to ping a site, or ssh somewhere, and fat-fingered (sorry
all couldn't find politically correct term) an address?
E.g. ssh 220.127.116.11 when it should have been 10.0.0.1. Now
imagine the amounts of data caught in the "cross fire."
What I sought to do what take data and find out why exactly
are causing say 18.104.22.168 (example) to be re-aggregated into
threat lists. Too many "threat" lists with little info
to go by. What I found over time was even stranger... Not
naming names, but 90+% of "threat" vendors cross correlate
the same nonsense/pollution into a smorgasbord of: "OMG
your mom is a threat" alerting.
Hoarding data is meaningless if terabytes of the data being
captured is insignificant. I have been playing with IBM's
Watson so sooner or later when I am even more bored than I
am, I will dump terabytes and say: "Go make sense of this."
To be honest, the Watson Analytics side could not do this
as good as I connected my own dots with i2 Analyst Notebook
so who knows what AI Watson will push out. (Maybe Grugq is
responsible for 97% of traffic to my Alexa Echo). Data is
becoming too polluted over time (IMHO).
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
"Where ignorance is our master, there is no possibility of
real peace" - Dalai Lama
0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463
Dailydave mailing list
Dailydave at lists.immunityinc.com
More information about the Dailydave