Caroline Wong — The state of Penetration Testing

0:00Chris RomeoCaroline Wong is the Chief Strategy Officer at Cobalt.io. Wong's close and practical information security knowledge stems from broad experience as a Cigital consultant, a Symantec product manager, and day-to-day leadership roles at eBay and Zynga. Caroline joins us to talk about penetration testing and reviews key findings from the State of Pen Testing report. We hope you enjoy Caroline Wong's second visit to the Application Security Podcast. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo.

1:05Robert HurlbutHello folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut. Threat modeling architect. I'm also joined by my co-host Chris Romeo. Chris?

1:29Chris RomeoHey Robert, this is Chris Romeo, CEO of Security Journey, and super excited to be talking about pen testing today in the conversation we're about to jump into.

1:41Robert HurlbutYeah, definitely. And so with us today, joining us is, is Caroline Wong. Welcoming her back to our podcast. Welcome, Caroline.

1:51Caroline WongThank you. It's great to be back.

1:53Robert HurlbutVery glad to have you. In fact, I remember one of the topics that we talked about the last time you were on the podcast was around self-care and self-awareness for security people. That was a great podcast. I know there were— we got a lot of great comments on that. A lot of people said that was, that was so interesting and really actually hit home. I think it was— I mean, I remember when I talked to you about it and said, hey, I think this will be a great podcast, and it turned out to be fantastic. A lot of people enjoyed it.

2:24Caroline WongI'm so glad to hear that, and I think that, you know, some of that has become even more relevant for us this year with all the stuff that's been going on. So thank you for that. Thanks for that opportunity.

2:37Robert HurlbutAbsolutely. And so as Chris mentioned, today we're going to shift topic a little bit into another category of security, and that is pen testing. And so everybody, it seems, has their own definition. What is penetration testing? What is that for you?

2:56Caroline WongSo my definition is that pen testing is manual security testing that provides insight into an application's security by systematically reviewing features and components. So this test is intended to explore the complete application rather than just focus on one type of vulnerability or one particular section. So pen tests will follow methodologies related to topics like input validation, authentication, access controls in order to identify flaws in the application's implementation. A pen test program is a clearly defined series of pen tests which is designed to systematically identify and remediate vulnerabilities. So because of the nature of modern software development and the fact that we're simply making more software more frequently, I actually think that I observe, I should say, a change from a point-in-time pen test To pen test programs.

4:08Robert HurlbutSo something that can be done, um, not— oh no, no, continuously, but certainly more than once, right? As you said, not a point in time.

4:16Caroline WongRight. So I think of a pen test program as having testing that is completed periodically. So whereas, you know, maybe a decade ago, you know, you'd talk to a— an AppSec leader and he or she would say, yeah, you know, we do a pen test every year. These days, you know, you're seeing folks do pen testing twice a year, every quarter, every month, as frequently as every week. And that, I think, is a direct reflection of the way that software is developed today, which is just faster.

4:50Robert HurlbutRight. Like, for example, DevOps. I mean, people are releasing software much, much more frequently, so it would stand to reason that they probably should be testing for security issues much more frequently as well.

5:02Caroline WongExactly.

5:03Robert HurlbutGreat. So another interesting thing that I hear, maybe some confusion really, about a pen test. So you've given us a great definition of that, but what about vulnerability scanning? Is that— some people get those two confused, I think, or they think they're interchangeable. What are your thoughts on that? Yeah.

5:26Caroline WongI think they are different, um, and I can see why some folks think that they're similar. Um, I actually like to point folks to the PCI security standard definition. So according to PCI, a vuln scan— the purpose of a vuln scan is to identify, rank, and report vulnerabilities, whereas the purpose of a penetration test is to identify ways to exploit vulnerabilities in order to circumvent or defeat security features. And so fundamentally, I think, you know, a scan involves the use of a machine and penetration testing requires actual human effort, things like creativity, thinking outside the box, systems thinking, things that today, you know, despite advances in things like AI and ML, we still can't really rely on machines to do.

6:23Robert HurlbutOkay, so there is that human element really of that creativity, as you said, in a pen test versus the vulnerability scan, checking for vulnerabilities, but not necessarily how do I then use that to break in? How do I then determine next steps and maybe putting 2 things together to break in? That's what you could certainly do with a pen test as well that you may not may not be as obvious from just 2 or 3 vulnerabilities that are listed. Interesting.

6:51Caroline WongRight, right. And then another thing that I'll just point out, which of course I expect a lot of practitioners experience actually, is that, you know, scanners do still require manual setup and they also produce a significant number of false positives. So there is actually human effort involved. A human's got to configure the scanner. sift through the results. And the other thing is that, you know, scanners can sort of guess the criticality of a vulnerability based on some customization and tuning, but it cannot assess the severity within the context of an application the way that a human can.

7:29Robert HurlbutSure, right. Okay, that makes sense. So let's talk about software development. Where does pen testing fit into a software development lifecycle?

7:41Caroline WongSo I'll share a bit of context where I really began to think a lot about an SSDLC, what I consider a secure software development lifecycle. Prior to my role at Cobalt.io, I was doing managing consulting for a company called Sigittal focused on application security. Sigittal was recently acquired, not so recently now, but Sigittal was acquired by Synopsys. And part of what I did at Cigital was I was one of our lead BSIMM assessors. So BSIMM is this kind of list, if you will, of more than 100 security activities that have been observed in software security programs around the globe over the past more than a decade at this point in time. And so the idea says, okay, you've got your security development lifecycle, what are the activities that take place throughout that lifecycle to enhance the security of the end product. And I actually think that, you know, I observed different behaviors at different organizations depending on their level of maturity. The vast majority of organizations, and while I was there, I did more than 3 dozen or so BSIMM assessments. The vast majority of folks that I met with were doing 2 things. They were doing pen testing and they were doing some secure coding training. Now, that is not a bad way to start. However, if I look at folks on the more mature end, they've actually got security activities throughout the software development lifecycle, and pen testing is not the whole thing. It's actually a check at the end. To say, look, if all of our previous security activities were working the way they're intended, then we'd actually like to prevent or eliminate security defects before we get to production. And then what I see is mature organizations using the results of a pen test to actually indicate where did the process potentially break down. So that it's not so much like an instance of whack-a-mole, find a bug, fix a bug, find a bug, fix a bug, but rather, find a bug, examine the process. How did this bug get through? How did this get created in the first place? Then, not only might you incorporate some sort of automated testing into a regression test to try and eliminate that from coming up in future iterations, but also putting a step earlier in the process to try and prevent it from being created in the first place. So I think that it really depends in terms of an organization's investment in application security. It depends on their stage of maturity, but regardless, you know, pen testing is a way to try and break something, before, you know, the bad people do. And so I'm really excited to be at an organization that is focused on pen testing. I find it to be endlessly interesting.

11:04Chris RomeoSo I've got 2 specific pen testing related questions. And just for our audience, they already know the Application Security Podcast is primarily non-commercial, but I'm about to ask you a commercial question and let the record show I asked the question of my own free will. One thing that I think about when— that I don't understand about Cobalt and kind of the rest of the industry that I'd love to know here is when you think bug bounty, when you think bug bounty versus pen— I think of Cobalt as kind of pen testing as a service, and correct me if I'm wrong, if I'm using the wrong term there.

11:37Caroline WongThat's exactly right. That's exactly right.

11:39Chris RomeoIs that okay? So when you compare and contrast pen testing as a service versus bug bounty, I would love to know like what's the difference there? Because I've been doing this for a long time and I don't think I can answer that question. And so this is a— I'm asking the question, audience.

11:55Caroline WongThis is not—

11:56Chris RomeoCaroline is not leading into what she does. I'm asking.

11:59Caroline WongCool. Yeah. Thank you so much for the question. And I'll tell you a story, Chris. So Cobalt as a company actually was launched in 2013. It launched under a different name, CrowdCurity. I give our founders a pass on that because they're Danish and English is their second language. Cobalt CrowdCurity started out as a bug bounty company, and it focused on sort of cryptocurrency-related companies. So in its time as a bug bounty company, CrowdCurity performed about 200 or so public bug bounty projects and accumulated thousands of security researchers. Now, there are a number of challenges related to bug bounty, and so Cobalt made the decision about 5 years ago to totally switch, to completely stop doing bug bounty and to instead focus on pen testing. We did something where we looked at, for example, our, you know, thousands of, you know, bug bounty hunters, and because we had gotten feedback on those individuals, we picked the top 100. and we said, hey, how'd you like to be a pentester? You know, instead of just getting paid to be the first to find a valid bug, we'll actually pay you by the hour. So the first difference is actually the payment. The second difference is that there is this sort of collaborative aspect to the pen test as a service model. You know, an organization says we need a pen test, Here's the asset or the set of assets that need to be pen tested. We look at our closed— and by closed, I mean exclusive— group of pen testers, and we put together teams. And these teams of people get paid for their effort, not for their findings, and they work together to systematically review an application. So whereas an organization like HackerOne or Bugcrowd, you know, these are folks who alongside with Crowdsecurity pioneered and they're really leading the bug bounty industry. And so while they claim to do pen testing along with bug bounty, their pen testing scale is simply much smaller. So the Cobalt pen testing is methodology-driven, it's collaborative. Bug bounty is very open and it's very competitive. So I think about them as, as being quite different, but it requires a bit of a deeper look to kind of understand it. Does that make sense, Chris?

14:42Chris RomeoSo Caroline, that definitely makes sense. And I do have another question related to pen testing in general. And so there's a company that I'm aware of and they have a cloud-based portal application that they've built. It's built by security people. And when they're going out into the market, there's a number of different requirements that are being levied on them, you know, in the purchase of the service. where someone will say, hey, you have to have a pen test. Do you do pen testing? Do you do vulnerability scanning? They usually ask them separately. And what they found is that when you have an app that's been built with security in mind from the beginning by security people, the argument is, do we really need, or do they really need to have a pen test at that point? And so, what's your take as somebody who's kind of seen both sides of this? What's your perspective? What advice would you give them?

15:32Caroline WongSure, so my, my thought on that is that any given individual is going to have a limited experience and limited knowledge. You know, if I took the 3 of us, you know, Robert, Caroline, and Chris, and I said, hey, we're security folks, you know, let's go make something, I would not necessarily assume that it is totally secure. And that's not a That's not a bash to any of us. That just simply speaks to our finiteness. And so while each of us may be an expert in a particular area, there's probably other people that aren't us that are experts in other things that might be able to kind of double-check our work. I also think that there's something natural about, you know, if I write something, it's actually kind of hard for me to identify typos, where if I, if I ask you, Chris, to take a look at it, you'll immediately see something that I missed, and that's just the nature of our own work. You know, I think that in security, for a long time, we've really believed in this sort of like trust but verify model, and I think there's no reason not to apply it to ourselves.

16:49Robert HurlbutSo now we had a question about your company. Your company also recently put out a report. I think it's the State of Pen Testing in 2020. Could you take us through, Caroline, a little bit about what was in that report, help our listeners understand a little bit more, and viewers, what was in that report?

17:08Caroline WongYeah, so we are super excited about this report. I partnered with my brilliant colleague Vanessa Sauter on this, and the State of Pentesting 2020 assesses which web application security vulnerabilities can be found reliably using machines and which ones require human expertise to manually identify? So we have this idea that— and we talked a bit about it when we discussed like, what's the difference between a vulnerability scanner and a pen test? And to date, there's actually been relatively little research that's been published on the classes of vulnerabilities that machines and humans respectively are good at finding. And yet that distinction can really change a security team's application security strategy, right? If you look at an AppSec leader and he or she is trying to put together their budget ask for 2021, you know, how does he or she know if he or she ought to ask for, you know, an FTE to hire an internal pen tester, you know, if he or she ought to go and buy some SAST or DAST tool? And so these decisions when it comes to allocating time and resources to the most effective activities that are going to allow a team to find and fix application security vulnerabilities, we think that that's really relevant. And so we're really excited to have done that research and to have that research publicly available for all to consume and learn from.

18:45Robert HurlbutYeah, tell us about some of the ways that humans win. I like that way of phrasing it, but certain vulnerability types. Let's see, business logic bypasses, race conditions, and chained exploits. Tell us a little bit more about that.

18:59Caroline WongSo, you know, when you kind of say it that way, it's kind of a mouthful, right? Business logic bypasses, race conditions, chained exploits. But at the same time, if you kind of take each of those one by one conceptually, It makes perfect sense, right? A business logic bypass exploits a flaw in an application's design. If an attacker can actually circumvent an anticipated workflow or alter an application's execution path, then you've actually overcome the system. You've compromised the system. You know, an example that I think we're all familiar with is a forgot my password flow. If the system doesn't check that my, you know, security credential, whatever it may be— it may be an out-of-band email, it may be, you know, a secret pass thing, you know, you know, what's your dog's name, what's the first car you ever drove— if the application, for example, were to skip that step, which would be a business logic bypass, then you're screwed. And that's something that a machine can't find. So, so basic examples include things like being able to change the price of something that you're buying. We already talked a bit about abusing weak password recovery validation, and then in general evading approval flows. So to the extent that any application workflow includes an approval at some point, if that can be skipped, then that's a security flaw. So, so, so that's the business logic thing. You know, the race condition thing, it's funny. So I graduated in 2005 with a degree in electrical engineering and computer science from UC Berkeley. And while my computer science and electrical engineering coursework did not, for the most part, include security topics, one of the things that, of course, we did learn about was race conditions. So when 2 threads are trying to access the same data at the same time and both attempt to change it, and one— and somebody hasn't locked the file, so there's a race when the file is opened and it's not locked down. That can be an application security issue, and that's something that's pretty hard for machines, machines to identify. And then the third category is chained exploits. So if you take vulnerability 1 and you can combine that with vulnerability 2 to make bigger and more impactful vulnerability 3, then that's actually where some of the most interesting exploits come from. And again, something that is is generally not possible using machines these days.

21:34Robert HurlbutYeah, in fact, that's— I was just curious about that. You also mentioned that there are some vulnerabilities that neither humans nor machines can find very easily. You mentioned authorization. I know that's— yeah, that's a really, really tough one.

21:49Caroline WongThere are these types of vulnerabilities, right, where either scanners can't reliably find them or they require really intense manual configuration. And then humans actually have to rely on automated tools to successfully do it. So for example, an IDOR happens when a user gets unvalidated access to an object through their supplied input. So this is the type of thing that a vulnerability scanner is not always going to find, an IDOR, but instead a person has to identify the object reference and then use an automated tool, something like Burp, in order to tailor the payload. So there is, of course, this kind of like coming together of human and machine to make this stuff happen. But what I'm really excited about in the report is that we kind of go through these different categories. You know, what are the categories that machines are really good at? What are the categories that humans are really good at? What are the categories that require both of them to come together? And I think that, you know, one additional comment that I want to kind of put in here is that when I use this broad category humans, We do assume that, you know, humans are gonna use proxies like Burp Suite, Fiddler, Zap to do things like modify HTTP requests, modify web sessions, you know, crawl sites. And so, so there is, there is often going to be this overlap. I actually think that in the case of humans using tools, it actually makes a security researcher a better pen tester if they're able to effectively use The tools.

23:20Robert HurlbutRight, so that, I mean, to me that just speaks to that case of needing a pen tester to take a look at this, to have that understanding of security, know how to use the tools, understand I can't find everything, but I can— the combination of creativity, ingenuity, understanding, using the tools to my advantage to find those kinds of things, I think again speaks to that need. and importance. Excellent. So another thing I noticed in terms of the report, you did run a survey, it looks like, just to get some feedback and how people are using tools or what are they doing. It said— what I noticed is 1/3 are releasing software on a weekly or a daily cadence.

24:09Caroline WongYeah, so there is so much data that simply says that organizations are requiring code, are releasing code faster and faster. So to the point that we discussed earlier about DevOps and sort of just like the speed of software release, this naturally is going to have an impact on the way that application security is done. Whereas in the past, in sort of a more waterfall model, a lot of application security folks, and you can actually see this evidenced in earlier versions of the BSIM, you know, there's this idea that you can have phases and that you can put in gates and that at these gates you can do some testing and then you can get like a go or a no-go to move on to the next, to the next phase. But today, you know, the way I think about waterfall is like phases and gates. Agile is like do everything faster. And then DevOps is like do everything faster and all the things all the time.

25:13Chris RomeoMm-hmm.

25:14Caroline WongAnd so security has to kind of meet those needs. Fundamentally, security is about getting problems communicated effectively to developers so that they can be fixed. I think that one of the mistakes that I've observed by application security teams throughout my career is that There can be a lot of focus on finding the vulnerability. I actually prefer to see the focus on fixing the vulnerability, which is easier said than done, right? If we look at something like the OWASP Top 10, the first version was released in 2003. I think we had like the 5th or so version at the end of— was it 2017?

26:00Robert HurlbutMm-hmm.

26:01Caroline WongAnd then, you know, hopefully we expect that we'll see another version come out in the spring of 2021. If I look at all of the iterations of the OWASP Top 10, there's a lot of commonality, right, between the 2003 version and the 2017 version. And what that says to me is that for a lot of these common vulnerability types, we as an industry, we actually know what they are and we actually know technically what to do about them. So why is it that the, the list of the most pervasive types of vulnerabilities has, has been relatively unchanged over the past literally 2 decades? And I think it's because of people and process. I think it's because people and process changes, and that's something that I think security folks are, are beginning to embrace more, asking questions of SREs and engineers and ops folks and trying to figure out how to effectively communicate, effectively integrate, actually get security folks and engineers to collaborate with each other and work as part of one team and not as sort of these, you know, opposing forces. So, so that's my conclusion when I look at something like OWASP 2003 Top 10 and 2017 version and I say, wow, these look kind of alike. I think to myself, we know how to solve these technical problems. The hard part is actually the people in the process. So when I think about something like the Equifax data breach, for example, this was not actually a particularly sophisticated technical problem that needed to be solved. In fact, Equifax was well aware that there was a patch and a software update that needed to be installed. The problem was not trying to figure out the technical problem and the solution, but actually the people and process problem of trying to deploy a patch and update software across a very large enterprise, which is indeed a super complex, difficult problem. So I have an idea. that actually some of the most challenging parts for us as application security professionals are not so much the technology. I think we've got a lot of that figured out, but actually solving some of these people and process problems and getting folks like engineering and security folks to actually collaborate and work well together, not only to find security vulnerabilities, but also to get them fixed.

28:44Robert HurlbutI have one more question, and this sort of— just thinking about this in terms of the cadence of all the deliveries and so forth. I remember hearing a number of years ago about pen tests. That's going to take 2 weeks. It's always 2 weeks. Everything is 2 weeks, right? That's the general answer. It's 2 weeks. But how does that work when— if you're looking to run pen tests but also have this breakneck speed, I'm delivering every day or once a week or whatever. Are you running these concurrently? Are you running them more frequently but concurrently? I mean, how does that work in terms of time and delivery of software?

29:28Caroline WongSo I think it really depends on the organization. For example, Cobalt works with some clients that have us come in and do a pen test every month, and they're like relatively small pen tests. We have this idea that you can actually buy pen test credits and then you can spend them when you need to, and you can spend a bunch all at once if you want to do a big test. You can spend a little at a time if you want to do a test on something that's already been tested but was maybe recently updated. So we actually see a lot of differences in terms of how organizations choose to do pen testing. For an organization that is not releasing code on a daily basis, they may actually still be in a model where they want the pen test to be complete and the highest criticality vulnerabilities to be remediated before that goes live. Sometimes an organization that's deploying code very quickly does not necessarily have time for that. But I also want to point out there's a time change on the other side too, which is to say that even if the code's live, once the pen test is complete, there's going to be a new code revision coming up very soon, so there's actually a quick opportunity to get those findings fixed. It's taking something which used to be like a step-by-step gated sort of process, and it's making some of that asynchronous, which I think is very much in line with the way that modern software development is happening today.

31:02Robert HurlbutAgreed.

31:03Chris RomeoAgreed.

31:03Robert HurlbutI like the iterative approach, too, like you said. It could be a larger pen test a couple times a year, but maybe sometimes smaller, just depending on the amount of changes that we've made and so forth. So I like that a lot. So Caroline, if you could give us some— I appreciate all the discussion here, it's been fantastic— some key takeaways for our listeners and viewers as they're starting to think about this, thinking about how do I implement this, or how do— what do I do now Some key takeaways and maybe even a call to action.

31:37Caroline WongSo I've got a few key takeaways to share. One of them, which we talked about a little bit, but I want to go into a nuance of it, is that identifying a vulnerability is not the same as assessing the risk that it presents. So you can take a scanner, for example, and you can quickly find some vulnerabilities, but you actually need a human to apply the necessary context to do things like remove false positives in order to find the true number of vulnerabilities in order to figure out which are the most critical so that those can get remediated. The second is another thing that we touched upon briefly, but which I want to emphasize again, which is that a good pentester does rely heavily on automation in order to test applications, whether that's writing Python code to iterate through hundreds of subdomains or automatically fuzzing inputs. And so pen testers do automate their processes in order to maximize efficiency. They use scripts, they make the pen testing experience a lot faster, and it can be more rewarding. And when I kind of put out this idea of like human versus machine, I actually consider these tools that pen testers develop and rely on to do their work. I, I think of that not as falling under the machine category, but actually reflecting the creativity and the persistence and the out-of-the-box thinking that comes from the human. And then, and then, and then finally, in terms of key takeaways, and then I'll get to a call to action, you know, scanners can really just be effective as the practitioners that deploy them. So open source and enterprise scanners are an excellent baseline to reliably identify simple classes of vulnerabilities. They can save tons of time when they're configured correctly. And so all application security programs, no matter how scrappy or robust, should be using static and dynamic testing. However, scanners are not a substitute for comprehensive application security measures, nor can they replace pen testing. And as a call to action, I would recommend that if folks are interested in what we talked about today, that you actually check out the full report for State of Pen Testing. It's extensive, you know, it's like a 20-page report. And what I wanna share with folks is simply that Application security leaders find ourselves in a position where we have to make decisions about how we're going to allocate time and investment and budget. I think that knowing a little bit more about what people can do and what machines can do can actually help us to make those decisions.

34:13Robert HurlbutGreat advice. Thank you, Caroline. Thank you for joining us today. I really, really appreciate it and look forward to the next time that we can talk about another Me too.

34:23Caroline WongI am so looking forward to it, and thank you so much again for the wonderful chat. It is really great to see both of you.

34:30Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find cool Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.