top of page
  • Phil Venables


Many well-known security incidents appear to have a common pattern. They are not the result of some awesome attacker capability to exploit some hitherto unknown vulnerability or to realize a risk from some combination of controls weakness not contemplated. Rather, a remarkably common pattern is that the control or controls that would have stopped the attack (or otherwise detected/contained it) were thought to be present and operational but for some reason were actually not - just when they were most needed.

There are many reasons for these failures to sustain the correct implementation of important controls, for example: a bad change, operational error, a new implementation that was incomplete, other faults/breakage, some wider change that nullified the in-situ control. In fact any issue that drives any type of system error can be an issue that negates or disables a control. The incident/after action reviews no doubt have the same moments of people exclaiming: “But didn’t we have a [ process | tool | component ] to stop that happening?”

Incidentally, we talk about attacks but a similar pattern exists for control failures that lead to other realized risk for other types of incidents across the full spectrum of enterprise risk domains. So, what to do. Treat controls as first class objects like other parts of system function.

  1. Build a catalog of key controls using a well formed ontology (I’ve not totally drunk the overall FAIR cool-aid but their controls ontology is very good).

  2. Conduct independent assurance / design reviews for key controls. This doesn't have to be fully independent - but at least a peer review in whatever development methodology / style you operate.

  3. Treat controls (especially security controls) as automation / code. Build tests / coverage for control correctness as you would with other code.

  4. Test for the presence and integration of controls at build time in integration / deploy suites. Different styles of test will be needed depending on the nature of the controls (component, software, hardware etc.)

  5. Perform continuous control monitoring to assure the continued correct operation of controls at run time and ensure completion of deployment. Minimize the time between a potential control failure and the detection/correction of that failure.

  6. [Big point] Declare any control that doesn’t prove amenable to such assurance or doesn’t emit the data needed for continuous monitoring to be a control in need of improvement / replacement.

  7. When a control (or instance of a control) is detected as having failed then declare a "control incident" and handle as if a security incident has occurred (as it might well actually become if not attended to quickly enough).

  8. Treat control incidents as first class objects alongside security incidents (reporting, escalation, after action review, thematic analysis) whether or not the control incident actually resulted in a security incident. [consider close-calls as well as actual incidents].

There are emerging tools to help (e.g. some vendors and many cloud-native tools) + what some orgs have self-built. Btw - many so called GRC tools don’t do much here unless you count intermittent human self-assessment as continuous monitoring - some are adjusting though.

Bottom line : many incidents are not due to a lack of conception of controls but due to failures of expected controls. Hence the need to conduct continuous control monitoring & treat control incidents as first class events like security incidents.

Validate continuously.

653 views0 comments

Recent Posts

See All

I first posted this as a Twitter thread in 2019. These forces still seem very much current - perhaps even more so. It is interesting to think that most of the issues and risks we face arise from a sma

There is a lot of conventional security that is based on established ceremonies and an unquestioning faith that if we keep doing these things then all shall be well. If the ceremonies don’t produce th

It’s that time of year when you’ve inevitably written notes to your organization and leadership about all your team’s achievements over the year (and possibly quietly shuffled all the things you didn’

bottom of page