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

2008 Incite: 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.

I have gotten a total of zero calls this year telling me that management has doubled their security budget and is hiring a full staff in 2008. That doesn’t mean it doesn’t happen, but it’s about as likely as you hitting the lottery. 2008 will be like every other year I can remember. Security professionals will be forced to continue doing more with less and staying strong in the face of innovative attacks.

We all have a long list. None of us can get through the list daily. And once you cross one thing off, it seems two new ones appear. As I mentioned in the 2007 Incite on CSO Next, the ability to prioritize may be the most important skill for practitioners. The first step in that is to understand what is important. That’s Step 1 in the Pragmatic CSO.

I call this prioritization, but you could also make a case that this is what risk management is about. You decide what to do based upon the risk it presents or mitigates for the organization. Easier said than done, of course – but it needs to be done.

Yet, there is another aspect of the prioritization process that is starting to come into vogue and that’s what I call “security assurance.” A lot of folks have a lot of different opinions about what security assurance means, but to me it’s about making sure your defenses are up to snuff. The only way to do that is testing. Basically hacking your defenses, before the bad guys do.

Big companies should have their own assurance team, whose sole responsibility is to break things. They need to work fast, they need to be candid, and they need to kill the sacred cows. You (as the security guy/gal) want them to find all sorts of stuff. Remember, it’s a race and the bad guys are searching for successful attack vectors at all times.

If you aren’t a big company, then hire someone periodically to provide this type of testing. You want them to penetrate your defenses and show you the paths of least resistance. Small company practitioners should also invest some time and become familiar with the automated pen testing tools (Metasploit, Core Impact, Canvas, etc.). You should use these tools, as often as you can. You will find stuff and then you’ll know what to fix first. You aren't going to be able to stop a determined, skilled hacker - but you can make it harder for a script kiddie, using some tools he/she downloaded from a hacker site.

I'm also a big fan of social engineering your own employees. Of course you shouldn't keep any money you manage to collect, but everyone deserves an annual trip to Morton's, no? In all seriousness, if you believe Roger Grimes’ contention (thanks to Shostack for reminding me of that) that 86% of the Windows vulnerabilities required the user to do something, that means it’s a type of social engineering. The bad guys will be social engineering your employees, count on it. You should too.

Lastly I want to draw a distinction between vulnerability and exploit. Vulnerabilities show a theoretical attack path. But you may have other defenses that don’t allow the vulnerability to be exploited. A lot of companies spend a lot of time and a lot of money to fix vulnerabilities that cannot be exploited, which of course is a waste of time and does not help us prioritize on the most important stuff.

An exploit is just what it says. It’s a real attack, in the wild, which can be used to 0wn your networks, systems and applications. This is live ammo, folks. Obviously you don’t want to shoot your foot off. But you need to know what can be exploited because that’s the only way you can figure out what to fix first.

And given the amount of stuff on your plate, you need to know what to fix first.

Photo credit: rollerboogie

This is it. The last day of our visitation of DR's Top 10 IT Security Myths. The link is here. Which is fine by me, since I'm pretty much tired of this myth busting. I'll leave that to the Urban Legend folks. I hope you've enjoyed the quick series and maybe even busted a myth or two yourself.

Myth #9 - Clean Bill of Health Attainable? (link here)

The fact is that auditors are paid to look for problems, and they usually find them, experts say.

Ah, the ages old battle between security people and auditors. I do find that most organizations fail audits frequently, and then they go into a few weeks long death march to get things right. Of course, as the DR folks point it - it's usually a failure of documentation rather than a failure of controls.

To be clear, this is our problem - not the auditors. Relaxing the documentation requirements won't fix things. I guess some reporting requirements are onerous, but deal with it. You need to have the data, if only to verify what you do on a daily basis and the value that you bring to the organization. As we learned in the UBS insider case, it's critical to document the stuff you do - or else the forensics folks will need to do it for you. So documentation is not a bad thing. Protection and documentation can be done synergistically. I promise.

All security folks need to get a little auditor empathy. Maybe we can make up some bracelets that say "WWAD." What would the auditor do? So when we are implementing new products or controls, we know we can get the right information out at the right time. It's usually a bad day when you figure out you don't have information as the auditor is breathing down your neck.

WWAD. Make it a mantra, and your life will be much easier. This was pretty good. B+ I say!

Myth #10 - More Spending = Better Security (link here)

There's no real way to measure your return on investment
from hiring white-hats to run penetration tests and stage social
engineering exploits. It's much more cost-efficient to train your own
instead.

Man, DR really whiffed on this one. For one, the title is misleading. They are talking really about outside pen testing, not a broader security spending bucket. I do believe that more security spending does NOT lead to better security, but what does that have to do with pen testing?

What the so-called "experts" here missed was why company's engage outside resources for pen tests. It's pretty simple really. Management doesn't believe their own people. So getting someone in (even if it costs more money) to basically validate what the security folks have said is money worth spending to these folks. Sure you could do it cheaper, but that won't give answers to the muckety-mucks. Sometimes we need to do things to give answers to the muckety-mucks.

That being said, training your folks to do poor-man's pen testing and social engineering attacks is a good thing too. I don't think it's an either-or proposition here. And looking at automated pen testing products to provide more sophisticated tools for your own internal use is a good thing as well.

Then when the outside folks show up, they either won't find much or you'll already know the answers. And that's a good day, when you know (and hopefully have already asked for money to fix) all the holes.

Well, that's it. I need to get working on some of my own myths.