Your security team is probably an infuriating obstacle – but it doesn’t have to be this way

Security is empty, meaningless theater — or, at least, that’s the lesson taught to most employees of most large companies. Security is your password expiring every few months, your inability to access crucial services if you’re new or a contractor, a salty message from a team you’ve never met explaining that your new initiative is not permitted, a transparently convenient excuse when someone doesn’t want to admit their real reason. Security is bullshit.

I can cite more examples from my own career as a consultancy CTO than I care to think about. The household-name company whose security team explained that cloud services were inherently insecure, until the day they decided to switch to AWS and began to explain how local servers were inherently insecure. The household-name companies that deluged us with detailed security questionnaires regarding the security of our servers, but whose assessment protocols were then unable to comprehend our “uh, everything’s in the cloud with GitHub and GSuite etc., we have no servers of our own” responses without hour-long hand-holding calls.

Which is why it was such a glorious breath of fresh air to hear Dino Dai Zovi‘s keynote speech at the Black Hat security conference in Las Vegas this morning. Dai Zovi, staff security engineer at Square, argued that the all-too-common model of security as a team, which sits and snipes at the people who actually build things, telling them no and pointing fingers, is in fact fantastically counterproductive.

Instead, he argued, security has to change its culture, which is far more important than strategy, which in turn is far more important than tactics. Instead of security becoming a faraway flaming hoop to jump through, teams should become responsible for their own security. Furthermore, security engineers should write code to help those teams. Fuzzing is great, but as he put it, “the next level is making fuzzy easy for software developers, because there are way more of them than there are of us.”

Most importantly — and most revolutionary — he argued that instead of defaulting to saying “no” all the time, and throwing up as many obstacles as possible, security people should always start with “yes, and here’s how we can help.” The fact this is so different from today’s practice that it actually sounds comical says a lot, none of it good.

The sad truth is that still, today, in the real world of enterprise software, security as most employees and vendors encounter it tends to be at least as performatively useless as the “take off your shoes & take out your liquids” security theater of American airports. The horror stories are legion. You have your own, I’m sure. Who doesn’t?

A couple more: Once a movie studio that wanted us to do some minor web-development work, for ancillary web sites with no real connection to their intellectual property, told us we would not be able to do anything unless our (primarily remote) workforce had continuous keycard access to, and closed-circuit camera coverage of, every computer which might work on these sites … then intimated that what they really needed was just for those boxes to be checked, not for any of that to actually happen.

Another time, a big company insisted that we become SOC-2 compliant — SOC-2 being a standard birthed not in tech but in accounting, and seemingly primarily designed to provide full employment for accountants rather than, you know, meaningful security standards and processes — without caring which, if any, of SOC-2’s five “trust services” we were talking about; they just needed to tick the “SOC-2 compliant” box on their list of vendors.

It doesn’t have to be this way. Security people could be contributors, rather than gatekeepers. And if they were, everyone would find it easier, more rewarding and more intuitive to contribute to security. Siloed security bureaucracies aren’t just slow and frustrating; in the long run they are inherently a more fundamental threat to the security of the companies infested by them than any exterior hacker or even APT ever could be. It’s long past time we all learned that lesson.