Welcome to NBlog, the NoticeBored blog

I spy with my beady eye ...

Jan 6, 2020

NBlog Jan 6 - post-malware-incident notification & other stuff

A couple of days ago here on NBlog I wrote

"One screamingly-obvious lesson from the rash of ransomware incidents is that we need to anticipate malware infections when the preventive controls fail, which means strengthening the security protecting our business-critical systems and being ready to recover IT services and data efficiently following incidents." 

That's not all.

Anticipating that, despite all we do to prevent them, malware infections are still likely to occur implies the need for several post-event controls.  These are the kinds of controls I have in mind:
  • Reliable, efficient, effective, top-quality incident response and management processes - in particular, speed is almost always of the essence in malware incidents, and the responses need to be well-practiced - not just the run-of-the-mill routine infections but the more extreme/serious "outbreaks";
  • Decisive action is required, with strong leadership, clear roles and responsibilities, and of course strong awareness and training both for the response team and for the wider organization;
  • Clarity around priorities for action e.g. halt the spread, assess the damage, find the source/cause, recover;
  • Technological controls, of course, such as network segmentation (part of network architectural design), traffic filtering and (reliable!) isolation of segments pending their being given the all-clear;
  • Clarity around priorities for reporting including rapid escalation and ongoing progress updates, in parallel with the other activities;
  • Forensics, where appropriate, feasible and helpful (e.g. which preventive controls failed, why, and what if anything can be done to strengthen them);
  • Restoration and testing of backups, prioritizing key business processes and other cleanup efforts as part of ...;
  • ... Business continuity management;
  • Additional/heightened preventive and detective controls with alerts/alarms and rapid responses to further/reinfection - that jumpy phase when we think but aren't entirely certain that everything is resolved;
  • Stakeholder notification, with implications for exactly what can and should be said, to whom, when, how and by whom (taking account of the impacts on them, including compliance failures and business service interruptions);
  • Post-incident reviews to identify and learn the lessons once the dust has settled, making the best of a bad job by improving whatever can and should be improved for the future - part of systematic improvement.
Stakeholder notification is something one of our awareness customers raised, and something we intend to cover specifically in February's awareness materials ... and while we're at it, I figure there's plenty more mileage in the remainder of those bullet points above. Given that, sadly, this will be our final update to the malware awareness and training content, it seems fitting to end with something new on what needs to be done when (not if) malware incidents occur, our legacy if you will.

No comments:

Post a Comment