It’s been a while since I blogged, but as everyone following me on Twitter, I’ve been in the books doing my own research on Safety Science and Resilience engineering literature. In inspiration for this post, I’d particularly highlight Sidney Dekker’s “The Safety Anarchist: relying on human expertise and innovation, reducing bureaucracy and compliance”, which I’m almost finished with and has been really expanding my understanding and worldview of the multitude of factors which influence and constrain Information Security in organisations.

So the title says, “Compliance is not Security” which is something most security professional tout at some point. What is typically meant by it or the overall intent of saying so is a reminder that “ticking boxes” isn’t enough to secure an organisation and that our security programmes must include more than the “bare minimum” as set by a standard such as ISO 27001, as standards tend to define expert-agreeable baselines (the process by which ISO standards are developed and established, requires an initial development and approval by an international committee in which many countries are represented and need to achieve a majority consensus to finalise and approve). And I’m ok with that, I completely agree with that position.

However…

There’s a “dark side” to what that usually entails or on how it is usually enacted, and to make sense of it we need go a bit further behind to understand current best practices about Management and how they permeate through our organisations.

I’d posit that Management overall (and this affects Finance, Security, HR, Procurement, etc) have all developed management systems which supports organisations in not only evidence due-diligence of each expert domain, but do it in a traceable and repeatable way across the organisation, so we can evidence to any stakeholders that we do $THING according to good and best industry practice. And the way this is implemented, tends to rely on the legibility of the work being managed. What I mean by this, is that most of it rests on the assumption that the work to be governed can be clearly defined, with all the required tasks identified, the sequence in which they’re done which make up the rules (which are yet another expectation) that are expected to constrain how actual work is performed, and this legibility in turn enables measurement (eg if I know what the work should look like, and I know what in the process certain artefacts are created, then I can look at those created artefacts and assert if my rules are being followed).

So, we all build these management systems (with all its legibility in the form of policies and processes, and associated metrics) which help us “scale” (as it’s usually referred to) on making sense of what’s happening on that particular expertise across the whole organisation. The emergence of this type of practice can probably be traced back to Scientific Management and Taylorism, and the introduction of government regulations affecting different domain expertises. We had to develop these types of management approaches to satisfy a very pragmatic need: assure government and entities with which we have commercial contracts that $THING is well managed in our organisation, so they have assurances that we provide competent service and also generates outputs which can be referred to in courts for instance or external auditors.

Now, there’s nothing wrong with this in theory. This serves a pragmatic need and provides a shared mental model of how to approach problems. Plan-Do-Check-Act and all of that. But this is where “Compliance is not security” starts going wrong. And it does so for 2 key reasons: How we approach the doing and management of what’s “over and above” the compliance requirements, and how legible real work actually is.

Steven Shorrock wrote a great article on the varieties of human work, and for for this argument I’d highlight the differences between Work-as-imagined and Work-as-done. The fields of both Safety and Security have developed overtime to be these specialisations on “what constitutes safe work”, so we have these Compliance teams who likely have never done the work itself writing all the rules and procedures to constrain that same work to make it safer or more secure. This is the first challenge of “Compliance is not security” as it tends to take the form of ADDING (it’s always an additive approach over time) to this massive management system that assumes work is done the same throughout it, when we know from “Accelerate” research that “teams have their own context, their own systems, their own goals, and their own constraints, and what we should focus on next to accelerate our transformation depends on those things”[Forsgren] and we also know that real-work (work as done by practitioners) has a form which is affected by continuous and dynamic pressures between workload, economic and safety boundaries [Rasmussen].

So all this legibility that our Management systems require and our policies and procedures assume isn’t an accurate depiction of work-as-done. I was surprised to see Dekker and I agree on something else I wrote about here in the Safety Anarchist book, which is the more we add detail to these policies and procedures the more liability we create, as we effectively write down the expected function of an extremely well defined piece of work, with known parameters and performed in a context without all the competing pressures which exist. (refer here for that blog post “Why your security policies are a business liability and what to do about it” )

And because we’re expected/required to have a management system, all these “over and above” things become extensions to these management systems and we add tons of paperwork (which never gets removed, only added to) and non-productive resources to just check on things, with the added problem of periodically trying to reconcile what “should have happened” because policy mandates and what actually went on. The end result, is we keep chasing a debt of our own creation and demanding adherence to rules which make no operational sense for those doing them. So if real work isn’t as legible as our management system, our management system will forever be grappling with that difference.

So, this view of “compliance is not security” exacerbates the pragmatic problem that all compliance/audit functions face in reconciling work-as-imagined and work-as-done.

But “Compliance is not security” can mean something different. Most (not all), of what is Compliance tends to be focused on discreet components in which a stricter Compliance-view is helpful and pragmatic. eg my policy says that backups must be performed, so I can programmatically check if EC2 instance X has configuration Y through my cloud API. So for these things which more easily made legible, the pure Compliance approach supported by automation for verification is, in my opinion, a very useful pattern to enable communications between different teams as requirements get integrated into existing feedback loops.

But here, “Compliance is not security” is a reminder for the emergent nature of security. Security is more about the interactions of components (which tend to propagate effects) than their individual characteristics. Complex systems, sociotechnical systems are defined by their interactions so that’s what we should be looking to.

“Compliance is not security” in that just ticking the hopefully-legible compliance boxes isn’t enough, but that to understand how secure the “things we do” actually are, we need to better appreciate work-as-done by practitioners, what sacrifice decisions do they usually make and the patterns for decision making which accompany them, how they tend to make decisions under their normal constraints within workload, economic and accident boundaries, where our policies are trying to dictate operational expectations that can’t possibly be reconciled under these dynamic and continuous pressures of the compliance monster that’s been additive through your organisational history.

“Compliance is not security” because we don’t need more processes and more role authority. we need better understanding of what knowledge workers are actually doing and ask more questions, and write rules and policies they can subscribe to and not the ones our compliance books expect, or better yet, delegate their writing and collaborate for any big problems. Understanding from Senior people what heuristics they use (when is it really bad ? or what are some indications of $THING that you’d prefer if someone Junior would come talk to you about it before doing, because there’s a lot of nuance that the expert knows and everyone else doesn’t ? Real work is THEIR expertise, not yours.

“Compliance is not security” because Compliance doesn’t track the relationships you’re building, how you’re fostering informal networks to make security effective and relevant and integrated in practices, and not external mandates dedicated for Compliance satisfaction.

“Compliance is not security” because ticking boxes on spreadsheets has generated an expectation in your organisation that that’s all “Compliance bring to the table” so you’re not invited where trade-off decisions are being made and you need to force people into your rooms through role authority.

So, yes. We agree. “Compliance is not security”, but not like that. Let’s use it as a venue for more insight, not to ossify outdated practices at the expense of operational clarity for those doing the work.

“Compliance is not security” because a lot of what makes security work get done and how we can perceive as the affordances and opportunities for change, is NOT legible. You can’t write a manual for them. You need to talk to people (experts and non-experts) and understand their world, if you’re to having a fighting chance of “why it makes sense to them” or how they make sense of their own work.

References

Forsgren PhD, Nicole. Accelerate . IT Revolution Press. Kindle Edition. 

Rasmussen, Jens “Risk management in a dynamic society: a modelling problem” https://orbit.dtu.dk/files/158016663/SAFESCI.PDF