View Security as QA, not Insurance

My very first job after college back in the mid-1980s was as a Shipper/Receiver. I had come out of BCIT from the Robotics program and discover (surprise, surprise) that there weren’t any robotics jobs. I ended up going up against full Electronics grads for electronics jobs and full Mechanical grads for mechanical jobs. Needless to say, I didn’t get those jobs and took what I could get.

That job was with Anatel, a manufacturer of thick film hybrids which are a  solution half way between PC boards and ICs. Think a ceramic board using conductive inks in place of electronic components such as resistors and capacitors.

During my time there, they hired a Manager of Quality Assurance. This was back when ISO 9000 was taking off and the entire world was big into building in quality (yet another business “fad”). That gentleman and I had long conversations and he explained QA to me in a way that is very apropos to Security now.

What he explained was that, in normal circumstances, when the day starts out people are fresh and focused. As a result, the quality of their work is at it’s highest. Then, as the day wears on, their quality goes down simply because they get tired and don’t focus as much. So, if you were to graph it, you’d see a spike in Quality right at the beginning of the day and then a ski slope down until the end of the day.

To improve quality, what you want to do is have regular checks that force people to bring back that focus. If you do that, you end up getting that original spike at the beginning of the day and then the rest of the day looks more like a saw tooth with a new “mini” spike occurring whenever the QA check shows up.

Because the quality of the work goes up, there is a return in investment by the company because you get fewer reworks, saved components, and improved productivity.

I bring this up because it’s the exact same with Security. At the beginning of a job, people are really focused on security. So you get that spike at the beginning and then, inevitably, the long downward slope in Security. The only difference is that we are talking Security rather than Quality.

So when you build security into each process, you are raising that bar like the Manager of Quality did at that company. You end up getting a saw tooth and the overall security goes up.

So how does this apply to Security Architecture?

Because people always forget that architecture has 3 components; technology, people, and process. If you focus on the technology aspects, you may be missing a MAJOR solution that could be available in the process side of things. Take for example a Secure Development LifeCycle (SDLC).

The SDLC was meant to integrate security into the application development lifecycle. By improving the “security quality” of an application being written, you end up with an all round better written solution. And getting security built into that development lifecycle is what a Security Architect should be focusing on. Not a “vulnerability scanning” tool but the entire process, end to end.

The same goes for any Project Management lifecycle which can be applied to infrastructure programs. Each stage has it’s important component of security. So build security into that process.

At the end of the day, most companies understand (now) that quality control brings cost savings. Well, security is just a specific type of quality. So stop talking about “insurance” and the “what if” conversations and start talking about “security quality control”. The end result is something that the business will understand.

Leave a Reply

Your email address will not be published. Required fields are marked *