Maksim Kabakou - Fotolia

How to respond when your cyber company becomes the story

The Computer Weekly Security Think Tank panel considers incident response in the wake of the July CrowdStrike incident, sharing their views on what CrowdStrike got wrong, what it did right, and next steps

The dreaded realisation that something has happened, data has been accessed and now you need to tell customers and the world. Years of hard work to build trust and reputation now hang in the balance of how you deal with and communicate the incident.

When and if this happens, there are key steps that need to be taken to maintain trust and mitigate potential damage. From my own experience, the number one element is transparency. Even if you don’t have all of the information, acknowledging the incident, accepting responsibility - while crucially showing empathy - and sharing what you do know enables customers and authorities to make their own assessments and provide assistance in reducing risk. 

It’s important to be clear on what happened, what systems were affected, what data was accessed and what it means for customers. Initial investigations are key to being able to clearly articulate the details to customers who may be affected. The initial shock of being told there has been an incident soon kicks the customer brain into action mode; what, when, how, who are all valid questions that customers have around an incident and being able to explain those details can provide some reassurance that you have a grasp on what has happened, and how you will ensure it won’t happen again. Many customers will expect and ask for an independent third-party cyber security team to be engaged to ensure that the incident is fully understood and managed, so having an agreement in place is important to be able to call on those expertise, maintain trust and provide that reassurance. 

It’s this engagement with customers and the community that allows interested parties to ask questions and being able to deal with that influx is something that should be part of every organisation's incident response communication plan. Who schedules calls, how calls are scheduled, who takes the calls, who is authorised to make statements, how do we accommodate 24x7x365, all need to be considered as new information becomes available or public statements are made. Sharing regular updates on the incident and investigation ensures an organisation can control the narrative and explain actions taken, next steps and define an end to the incident. This can often include recommendations for customers such as sharing IoCs, TTPs or processes to be followed to further protect customer data. Conversely, a lack of information will lead to uninformed parties making hypotheses and propagating misinformation.

As the incident and investigation concludes, it’s important to think about incident closure, what are the outstanding actions and next steps and how do we communicate any further updates going forward. Tools such as post incident review, lessons learned and embedding changes required to continuously improve the incident response and communication processes are vital steps to ensure that best practice is upheld and processes continue to evolve. 

From our own experience, this is where Project Bedrock and the Okta Secure Identity Commitment were born from. Mechanisms that allowed us to define those actions but more importantly, how we as a business would ensure that our focus would, and could, remain on the defined improvements and cultural changes we needed to make. 

It’s critical that we learn from every security incident and while incidents will happen, it's how the organisation responds that will be the defining measure for customers and our success.

Stephen McDermid is EMEA CSO at Okta  

Read more on Security policy and user awareness

CIO
Security
Networking
Data Center
Data Management
Close