Defeating factors in Security controls
As anyone following me for a while knows, I’m a big fan of David Provan’s work on Safety and Safety Management. In his latest book “The Field Guide to Safety Professional Practice” he talks about a construct that I believe is very useful for us in Information Security as well, namely those of us tasked with implementing and assuring security controls.
He calls it the ‘defeating factors’ and defines it as “those things that can make risk controls inoperable or unavailable or defeat them in terms of their function, reliability or availability”. This leads us to the idea of “defeating factor controls” which are “the activities undertaken specifically to prevent or reduce the likelihood of the defeating factors invalidating, defeating or impairing the critical controls”
I think we have a lot of common defeating factors in how we implement security controls in our organisations, and we’d do well with adopting this construct as a way to look for brittleness in our security controls.
Let me clarify with an example, a quintessential one that comes up over and over again, in relation to controls we implement in CI/CD systems in particular.
Here’s a list of what I believe are common defeating factors in controls implemented in CI/CD alongside some of the critical activities we can undertake to help manage the resulting risk
| Defeating factor | Defeating factor control | Critical activity |
| Overwhelming number of findings | Routine review of feedback from CI/CD in context of each team | Assess how much feedback Developers get from CI/CD output (considerate of unit, integration and e2e testing, linting etc) and how much security contributes to excessive non-actionable findings |
| security management performed out-of-context | Review tools for capabilities to manage security in context of development | Review how current tooling allows for management of security in the context of development (eg managing false positives as code, pre-commit hooks) as opposed to having to login to separate portals to assess and manage security outcomes |
| lack of guidance on how to fix findings | Review tools for capabilities to guide required adaptations to deploy secure software | Check that security tools provide actionable guidance on how to fix security findings that can easily be accessed from the output provided in CI/CD (URL’s to cheat-sheets or code fixes) |
I think this is an extremely useful concept for us to add to our language, that of defeating factors and that by adopting and looking at our security controls with this lens allows to focus and uncover how we’ve built designs which aren’t congruent with the work systems and the outcomes we wish to obtain. And to be clear, this is not a “Devs don’t do the right thing because they’re lazy”. If we are the budget holders that are driving adoption and deployment of all of these controls, it’s ON US to ensure they’re delivered in a way that is effective and that we subordinate our tool choices (not to what Gartner tells us is best) but to what actually integrates best into the work systems we wish to affect.
If we’re the designers, it’s on us to do the work of identifying the defeating factors that will decrease effectiveness of our security control estate.
