Quantcast

Adaptive Penetration Testing 2: Real vs Simulated Breach

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.

The bitter truth

The bitter truth

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.

Meeting the challenge

Meeting the challenge

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.

Real breach

Real breach

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.”

Simulated breach

Simulated breach

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.

You should leverage it to your benefit if you experience a breach.

What pentesting should be

What pentesting should be

Dave: Penetration testing isn’t the smash and grab that we are used to; it’s not firing off the scanners; it’s not running a bunch of exploits trying to barrage the infrastructure. I mean, it’s not the techniques that we are leveraging right now. It’s more than finding exploits, it’s more than actually going after a system and saying “I got domain admin.” It really has to hit the company where it hurts, and that’s the most important part about it.

Think outside of the box

Think outside of the box

Again, the reason why we wanted to go into this and give you a little bit of history behind it is because we truly believe that penetration testing is absolutely one of the founding things that can help a security program grow. And what we wanted to do is give you a perspective of how you need to look as you’re doing these penetration tests and what you need to think of. Think outside of the box, think of something that hasn’t been done. I mean, yeah, if you’re having a low-hanging fruit with SQL injection, that’s great, but leverage that for something else.
Further focus of the presentation

Further focus of the presentation

And so, the rest of this talk is story time. We are going to go through real-world scenarios that we’ve done in penetration testing that’s unique, something that hasn’t been done before, something that is unique in nature, something that might not be as crazy sophisticated or might be, but something that was unique that actually provided the value to the customer.
 

Read previous: Adaptive Penetration Testing by Kevin Mitnick & Dave Kennedy

Read next: Adaptive Penetration Testing 3: Prep for a Software Vendor Compromise

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: