Securing the Digital Factory: Part 1
I’m not sure what’s the best hero image for an article talking about “digital factories”, maybe it’s a “Minority Report but in a hardhat” kind of vibe? Let’s go with that. To business!
If you know me you know I’m not a big fan of analogies. They’re generally used to poorly convey a reasonably complex topic in an overly-simplistic way, by people who have a poor understanding of the subject matter to start with.
Woo, there’s a statement.
BUT! There is one analogy that has stubbornly stuck around in software engineering and it’s the one of a factory. A production line where product is built, with people or machines doing things at each stage of the line and a finished item dropping off the end of the line to be shipped to the customer’s virtual hands. Or real hands… I guess you can use your real hands to interact with software.
This factory analogy is so close to the reality of software engineering that it’s going to be hard to avoid getting satirical, so, my apologies – it’s an accident if I do. Unless it’s funny, then I totally meant it.
What if we made a factory that built factories?!
The world of DevOps has used this analogy to promote the Theory of Constraints, picturing software development work “piling up on the factory floor” in front of the slowest part of the production line, starving downstream “work centres” (you can just call them people) of things to do and causing all kinds of problems. Value stream mapping takes this analogy and looks at the hand-off of work from one part of the production line to another, measuring how long it takes for a work centre to actively start working on the next item and how often there’s a problem with the work that requires it to be sent back up the line for clearer definition of the work required or for rework.
This is all Very Good Stuff™ that allows us to objectively measure the product delivery process and concentrate our improvement efforts in the most effective places.
In this factory, what does it require of us to make the products being delivered secure? We’ve not only got the work that’s gone into the product on the production line, our product also has a pretty big supply chain. It’s made, mainly, of components that came into the factory from a supplier that we just assembled. In fact, for most software, around 80% of it is 3rd-party software components, with the production line only adding the 20% of custom components that makes the product what we need. Making these components is a very complex task and so far we haven’t managed to get the robots to do it, so people still have to. There are lots of ways people can put the components together that are functionally correct, but very insecure. It takes skill.
There are many people moving around the factory, with access to most of the production line, who could accidentally or deliberately cause security problems. Our factory workers also have a high rate of turnover – this is hard work! Somewhere from 10-30% of them leave and are replaced each year. We lose the skills required to assemble our products securely at a pretty alarming rate.
But we should be able to see what the solution is as we think through this analogy. It’s the same as in physical factories developing physical products. Product security is fundamentally about quality control. Some of that quality control is focused on the product itself. Some on the supply chain components that make up our product. Some on the people in this system, how they’re working and what they know. Some on the machines we use on the production line. And some on the supporting systems around the factory itself that keep things ticking along.
And the key things about quality control is it must have control and you need to know what your acceptable tolerances are. There’s no use in measuring something and going, “Well, that’s… probably… crap?”, and doing nothing about it. That’s not control, that’s just depressing. Quality control has to have measurable objectives (because building products to a much higher quality than needed is not just unnecessary it’s expensive) and be part of feedback to the whole factory floor to keep things continuously within tolerances as product is delivered.
In part two of this series we’re going to take a look at the first part—applying quality control to the security of our digital products themselves. And if “part two of this series” is currently a hyperlink then I’ve already written it, go and read!
How we can repair the painful disconnect between Product & Security teams and foster a strong, efficient and successful relationship?
Change how you think about security and you can avoid serious headaches, impress your friends, have pool parties and even deliver better products with great ROI.