If your security function has been operating for more than a few months, it’s likely that you’ve put some management system in place to enable and support evidencing that your organisation manages their security programme and outcomes in a consistent, documented fashion. As security professionals, namely in Governance, Risk Management and Compliance, that’s expected of us and will be part of the initial concerns we have.

These management systems can range from a few spreadsheets support by some regular ceremonies, usually to talk about Risks, and a few templates you downloaded from the Internet for policies all the way to something more automated, with policies and risk management frameworks which have been discussed and agreed by multiple stakeholder groups with an interest within your organisation, and maybe supported by a GRC tool. More likely, your management system will be aligned to something like ISO 27001 which is the most common that I see in industry and government, and which allows Infosec GRC to evidence due diligence to Executives, Boards and external stakeholders like clients and, increasingly, regulators.

Management systems have certainly done very good things for us over the years, but in their strengths (repeatability, standardisation, normalisation) also lie their weaknesses.

A problem with how management systems tend to evolve, is that they have an additive nature to it. You always add more control statements in your policies, more standards and procedures so for those operating systems over 5-10 years old, all those things we’ve added over time may experience the following 2 problems:

  • “Things” are added without real collaboration in setting them between different stakeholder groups, namely those directly affected by these things. This often happens due to poor organisational dynamics between the traditional gatekeeping functions and the value creation structures, wheere they tend to use and employ different language, different practices and have a different disposition to have documented guidance expected to be adhered to at all times
  • “Things” that were once pragmatic and useful, are no longer valid or helpful because the context moved on and policies and procedures are no longer fit for purpose. Either because technology moved on to encompass different types of patterns (on-prem vs cloud architectures, DR/HA vs distributed systems, etc) or because the underlying practices used moved on as well (think Waterfall vs Agile vs DevOps).

This blog talks about that last one. How things we codify into our management systems have a tendency to, over time, become less relevant and constitute clutter.

This idea of clutter is a concept developed in the Safety Science literature, and if you follow my blog, I’m sure you’re not surprised by my attempts to apply some of those ideas and concepts into how we manage Information Security in organisations.

So, this is my adaptation of the concept of Safety Clutter to security:

Security clutter is the accumulation and persistence of security rules, procedures and practices that do not contribute to the security of work

In a nutshell, it’s all those things that we do because we think they’re the right things to be doing but that, in the real world and those supposedly affected, it doesn’t actually contribute to reducing risk in our development and operations practices. Saying it simpler, just because you wrote it down doesn’t mean that a) teams actually follow that practice and b) that even if they did, if would have any significant contribution to the risk that we’re exposed to.

What the authors of the concept argue is that we should continuously assess what in our management systems is clutter and take actions to actively reduce such clutter, to ensure that the expectations set by our management systems are actually meet and that involved stakeholders both understand and incorporate practices which help meet the requirements of said management system. For me, this is ultimately an exercise to reduce unforced errors (using terminology from tennis) in that GRC folks often end up creating unnecessary business liabilities through uninformed additions of requirements to management systems

The authors mention there are 3 dimensions we should do to identify if something in our management systems is clutter.

  • Contribution: the extent to which the activity has security value
  • Confidence: the certainty (either through evidence or strength of belief) which this judgment is made
  • Consensus: the level of agreement about the security value of the activity between those who mandate the activity, those who perform the activity ,and those who are ostensibly kept secure by the activity

Let’s look at each in more detail with an example you’ll hate me for, our typical security awareness training programme 🙂

Contribution: to what extent is our awareness training programme providing security value ? The value to GRC is obvious. we’re in a position where we can meet framework and standards requirements, and general expectations of clients and certifications we may have. For staff, it doesn’t contribute as much usually, from experience. Content tends to be decontextualised from the actual operational practices that teams perform. It may include general information about your classification policies and acceptable use, but that if not translated into actual practices through procedures in practice probably no one will remember that 30 min after the training. Some general niceties around phishing awareness are usually part of it, which while with some utility, again fails to address or understand the context as it’s just general guidance so may heighten awareness and chronic unease for a few weeks but likely to subside thereafter. So contribution, I argue, is likely to generally low if it doesn’t include team/department specific understanding of competing goals and pressures and relation to actual practice

Confidence: GRC people will likely have certainty through belief (big on belief) that the programme is effective. wee tend to measure success by counting negatives so, the thinking goes, if I didn’t have a phishing incident in the last year that strengthens our belief that the awareness training must bee working. For everyone else, they likely dread having to go through that once a year, just want to get it over with and appreciate that even the phishing stuff, may be interesting but within the pressure of responding to competing pressures in actual practice, that they won’t always be as attentive. If you receive 50-100 emails and that’s a small part of what you do in your job, we can’t really expect to be in constant heightened state of awareness 100 times a day, everyday for years. Our cognition evolved in ways that don’t make this possible even, and if people actually were that heightened all the time, I’d fear for their physical and mental health.

Consensus: Finally, the agreement about the security value between us, GRC, who mandate this and those who actually perform the activities. Again, there’s likely to be low consensus between these stakeholder groups about this value for the reasons I already covered

Identifying clutter can be done at any level. Programmes, particular policies or specific procedures and keep this information live is important to ensure our management systems keep being fit for purpose as our context evolves, and hopefully can be a practice you can adopt to open productive lines of communication between stakeholder groups.

Now, what I’m not saying is that you should stop all you’re doing and go deal with your clutter, Spring cleaning style. Our management systems, even if largely living in fantasy land, provide business value and us, GRC, need to be able to articulate why and how we’ve made changes to it. Certainly, I don’t want to be the one who watered down an expected control and a client/company I work for be breached 6 months after because a control was removed, so we need to be thoughtful and strategic about decluttering. Here’s how I propose you start:

  • Ask your operations/development teams a loaded question –> what is the stupidest thing you’re asked to do in the name of security, which you’re sure doesn’t contribute to it ? If you ask it like that, I’m pretty sure you’re going to hear it. Addressing that has the social benefit of them hearing that you’re interested in making pragmatic things to them and that you’re willing to make changes to management system based on their feedback. This will pay off in relationship building pretty quickly
  • From incident information, identify the areas where the expected controls aren’t working and do deep dives into why that it following this process
  • Look at policy exceptions, if you do them well. If you have lots of policy exceptions around a particular theme, that probably indicates that the policies aren’t really appropriate
  • As part of your security programme, focus on a particular area of concern. Say “access control”. grab your policies and procedures for access control, and go discuss with a few different teams which have different scopes how they’re meeting it and understand if your documents are introducing clutter or appropriate to each of their contexts, and if not, help them bridge that gap

I think this is a tremendously useful concept we should adopt and use strategically as means to ensure suitability of our management systems to the contexts we wish to affect, and being strategically concerned about ensuring this match between paper and practice will do wonders for fostering productive relationships by those writing rules and those expected to comply with them.