Glass Houses are Cheaper: the Case for Transparent Pentesting


Posted on

When you engage an external company to do vulnerability assessments and penetration testing, you have a few options on how to scope it. Here are some of them:

Win/lose engagement: either they get in, or they don't. In a previous life, I bought pizza for the consultants if they got in during the annual pentest. For four years I bought pizza, and then in the fifth year my wallet finally got a break.

This is usually time-bounded, and should only be done if you're pretty sure you've got things locked down. It can also result in a findings report that basically says, "Here are weaknesses we found, but we couldn't exploit them in the time allotted." Stopping after the first break-in may make your executive management feel less nervous about the testing—"okay, you've made your point"—but really only shows the particular talents of that consulting team: what they identify as the low-hanging fruit, and what they tend to aim for first. It doesn't show the extent of your exposure.

Grab all the things in a fixed time period: they see how many different ways they can break in during the term of engagement. Again, because it's time-limited, they will opt for easy and fast over complicated, so this doesn't really reflect the time and effort that a determined adversary can put in. Nevertheless, you can learn more about how many ways you're vulnerable than if you just stop after one breach.

Go wide rather than deep: have them enumerate as many vulnerabilities as they can find. Whether it's time-bounded or not, the focus on breadth may result in the consulting team relying more on automation and less on manual pentesting and crafting custom exploits. But the upside is that you get more tickets to submit for remediation.

Role-based pentesting: you task them to play the part of an external adversary doing reconnaisance, as an internal employee committing fraud, or a disgruntled sysadmin (to name a few examples). The engagement is scoped to a particular scenario, which allows the consultant more time to be creative, but doesn't step beyond what you've already thought of.

I'd like to argue for one more type of pentesting to add to this list: full white-box (or glass-box, or whatever you want to call it).

The problem with having consultants test you in the role of an outsider is that to some extent, you're relying on security through obscurity: you assume the adversary knows nothing about you to start with and has no access to internal systems or information. Once an attacker learns something about the inside, though, your assumptions are invalid, and so is the usefulness of the external-only pentest.

It's also a waste of your consulting dollars (and the consultant's time and expertise) to have testing done to discover things you already know about. If you do nothing else, run cheap scans on your own and give them to the consulting team before they start; there's no point in paying them to sit in front of the same scanner and wait for it to finish. Optimize their time wherever you can.

To get more value out of that engagement, tell the pentesters everything. Give them network maps, let them see documentation, have staff available to describe the business logic of applications. Show them what you're most worried about, and see if they agree with you after they've done their work. That way, they can go straight to the most sophisticated parts of the pentest—the parts that would take an outside adversary longer to reach—and give you the full benefit of their expertise for those same dollars you would have spent on discovery time.

Otherwise, it's kind of like going to the doctor and refusing to allow any lab tests or be examined anywhere except where it hurts. Why wouldn't you want to get as much expert information as you could, as quickly as possible, for the same price? Glass-house pentesting lets you get the most value.

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs