Thread by @philvenables

Controls. A Thread.

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 vuln. or to realize a risk from some combination of controls weakness not contemplated.

1/15

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.

2/15

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.

3/15

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?”

4/15

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.

5/15

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).

6/15

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.

7/15

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

8/15

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.)

9/15

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.

10/15

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.

11/15

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).

12/15

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].

13/15

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.

14/15

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.

15/15