Canadian Underwriter

Cyber Investigations

May 31, 2014   by Trevor Raybould, IT claim investigator, Newtron Group

Print this page Share

McAfee’s The Economic Impact of Cybercrime and Cyber Espionage report estimates that cybercrime costs the global economy between $300 billion to $1 trillion Companies have a balancing act when it comes to IT security – they need to put a reasonable effort into protecting their network and data; at the same time, they must also take into account employee productivity and security costs. In many cases, companies will implement a reasonable safeguard to reduce risk, and have insurance coverage to protect against the residual risk.

When an attack happens, it may be noticed immediately or may not be noticed for some time. Once it is noticed, the typical reaction most organizations have is to identify and fix the breach then repair any damage caused by the breach as soon as possible. At this point, the true extent of damage starts to emerge and an insurance claim is often submitted. It is understandable that companies want to repair the damage and get up and running as quickly as they can. This, however, may result in a loss of evidence, may thwart any data recovery efforts, and may make the determination of eligibility for insurance coverage a difficult task.

Every investigation encountered is different. Even though scientific methods are applied to the investigations, they are often an art form that requires intuition and creativity. In one case, digital evidence may be plentifully and easily available; and in another case, it can be the complete opposite, and the bulk of the evidence must be gathered by interviewing people. It is important for an investigator to work around the roadblocks and keep working towards uncovering the facts of the case.

Just about every investigation requires more data be collected than what was originally communicated to the adjuster, or the adjuster appointed expert, to start the claim. Once the data is collected and analyzed, the investigator can then construct a hypothesis. In most cases, the initial hypothesis is typically dictated by the insured because they have the first person account of the events that took place, and the steps they took to repair the damage. An experienced investigator will keep that in mind, but he or she must also maintain an open mind and be willing to accept and investigate other theories, especially if the facts do not fully fit. The investigator’s ultimate goal is to determine the true nature of events.

The first example case below demonstrates how an investigator must keep an open mind and be willing to accept and investigate additional theories. The second example case demonstrates how the wrong approach to handling an attack can lead to evidence loss and increase costs.

A company suffers a network wide outage for a span of a week. They worked with their vendors to try and determine the root cause of the problem. Their vendors investigated the issues and decided their problems were hardware related and started replacing parts. Several items were replaced but that did not correct the problem. After a complete network reset the problem went away. In this case the initial hypothesis was that equipment breakdown was the root cause. The insurance company appointed investigator started reviewing diagnostic logs submitted by the vendors but failed to find any evidence of any hardware failure. The investigation cannot stop here, it is time to move on and investigate other theories. The facts of the case now point to a denial of service attack as the next best theory.

Additional information was gathered through interviews and through review of additional documents. Network traffic analysis was performed, and information gathered showed an incredible spike of traffic. By comparing this to baseline information, it was determined that this traffic pattern was consistent with that of a denial of service attack. After collecting and analyzing all the technical logs and support case notes, it was time to interview the IT staff to get details about how the problem was finally resolved. Information gathered revealed that the steps taken towards the resolution of the incident did not fit with what would have taken to stop a denial of service attack. By that time the easy answers were off the table, it was time to dig deeper and examine the network configuration and see if there were any clues there.

After a review of the network configuration, and after revisiting the network traffic information, as well as the steps taken to resolving the issue, it was discovered that the insured was a victim of a network loop that created a broadcast storm. Network switches can be connected together in a manner to create a redundant path through the network in the event that the original path experiences a failure. This second pathway is supposed to remain inactive and not allow network traffic to pass until there is a failure in the primary pathway. The loop occurs when network traffic travels through both paths unexpectedly due to a hidden flaw in the overall system, and some of that traffic circles from the primary pathway to the secondary pathway and back. This resulted in a broadcast storm that flooded the network, using up all the available resources and prevented legitimate network traffic to get through, and grounded the network to a halt. A network outage was the final result.

This second example in an incident of how important it is to not immediately fix a breach and the resulting damage, but to plan the approach and seek expert guidance to minimize the loss of evidence.

Over the course of a weekend, a company’s server was allegedly breached and had a crypto locker virus installed and activated inside it. On Monday morning when the office opened up the employees were unable to connect to the server and access their data. Some employees were working over the weekend prior to that and the system appeared fine. Their IT support was called, and their personnel took pictures of the crypto locker message on the screen and then proceeded to repair damages done to the server. The initial hypothesis was that someone had hacked into their servers, installed and activated the virus. The insurance company was called.

Once the IT support staff completed the reloading and reconfiguring of the server, they moved on to try to restore the data from backups; this is where they discovered that all their backups were empty. An investigation was launched to determine what happened, how it happened, and if there was any possibility of recovering the data. The hard drives and backup devices were removed for examination and retrieval of evidence and to recover data. Unfortunately, due to the rebuilding of the server, alteration to the old file system was too extensive to be able to recover any data or digital evidence. The backup devices were empty – the company had failed to properly setup and test their backup system prior to the loss, and it was not working.

A review of the firewall logs and their configuration was conducted to try and develop a theory of how the breach could have happened. The logs yielded no evidence, but the configuration showed ports were opened up to allow incoming traffic. It was also revealed that there was no virus protection available on the server.

Due to the lack of digital evidence, the investigation had to rely on firsthand accounts of the incident. After conducting interviews with staff and their IT support, the investigator determined that no additional useful information could be gathered, and the case remained inconclusive.

The above examples illustrate that it is the investigator’s responsibility to remain impartial, maintain an open mind, be willing to accept and investigate other theories, and be able to conclude that the cause is undetermined when situation warrants. The conclusions on cause of failure must stand up to scrutiny and any challenges that are subsequently put forth. This is true for IT claims investigation, and is also true for any type of claim investigation.

Trevor Raybould, CISSP, is an IT professional and IT claim investigator with Newtron Group. Trevor has over 15 years of experience in the industry with a focus on cyber security and incidence investigations.

Print this page Share

Have your say:

Your email address will not be published. Required fields are marked *