Continuing education through the ESRM approach

As security professionals, we all know that stuff happens. Sometimes we respond to incidents quickly, and then simply carry on with our jobs. Other times, it may take weeks or even months to recover from a breach or disaster. Once our organizations are back to business as usual, we forget the events that led up to the problem.

The Enterprise Security Risk Management (ESRM) philosophy takes a different approach. What if we took the time to review the lessons we’ve learned from the incidents we experience, and use this newfound knowledge to our advantage? The same way we can learn from our personal experiences, we can learn from our professional ones as well.

The ESRM model requires that we are continually learning about our organizations, learning how the assets support the business objectives, the risks facing these assets, and when an incident occurs, reconstructing it to document how we can reduce the impact of a similar event in the future.

Following the ESRM approach, we take the time to explore the event, objectively identify what went well, and document what can be improved in the future. Sometimes it is as simple as changing a procedure for patching desktops to avoid the latest computer virus. In more complex reviews, we may determine a physical location should be upgraded with new security cameras or access control systems, or we determine a software application must be rewritten to support a new operating system.

Every security event is unique, which means every post incident assessment is unique. It seems like so much effort, but deconstructing a security event is worthwhile for a couple of reasons. First, as security professionals we need to understand how a certain control failed, or how an event could unfold and impact our assets and our organization. Assessing how an incident exploited a vulnerability gives us valuable information — information we can include in our next risk assessment against the asset.

Second, we have a chance to reassess the risk appetite of our organization, and determine if the asset(s) impacted by the incident are still critical to the success of the organization. This may seem simple — of course the asset is critical, it was involved in an incident! But a careful review of the asset, the role it played in the incident, and its past and present ranking against the business objectives can be an eye-opening experience.

During one post incident review, I was quite pleased with the response time to recover a website for a business owner. The site was affected by an incident and I was satisfied with the time taken to recover the website. What I didn’t consider was the impact this server had on other applications, and these impacted programs took longer than expected to recover. Those business owners expressed their concerns that we were more concerned about bringing up a little used website, while more critical applications remained impacted by the outage. We thought we were doing the right thing, but realized we hadn’t done our homework. The post mortem review helped identify the assets we should have been worried about – a lesson we documented and used in future assessments.

It doesn’t take a lot to learn from incidents, but the benefits far outweigh the effort. And we should never stop learning, not in our world.

Tim McCreight is the owner of Risk Rebels Consulting Ltd. (www.riskrebels.com).

This article originally appeared in the March/April 2018 issue of Canadian Security.