In our series ‘Causes of Cyber Attacks: Our Experience’, we have already given you an insight into the work of our Incident Response Team and discussed common triggers of cyber attacks. In this series, we would like to take things a step further and discuss typical obstacles encountered during the investigation, handling and mitigation of an incident, as well as offering helpful tips for dealing with such an exceptional situation.

Delay in seeking professional assistance

In many cases, we receive requests for help from companies that have been the victims of an attack on Friday afternoons, even though the incident was detected several days earlier. The reason for this delay is often that the situation was not initially assessed as being particularly complex, and attempts are first made to deal with it using internal resources. In some cases, unclear responsibilities and decision-making processes, as well as budget constraints and inflexible approval procedures, also contribute to this delay. However, shortly before the weekend, it usually becomes clear that progress cannot be made effectively without support. 

The resulting delay in seeking professional support can lead to the following problems: 

  • Taking inappropriate countermeasures: Without the necessary technical expertise, a cyber incident can easily be misjudged, leading to the implementation of inappropriate containment measures. This carries the risk of further damage, whilst potentially creating a false sense of security.
  • Failure to comply with legal requirements: Regulations such as NIS-2, the BSI Kritis Ordinance, the GDPR and many others contain requirements for dealing with cyber incidents, such as defined reporting obligations. If the staff of the affected company are inexperienced in dealing with security incidents, the situation can quickly become chaotic and confusing, and applicable regulations may be inadvertently breached. In addition to the financial damage caused by the incident, there is then a risk of substantial fines.
  • Covering up traces: When recovery measures are implemented, such as restoring backups, original traces that are important for investigating the incident may be unintentionally deleted or overwritten. This can result in the cause and extent of the attack not being sufficiently investigated, leaving a high risk, for example because not all compromised systems and accounts could be identified and remediated. 

To counter this scenario, it is essential to be adequately prepared for the occurrence of security incidents. Well-defined processes with clearly assigned responsibilities, including a system of deputies, could speed up decision-making and bring order to a chaotic situation. Furthermore, where possible, cyber insurance should be taken out to ensure greater flexibility for investment in an emergency and to avoid becoming bogged down in budget discussions. It is also helpful to enter into a contractual relationship with a qualified incident response service provider in advance, so as not to have to enquire with multiple service providers regarding available support capacity in an emergency. 

No documentation & routine

In our experience, when we are called in as an incident response service provider, it becomes clear from the very first meetings just how well an organisation is prepared for handling incidents and crisis management.

Are roles and responsibilities clearly defined? Is everyone fulfilling their duties? Is there an emergency manual, and is everyone familiar with it? How effectively can the emergency procedure be implemented in practice?



Without this preparation, coordination and the handling of further tasks lead to lengthy discussions without any important decisions being made. This wastes valuable time. 

Even well-prepared companies that have already developed an emergency manual can run into problems in exceptional situations if certain aspects have not been considered. In the case of ransomware attacks, for example, it is common for the entire IT-infrastructure to be encrypted and unavailable. This can mean that, in an emergency, the emergency plans cannot be accessed if they are not also available offline. 

Problems can also arise as the incident is dealt with. Questions about the structure of the IT-infrastructure quickly come to the table. 

  • Are there up-to-date network diagrams? 
  • Is there an overview of all assets?  
  • Can IP addresses be clearly associated with specific systems? 

If these questions cannot be answered – for example, because no documentation, or no up-to-date documentation, is available – it is not possible to take appropriate measures to contain and investigate the incident. Alternatively, processes may be slowed down because the information has to be obtained through other, more cumbersome channels.

In practice, this might manifest itself as follows: once a compromised system has been identified, it is often advisable to isolate it or disconnect entire network segments from the internet in order to prevent the attackers from spreading further. However, if the structure of the network is unknown and the dependencies on other systems and business processes are unclear, the measure cannot be implemented effectively, nor can the resulting risk to other areas be assessed.

Here, too, it is advisable to make preparations before an incident occurs and, in addition to defining an emergency procedure, to test it in practice by conducting emergency drills involving all relevant staff. This ensures that everyone is fully familiar with the procedure and that any gaps in the process are identified. 

Important documentation and emergency contacts should also be kept offline to ensure that the organisation remains operational even in exceptional crisis situations. In addition to processes, the IT-infrastructure must also be adequately documented so that, in an emergency, all necessary information — such as network diagrams and an overview of all IT systems — is readily available.

Use of private devices

In some of the incidents we have encountered, the affected company has had a so-called Bring-Your-Own-Device (BYOD) policy, allowing employees to use their personal phones or computers for work. However, when it comes to security incidents, this approach presents a number of challenges, depending on the specific circumstances:

 

    • Increased security risk: Private devices are not managed centrally by the company. It is often unclear what devices are involved, how securely they are configured and used, and whether, for example, security updates are installed regularly. They are also often not monitored by security software, making it difficult to detect in time if such devices have been compromised. In a previous incident, an employee fell for a phishing email and opened it on their private home pc, which later led to their account being compromised. For employees who opened the phishing link on company computers, the phishing attempt was detected and blocked by the deployed security software. Had the private device not been used, the resulting incident could have been prevented.
    • Difficult access during investigations: If private devices are involved in corporate security incidents, the company or the incident response service provider cannot use them for an investigation without the cooperation of the employee concerned. In such cases, most employees refuse to allow their private device to be examined by their employer or a third party. Access then requires additional involvement of a solicitor and the police, which delays the investigation and does not always lead to a successful outcome. Furthermore, this usually places a lasting strain on the relationship of trust between the employee and the employer. 

From an economic perspective, there are some arguments in favour of allowing privately owned devices; however, from an information security perspective, this poses significant risks and should be avoided or permitted only to a very limited extent under strictly controlled conditions. In the case of mobile phones, for example, manufacturers offer solutions that allow private and business data to be kept separate in distinct work areas. This prevents data from being exchanged between the areas, and the work area can be managed via the company’s device management system. Without these additional protective measures, however, access to company data and systems from personal devices should be prevented.

Conclusion

In this article, we have demonstrated how important factors such as time, well-defined processes and responsibilities, documentation, and control over one’s own IT-infrastructure are in the context of security incidents. In most cases, the hurdles outlined here can be mitigated through good preparation and by addressing the question ‘How do I prepare my company for a security incident?’ at an early stage. And, of course, even with good preparation, an incident can still raise new problems; however, it is possible to respond much more confidently if the foundations of emergency preparedness are in place.

 

In the next instalment of this series, we will take a closer look at staff shortages, inadequate service provider contracts and the challenges involved in managing security software. Here, too, we will share our practical experience and highlight what you need to bear in mind in the event of a security incident. 

Whether you need help assessing your security level, planning and implementing security measures, or require immediate assistance in an emergency, please do not hesitate to contact us.

Our cyber security experts are happy to assist you.

This article was written by