Crowdstrike - remember that?

The last of a dozen learning points I made in a post-incident review of the Crowdstrike incident was: "Unless changes are actually made as a result of an incident, the uncertainties (risks) remain. We have missed out on a valid learning and improvement opportunity."

Although I accept that nobody is obliged to learn from incidents, make changes or improve, the Crowdstrike incident was Big News when it occurred back in July, and here we are in October. So it's fair to ask what - if anything - are we doing differently now?

[I'm using Crowdstrike here simply as a well-known example. Even if the Crowdstrike incident had no material impacts on your organisation, you have undoubtedly suffered various incidents, possibly something serious or critical. As you read on, by all means substitute some other significant recent incident in place of "Crowdstrike" if that helps you relate to this piece.] 

A cyberattack can be a devastating event for any organization. It's crucial to respond effectively, identifying and implementing whatever changes are necessary to enhance security and protect the organisation against the same or similar incidents in future. Implementing significant changes requires a systematic approach, starting with identifying, clarifying and prioritising the changes needed. 

In more detail, that means:

  • Assessing the causes (threats and vulnerabilities) of the incident; 
  • Identifying the systems, services and data that were involved;
  • Exploring the actual and potential business impacts - not just what actually occurred, but what might have made things even worse;
  • Determining the pros and cons of potential security improvements to identify the most promising approaches,. including things that might have made the incident less significant and shorter;
  • Generating an outline of potential changes with sufficient supporting information (such as a business case with prioritised options and a high level plan) for management to decide whether and how to proceed.

Have you reviewed/revised your cybersecurity priorities following Crowdstrike? Does management understand the issues, appreciate the need to respond, and agree with the priorities? Does the plan align with strategic objectives and other initiatives? Are the business objectives clearly and convincingly expressed? Does management have sufficient appetite to proceed, in fact?

Hinson tip: if you are currently in the midst of preparing and negotiating your cybersecurity budget for 2025, incidents such as Crowdstrike are opportunities to remind senior management that the threats are real, the business impacts are potentially devastating, and now is the time to act. Exploit opportunities to enhance the business and support or enable the delivery of its mission or strategic objectives. Ultimately, senior management is accountable for significant business decisions, so be crystal-clear about significant risks that must be addressed.

Moving on and assuming you have the green light, more detailed project plans should be prepared, expanding on the agreed priorities and objectives. The plans should lay out specific actions or steps, roles and responsibilities, timelines and the resources necessary to achieve the objectives. For good measure and to ensure success, plans should address implementation risks/uncertainties, for example by securing sufficient contingency resources (funds and man-hours) to adapt and respond to any challenges that may arise. Plans should also reflect the priorities in terms of assigning the most capable people to important tasks and if necessary applying sufficient pressure to avoid delays to the critical path - which of course means identifying it.

What have you planned to do as a result of Crowdstrike? Are your plans feasible, sound, sufficiently low-risk and resilient? Will the resources be adequate to meet the planned timescales? Are the key objectives and critical path duly emphasised, in both business and technology terms? Are the plans formally approved? 

Effective communication is vital for any significant change. Relevant workers (staff, managers and specialists) should be informed about the Crowdstrike incident and the changes being made as a result. Explaining the reasons for the changes, particularly the objectives and benefits, helps secure their support and cooperation. Once rolling, regular progress updates keep everyone informed and present opportunities to raise and address any problems or questions that may arise, including any departures from the plans or particular concerns.

Look dispassionately at the change or project-related comms. Are the messages clear, consistent, timely and valuable? Are the right things being measured and reported? Are the relevant audiences (people, functions, management reps ...) appropriately informed and engaged? Aside from the leaders, is the team as a whole aligned, working productively, able and willing to voice concerns or suggest improvements?

The systematic improvements that are key to long-term success revolve around governance and processes, with implications for the procedures, IT systems and technologies, information flows and supply-chain/business relationships etc. For instance: 

  • Better incident response plans facilitate more effective responses to future incidents. 
  • Enhanced business continuity and disaster recovery plans reduce the severity and length of disruptions.
  • Layered controls support and complement each other, suggesting the value of an overarching security architecture at a level above the individual controls, systems, processes etc.
  • Improved security monitoring and alerting, plus incident reporting, speed incident detection and initiation of appropriate responses. 
  • Assurance activities such as penetration tests and audits identify vulnerabilities, measure the effectiveness and suitability of security controls, and indicate improvement opportunities.
Ultimately, it all comes down to people who: 

  • Are affected by incidents. 
  • Specify, design, develop, implement, use, monitor and manage/oversee controls. 
  • Resent and resist change, and evade, bypass or disable controls, especially if they are or are perceived to be onerous.
  • Have personal objectives and constraints, biases and concerns. 
  • Are 'only human', make mistakes, cut corners and have off-days. 

Therefore it is important to consider the people involved, addressing their emotional needs.

And that includes me. I am a human too. Cut me and I bleed. I wasn't directly Crowdstruck. Nothing I wanted to do that weekend was affected. It could easily have passed me by, if it were not for the extensive media coverage, and a slew of inane comments and ambulance-chasers desperately advertising their products on infosec social media.

Nevertheless, I've learnt from it and thought about it enough to write this blog piece, documenting it rather than letting it fade from my memory. I hope you find this thought-provoking, at least, if not insightful. 

Popular posts from this blog

Pragmatic ISMS implementation guide (FREE!)

Two dozen information risks that ISO forgot

Philosophical phriday - compliance risk