Stop Measuring Security Controls. Measure Decision Latency.

The attacker already made a decision.

Your organization is still scheduling the meeting.

For years, security programs have measured the presence and performance of controls. We count vulnerabilities, patching percentages, phishing failures, endpoint coverage, open findings, audit exceptions, and incident response times.

These metrics can be useful.

They can also create the illusion that security outcomes are primarily determined by control quality.

In many consequential events, the organization does not fail because it lacks information or technology.

It fails because it cannot make a confident decision quickly enough.

Cyberleader

Continue reading

Incident Reporting & Handling WorkFlows

I had an interesting conversation with a client today and they are planning to implement a web site that would give their internal employees a centralized resource for looking up how to report security incidents, building/facilities issues, HR problems, policy violations, etc.

They picture this as a web page with a list of phone numbers, intranet applications and other contact mechanisms for their staff to use to report issues. The conversation was around attempting to create a workflow or flowchart for decision making about how to report an issue and how to decide which contact method to use.

I know a few other organizations have created formal incident reporting and such for their employees. Would anyone care to share their decision trees or the like for incident handling and user training around this topic (sanitized, of course!)?

Thanks, in advance, for any insight on this. The client will be monitoring the thread and it may help others as well.