Incident Response, in line with Information Security, is generally a challenge for a lot of organisations. Despite this, the good news is that cybersecurity is now being recognised as more of a crucial component of a business plan within organisations; many of which now have a programme in place to implement Incident Response capability. Whilst this is a step in the right direction, it should be ensured that these programmes should be iterative in order to facilitate the maturing of their capabilities.
In addition, it is also now more widely understood that large errors such as failing to develop an Incident Response Plan and failure to regularly test the plan, inevitably lead to disaster during a cyber incident. Unfortunately, this only becomes apparent once an organisation experiences a cybersecurity incident. Outside of the critical errors, there are small handling errors that can have a big impact on the outcomes of a cybersecurity incident.
This blog post looks at some of those errors based on the real-world experiences of LRQA’s Incident Response team.
The CREST Cybersecurity Incident Model
Incident Response maturity programmes should be bench-marked against a robust framework, such as the CREST Incident Response maturity model as shown below:
Source: CREST Cybersecurity Incident Model
3rd parties not joining the party
An overlooked component of the “prepare” phase of an Incident Response programme is reviewing the SLAs and contracts in place with 3rd party I.T managed service providers. Organisations often find that their 3rd party contracts don’t adequately address the responsibilities of MSPs during a cybersecurity incident. This results in the priorities of the organisation and MSP becoming misaligned. In addition, this often results in delays in obtaining critical log data from an MSP when, for instance, an SLA might make provision for the production of log data within 48 hours, but the requesting organisation needs those logs immediately in order to manage the incident effectively. The request for data to be provided urgently often attracts a significant premium fee from the MSP.
The solution is to work with your MSP as part of your Incident Response programme and establish exactly what each party’s roles and responsibilities are during an incident. Make sure that, once agreed, these elements are put into any contracts between the parties.
Got it logged but not retained
So, you have spent a lot of time identifying the log sources that you require to assist in detecting and responding to security incidents, but you’ve failed to define a retention policy. Now what’s the plan?
LRQA typically sees this issue manifest itself with firewall logs in particular. Another common issue is when an organisation has contracted an MSP to implement and maintain a firewall but they omitted to implement firewall log retention policy. It is surprisingly common to find that firewalls were provisioned with their default configuration which, by default, have a log retention time of, for instance, 12 hours; this is not much use if you are looking for logged firewall activity from 24 hours ago.
Organisations need to include defining retention policies as part of their Incident Response preparations and make sure that the internal policy is mirrored with any 3rd party MSPs.
Maslow’s hammer
More commonly understood by the phrase “If the only tool you have is a hammer, treat everything as if it were a nail”. This is a cognitive bias wherein an actor becomes over-reliant on their specialism or tool. LRQA Incident Response team most frequently see this when organisations try and manage an incident with no experienced Incident Manager to direct the response. We observe that the firewall specialist views the incident through the prism of the firewall being the key to resolving the incident, even when firewall logs are not yet in play for the incident. An endpoint may have been compromised but the firewall specialist will go straight to the firewall logs and spend significant amounts of time trying to identify the signal of a threat actor amongst all of the noise in the logs. The logs may well contain a critical piece of evidence, but firewall log analysis is best performed when you have some sense of what you are looking for. The time spent blindly looking through firewall logs could be much better spent on more fruitful lines of enquiry.
To resolve these situations, LRQA recommend that organisations have access to an experienced Incident Manager who will allocate specific and relevant tasks to those investigating the incident.
Correct action,wrong time.
During the response phase of an incident, we can’t emphasise enough how important it is to perform each step-in sequence. The investigation step should always be undertaken before the recovery step. LRQA have undertaken a number of incident response engagements where we have found that the client moved straight to recovery step before completing the investigation. We typically see this during a ransomware outbreak on a network. Impacted systems are subjected to wiping and rebuilding thereby destroying potentially critical data. The knock-on effects of this can be significant, especially if the recovered system was “patient zero” and therefore the most obvious source for establishing the root cause of the compromise. Another example would be where the recovered system contained firewall logs or other critical log data that wasn’t being sent to a SIEM solution.
LRQA recommend that organisations have access to a certified and experienced Incident Manager during their Incident Response investigations. The Incident Manager will allocate specific actions to relevant parties during an investigation to ensure that the breadcrumbs left by an attacker are followed to their source.
Lots of assets…we think
An asset management programme may be on many organisations “nice to have” list, but failure to undertake such a programme can have significant impact on your overall security posture. At a very basic level, it is difficult to see how an organisation can consider themselves to be secure if they don’t know what assets are in place and what services those assets have running. Many organisations aspire to have a robust vulnerability management process in place, but the foundation of such processes requires a comprehensive asset management programme in place. This absence of an asset management programme really hits home when an organisation experiences a cybersecurity incident. Understanding the potential impact of the compromise and the potential scope of the compromise becomes extremely challenging without an asset register being in place. LRQA incident response team will dynamically try and get an understanding of the network topography but this is sub-optimal and will inevitably result in only a partial understanding of what the network looks like.
LRQA recommend that you develop an asset management programme which should be continuous in the sense that you should update your asset register regularly throughout the year. The asset management program should include the discovery of which services are running on any given asset.
Making a hash of things
It is now widely understood that detailed note taking during a cybersecurity incident should be part of your processes for incident management, however there is often little thought to what the notes should include. It should be borne in mind that as an incident progresses, in may become apparent that an insider threat is involved. In these cases, your notes become critical as the probability of criminal charges or legal tribunal increases. LRQA have observed that most organisation don’t time stamp their notes or record the hashes of data sets that they have analysed or collected during an incident. Hashing data sets and recording the resultant hash digests in case notes goes a long way towards proving the integrity of data sets. Although not recording hash digests will not automatically exclude the data set in any subsequent legal proceedings, it does open them up to being challenged.
LRQA recommend that organisations note taking software that facilitates collaboration and has functionality that allows for the embedding of time stamps into the notes. We also recommend that all data sets are hashed during every cybersecurity incident and the resultant hash digest recorded in the incident notes.
For more information on this subject, please don’t hesitate to get in touch with your local team.