What is wrong with Infosec?

Why do we still have breaches? What is wrong with infosec?

The infosec community is on the wrong side of speed. Let me explain.

A security expert posted links to web site security analysis tools. Out of curiosity, I ran them on www.scling.com. The reports were mostly red, indicating several security flaws, and the tools recommended that I fix them.

This would have been fine if it wasn't the case that the tools were wrong, and reported false positives, which distract from what we should really spend our time on. How can I be so sure? The site is too dumb to have significant security flaws - it is merely static HTML and a few innocent lines of Javascript to adapt layout for phones. There are no security risks in the content because the content cannot do anything. The site is hosted on Google Firebase, and I am convinced that Google is capable of securely hosting static content.

If we look at the reports, there might be wisdom in there, but it is lost embedded in false positives. For example, I am told that I should add a content policy to limit what the pages might load. But the content is static, and everything that can be loaded is known at scan time. I am also told to explicitly state that I am content with the default referrer policy. Which makes a difference for no one, except the tool.

I also asked the tools to check my email account, which is also hosted by Google. They have world leading capabilities of identifying phishing attempts, yet the tools complain about precisely this.

We care a lot about security, since Scling's business is to take care of other companies' data processing needs. We have lots of security improvements that we want to do, but the tool suggestions are somewhere around priority 385 in the backlog. Following the tools would distract our security effort budget from things that really matter, and in thereby make our security worse. Many security efforts that I have encountered have negative security value. For example, many policies lead to shadow IT processes when people have to choose between succeeding in terms of KPIs or following policies - often an easy choice.

The infosec community is mostly built on outdated concepts - fear, policies, on-prem structures, and manual, one-off efforts. The community as a whole needs to mature, and these tools illustrated the need.

The infosec community is still primarily in you-must-slow-down-and-prioritise-security mode. There is a tradeoff between good security and development speed. Security and innovation is driven by different people, with conflicting goals. As long as the tradeoff remains, little significant progress will be made. Security and risk management will always lose against direct business needs in the long-term.

The QA community used to suffer from that tradeoff, but solved it. Testing used to be in conflict with development speed. Through a cultural shift and development of tools and processes, quality and development speed are now aligned.

In operations, there used to be a tradeoff between development speed and operational stability. Ops has gone through a similar transformation as QA, resulting in DevOps culture. Forsgren et al proved that it has resulted in both faster development and more reliable operations. (Do read the Accelerate book!)

Infosec needs to follow and get aligned with development speed. When the tradeoff is gone, security will significantly improve. There are efforts, aka #DevSecOps, but they are not yet widespread. Most remains to be done. There are plenty of ideas and concepts to learn from how QA and Ops went through the transformation to get on the right side of speed. 

In order to mend infosec, we must shift it left to the architecture and development stages, adapt security processes to make proper use of what the cloud can offer, and transform security to an iterative process with quick feedback cycles and continuous improvement.

This post originally appeared as a Twitter rant, which links to the original post. You can listen to more of my rants on getting aligned with speed in my DevOpsDays Stockholm 2020 presentation.