Matthew Runkle Arms Dev Teams with a Hacker Mindset
To create secure apps, developers need to think like builders AND breakers.
Veracode’s Matt Runkle started his cybersecurity career by designing malicious Android applications. But his aim wasn’t to create chaos; it was to help the government.
In this role, Runkle was one of a growing class of “white hat” ethical hackers who adopt a breaker mindset to help developers protect their software from real attackers. They play an essential role in the ever-vulnerable software world. According to the Ponemon Institute's 2017 “Cost of a Data Breach” study, a company’s odds of undergoing a security breach are one in four—and each breach can cost an average of $3.62 million.
Although Runkle has put his white hat aside, hacking is still a major part of his job as an Application Security Consultant at Veracode. Now, rather than personally hacking, he teaches developer teams at other companies how to think like hackers—what he calls having a “breaker” mindset—to help the companies address and manage vulnerabilities.
In the Q&A below, Runkle—who has a master’s degree in cybersecurity from New York University—explains why software companies everywhere should equip their engineer teams with this training, to keep software development secure while maintaining today’s agile pace.
Modern Software Factory Hub: Can you describe what characterizes a “breaker” mindset?
Matthew Runkle: With a maker mindset, the outcome is a functioning, robust application that operates and performs designated tasks. A breaker mindset looks at the same application and uses its functionality to do something else.
One classic example is called “phreaking”: someone figured out the sequence that charged callers for placing long-distance calls and then used it get free calls. The maker designed a functionality in which playing certain audio tones ensures that the right account is billed. But the maker didn’t intend for someone to reverse-engineer that sequence. There were no defenses that would prevent someone from gaining access to the underlying functionality.
MSF Hub: So, developers today should try to wear both hats—“maker” and “breaker"?
MR: Exactly. They need a maker mentality because that’s what’s going to build their applications and software correctly. But every time they add a feature, they need the breaker mindset to consider how someone might input data in an unexpected way, either for malicious reasons or just out of curiosity.
DevSecOps is the new buzzword, and it involves building security into your development cycle. Part of that is making sure that a developer’s training process includes security training.
Integrating Security into the DNA of Your Software Lifecycle >
MSF Hub: Do most developers have enough security experience?
MR: It’s often assumed that developers know how to prevent security flaws, but we’ve seen that that’s not necessarily the case.
When I first started at Veracode, a developer’s role was to explain to clients where an application was flawed, and how we could fix it. We’ve evolved by adding new services, primarily around education and augmentation of security knowledge. For example, we now meet customers for immersive, onsite workshops that teach them the basics of application security and let them experiment with vulnerable applications.
I really like the training portion of my job. Once people get a little bit of experience exploiting and then patching vulnerabilities, a light clicks on: They get it.
MSF Hub: Does the number of security breaches happening these days make it more challenging for developers to manage vulnerabilities?
MR: Security is a lot more public than it used to be. Many breaches now boil down to some of the same fundamental principles, though. Hackers are using some basic, fundamental techniques that have been around for a long time. Developers, then, need to understand and internalize those concepts to try and prevent breaches.
MSF Hub: What's it like engaging with companies about security?
MR: My supervisor once told me that security consultants are 60% psychotherapists and 40% security experts—and it’s so true. Our job is to approach an organization and say: “Hey, you have a whole bunch of flaws. Your application is insecure.” That’s intimidating and—in most cases—developers are under tremendous deadlines. My job is to figure out how we address those security vulnerabilities in a way that works for that organization, one step at a time.
MSF Hub: Are there any particular vulnerabilities that software companies should prioritize?
MR: Application security is a very large piece of the puzzle, because applications are at the surface of an organization. If your application has weaknesses, it's easier to compromise it further. You also have to consider network security and operating environments. But identifying and focusing on critical applications that have access to sensitive information is a good place to start.
MSF Hub: What will the next development hurdle be for companies?
MR: There’s been a big shift to providing microservices—delivering specialized applications responsible for doing one small thing well. With this structure, companies can build larger, more complex applications by assembling smaller microservices together. Because this approach requires passing data back and forth, we’re going to start seeing flaws stemming from the interactions of multiple services, abusing that data transfer to break the application. But, it’s also an opportunity to apply the breaker mentality and figure out what we can make that application do that it wasn’t intended to do.