CISO Panel: Baking Security Into the SDLC

Richard Greenberg, Global Board of Directors, OWASP twitter, linkedin
Coleen Coolidge, Head of Security, Segment twitter, linkedin
Martin Mazor, Senior VP and CISO, Entertainment Partners linkedin
Bruce Phillips, SVP & CISO, Williston Financial linkedin
Shyama Rose, Chief Information Security Officer, Avant linkedin
abstract video

Shyama
Works in the financial industry. The biggests challenges for her are the supplier due diligence and collusion problems. She’s received warnings from DHS before about supply chain security.

Bruce
Works at an insurance company. There’s always a tradeoff between security and usability. Businesses generally care about revenue and usability.

Martin
Thinks about the culture aspect. You can’t just have security people telling devs their baby is ugly. “DevOps is ultimately a cultural discussion, not a technical discussion.” This is ultimately a people problem.

Colleen
Works at Segment, a rapidly growing startup. When you join a startup, you never know how someone is going to receive security. You could have had the best AppSec in the world at your previous place, but when you go to a new company, it’s completely different. They don’t know who you are, they may not trust you, but they suspect that you’re there to slow them down. So figuring out what the dev workflow looks, and being able to embed what you want to accomplish into their workflow so devs don’t feel like you’re telling them “no” or giving them a bunch of work. You want thtem to feel like you’re weaving it into their day to day that’s already happening.

They’ve found a lot of success with embedded security engineers in dev teams and having them build something with the devs. This shows you what devs struggle with on a day to day basis, what they have to deal with, and enables you to bring back these insights to the security team. You’ll model secure development for them that they can copy once you’ll leave, and you’ll meet devs who are passionate about security who you can later mentor and encourage them to be security champions.

The closer you can bring in the rest of engineering the better. The security team should not be seen as separate, you should be seen as a partner and a critical part of how engineering build things.

Richard
Meets upfront with engineering leads on teams and takes them to lunch. First impressions are crucial. They’ll remember 3 years later that you took them to lunch. You have to establish a dialogue with people you’re going to be working quite closely with.

Bruce
Views DevSecOps as “the perfect world where the security team and the operations team and the development team all get together to build applications that meet business needs and protect consumers and shareholders.”

To him, the #1 challenge with DevSecOps is that it doesn’t include the business. His primary challenge is getting the business to understand the complexity of building the apps they try to run things on.

He believes it should instead be called something like “DevSecBizOps,” because we need to add the business side into things.

Martin
DevOps’ value is velocity, taking the standard change and build processes and enabling devs to ship code quickly. We can also talk about DevSecOps as quality, not just security.

Colleen
She doesn’t like the term “DevSecOps,” because when we mash things together as a community, each person has a different idea of what it is and what it means. To her, it means that we see what the dev process actually is, where flaws are coming up, where certain teams need more educuation, where certain teams need to slow down, and where security automation should be added, deconstructing the whole process and figure out how we can reconstruct it with security along the way.

The devs she works with are happy to receive security advice and go through these extra steps because their nightmare scenario is deploying code that leads to a breach and headlines. Dev teams view the security team as helping them prevent these catastrophes.

There can be contention at times, but when the security team sits with devs and explains why certain practices are being used and their value, dev teams get it and see that security is there to help.

Martin
SAST can be a double-edged sword, you’re telling a dev that they’ve made it this far but have to go back. The best way he’s seen to do this is to view it as an education opportunity: if you find the same problem over and over from same repo or dev, help them get better. Security automation isn’t the answer, ultimately you want to instruct devs.

They’ve explored using bug bounty. It’s a lower cost model in which you get nebulous testing capabilities against assets that are in scope, but it does provide the value that it’s another opportunity for educating devs.

Shyana
She joined her current company when they had no security team but they already had a bug bounty program. She felt like they weren’t sophisticated enough to have the bug bounty program yet- the issues that were found didn’t add much value to the org. She put the program on hold until they were ready to take it on.

They get third-party pen tests with letters of attestation, which is a selling point for their customers. They also use pen testing as assurance for third parties they use.

Colleen
However you’re going to grow your org, at the end you’ll have a suite of things testing your code. There can be a lot of value in SAST and DAST, but you’ll probably go through a really long PoC and find that tools only partially work. Her challenge with SAST is that it requires lots of tuning and finds many FPs. This is an issue as you don’t want to give a raw report of 1000s of potential issues to devs.

As they’re building out their suite of tools for testing, they’ve found pen tests great for coverage as well as helping customers and ISO auditors feel good.

Segment has found bug bounty quite useful, depending on the researchers who are engaged. When a researcher writes up a really good PoC for an issue, you can weaponize it - when their security team submits it to the dev team, they drop everything and scramble to fit it, as it’s an issue found by someone external to their org who doesn’t know how everything works. This definitely lights a fire under everyone’s asses.

Richard
It helps to have someone on the security team with dev experience so they can participate in discussions around the validity of SAST and DAST findings to determine if the claimed mitigating controls are in fact appropriate.

Bruce
SAST and DAST are not a hammer - don’t beat up devs until they get things right. The idea is to find teachable moments. We shouldn’t have to wait for SAST/DAST scans for the smart people to work for us to find these things and autocorrect.

Work together as a team using the tools that make sense. Bug bounty is a tool. If it doesn’t make sense, don’t waste time and effort on it.

You don’t want to case friction between security and engineering if a tool is finding things your org doesn’t care about.

Colleen
Their security training, which aims to teach devs to think like a hacker, has been hugely successful. They use OWASP Juice Shop for hands-on practice, give tailored examples based on Segment’s tech stack, and they’ve asked devs to write up what they’d like to get out of the training to ensure the training meets their needs.

When you’re creating security training, don’t have your security hat on, have your dev hat on. What is it that’s missing from the traditional training you’re giving them? How can you mix things up? Devs are smart, engaged, and want to partner with the security team, make it easy to do that.

Their training has a CTF element, which makes people exited to be on the leaderboard and compete against their friends.

Your security team will never be big enough to keep pace with the rest of the org, so the secret is evangelizing and converting devs into writing code with a security mindset.

Shyvana
Staffing is something we all struggle with. She recommends starting to look internally, pluck people out of various parts of the org who may not even be in tech. She has an excellent security team member who was previously worked in the call center.

Bruce
His #1 security hire in the last 2 years was their former receptionist, a political science major who loves security.

“You’ll find people who are really good in all places.”

Colleen
One thing she’s learned working with executives is they don’t want to get in trouble.

Work with your security team to compile stats on the types of flaws your company has. Maybe there’s some disturbing pattern that keeps coming up.

Throw some metrics in front of the executives and do a demo to show how easy it is to use those flaws to create a really scary exploit. This can help make the executive suite aware that when there’s a legitimate risk that you bring them and they decide to ignore it, it’s off your chest and onto theirs. No one wants to be in the headlines.

Show them in black and white, we found this risk in our infrastructure, all someone would have to do is combine this and that to do something serious, and demo it for them.

“It’s like DARE in the 80’s, it gets them scared straight.”