Dave Kennedy and Kevin Mitnick focus on nuances of real-world company breaches as opposed to simulated ones and explain why the former are more instructive.Dave Kennedy: We are the only industry that I know of who keep increasing their budget, keep increasing their capital expenditures, and continue to get worse. Oh wait, it’s been proven that it’s not actually accurate – weathermen are the first, and we are second. So I guess we are the second industry that I know of that continues to get worse. This brings us to our point: we believe that penetration testing is partially the answer to fix the problems that we see in the security industry. Without knowing where your exposures or your risks are at, you aren’t going to be able to protect or defend against them. That’s why we came up with adaptive penetration testing. For us, security breaches are the best thing that can ever happen to a company. Take a look at Diebold – you sold these things off eight years ago or something like that, and they continue to be in the news. What that did for us, though, is it really put security into our entire company. I mean, our CEO loves security, he looks at it as an enhancement. I get budget, I get people, and I’m able to actually protect the organization. I’m able to do what I need to do in order to actually protect the organization. If we suffer a breach we experience significant pain as a company, and a company is generally not going to move on security unless they experience pain.
Kevin Mitnick: In fact, we get some clients because there’s fear in the media because of recent attacks, and also we get clients because they’ve been in compromise, so they go: “Oh shit, we got to do something about it,” and then they hire us to do security assessments or code reviews.
Dave: Fear is not always the best thing, but at the same time if you can represent how to actually systematically take down their company, it could be good.So let’s investigate a real breach. Company A experiences a breach. Security up until that point was extremely difficult to implement. They leverage that breach, you actually communicate it, you can use that to your best advantage. Now, in stating that, obviously, you don’t want a breach to occur. But at the same time, that’s not the doom and gloom that everybody makes it to be. I mean, if you experience a breach, what company has gone out of business? I think in the history of breaches, some guy at ShmooCon did a presentation and did studies on this, and two people have gone out of business because of a breach, and one CEO lost his job.
And so, if you look at that, systematically we are not going to go out of business. You should leverage it to your benefit if you experience a breach. I mean, most of our first reactions are “Tuck it away”, “Make sure nobody knows about it”, “Hide it because I don’t want to get fired”. If you are doing your security job right and you’ve been preaching that your security sucks for the past five years, you should have a pretty good backing to say: “Listen, I’ve been telling you guys for five years this is what we need to do. Let’s make this work now, because we’re screwed, you guys feel pain, and I can fix it.”And option two is a simulated breach, penetration testing. For us, maybe it’s not as effective as a real breach can be, maybe it’s not as good as a real breach can be, because they are actually experiencing pain when you do it. But the ability to simulate an attacker, the ability to actually go into a company and exploit them is going to be leaps and bounds beneficial to, obviously, happening in the news.
Kevin: And that’s one of the things we actually enjoy doing: when we take penetration testing jobs we actually only take the ones that allow us to do full compromise. So the client will give us, you know, what’s the target asset. If it’s a software development company, that’s source code; we’ve done ecommerce companies where it’s been their credit cards. And that’s the only ones we take because those are the only ones that are interesting. And then, one of the other rules that we set for clients is they can’t change anything as the pentest is going on. So if we find some sort of vulnerability that we have to report as part of our contract, we ask that they don’t share that with the IT team so they fix it, because it affects the pentest. But we like to simulate real-world type of stuff, we don’t like to stop at a particular point. So we are very picky on what ones we actually do.
Read previous: Adaptive Penetration Testing by Kevin Mitnick & Dave Kennedy