How modern workflows can benefit from pentesting

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, tell us about your approach for building a security program in general.

Imagine you’re faced with having to build a security program from scratch. It sounds great, as everyone wants to be a builder and leave their mark. But what happens to every security leader when you jump into a new position is that you discover gaps that need to be filled. You might find that practices you took for granted elsewhere aren’t actually being done at your new company. In some instances, they exist, but are being done intermittently or without the rigor you’d expect.

The security situation of each company is unique, and every program must be designed with this in mind. That means you must take into consideration the company’s customers, the attack space they live in, the tech stack they’re using, and the unique challenges they have. There is also a standard menu of things you’d want to make sure you’re checking off as well.

When you dig into the application security space, you have to think carefully about building your discipline — both the people component and the controls roadmap. When considering the people you want to hire, first look at what levels you need to fill and the qualifications for each role. For example, do you need a team member with a strong coding background? Additionally, I look for people who are comfortable with counseling and teaching developers how to code securely, someone developers will trust and respect.

While you’re building up processes within your application security department, you work with engineers all over the company – from DevOps, to infrastructure, to product engineers. You can teach each of these internal partners to support your program through various means, such as secure-coding practices. However, there is an operational rigor that the public and customers expect from your organization. It’s great that you’ve created an internal security team, champions, and process, but you also need third-party validation of the strength of your security program.

Let’s use bug bounty programs as the first example. In a bug bounty program, a third party takes a look at what you’ve scoped out in your brief. They test your system by pushing to see how far they could go if your app had flaw(s) or deficiency(ies).

This is extremely important, because security practitioners on the inside just see a myriad of things to fix, along with a prioritized roadmap. However, a bug bounty researcher may try approaches or ad hoc combinations that your team is not thinking about. So if a bug bounty researcher identifies something we need to fix, we reward them because they are doing us a favor by zeroing in on the holes we may not see, or may not have prioritized appropriately. We keep them apprised of our “fix schedule” and maintain that relationship moving forward.

Give us the 100,000-foot overview of where you see pentesting fitting into a cybersecurity program.

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 one to two times a year there is an accredited and skilled pentester going through the app and systematically looking for flaws, reporting on them, and producing a report. They go through a list and iterate on things that could be weaknesses or that we could be doing better. The produced report is a big deal and takes quite a bit of time.

Your pentester experience may vary, depending on the quality of the firm and other factors. With a vendor like Cobalt, where you have pentesting as a service, there’s less administrative overhead cost on either end. This means you can get a group of pentesters looking at your app or infra quickly. I appreciate that we can schedule through the portal on our own, list exactly what we want to accomplish, and do it on our own terms. It feels very transparent from our side.

It’s also good to have more than one pentesting firm on your bench. Sometimes customers will look at whether you just have one company always evaluating you or bring in a variety of companies. Beyond that, having people with different perspectives and backgrounds test your app or infra gives you different results, and that’s a great thing. If you capture “the unexpected” as a thoughtful part of your program, all the better for your company.

Absolutely. How important is diversity of thought to Segment?

It’s extremely important. For appsec, you want to simulate how the rest of the world sees your app. We need people from all geographies, ages, genders, technical backgrounds, points of view, etc. You want to simulate the rest of the world as much as possible; we believe in 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?

It’s always on my list. Even a very experienced security contributor or leader has blindspots. If you build your appsec layers well, you still want them to undergo testing. You could just let the public have a go at it, but that can be… dangerous!

As for your internal-folks-only doing the testing, you don’t want to be locked in an echo chamber of positivity or static skillset. It’s always best to have a third party double check your work regularly.

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. Whatever you can do as a leader to accelerate toward that outcome, do it. Any problem that is caught early is easier and cheaper to fix. I would point you to a blog from Leif Dreizler (Engineering Manager, Product Security at Segment) who talks about this in detail here. Even more recently, Jeevan Singh (Engineering Manager, Application Security at Segment) talked about another way we’re shifting left (I’m incredibly sorry for using that hackneyed phrase) with self-service threat modeling.

Colleen Pate, Cobalt: Thank you so much Coleen, it’s been a pleasure speaking with you and learning more about your approach to security programs.