Re: Improvements

[Oliver Friedrichs <oliverfriedrichs () gmail com>]

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.

Oliver





On 2/16/17, 10:49 AM, "J. Oquendo" <dailydave-bounces () lists immunityinc com on behalf of joquendo () 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
    > data.
    > 
    > Cheers,
    > Wim
    
    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 19.0.0.1 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 8.8.8.8 (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).
    
    -- 
    =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    J. Oquendo
    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
    https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463
    _______________________________________________
    Dailydave mailing list
    Dailydave () lists immunityinc com
    https://lists.immunityinc.com/mailman/listinfo/dailydave
    


_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave