Incite Redux: Day 10 - Hack Yourself
Good Morning:
On the last day of vacation last year, I started the post
with:
But this year, I'm sure things will be a bit different. First
of
all, we've been with the kids. So it's not like I've gotten away from
screaming kids. And "working" a few hours each day has kept me
reasonably current with what is going on.
As Dorothy says, there is no place like home. She was right. I'm
looking forward to sleeping on my own bed, using my own stuff, being
back in my own routine, and enjoying all of the angst I constantly
create for myself. Being able to go away for a few weeks is such a
luxury, and we are very fortunate to be able to do it. But at the end
of the day, being away makes you appreciate being back.
And it's time to get back. You'll see a special Incite on Monday, and
TDI returns on Tuesday.
Have a great weekend.
Incite #10: Hack Thyself
Given that
there is no panacea on
the horizon, security professionals start to understand the concept of
risk management, as opposed to throwing money down the security toilet
on the latest, shiniest widget. Security organizations must start to
put a premium on prioritizing activities, based upon what’s
important to the business, as well as what is really exploitable in
their environment. The only way to figure out the latter is through a
new function called “security assurance,” which
focuses on
breaking stuff (networks, systems and applications) before the bad guys
do.
Read the original Days
of Incite post on this topic.
6-month grade: B+
I love how you can be right and wrong at the same time. First things
first, it's clear that the term "risk" is much more in vogue this year
than "security." I guess most folks think that risk is a more business
oriented term. But no matter, I do think that slowly, but surely many
practitioners are understanding that not everything is going to get
done and focusing on the activities that reduce the most risk is not a
bad thing.
How do you know what that
activity is? Well, you need to be able to isolate real risk vs.
theoretical risk. The only way I know how to do that is to actually
test your stuff. Yes, I'm a big fan of testing of pretty much
everything. I've said that about a million times. Unfortunately the
tools to test the really important stuff are still pretty immature.
Yes, I'm referring to applications. The tools to do automated pen
testing for networks and systems are maturing quickly. There aren't a
lot of them, but the one's out there work pretty OK. But in reality,
network and systems are not really the path of entry for most attackers
nowadays. It's the applications.
And the tools to penetrate applications are still early. Sure they are
maturing, but you still need a bunch of big brained dudes to figure out
the logic errors that are more likely the cause of application
compromises. Any scanner is going to do a decent job of finding XSS or
SQL injection flaws. Though that is still low hanging fruit for
attackers because not enough people are running scanners on their
apps.
Alas, Rome was not built in a day and neither are the application
security testing tools. I can only hope (and I know hope is not a
strategy) that the big companies that have acquired these tools
continue investing in making them better. Or the start-ups (yes, there
are still a few out there) will drum them.
Yet the real reason this is graded as a B+ is that I'm not seeing
enough of the organizational change I predicted (and again, hoped for).
I know a lot of folks that testing is PART of their job, but not the
entire thing. And that means they don't get to it as religiously as
they should. Not by a long shot.
I can't stress enough the need to test all aspects of the
system, and to be serious about it. So the sooner someone is appointed
the internal "white hat," the more likely you'll find problems before
your customers do. Capiche?
Photo credit: "black & white hats" by w00kie



Post new comment