2017: “How did this happen?”

Audit & Challenge article 10: Leadership

Shadow Brokers, Wanna Cry, "The Year of Vehicle Attacks", WikiLeaks: CIA, Manchester, Equifax, Las Vegas, Sutherland Springs… 

This has been a frustrating year for the security industry with unprecedented incidents having a massive global impact. Some of these are easily understood while many of them are difficult to forecast, and prevent. I’ve often seen these types of responses from the security community.

Shock: How do we train people to address this? How do we stop this?

Knee-Jerk: How could they have not seen this coming? They should have…

Backlash: To the people who are criticizing: where were all these insights before this event?

If we are reacting this way, its no wonder the organizations we serve are unsettled as well. We need a consistent process for evaluating security incidents. This is a tool for drawing meaningful conclusions and lowering organizational anxiety. 

Here are the basics of my approach.  

Risk Assessment

You must choose. We cannot mitigate all the risk in the world. We must choose which risks make sense to address and which do not. Explanations must be documented and discussed with the stakeholders who own the risk.

The world changes over time. What we accept as a reasonable risk today, is different from what is acceptable next year, or maybe even tomorrow. We need to understand the nature of risk and forecast how it may change in the future. This will create a common platform for stakeholder education and future conversations.

Risk is like water. As you treat risk in one area, it moves or causes ripple effects in others. Once a mitigation strategy has been implemented, the risk needs to be re-evaluated to understand what unintended consequences were produced.

There is always residual risk. After a risk management plan is executed, this needs to be measured and and explained to the risk stakeholders.

Define success and failure. As humans, we tend to think irrationally out of fear. We need to understand what failure actually is. Security incidents don’t automatically equate to security failure. Sometimes a successful outcome is not neat and tidy. There is a reason your organization is spending their money on security services. 

Security programs cannot fail solely based on the actions of aggressors.

Instead, understand and document the point at which Detection, Recognition, and Response are successful and at what points these elements begin to fail. Document and set the correct expectations within your organization.

Post Incident Review Process

I believe in Post Incident Reviews. We conduct them all the time. Small incidents, big incidents – even when something weird happens; I’ll review it with the team to identify the lessons learned and ensure our policies were adequate. 

These reviews are a critical component of my “people strategy.” If you only review incidents which result in disciplinary action, your people will not trust you. Mistrust tends to create integrity issues. On the other hand, if you review all kinds of incidents, your teams become owners of the program. They participate in policy and decisions. Reviewing their work becomes a normal operational procedure.

Organizational stakeholders benefit as well. Your programs are perceived as calm and well managed. You can stop knee-jerk reactions in their tracks while you work through your normal process. 

Once allowed, knee-jerk reactions are the death of every security program. They are a cancer of expectations which will grow inside your organization. A well-developed review process, in addition to strong, calm leadership, will bring order and insight to the discussion.

To be effective, rules need to be established to govern the Incident Debrief process. Here are mine:

Rule 1: Understand the facts and timeline of the incident. Rule out bias and emotion from this process by noting inference and opinion.

Rule 2: Measure the totality of the incident against the policies and understanding of risk that existed when the incident happened. This is the only way to be fair to the people involved. We can never apply today’s understanding of risk to yesterday’s incident. Frustration and mistrust will follow.

Rule 3: Focus on policy, process, and professional development. As humans, we feel a need to find a culprit. We already have one, the aggressor. Focusing on development uncovers what could be done in the future while still meeting the needs of the business. 

In the Codes of Conduct for my teams, I write the following into policy:

“Problems are opportunities to be excellent. Someone does not  always need to be at fault. We succeed and fail as a program. We are committed to the professional development of one another.”

Rule 4: If negligence is uncovered, it should be dealt with separately. Incident Debrief is a development process, not a disciplinary process.

This is how I approach Post Incident Review. It has served me well and I hope it is helpful to you. Let me know what you think!

Merry Christmas & Happy New Year!