As an outsource security partner BAI provides managed security, managed firewall, managed ids, content filtering, internet security, network security, penetration testing, and vulnerability testing.

The way security investigations are performed in banks is receiving more attention nowadays. In the past, general procedures and practices for incident response were acceptable. However, due to security trends and regulations that affect banks specifically, these institutions require slightly different approaches to their security investigation progrmas in order to account for these new regulations and security trends.

This article provides a general overview of the security investigation process, how it fits within the incident response process, the required preparation process, specific issues in banks that need to be considered and the relationship between this process and security intelligence activities.

SECURITY INCIDENT INVESTIGATIONS
Security incident investigations are tasks aimed at answering questions (when, where, what, who, how and why) regarding a particular event that affected the information or infrastructure of an organization in an undesired, undefined and/or illegal manner.

In contrast to most types of security assessments, security incident investigations are reactive in nature (i.e. an incident has already been detected), and this puts additional pressure and time/resource constraints when compared to other security tasks.

Even so, an investigation of a security incident is not completely independent from other information security tasks. Other tasks can provide useful input before/during the investigation, be initiated as a result of the investigation or receive as input the results of the investigation.

Incident response process
The general model of incident response comprises six steps:
• Preparation
• Identification
• Containment
• Eradication
• Recovery
• Lessons Learned

Traditionally, proper security incident investigation activities would be expected to start at the last step. This model for incident response is appropriate for many businesses since it gives priority to business resumption. However, with banks we should expect the investigation process to be present (at least partially) in each of the six steps.

Banks face now difficult decisions while handling security incidents, mainly because of regulatory requirements. As with any other organization, they are definitely interested in stopping further damage (containment) and guaranteeing continuity of operations (recovery). However, new regulatory requirements require banks to not only fix the problem but also to investigate the causes, be able to determine the impact and, in some cases, notify third parties of the results of these investigations.

Unfortunately, many of the activities performed during the containment, eradication and recovery phases tend to destroy potential evidence that could be useful for the investigation of the incident. A typical example is the recovery from an intrusion; best practices recommend format and full reinstallation of a compromised system as opposed to simply trying to locate the problem and fix it. Reinstallation of the operating system and software (from trusted sources) is definitely a better way to ensure that the intruder won’t have any further access to this system, however, much of the evidence related to the incident is also lost.

A look at current security threats for banks and financial institutions also makes us realize that the traditional incident response process has to be modified. For instance, targeted attacks (e.g. malicious software created to commit fraud, social engineering attacks and phishing attacks) are becoming increasingly common for banks. Moreover, we know that many of these attacks start or are aimed at the interior of the organizations. Therefore, we cannot expect that traditional security controls will be able to spot these attacks.

Nontraditional sensors might be required to detect these threats, but even then, the task is not so easy. Imagine a hypothetical case where, a bank is able to detect unauthorized modification of customer’s information thanks to feedback from the affected individuals. What was the attack vector used? Which server do you have to format/reinstall (if any)? This example illustrates how the complexity of information processing within banks (many applications interacting with several databases and other applications simultaneously) can stop dead a traditional incident response approach.

In these cases, identifying a potential incident is still not enough to proceed with containment, eradication and recovery. A security incident investigation needs to take place at this point to correctly identify attack vectors and impact before other incident response teams are able to do their job.

The following table summarizes a suggested approach to involve the investigation function within a security incident response process in banks:

 

From what we have discussed about the conflicts between security incident investigations and other incident response tasks, we can conclude that banks require security investigations that are:

• Fast – Other security functions my depend on it (e.g. identification step)
• Reliable and accurate – They must comply with regulatory requirements and best accepted practices.
• Non intrusive – They should not affect other security tasks (in particular, containment, eradication and recovery tasks during incident response). Hence it might not be possible to take systems off-line to perform the investigation.
• Complete – Investigations should include answer to the following questions regarding the incident: what, what, when where, how, who and why.