When I was Director of Information Security (“DIS”) for a small internet company in the Washington DC area, I took over a program that had been managed in the head of a long time employee who led the security department, of which he was the only member.
The security department had only three functions at that time: advising developers on security best practices, managing patches, and coordinating audit activities for our Federally cross-certified Certificate Authority.
Like many small companies, we had processes, procedures, and policies that had grown organically over many years and were executed by people with deep internal knowledge about the environment. Everything was in people’s heads or buried in spreadsheets. Everything was managed, tracked, and executed manually, based on email requests or in-person discussions.
This would have been a great system for people with an encyclopedic knowledge of the environment who regularly put in 12 hour days, but it doesn’t scale. My first act as DIS was to create a plan to get out of this mess. To develop a plan, I had to communicate what security was and what my department’s key functions and metrics should be.
I was fortunate to work with some genuinely brilliant executives. Still, not all of them were InfoSec gurus, and they were more aligned with sales and financial accounting than with the nuts and bolts of technology. Though they were not technical, they were smart, and they had excellent bullshit detectors. I couldn’t snow them under with specialist jargon.
I needed something that communicated what we were trying to accomplish in straightforward terms. I needed something that communicated how we would structure the security program’s roadmap and measure our progress.
To communicate with the management team, I developed the “Jargon Free Security Model.” While parts of it may be original, it is mostly a synthesis of things I’d read and considered, informed by my own thoughts about the limitations of complex, jargon-laden security models.
The Jargon Free Security Model has only five elements:
Visibility: How much do you know about the environment?
Control: How effective is your ability to respond to security events in the environment?
Compliance: How well are you managing the artifacts and processes related to internal and external compliance regimes?
Innovation: Are you spending sufficient time identifying new techniques and technologies to help with Visibility, Control, or Compliance in the future?
Execution: Are you managing your resources effectively to accomplish the rest of the elements of the model?
These five elements are easy to explain, and it’s easy for non-specialists to see why they are important. Despite its simplicity, however, the model can be used to plan and structure a complete security roadmap.
In future articles, I’ll describe each of the model elements and discuss how they can be used to develop a roadmap.
By the way, we do this stuff for a living. Contact us if you’re interested in finding out more.
Copyright 2020, Credentive Security
