Interview: Why Security Teams Need To Embrace Change To Improve Application Security

Dan Cornell is the Vice President of Product Strategy at Coalfire. He is globally recognized as a software and cybersecurity expert, with over 20 years of experience building and developing secure systems. Cornell joined Coalfire in 2021 after it acquired Denim Group, a global leader in the application security space, where Cornell was a co-founder, and CTO. 

As well as his role at Coalfire, Cornell helps organizations around the world improve their application and software security processes, speaking at international conferences including the RSA Conference, OWASP AppSec USA and EU, TEDx, and the BlackHat CISO Forum.

After RSA 2022, we spoke with Cornell to discuss the Coalfire platform, the challenges developers and security teams are facing today in a quickly changing threat landscape, and his advice for security teams to improve their systems’ resilience against sophisticated cyber-attacks. 

Can you give us an overview of Coalfire, and the security solutions that you offer?

Coalfire is a giant cybersecurity services firm, on the order of four thousand projects a year and over one thousand pen tests per year. We do 70% of the FedRAMP ATOs, so we’re huge in the FedRAMP space, and we cover compliance across seventy different frameworks, we do about two thousand compliance assessments per year. We’re really, really strong on the compliance side. 

And then we also offer cloud and application security. We do a lot of work with the top five cloud providers: Amazon, Oracle, IBM, Google, and Microsoft. We work with eight of the top ten SaaS businesses, such as Salesforce and Adobe. And so, we’re also really, really strong there. 

And then we have our technology platform, both on the on the compliance space, as well as the vulnerability and risk management space. We are starting to deliver our solutions via those technology platforms.

What are the main challenges that security teams are facing today when it comes to cloud and application development? 

The real challenge is digital transformation. As techie person, I die a little inside every time I say digital transformation! But I think that it is helpful to recognize as a real force in the industry. Organizations are undertaking these digital transformation initiatives as a risk mitigation strategy. But not cyber risk, but existential risk. Because they’re being forced to provide better ways to interact with customers and to provide value to them. 

Think of two different experiences renting a car. One, you fly in, you go to the rental place, they pull up your record, they bring out a car. Oh, wait, you know, that car’s license plates are out of date. Okay, they take that car back. Again, get a new car. Oh, wait, that one needs to go through the carwash. This is sort of disjointed, it’s different systems that aren’t working together. Versus a situation where, while you’re in the air, you get a text message from the rental car agency saying, “Hey, your car is in slot A5.” You roll in, it’s the exact car you wanted. It’s in A5, the keys are in the car.

Obviously as a security professional, hackers breaching things is the worst thing in my world. But the actual worst thing is to be the last CEO of a company because you missed these major changes in the industry. And all of a sudden, you’re the most efficient buggy whip maker in a world that no longer has a need for a tremendous volume of buggy whips. 

With that as the backdrop, we’re seeing that the security organizations are having to change. And security used to have a goal-line defense, it was the ‘department of no.’ You’d show up and say: “We’d like to provision some servers to do XYZ,” and they’d say, “No, we’re not going to do that because of XYZ requirement.”

Well, that’s getting flipped around because at the CEO-level or the board level, folks are saying to security teams: “No, you will undertake this digital transformation.” And that’s forcing these organizations to move away from a siloed type of culture to more of a DevOps, or hopefully a DevSecOps type of a culture where you break down the barriers between these different groups. 

And this scares the hell out of most traditional security organizations and puts a decision on the security team, where they can either keep trying to work in an obstructionist, pure risk avoidance type of a culture, or they can adopt a different approach and say: “How can we rebrand ourselves as an advisor about risk?”

It’s kind of like improv comedy. In improv, you don’t say “No, but.” You say, “Yes, and?” So, when the development team says, “We’re going to use serverless in Amazon for this new thing that we’re building,” and a traditional security organization would say, “Absolutely not, we’re not going to let you do that,” more modern security organizations need to take the approach of offering more architectural guidance, more testing guidance, and showing technical teams how to do that in a way that is safe.

It’s a culture change that a lot of security organizations are not really comfortable with, but they need to either get comfortable with it, or they need to get comfortable being uncomfortable. Because that really is the mandate, if you look at it from a business risk standpoint, security teams need to figure out how they do the good improve, the “yes, and?” so they can enable the technology organizations to be successful in a risk appropriate manner. 

That’s really what we see as the challenge for a lot of modern security teams. The business landscape has changed, and like everything else, security teams have to change with it. 

How is Coalfire helping security teams to deal with these challenges?

We provide a spectrum of services, from the more advisory services, such as helping organizations build programs and driving better program maturity, all the way to providing unique, penetration testing, application testing, and cloud testing services. 

So, as organizations are building these applications, especially with these cloud native types of architecture, we can help them in advisory services as they’re setting up their program and then making sure they were built in a way that meets those security priorities. And by interacting with them, we can help them to grow better maturity across their program over time.  

When you talk about application security maturity, what does that look like in practice?

It really is a journey that an organization has to go through, from having a program that is not necessarily structured, to one where you get a set of practices in place, and you scale that across the practice. And then at the highest level, where you are doing a lot of measurement, and then you are using that data to really accelerate the program. 

We meet organizations across that spectrum. At a very early stage, you ask them, “Do you have a list of all the web applications that you’re developing,” and you get what I like to call a ‘two shoulder salute.’ That’s low levels of maturity because you can’t protect attack surfaces that you don’t know about. 

Once you’ve got that awareness in place, we look at how we can scale that across your program as a whole, so we have a risk appropriate level of coverage across all applications. And some applications are very critical, managing very sensitive data, and so it makes sense to apply a greater degree of inspection to them versus applications that are managing lower risk data.

And then, at the highest level, it’s about matching security inputs with security outcomes. It’s how organizations invest the limited security resources they have available into appropriate security inputs, so we see better security outcomes.  So that’s when we look back, and we try to run some experiments to find out what has worked well, and what hasn’t. And really, it’s starting to take a much more quantitative view of the program. 

Are developers more focused on creating secure applications than in the past, with the backdrop of increasing data breaches?

Yes, and I think there’s a segment of the security industry with a belief that developers just don’t care about security. But what I’ve found is that developers actually do care about security, no developer sets out to say, “I want to write your code that has bad security properties.” But there is a lack of education.

I did a TEDx talk a while back talking about how when I was at school, I took every computer science class I could fit in my calendar; but we almost never talked about security. Developers don’t necessarily get a lot of this training, either through Code Academy or through university. So, one challenge is, how do we get resources to these folks, and change the install base so that developers have more security training. Coalfire does security training for developers, but that’s not necessarily systemically the right answer! 

But then, on the other side, I think it’s important to understand that while developers do care about security; it’s just one thing that they care about in a spectrum of other issues. What they get judged on is getting features finished in an approved timeline. You can write the most secure code in the world, but you can end up being the developer that never gets their code finished.

I think that is important for security folks to recognize. For the average developer, security is important, but it has to take a position among a variety of other concerns. 

What is your advice to teams looking to improve their security processes and achieve better application security? 

For organizations that don’t really have a program in place, we can come in and do a maturity assessment, but everything will get zero, which won’t be super helpful! So, for organizations that are really just at the outset, just getting on the path, my typical recommendation is to take a handful of applications, across different parts of the organization, and run them through some testing. Use this to try and identify some of the problems that your technology teams have. 

Then, take any security vulnerabilities that were identified, and run those through to remediation. You find problems? Great. Let’s find the team that was responsible, and communicate to the team, so they know what they issues are. Let’s get them to prioritize this versus new features and functions. Let’s run it through a remediation cycle, an then we have some visibility into how this process works in any given organization.  

For organizations that have a little more maturity, it’s looking at getting more consistent in how you are applying these things. And ultimately, looking at the numbers, so you can have a better understanding of how you drive better decision making. Because every security organization, even in the best-case scenario, will have a one to one hundred ratio of security professionals and app developers. Security is just outnumbered! And there’s no way around that. So, your application security program is never going to have the level of resources for you to do everything that you want. 

And so, the question is, how do we make sure that with these limited resources, we make the most effective use of them? For every unit of resource spend, we want to see the greatest possible reduction in risk exposure for the organization. At the higher levels of maturity, you can start to play around with that math.

You can find out more about Coalfire here: https://www.coalfire.com