I believe that generally, Infosec as an industry missed out on all of the good things that LEAN had to teach us regarding how to do a better job at managing work. Most of us, probably went straight from Waterfall to “DevSecOps”, kind of missing a lot of the ideas that supported the development and expansion of DevOps to begin with. I’ll argue even a lot of the DevOps movement itself, these days in 2022, tends to forget these basic principles of its genesis or evolution of DevOps.

So, today I re-found an internal presentation I was giving my own teams back in 2017 about the flow of work, that I’d invite you to consider in your own Infosec practice and (more importantly maybe, but that I’ll address in a separate future blog) how our OWN security practices are affecting the flow of work of value creation structures in our organisation. but will leave this second one for later…

First, let’s use someone else’s definition of “flow of work”

Flow of work is concerned with the way work move along with one operation to another. It denotes the volume of work going through the rate at which it moves along and the smoothness of its passage.

The flow of work aims at greater efficiency in every office activity, so that costs are cut down and delays are eliminated. Flow of work is a problem to be solved by the managers.

So, what can we do to increase flow of work ? quite a few things:

  • Making the work visible – “work can bounce between teams endlessly due to incomplete information or work passed with problems that are invisible until we’re late delivering what we promised the customer”  – Think Kanban
  • Limit work in progress – work in progress is the silent killer. Priorities of the day or low-value activities take up time, often in invisible ways until we dig deep into the practices that “we’ve always done this way”
  • Easier to see problems preventing completion of work – When we limit WIP, we may find we get nothing to do whilst we’re waiting for someone else. It’s tempting to start new work, a far better action is to find out what’s causing the delay and fix that problem. “Stop starting, start finishing”
  • Reduce batch sizes – define tasks in way that are finite and deliverable. because we often work at bigger timescales or to pursue objectives which only provide observability in wider timespans, we often don’t bother with defining and managing all the small steps required to get us there
  • Reduce number of handoffs– each handoff results in an item in a queue where work will wait as resources are shared between value streams. Knowledge is lost in handoffs. Aim for automation and reducing amount of non-value-added time. A common case I see a lot of GRC teams do, is having 2 separate tasks: one for triage and a second one the actual assessment, and this is done under the justification that for the assessment we can provide something more targeted. The problem is that this adds 2 extra touchpoints, that as seen in the picture above, is probably much more destructive than you originally perceived. Allowing your clients to define “not applicable”s and managing any deviations you don’t agree it, is VERY likely to make for a much more efficient process without loss of quality
  • Continually identify and elevate the constraint – You’ll typically be able to find a key constraint in your work processes, where things build up and affects work from being released to the rest of the value chain. Aim to increase work capacity and efficiency at this constraint. Identify it, decide how to exploit it, subordinate everything to the constraint and elevate it. ANY IMPROVEMENT OUTSIDE OF THE CONSTRAINT IS AN ILLUSION
  • Eliminate hardships and waste in value stream – Waste is the use of any material or resource beyond what the customer requires and is willing to pay for. Another useful frame security teams should adopt is the ETTO principle (efficiency-thoroughness trade-off). We often err on the side of thoroughness which implies a decrease in efficiency. Keep the question alive, ask your stakeholders where they believe your trade-offs are being made and ensure you negotiate that. That for each step in the processes you create, that you take a “decluttering” approach to it by discussing what’s the contribution (extent to which that activity actually has security value), the confidence (based on evidence or strength of belief) by which that judgement is made and the consensus (level of agreement about the security value of such activity between those who mandate it and those who perform the activity)

If we all took these things in consideration, I think we’d have much more effective and efficient security activities in our organisations, and both our internal and stakeholders would get a different view of the value and pragmatism of the work we perform.