Over recent months, Nettitude have noted a sharp increase in cybersecurity incidents within our client base, alongside the unfolding of the on-going Covid-19 pandemic. One cause seems to be issues caused during the migration to remote working by workforces, in which organisations have been left vulnerable. In any event, it now seems timely to talk about the Incident Response process and how an organisation can mature their Incident Response capability.
How do we respond to a client cyber-attack?
When responding to cybersecurity incidents for our clients, Nettitude follow the CREST Cybersecurity Incident Response process, which is broken down into 3 phases, as shown in the following graphic:
Arguably, the incident response planning phase 1 is the most important phase as all the activities in the remaining two phases flow from the activities in phase 1. Let’s have a closer look at the 3 phases of the Cybersecurity Incident Response process.
1 - Prepare with Incident Response Planning
Planning Mistakes
Failing to plan is planning to fail, so the saying goes and this is particularly true in respect to Incident Response. It is essential that you have a robust Incident Response plan and policy in place. Your Incident Response plan needs to be moderately high level, establishing who gets contacted and at what point during the Respond phase of the Incident Response process. One of the common mistake’s we often see is to develop a very detailed plan that describes very complex technical responses to a variety of threats; thus when an incident occurs your responders have to wade through >100 pages of documentation to establish what they need to do. If your plan is more than 25 pages in length then it is probably sub-optimal. You can buttress your Incident Response plan with play-books for defined incident types, but extensive technical actions generally shouldn’t be included in your Incident Response plan.
Testing the Plan
Once you have developed an Incident Response plan you absolutely must test it via a table-top exercise. This will facilitate the identification of any further gaps in your Incident Response process; you should seek to bridge those gaps at the earliest opportunity. You certainly don’t want to be in a position where your first run through the plan is during a live incident.
Being in a General State of Readiness
The preparation phase of the Incident Response process goes well beyond developing a plan. Organisations should assess their general state of readiness for a cybersecurity incident and consider the role of people, process and technologies in respect of their readiness. Nettitude typically find that the pinch points in the Response phase of a security incident relate to access to log data or other forensic artefacts. These generally occur due to their being no log retention policy in place, thus the log data has “rolled over”, or that there is no agreement in place with I.T. MSPs around producing log data in a timely fashion. These types of issues should be addressed when you are developing your Incident Response plan.
Nettitude also frequently find that organisations do not perform any form of asset discovery or asset management. This makes establishing the scope of an incident extremely challenging as the number of assets in an environment and what services that those assets are running cannot be determined without additional technical work.
Organisations also need to consider the I.T security posture of other organisations in their supply chain during the Prepare phase of the Incident Response process. Do you know if those organisations have their own Incident Response plan in place? Do you have a “right to inspect” the Incident Response documents held by organisations in your supply chain?
2 - The Incident Response Itself
As we stated in the introduction, if you have prepared well, then the Response phase should go a lot more smoothly. That in no way implies that this phase will be “simple”, just that your response will be hewn to a robust process with, hopefully, no insurmountable obstacles preventing you resolving the incident.
What Steps to Take
It is important that you investigate the event or alert that triggered the Response phase of the Incident Response process. Far too often we see organisations setting the hares running by pulling back logs from a range of log sources looking for suspicious entries. Experienced Incident Response investigators will know that log sources are generally full of suspicious entries, mostly benign and mostly not connected to the event or alert that was triggered.
Your first step should therefore be to investigate the initial event that triggered the alarm and determine if it is a false positive. Nettitude have noted that the direction of the Response phase is often dictated by the description of the event or alert. A series of failed authentications on the internal network are often categorised as a brute force attack; when this is escalated into an organisations Incident Response process, there is an immediate assumption that the environment has already been compromised and that the attacker is now brute forcing further user accounts. Experienced Incident handlers will know that in the vast majority of cases, these types of alerts are benign and most likely associated with a password synching issue. It is therefore important that following the receipt of an alert, the incident handler drills down to establish what precisely has been alerted upon and that they consider all possible alternative explanations for the generation of the alert. It is only through completing these steps that the appropriate action can be taken in respect of the alert.
Nettitude strongly recommend that the objective of the Response phase be written down and communicated to all the staff who will be involved in the response. This is crucial to identifying the most valuable investigative steps. There are potentially dozens of lines of enquiries or investigative steps that might be taken but many of those options will have no value in helping you achieve the objective of the response.
Recovery of Systems
Part of the Response phase will include the recovery of systems; this involves returning them to a state where you have a high degree of confidence that they are no longer compromised. It is important that you preserve all of the data necessary to complete the investigation BEFORE you move into recovery. Nettitude often encounter situations where organisation move into recovery almost as soon as an incident is detected. This will manifest itself in situations where, during a ransomware attack, critical systems that have been impacted are taken offline and rebuilt so that they can be returned to service. We then find that those systems were hosting critical data such as firewall logs that have now been destroyed.
Our Recommendations -
Nettitude strongly recommend that organisations adopt a “zero risk” approach to remediation and recovery in the Response phase of the Incident Response process. Simply removing a known malicious binary and putting the compromised host back into the production environment is incredibly risky. Many families of malware will seriously degrade the security posture of a system by modifying registry keys or disabling security processes such as anti-virus, simply removing the malware will not reverse those changes and often malware will make hundreds of changes to the configuration of an infected system, so simply reversing the changes is not feasible.
3 - Follow Up with an Incident Response Report
This is the final phase of the Incident Response process. In Nettitude’s experience, it is often the most poorly executed phase. The follow up phase should be used to conduct a deeper dive into the data you gathered to ensure that you have identified, as much as possible, the tools, techniques and processes that the threat actor used against your organisation. Once you have identified these TTPs you should update your controls to ensure that they cannot be deployed against you undetected in the future.
Creating an Incident Report
A thorough post incident response report should be created in order to identify the lessons learned and establish if your Incident Response plan worked as expected. Any gaps in your people, processes and technologies should also be identified during the post incident review and these gaps should be bridged as soon as possible.
Nettitude provide a range of incident response services – find out more.