How many times have you heard "Security is a process"? Say it often enough and it produces a certain Zen-like calm. But what does it mean, is it likely to happen or even achievable?
I have often wondered at the tremendous number of "silver bullet" efforts in the security industry. The first time I saw the trade show floor at RSA I was powerfully moved, and not in a good way, by the sheer number of people questing for the Seven Minute Abs approach to security. Most of the answers were not on the tradeshow floor, they are back at the home office, lurking in source code and the processes that built them. I wondered - security is a real problem, these people know this, so why were people here in San Fran talking to vendors about Bassomatics instead of back at work getting the job done?
Turns out there is an answer - this is how pesky humans operate. Its situation normal. John Kay's recent column in the Financial Times Why do we welcome innovation to products more readily than to processes? is one that every security pro should read.
"Children love to play with new toys but hate disruption to their routines. These traits persist in adult life: innovation is readily adopted when it is incorporated in new gadgets but innovation that involves doing things differently is resisted.
Look around a university. At a superficial level, modern information technology has changed everything. Most activities — communication, scheduling and presentations — are conducted electronically. At a deeper level, nothing at all has changed. The course structures, materials and the methods of pedagogy remain essentially the same.
As Richard Nelson, the economist of innovation, has pointed out while American children are much healthier than they once were they are not much better at learning to read. Innovation that comes in a pill or injection is easily adopted: innovation that manages a process better is not.
It has always been so. Anaesthetics were developed in the mid-19th century and soon all surgeons were using them. However, when a Viennese physician discovered that the most important thing surgeons could do to keep their patients alive, especially those patients who were newborn infants, was to wash their hands, the profession resisted the innovation for half a century. While doctors would readily experiment with new chemicals, they fought any acknowledgment that their procedures were defective."
Again, go read the whole piece.
You see security pros are engaged full time as change agents. Security processes are fundamentally new to most organizations. Companies are trying to go from Crawl to Walk to Run. Even if your company is crawling along in security, its trying to get to walk, these introduce major process changes. Do not underestimate the level of friction that process changes can incur. Do not underestimate the amount of process engineering required to get the job done. The knock on effects of this are why most security programs fail to achieve their goals. Usually better to start with something simple like a checklist - must wash hands before deploying code to production.
One test that I like to use, is to see what is the most security value that you can create with the least amount of process change? The main reason I really like Gauntlt is that it does introduce a fundamentally new development process, instead its engineered to fit inside of existing development processes. Sure there are any number of other theoretically better SDLs out there than putting Gauntlt into Agile test cases, but Agile is how the hundreds of developers at your org are already building software. Will you be successful changing how they build software and rolling out new security mechanisms at the same time? Or is it better to find improvements near at hand, and embed security inside existing processes?
Process engineering is deeply unsexy. It is about as far removed from the glamour, fashion show world of security conferences as you can possibly imagine, but its where the actual changes occur.