Security and Friction

Let’s talk Friction. In kindergarten, we learned that friction lead to carpet burns. In high-school physics, you learned that friction was the force that kept objects in place even if the surface wasn’t perfectly flat. Here in the development and security community, we learned that friction is any process overhead that leads to things that people dislike - delays, more work, fewer features.

A textbook would say that process friction is a slowing force on a process that requires energy to overcome to maintain momentum. I’ve heard it argued that not all friction is bad. Sometimes, like when a driver applies breaks to reduce speed before a sharp turn, reducing speed before performing dangerous activities such as integrating new libraries, releasing new features, or building for new architectures can prevent incidents and issues. However, most would argue that reducing friction is a nearly universal good.

However, all of these views focus on the “slowing force” part of the definition and forget the human that has to provide energy to keep momentum. Friction pops up in more than just productivity processes. A volunteer lead organization will eventually peter out and disband without a strong leader, and most efforts’ first real existential crisis comes during a leadership change when the original person providing input energy is no longer there to turn the crank. Overcoming development delays due to friction requires developers to put in crunch time hours. Applying governance controls is often done through the power of people with clipboards. If I don’t put energy into typing this newsletter, it doesn’t get sent out.

Friction, then, is a people problem. It’s not so much always caused by people, but it’s primarily there for people to solve. Let’s look at types of friction that may be out there and how we can help apply a little bit of grease to get things moving along.

• Cognitive friction is what most developers have when faced with a security problem for the first time - They’re confused and it takes energy to iron out that confusion. This is often solved by either making the opaque transparent through communication and explanation, or building ready-made solutions that turn complex problems into easy-to-use reusable libraries.

• Collaborative friction is, as the captain from from Cool Hand Luke helpfully pointed out, “a failure to communicate”. When security team members and developers don’t work well or communicate freely, when schedules don’t match up, goals don’t align, or blamestorming prevails, collaborative friction needs soft skills to ease the tensions. Speak the development team’s language, learn their goals and incentives, and open up additional communication channels that integrate with how developers chat.

• Operational friction happens when processes, tooling, or outdated infrastructure is letting people down. I see this all the time with teams forced to use outdated SAST tooling to scan code written in modern languages and framework. Those old tools built for java web apps and c++ monoliths aren’t able to keep up with the built-in security features available in modern frameworks, or react to new threats caused by new architectures. This is where process engineering and tooling budgets are required. Of all the frictions, this is the one that can be solved by throwing money at the problem.

• Regulatory friction comes from outdated, draconian, or difficult regulations or laws that impact how software needs to be built and secured. Some of this friction comes in the form of adapting DevSecOps to work in SOX compliant organizations by redefining “Ops” to have split release/deployment processes and environments to support proper separation of duties. Other pieces of this friction may come from onerous testing requirements PCI DSS’s old requirement to pen test every release. Yet others come from FUD around regulation’s newness like we’re seeing with organizations trying to adapt to the SSDF. This is the type of friction that orgs have the least control over, but flexibility and expectations management go a long way.

• Technology friction can come in the form of outdated tools, tech debt, interoperability and compatibility issues, and good old software bugs. Solving tech friction requires creative solutioning, tech refreshes, and collaboration. Throwing money at tech friction isn’t as helpful as it appears at first blush because on-boarding to new tools may be tougher than adapting or fixing old ones.

• Security Friction. Yes, we have our own friction. Often times this comes in the form of “No, you can’t do that” or “You can’t do it that way” when the easy way is insecure. It might be easier to just echo user input back to the browser via the template engine, but a little bit of friction introduced by using a built-in encoding and validation library has a huge security payoff. However, one early security friction fail came from using the OWASP ESAPI library. Sure, it was better than nothing, but it had to be applied to every single output that would be sent back to the user, and if a single output was left unprotected, the entire application was vulnerable to cross-site scripting.

Hopefully this overview of the types of friction we deal with will help you alleviate unneeded sources of friction and inflict as little as possible when rolling out new processes, tooling, and governance.

There's always more words to spend on a topic like this one, but I've hit my budget for now. Stay secure, and never forget the humans.