The Colossal Challenge of Simplicity

I want to live in a world where security can be made simple. It’s that simplicity that’s inherent in business logic, technical designs and elegant process. Unfortunately, that world seems fundamentally incompatible with the world we actually live in. Bummer.

Some of you are old enough to remember the days when there was a single ingress and egress point in your corporate networks. Back before everyone had a “smart phone” and pagers were the thing important business folk carried. When the T1 line was what distinguished a modern company from the old guard.

Remember how simple it was back then?

Today that simplicity seems to completely elude us as security professionals. Security deals with extremely complex systems where applications, data and users interact in the hundreds of ways they were designed for, and potentially dozens more that no one predicted or expected. Patches and fixes pile up over time. The complex patchwork of fixes and patches can be completely mind-numbing over the length of the lifecycle of even a single application. Keeping track of fixes requires a full-time job!

If we readily admit that complexity is the arch-enemy of security, how do we get back to simple? Is there even a way back? Are we hopelessly lost in the entanglements that are years of legacy “stuff” built up, coming back to haunt us like last night’s 2 a.m. drive-thru burrito?

I personally don’t think it’s hopeless. I’ve witnessed first-hand some masterful crafting of security solutions that shine in simplicity and get the job done. I’ve come to believe that the complexity in security solution is a result of addressing symptoms rather than fixing the root causes of problems. Think about it for a moment.

Remember Cross-Site Scripting (XSS)? I do. I recall, early in my days as a security analyst, penetration testing a web app and finding dozens of these bugs everywhere in one particular application. Of course, I devised a complex scheme of character encoding and sanitization additions to the code to address the points at which XSS was manifesting itself. Then, someone who quickly became my mentor showed me a better way. She made me realize that if we look for simplicity we can often apply the fix once – at the source.

This approach solved the problem, but also avoided introducing unnecessary complexity into the code base. Even with the best intentions and peer reviews, if I had asked a group of developers to apply a fix in 10 different ways in three dozen places they were bound to make an error. That error would likely not have fixed the original problem entirely and would also have introduced at least one new one. So, by minimizing the number of ‘fixes’ we recommended, we minimized the ‘oops’ factor too!

When you’re solving problems it’s easy to get lost in creating something complicated. I believe that the more difficult path is to simplify, simplify, simplify. Finding the root of a problem and solving it keeps us from chasing symptoms and designing ever-more exotic security solutions that could potentially create other problems down the road.