Key tips for preparing an efficient Security Incident Response Plan - Part1

Welcome to this post. Today I'd like give you a few tips on how to prepare and approach a security incident response with a few examples.

The reason why I thought this could be useful because according to 'The Third Annual Study on the Cyber Resilient Organization' organisations continue to struggle with responding to cybersecurity incidents due to the lack of formal incident response plans. No surprises there, if a process is not standardized the desired outcome is not guaranteed either. For now rather than approaching security incident response from a technical point of view I'd like to focus on the communication aspects and dependencies first, let's get started.

First I'd like to clarify what cyber resiliency means. In its simplest term cyber resiliency means your organisation's capability to conduct business in case of cyber attacks. The Cyber Resilient Organization study I mentioned above is a great reading and outlines a few other challenges in this area. For example insufficient (or should I say non-existent? :)) budget allocations for cyber response, inadequately skilled staff in cyber and even more so the difficulty in hiring skilled IT security practitioners and so on. This paints a not too optimistic picture for organisations willing to improve their cyber resiliency and capabilities but hopefully my tips will help to spark some ideas or highlight some gaps in your cyber response processes. The examples below approach incident response not so much from the technical point of view but rather to help preparing for one.

Tip #1 - Put it in writing

The first tip is...you must have an incident response policy :) This is the first step towards standardizing basically anything and even though policies are universally frowned upon they play a critical part in the preparation and planning. This policy should include at a minimum:

• The purpose of the policy: this is a trivial one :)
• Communicate senior management support and commitment to the policy.
• Organizational structure and definition of roles and responsibilities. Everyone who reads this policy should know who have the authority to make important business impacting decisions in case of an incident.
• Scope and basic definitions: this is pretty self explanatory.
• Key Performance Indicators. To reference the immortal words of Peter Drucker: "If you can't measure it, you can't improve it."

Tip #2 - What are you trying to protect?

It's all about the assets and the organisation's capability to protect those assets. Asset registers are pretty much one of the foundational building blocks of information security in general and plays an important part in the preparation. Keeping these registers up to date can also be a challengein today's fast changing environment and let's face it, keeping an asset register up to date is not in anyone's TOP5 most favourite responsibilities either. It's not just about the assets, ownership of assets and sensitivity of the asset is key. If your data classification is linked to your asset inventory congratulations, you have done well. With this information the impact of a security incident on a the assets will help immensely communicating with upper management.

Tip #3 - "If there's something strange in the neighbourhood, who you gonna call?"

..."Ghostb"...no, wrong answer! Security incidents come in many way, shape and form and one cannot do it alone. Depending on type of incident you will need all the help you can get. For example, let's consider the following example. On a beautiful day one of the externally facing websites responsible for generating 30% of global revenue is under a DDoS attack. Now it is not accessible to the customers and it does not get better any time soon. Do you have your hosting provider contact details to call for help? Could they actually help, would their actions be sufficient or would you be better off with a specialized DDoS protection service? I always recommend as part of the preparation activities to have an Incident Response Contacts list (IRC for short).

Let's take a closer look at another example. The incident in this case is your customers' data has been transferred from the organisation's internal network to a public cloud service provider...or even more common it was "just" simply sent to a personal email account (hotmail, yahoo, etc.) by one of the employees without the necessary approvals in place. Needless to say HR and legal counsel is key to add to the IRC. And this is a good example because it has a few other 3rd parties to consider. Actually, I should have started with this one. There are regulations, international, country and even organization specific laws to consider during a security incident and navigating through all these requirements is a challenge not to be taken lightly. These regulations could also outline what authorities an organisation has to contact in specific cases. GDPR is a great example of another mandatory obligation when personal data loss is confirmed to the supervisory authority. The supervisory authority is an independent public authority nominated by each Member States (as per Article 51 of the GDPR). Who is your supervisory authority? In the United Kingdom it's the Information Commissioner's Office - ICO.

Have you considered any 3rd party contractual agreements and obligations the organisation has in terms of security incidents? For example if the incident involves payment card data there is a contractual and therefore mandatory obligation to notify merchant banks and card companies. Certainly those contact details are worth adding to the IRC. Law enforcement is again an important one to consider on a case by case basis and for certain types of security incidents (eg. fraud).

How would you communicate a data breach to your customers? History shows a lot of cases where communication caused confusion and and damaged company reputation. An effective communication plan could mean all the difference in terms of public image, reputation and customer trust. I always recommend preparing for at least 3 different types of communications ready to go just in case.

I'll leave a very common incident for last. This time one of the employees has clicked on an email attachment which turned out being one of those "Blimey, I should have not clicked on it...". At least the user was vigilant enough to call the IT service desk. At this stage nobody knows how deep the rabbit hole goes, what happened after the attachment was opened, should you be worried about what comes next? Could sensitve data have been transferred? Maybe a crypto malware deployed hidden and waiting for the right time and date to activate? This question requires specialized forensics expertise to tell "how deep the rabbit hole goes...". As this expertise is even harder to come by getting a 3rd party service with contact details in the IRC is essential.

Tip #3 ended up a bit longer than I expected, for now I'll wrap it up. I'll return with part 2 soon with more tips, stay tuned. If you have any questions please let me know in the comments below.