Why the Security Policy is Dying
Security policies, a familiar tool of the CTO or CISO, are dying off, and I am glad to see them go. Long narrative descriptions of a top-down prescribed security policy ideal are a meaningless effort that can now be replaced by a more sensible, accessible and effective process for defining security.
In my previous role as CTO for a startup, I was in charge of security policy. I managed that role as we always have; I started writing policies. Eventually, I had 20 narrative security policies. When a customer wanted to know about our security, I would show them the policies and they would be impressed. Customers never read all that text, though—and neither did anyone in my company.
It is hard to live by an unread policy, but that is not the only flaw of a security policy. In our world, where security threats and compliance requirements are increasing, an ineffective policy that takes up a lot of time is the last thing we need. Hard to map to standards, hard to put into practice and hard to validate: The complex and arcane security policy is a broken system that has to go. The replacement, control-centric security, takes its inspiration from Agile software development.
Lessons Learned From Software Design
Security is at a crossroads similar to where software development found itself during the early 2000s when we realized that our waterfall process was failing us. Before the Agile process changed software creation, we would start out a software project by writing reams of requirements, defining a critical path and then agreeing to a ten-month timeline. It never worked.
One change allowed software developers to rethink the entire process; that same change can now enable our improved security posture. The key is the user story. Instead of voluminous top-down requirements statements, agile processes rely on a plainly written sentence or two that explains who should do what and when. Each user story can be tackled individually and a test can be written to confirm that it is in place.
The user story is changing security just as it changed software development. The value of this process to security is vast and worth the dramatic shift from a top-down, narrative-centric process to a bottom-up, user stories-focused process.
Control-Centric Security: Applying the User Story to Security
With user stories as a starting point, organizations can create a control-centric process for security driven by ground-up reporting. Owners of a security process write their own story instead of receiving it from on high.
For example, a user story could say, “Access to APIs is authenticated and encrypted by the transport layer security (TLS) protocol over hypertext transfer protocol secure (HTTPS).” A test can be easily stated as, “Take a screenshot every quarter of the web service configuration showing HTTPS and TLS enabled.” We can assign a person to this task.
Instead of writing long documents that never get read, the CISO becomes a consumer of short, self-reported user stories. These stories are aggregated into a narrative that is in use the moment it’s written.
Magical Standards and Compliance
Once you have implemented a control-centric approach to security, you have performed a compliance magic trick; making the bulk of the work disappear from an audit.
When it comes time to respond to an audit or prove compliance, the first thing that a policy-centric CTO office does is to produce the narrative policy. Again, no one reads the policy. Then, the team has to fill out the table of controls and responses required by SOC 2, HIPAA or another standard.
With control-centric security, the stories become the controls. Associate them with the proper standards and you are ready for the auditor!
Shadow IT and Evolution: Managing Change
We know that the technology stack itself will constantly change. In one survey, 40% of CISOs believed their current cybersecurity strategy would be out of date in two years. As applications come and go, keeping a security policy up-to-date is impossible.
CISOs can lose a lot of sleep worrying about shadow IT. A business owner can quite easily subscribe to a new SaaS application and load sensitive information into it. Did they require complex passwords? Is the data stored securely?
In a control-centric process, that owner simply writes new user stories for that application and delivers them to the CISO. Instead of being imposed upon, the business owner is enabled and empowered.
As an organization grows, policies need to change. In our example of a control on an API that requires encryption, that might not be true for the new public API. It’s easy for the owner to rewrite the story to state that it applies only to APIs with private data.
Empowered Responsibility
At industry conferences, I often hear about getting the board to buy in and prioritize security. The board believes in security. The problem is not what the leadership believes, it is that the work and ownership are not distributed effectively. When I was the CTO, I had to manage the whole standard, but 60% of the standard was about business practices, not IT.
I have found that simplicity, transparency and empowerment are the keys to getting security controls in use. By ditching the “security by gravity” policy-centric approach altogether and building controls from user stories, we save time and run a more secure shop.
