Security Testing for Muggles: An Interview with Paco Hope


Paco Hope talks STARWEST 2014, his goals to reduce the stigma around security testing, and how you don't have to be a wizard to test the safety of your software. Paco also covers how security testing is like cooking, the future of security, and how he became interested in security testing.

In this interview, Paco Hope talks STARWEST 2014, his goals to reduce the stigma around security testing, and how you don't have to be a wizard to test the safety of your software. Paco also covers how security testing is like cooking, the future of security, and how he became interested in security testing. 


Cameron Philipp-Edmonds: Today we have Paco Hope of Cigital, and he is giving a presentation at STARWEST which is October 12 through October 17, and his presentation is titled "Softwarts: Security Testing for Muggles." Paco, to start us off can you tell us a little bit about yourself?

Paco Hope: Right, so I'm a software security consultant, so I work with a lot of financial institutions, retail companies, hospitality companies, folks who make software that do useful things for us in our lives. I work with them on making that software do the right thing, be secure, sometimes a white hat hacker if you will. The kind of person who helps developers get their job done, get it done right, and use technology the right way.

Cameron Philipp-Edmonds: Okay, now your presentation, it's titled "Softwarts: Security Testing for Muggles," and it seems like the presentation is humorously played off a very popular fictional wizardry book series. What led you to that association?

Paco Hope: That's right because frankly I work with a lot of folks who seem to have the opinion that security testing is this magical thing and you need to have a pointy hat and half-moon spectacles and a magic wand if you're going to do something productive in security. Actually it turns out it's pretty far from the truth. You can do a whole lot of really valuable security testing if you know anything about just good old software testing. That's the great thing about STARWEST is a lot of people who take software testing seriously, it is their job, it is their career, it is something that they're passionate about.

I really feel like we need to disabuse the industry of this notion that to do something meaningful in security you need to have special tools and special knowledge and all these techniques that only the wizards have. Actually you can do some really useful things and really powerful things as an everyday software tester who knows what he's doing.

Cameron Philipp-Edmonds: Great, now you consider you presentation a lesson in defense against the black hats which is kind of a defense against the dark arts to go along with that association. Can you cover the difference between a black hat and a white hat security tester?

Paco Hope: Yeah, it's a pretty easy distinction. The folks who are doing something good, trying to make software better, hoping that we all enjoy and benefit from technology; these are the white hats. The black hats are the ones who are trying to do bad things. It's taking advantage of mistakes in the software in it's design and implementation, and trying to do things that it shouldn't do. The reason we make this white hat black hat distinction is because there's actually a lot of techniques that are very similar between the two, but I'm looking to find the bug and the flaws, and the same thing with software testers.

We're looking to find the bugs and flaws to make the software better, not to in some way abuse the software or use it to our unfair advantage.

Cameron Philipp-Edmonds: Okay, so why do a lot of teams and projects stray away from security testing?

Paco Hope: Well, there's a couple of reasons. For one thing, there's a misunderstood notion that software testing is little more than checking, so we're just making sure that the software does the right thing and we deprioritize hunting for the wrong thing that might in fact hurt the business if it did the wrong thing. We're so focused on making sure the software does the right thing that we sometimes overlook the bad things that it could do to burn the house down.

The other side of that is people I think sometimes perhaps discount their own abilities. Well, I'm not one of those software security hacker-type people. I couldn't do what they do. I can't do something like security testing. I just know how to do regular testing. The two things are very, very similar. They're not that different.

Cameron Philipp-Edmonds: Okay, that leads into my next question here. You're a strong proponent of the ability to seamlessly blend security testing with existing testing practices with a little bit of extra work. Do most testing practices lend themselves to the addition and inclusion of security testing?

Paco Hope: Yeah, they do and I think that limitation comes from a limitation when we're thinking about software requirements. We start talking about what software does. We're usually talking about what we would want it to do in the good case along the happy path when people are trying to do the right thing, how will the software work? To be fair, of course, we have to get that right or the software isn't worth writing in the first place. Having said that, if you sit down and write your requirements only from the perspective of doing it right, then your testers will only test from the perspective of does it do the right thing.

That's the key concept. If you were to write security requirements, use cases, user stories, around what's the right thing to do when somebody is trying to do the wrong thing. Well now you've just written something that a tester has to go test. What do we do when the guy does the wrong thing? Suddenly security testing becomes just an extension of the rest of the testing that you're already doing.

Cameron Philipp-Edmonds: Okay, so it's becoming more exploratory.

Paco Hope: Exactly, it definitely trends towards the exploratory testing, and I feel like most organizations that are employing a significant number of software testers are actually almost squandering this opportunity to use highly qualified, highly trained people who know what the heck they're doing to actually go look for security issues. I work in a penetration testing capacity fairly often which means someone says there's our app, can you break it? Okay, I can try, but very often security testing is time boxed. It's like well, you've got ten days, or you've got $5,000, or whatever boundary around how much can I spend looking for security issues?

Contrast that with someone who does testing on this application for a living, they've got themselves a nice script. Every single capability that the software can do, they have a way to go exercise that functionality. They can go deeper, they can go more specific, and they understand how it's supposed to work. If they were to just toss in a few extra little test cases here and there deep down in some function that I as an outsider in a time boxed capacity, I won't be able to do that. It's sort of unused capacity in your own testing organization. If we just gave them a little bit of a more renip to do more things against their software, then the security guys would actually have a lot less to find.

About the author

Upcoming Events

Oct 01
Oct 15
Nov 05
Nov 14