Asking a DevOps team what they’re most worried about in their app is a great way to seed a conversation about risk. In my recent presentations, I’ve taken to emphasizing the use of threat modeling exercises as an avenue towards security awareness. Threat models are ways of reasoning about different ways an app’s data or users might be compromised. They can also be great ways to build security awareness by encouraging creative thinking about an app’s security in a way that drives constructive conversation and minimizes judgement about lack of security knowledge.

A penny-farthing for your threat model…

A key element to such discussions is using the “Yes, and…” principle, in which you guide the conversation not by negating someone’s ideas, but expanding on them or offering an alternative viewpoint. In this exercise, you are the security expert filling in gaps in knowledge and nudging tangents away from unlikely scenarios, but letting the DevOps team drive the discussion amongst themselves.

Bikeshredding is when this exercise devolves into distraction. The term echoes “bikeshedding” — a situation where a discussion (typically in software engineering) becomes overwhelmed by details irrelevant to the problem at hand. For example, if your problem relates to efficient structures for storing bicycles, it’s unlikely that the color of the structure contributes meaningfully to that efficiency. And that such ill-timed attention is counterproductive to the core task. It may also be as much about arguing over subjective choices as it may be about misusing data as an illusion about objective preferences.

In bikeshredding, a threat model becomes disjoined from reality. It may represent a scenario unduly influenced by ideology or one based on incomplete (or ignored) information.

A strong indicator of bikeshredding are models that begin with “Assuming…” or “All you need to do is…”. For example, “Assuming the Same Origin Policy is broken, then — “ it may not be necessary to continue this sentence if it involves a discussion of cross-site scripting or anti-CSRF tokens. Or perhaps the setup to an attack “just requires a DNS or BGP hijack” before the vuln under discussion could be exploited.

That doesn’t mean such scenarios aren’t impossible or that they should be dismissed. It does mean that threats are not unbounded agents that visit great woe unto apps or networks. Threat actors (those executing an attack) require resources and preparation. In some cases, those resources and prep may be nothing more than a browser bar and an unvalidated URL parameter. In other cases, those costs or sequence of events may be high and complex.

There is a place for stunt hacks, where an SDR Bluetooth spoofer affixed to a hedgehog launched (safely, with parachute) from a drone hacks an IoT fridge in order to obtain some tasty insects stored therein. Tinkering and creativity are fun. Always educational, it can sometimes inform practical appsec.

But there’s a reason that legacy systems and legacy software are notorious attack vectors. They’re easy and cost little for the attacker.

As you mature your organization’s stance and have more robust ways to respond to threats, you’ll also increase the time and resources required of an attacker. Over time, you’ll understand how successful attacks are executed. And, although you’ll continue to improve your app’s baseline security to prevent exploits, it’s highly likely that you’ll discover that an efficient detection and response becomes an equally important investment.

Use threat models to spread security knowledge throughout a DevOps team and engage them in prioritizing countermeasures and containment. Help them be informed about security topics and the chain of events necessary for various attacks to succeed. Avoid the bikeshredding and let them build the structure that handles user data with minimal risk.