Security Incident Investigations Within Financial Institutions - Part 1 of 2
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 financial institutions 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:
â€¢ 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 financial institutions we should expect the investigation process to be present (at least partially) in each of the six steps.
Financial institutions 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 institutions 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 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 financial institutions. 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, an institution 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 institutions (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 financial institutions:
|Traditional security incident response steps||Involvement of the security incident investigation function|
|Preparation||Requires: infrastructure processes and procedures in place to preserve evidence while interfering as less as possible with other incident response tasks. Also, Information and procedures should be in place to speed up the investigation.
Provides: Feedback to improve other incident response (and security) tasks.
|Identification||Requires: Indication of a probable incident and location where to start an investigation.
Provides: Confirmation of the incident, impact/extent information, and other details.
|Requires: information regarding any activities that might affect evidence or the investigation process (what, when where, how, who and why).
Provides: investigation results. I.e. information that can also be useful to perform more effective containment, eradication and recovery tasks.
|Lessons Learned||Requires: information about any problems during incident response where the incident investigation function was involved (e.g. input expected from the investigation that was not available or not useful).
Provides: security intelligence (i.e. evidence correlation that helps improve incident response and other security practices).
From what we have discussed about the conflicts between security incident investigations and other incident response tasks, we can conclude that financial institutions 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.