Social practices and Timespan of Discretion in Cyber Security
Social practices and Timespan of Discretion in Cyber Security
If you’ve been following me for long enough, you’ll know I’m a massive fan of Jabe Bloom work, particularly on Sociotechnicity and Design transition.
In this blog, I’d like to explore DevSecOps or Security in a DevOps environment from the point of view of practices viewed from the perspective of scope of responsibility of the stakeholder involved and the complexity of the decisions within it.
The information I’m commenting on today can be found in this video (https://www.youtube.com/watch?v=WtfncGAeXWU) that I’d recommend you to see over and over again.
Shared practices and expected outcomes
For clarity, here I consider Security as ‘another element of Quality Assurance’. You may very well disagree 🙂
In social practices involving different types of roles, expecting that ‘Operators’, ‘Developers’ and ‘Security’ have a shared mental model of the system, doesn’t make sense as we all bring unique perspectives into assessing the appropriateness of the system to the context if operates in.
So, in order to do this effectively, there are some Boundaries in the form of Shared Practices which should be a focus of effort in getting right as it will support the expansion of each expertise’s to include the information necessary to ‘develop securely’ and ‘operate securely’, in this example.
Before finishing this section, differentiating between Outcomes and Outputs is key. Output are “physical and measurable things” (Bloom) like a piece of code, while Outcomes tend to be more qualitative.
This is one of the reasons I’m a big fan of Business-attribute profiling techniques, as the Business attributes are by definition representation of Outcomes which are independent of particular Outputs but which allow traceability and coherence checking. These should be limited and not expansive, so we’re spending the right effort in providing everyone with the shared practice they need to achieve a particular Outcome.
In this map, for instance, the anchor at the top is my Outcome and the different Mechanisms and Components generate particular Outputs supporting the Outcome. Also relevant to remember that a single output can have multiple different Outcomes, particularly to different types of stakeholders and this is one of the challenges when communicating security across the whole organisation when people think in different timespans.
Temporal Complexity
When this Observability is short (weeks), we have the domain of the ‘Obvious’ in that it’s an easy association for everyone . involved. I do this, I get that and I can see it happened.
When this Observability is longer (months), we have the domain of Expertise which requires a longer correlation between actions and its distant effect.
When this Observability is even longer (years), we have the domain of Models and Theories where the distance between this cause and effect and even clarity on observing its result is less clear and traceable.
In the real world, the way we communicate User stories and Strategies require completely different models of what ‘fits in the story’ as they won’t necessarily align because their qualities are different. One is specifiable (outputs), the other ones are less clear (outcomes).
The key to understanding it is that they’re different kinds of ‘stories’ “different not better” Jabe Bloom
Timespan of discretion
That was the required background from Jabe Bloom talk that was necessary to establish a shared vocabulary and me to write about how I believe this could apply to Cyber Security practices.
Elliot Jaques came up with this definition. What timespan of discretion is in the most simple terms is the answer to the question ‘how long will your supervisor allow you to act before expecting to see an output and evaluate the outcome ?’
Knowledge workers are mainly dealing with Service Delivery, taking advantage of modern day management practices such as fast feedback loops.This is where direct value is created and requires exact and specific skills. Applying it to InfoSec, it’s about knowing what you’re building, understanding what can go wrong and what you can do about it. Threat modelling anyone ?
Directors and VPs are mainly concerned about the first layer of Strategy, answering “how do I win this game against that opponent with these capabilities?” (Bloom). This is the place of Expertise and analysis, where experts can generally have an understand of distant cause and effect and the different conditions which may impact on ability to achieve an outcome. Applying it to InfoSec, it’s about understanding risks and key risk indicators and understanding threat landscape. Risk management anyone ?
VPs and Execs concern themselves with the wider system. As Jabe puts it, they seek to answer the question “how do we change the system so we acquire new capabilities to pursue different strategies?”. This is the place of Theory and Model Building. It’s so far into the future that it’s hugely Complex and cause and effect cycle becomes larger. This is where models that can help understanding of climatic patterns and evolution can be very helpful. Wardley Mapping and Cynefin maybe ?
Maybe, time to try something different ?
Working in security for about 2 decades now, my experience suggest that in most organisations you saw (as I did) the birth of the ‘Security Octopus’.
No one cared about what we had to say about 20 years ago, and now often we’re one of the ‘big shows in town’ with increased regulatory pressure, technology related failures and evolution of the threat landscape. Whilst often others didn’t even hear the name of our functions until they needed firewall rules open, now for most organisations there’s a much tighter level of collaboration at different levels, so this Security Octopus often translate into numerous organisational practices which need to be managed, nurtured and developed and will have themselves their own emergent properties as the Complex adaptive system in which they live imply.
What if this Octopus could be focused on as the ONE Shared practice at each of the levels of the organisation, where Security puts the effort to fully map, understand and deliberately change the quality, effectiveness and dare I say joy in performance of the different activities with continual reinforcement of language in those practices such that overtime it becomes ingrained and the benefits would accrue into the other practices in Dev and Ops which the security team has no active role in, nor should ?
Focusing on Output fixes (create new and changing someone else’s practices) to cater for Outcomes which other’s have trouble visualising what their Output could be that would facilitate attainment of someone else’s desired Outcomes is tricky at best, wishful thinking at worst. But in order to effectively do that, it means the Security Message needs to delivered at the level of its peers and not aim to all touching and all seeing (Octopus) but in being strategically designed to create the conditions for the achievement of security outcomes.
