[Dailydave] Analysis

yersinia yersinia.spiros at gmail.com
Mon Jan 28 12:34:31 EST 2013

On Mon, Jan 28, 2013 at 4:39 PM, Dave Aitel <dave at immunityinc.com> wrote:
> A large part of doing security consulting is doing "Analysis". This
> means hugely different things to everyone, but I wanted to put together
> some thoughts on the "Immunity Way" and some of the lessons we've learned.
> First of all, when most people think "Analysis" they think "Deduce
> things from your data set", and frankly, I think they're off on the
> wrong foot already. This is what you get when people get fancy tools
> with nice dashboards - a misplaced idea that they have only one data set
> and that digesting it properly is how you get gold. People with
> expensive SIEMs think that the machine does the work. But while machines
> can do visualization, actual synthesis and the rest of the analytical
> process is iffy at best. As Halvar used to say when building BinNavi -
> "Now you have a ball of twine to look at. Pretty, no?" He doesn't talk
> like that, but you get the point.
> The first stage of analysis is generally what I would call synthesis.
> I.E. taking all sorts of information sets from as far around as
> possible, and finding a way to talk about them in the same terms, so you
> can do some basic correlation. This takes forever in terms of man-hours,
> but it's the key to focusing on "what's important" as opposed to
> focusing on "things I can say from what I have in front of me".
> The books will then say that the next step is "orienting to your
> consumer" which is important, but frankly we like to surprise and amaze
> our consumers, so I think this is really one of the later steps. In
> reality, the next step is "reduction" - i.e. we want to look at a LOT
> less data than we have. Unless your data gathering team is really bad at
> their job, you have more data than you could look at or even run a
> complex script against. So you want to do your best to remove data from
> your working data set. And the best way to do this is to focus, at
> first, purely on anomalies. Or as Justin Seitz would say "Why doesn't
> this host have a Server: header again?"
> After that it's about looking for connections - especially non-obvious
> connections in time that allow you to develop causality arguments.
> Grouping types of organizations together is one of those things where
> you feel like you're making progress without having to use your thinky
> bits too much. (aka "Looks like all the servers Joe set up that weekend
> aren't on the patch management system.")
> And then, finally deduction, which is where you get your four F's -1.
> (aka, the "things you know" and "the things you think you know" and in
> reality a long list of "the things you wish you knew"). Frankly, if you
> don't have a list of "Things you wish you knew" that is ten times longer
> than the list of "things you know" then you're a total failure as an
> analyst.
> As a final note: Good hackers are better at this than you are, so skill up.
A summary very beautiful and precise, thanks. In facts i love also
this following point, equivalent i think to the last your.

"Have a desire and drive to learn new stuff. This is a must; It’s
probably more important than everything else listed here. You need to
be willing to put in some of your own time (time you’re not getting
paid for), to really get a handle on things and stay up to date."


More information about the Dailydave mailing list