Pentesting, also known as penetration testing, is a security assessment, an analysis, and progression of simulated attacks on an application (web, mobile, or API) or network to check its security posture.
The objective is to penetrate the application or network security defenses by looking for vulnerabilities. These are usually weaknesses or flaws that an attacker could exploit to impact confidentiality, integrity, or availability. The goal is to find vulnerabilities and address them before a bad actor can exploit them.
Pentesting can fortify organizations’ general security posture and is a critical measure organizations should put in place proactively to prevent security breaches.
Recently, Colleen Pate, Customer Marketing Lead at Cobalt sat down with Coleen Coolidge, CISO at Twilio Segment to better understand how she views the role of pentesting in a cybersecurity program and how it can fit into modern workflows. This is what she had to say.
Coleen, give us the 100,000 foot overview of where you see pentesting fitting into a cybersecurity program and how you approach building a security program in general.
Imagine if you’re faced with having to build a security program from scratch. It sounds great, everyone wants to be a builder and leave their mark. You arrive [at this new company] and see that there are different practices that you may have taken for granted elsewhere that aren’t being done. Or maybe they’re being done intermittently or without the rigor you’d normally expect. That happens to every security leader when you jump into a new position.
One of the things you’re going to need, especially in a tech company, you’re going to need a program that is unique to the company and takes into consideration the customers, the attack space they live in, the tech stack they’re using and the unique challenges they have. There is of course a standard menu that we each bring in our back pocket of things you want to make sure you’re checking off the list.
When we dig into the application security space you think about the people you want to hire, at what level do they need to be, do they need a coding background, are they comfortable with developers, counseling and teaching developers how to code securely, etc. So, you have this people component and a teaching component.
There is also an operational rigor that the public and customers expect. It’s great that you do this internally but what does a third party say about your program and how effective your program is. And while you’re building up these processes and you build out your application security department you have these engineers working with engineers all over the company, DevOps, infrastructure, product engineers, and all types of engineers, and you have these internal connections you’ve made. You teach them secure coding but then you need this external validation to come in.
For example, you can have a bug bounty program, which we do at Segment. The main point about Bug Bounty is this is a third party, an outsider, taking a look at what you’ve scoped out in your brief about the limits they can have when they’re testing. How can they push it to see how far they could go if your app has a flaw or deficiency. We reward and have a relationship with those researchers.
We reward them because they are doing us a favor by zeroing in on the holes we may not see. Security practitioners on the inside just see a myriad of things to fix but a bug bounty researcher may try ad hoc things. If a bug bounty researcher gets the one thing right and we get that one thing wrong depending on the criticality of it, we’ll say, ok you’re right we need to fix this and pay them for that. We keep them apprised of when we fixed it and maintain that relationship moving forward.
Another great relationship we have with people on the outside is with our pentesting companies. Our customers expect us to have a bug bounty program but they also expect something more formalized around application pentesting. Customers want to know that 1-2 times a year there is an accredited and credible pentester that is going through the app and systematically looking for flaws, reporting on them, and producing a report. It’s not just one thing, they’re going through a list and iterating on things that could be weaknesses and checking off the things that we could be doing better. That report that is produced is a big deal and takes quite a bit of time.
Depending on the quality of the firm, pentester, or pentester experience results may vary. This doesn’t mean we’ll stop doing pentesting but it is more overhead to have a pentest program versus a bug bounty. Enter a vendor like Cobalt, where you have pentesting as a service, and there’s less administrative overhead costs on either end and you get the same types of results as with longer, heavier, more draining engagements.
Having a vendor like Cobalt on our bench means you can get a group of pentesters into your company really quickly. You can schedule on your own, list out what you want, and do it on your own terms. All of that is transparent. Over time, Cobalt understands our environment, and our specific needs for reporting, etc. It’s relatively low overhead for us to work with Cobalt.
Another best practice is to have more than one pentesting firm in your arsenal. Sometimes customers look at whether it’s always just one company evaluating you or if you bring in variety so that it’s a diversity of people and diverse backgrounds. Letting people with different backgrounds into the Segment app will get you different results and that’s a good thing.
Absolutely. How important is diversity of thought to Segment?
It’s so important. I think that you want to simulate how the rest of the world sees our app. We need people from all over the world, ages, technical backgrounds, etc. You want to simulate the rest of the world as much as possible. So yes, that’s why I believe in constantly keeping things fresh.
You mentioned a checklist that security pros keep in their back pocket to create a security program. Is pentesting always on that first iteration or do you save it as a nice to have for later down the line?
Yeah, it’s always on the list. There’s this idea that even if you’re a very experienced security contributor or leader you will always have blindspots. Even if you build all the appsec parameters you need to let it undergo testing. You could let the public just go at it but that can be dangerous. You don’t want to fall into an echo chamber of positivity. So it’s good to have that third party to double check.
You mentioned hiring the right team and having a team that can communicate with engineers and teach them to code securely and fix vulnerabilities. We notice this shifting left and DevOps becoming DevSecOps. Is this something you’ve seen at Segment?
Yes, that’s exactly what needs to happen. Any problem that is caught early is easier and cheaper to fix. I want to reference this blog from Leif Dreizler, Engineering Manager, Product Security at Segment who talks about this in detail here in this blog.