In the security world we say that there are 2 types of businesses; those who’ve suffered a cyber attack and those who are yet to suffer one.  The point here is to be prepared as cyber attacks are an unfortunate reality of today’s business landscape. 

So how do you prepare? Well, apart from a having a robust security framework you should have a plan in place that outlines how to deal with an incident. A clear process will ensure you are methodical and focussed in your response which saves time and minimises the impact of the incidence. The plan is referred to as an Incidence Response Plan and I’ll go into more detail below on some things to consider when writing the plan.  

The plan should outline all steps in the process, the procedures to use and who has responsibility for each step. Make it simple to use by preparing checklists of task to complete. 

The plan should document members of an ‘Incident Response Team’. These are the people who are tasked with managing an incident; they should be empowered to act quickly without having to seek further authorisation. Circulate the members, their contact details and responsibilities within your business. 

The plan should outline your crisis communication plan. An effective communication plan ensures panic and mistrust is minimised, reducing damage to your reputation.  Think about who your internal and external stakeholders are and how and when you’ll keep them informed. Write a contact list so you can quickly identify and contact those stakeholders. 

Regardless of whether you are a small, medium or a large company, or whether you operate within the financial, legal, banking or other industries make sure you understand the attack before you react to it. Identify the impact of the attack, the type of attack, the networks/systems affected, the stage and origin of the attack and the type of data impacted. The results will shape how the Incident Response Team takes action. Having advanced endpoint protection and response (EDR) systems and other security monitoring control deployed makes the job of understanding an attack much easier. 

Once you’ve understood the attack, you should move to contain it by stopping it spreading to other systems. Ensure to take forensic snapshots of infected systems and logs are kept for investigation purposes. 

You can then move on to eradicate the attack by identifying and eliminating the root cause to ensure the environment is secure to proceed with the recovery. The specific steps taken will depend on the nature and type of attack. 

With the attack eradicated, you can proceed recover systems to full working order. This step can take some time. Systems are rebuilt/reinstalled, files are replaced, patches are installed.  

Incident response doesn’t stop with eradicating the attack and recovering systems.  You should conduct a ‘lessons learned’ meeting and write an Incident Report, including any recommendations to improve the response process and stopping the incident from happening again. Perhaps your endpoint protection let through some simple malware so you need to investigate more advanced protection. Or an employee clicked on a suspicious link so you need to roll our awareness training. 

If you’ve decided you want to write your own Incident Response Plan you will find more guidance on the CertNZ website. But if it all sounds a bit complicated or you don’t have time, you can always contact us to write it for you. 

Recent blog posts

The Forgetting Curve – Security Training

The Forgetting Curve – Security Training

It’s something we all know instinctively, if a whole load of new information is thrown at you, your recall of it will be somewhat cloudy one week later. This is exactly what German psychologist Hermann Ebbinghaus showed back in 1885 when he developed the forgetting...

Possible Okta Breach By Threat Actor

Okta has provided additional information on the timeline of the incident affecting their services. In summary, the Okta service confirmed the breach by Lapsus$ group yesterday. As per Okta has confirmed 'The Okta service is fully operational, and there are no...

UPDATE: CVE-2021-44228 Apache Log4j 2 RCE – log4shell

UPDATE: CVE-2021-44228 Apache Log4j 2 RCE – log4shell

Since the news of this critical RCE (CVE-2021-44228) in Apache log4j was made public on Friday, Simplify Security's MTR team has been investigating activity to improve detection and response capabilities. As a quick summary, this vulnerability results from how log4j...