The Consequences Of Choosing Speed Over Security

This article originally appeared in Forbes.

In the wise words of Richard Powers, “Money you lose by slowing down is always more important than money you’ve already made.”

The first time I witnessed a bank security expert accept the electronic theft of his bank’s money was a career-defining moment for me.

In 2005, I had a front-row seat when a few of the world’s smartest security experts identified — for the first time — a security vulnerability called cross-site request forgery (CSRF/XSRF). We proved that this vulnerability could be used to steal money from our client. Discovering a new class of vulnerability was exciting. We were also pleased with the fix we identified that would thwart any attempts to use our newfound vulnerability to break into the bank’s systems. But much to my surprise, our customer refused the fix.

I didn’t understand. How could a bank possibly stand by and watch money being stolen?

It turns out that while our fix would curb theft, it may have also slowed down new account sign-ups. In other words, the fix was too risky because there was a chance it could hinder growth. Our client decided to let the theft continue and take corrective action only if the losses became unbearable.

Built To Accept Breaches

It is important to understand that most enterprise customers buy software with the knowledge that there will be a breach. They accept this inevitability, and controls are needed to ensure that the losses do not become unbearable.

This is classic and rational risk mitigation. Like our client, most of the world’s largest software companies prioritize speed over security engineering as well. Speed sells, and security may slow down market expansion. Taking a risk-based approach convinces software companies to invest in legal, incident response and public relations to mitigate the damage of breaches rather than to simply engineer products that are secure.

Just this past month, Microsoft’s PR was masterful in getting ahead of the media cycle surrounding recent Teams vulnerabilities, going so far as to push responsibility to the government. It’s a well-worn strategy and ensures software is built to perform at the expense of security. This is why many of us in the security industry were not shocked by the SolarWinds breach and fallout. Vulnerable software is inevitable given the current market forces and shifting trust models.

However, the general public and elected officials were surprised and shocked upon learning that our most critical national security systems relied on products that were so easily breached. In the case of SolarWinds, public information makes it easy to conclude that this was a fast-moving company that deprioritized security in favor of rapid growth and increased margins. In the case of the remote code execution in Microsoft Teams, it seems we can draw a similar conclusion — this was a fast-moving business that deprioritized security in its quest to dethrone Zoom. Microsoft is perhaps the world’s most prolific security engineering organization, yet it, too, fell into the trap of choosing speed over security. 

Tying Security To The Bottom Line

Back when our client was teaching us that securing software was not the priority of their security team, my colleagues and I got a crazy idea. We created five-year plans for building security QA processes that would quantifiably improve the security of products. We created a win-win cost model for security testing that would flatten based upon the maturity of our work and the security of their products. 

We first presented our idea to one of our best customers. Their security team was excited, but the finance team was not. Once again, I could not understand, so I pressed the procurement department. The procurement officer told me that they could not be distracted by the more secure products and millions in savings we would deliver. In fact, they were focused on a different negotiation that, if successful, would save them more than three times what they spent on security testing. That other vendor sold them break room snacks and drinks.

We have guaranteed a future of more events like the SolarWinds breach if market forces tell CFOs that they will be rewarded more for cheap breakroom drinks than securing their products. We need regulations that will truly penalize technology companies when they put our information — and national security — at risk. With tangible consequence, real engineering discipline will be brought into the artform of software development. Only then will the industry, and future billionaires, view security differently — as a necessary step in the process, not something that will just slow us down.