Security Incident Investigations Within Banks - Part 2 of 2

Security Incident Investigations Within Banks - Part 2 of 2
> Read part 1 of this article

Preparing for security incident investigations

Preparation is the most important phase of security incident investigations since most of the requirements previously discussed can’t be addressed at the time the investigation is being conducted.

Preparations shall therefore address these requirements (what the investigation must provide) and also the needs of the investigation process itself (i.e. all that is required by the investigation process from other sources).

To increase speed, we need to perform as many tasks as possible before any investigation starts. These tasks include:

• Gathering contact information
• Preparing and testing investigation resources
• Automating investigation activities (software/hardware)
• Preparing all administrative work (forms with some pre-filled fields, negotiate access authorizations, establishing communication channels and contact information)
• Ensuring that needed information is available (e.g. infrastructure maps, resource allocation/location information)

Of the above, access to resource information might be one of the most critical and difficult requirements to fulfil. During an incident investigation, security personnel will have to know things like: physical location of a computer, corresponding network information, applications used and their function, relationship between applications and other systems and contact information for personnel responsible for these resources. The application information might be particularly complex to document and analyze. Banks usually develop home-made applications to support customized services; maintaining detailed documentation of each application and their relationships with other resources is not an easy or cheap task.

However, it is essential that this documentation be accurate and readily available for investigators. Searching the location of a PC based on its IP might take up to a few hours if there is no information or a logical allocation scheme in place; also, having investigators wasting time to figure out the relationships with other systems and applications during the investigation is not optimal, especially when the rest of the incident response teams are waiting for information from this investigation to start acting.

Regulations are also an issue for Banks since they can affect the scope and the way investigations are conducted. Some regulations require certain levels of the hierarchy to be immediately notified of certain (serious) incidents. Also, customers, third parties (e.g. PCI Data Security Standard) and the law enforcement (e.g. FTC/OCC regulations) might need to be notified, under some circumstances, within a limited time frame. Other standards and regulations require evidence preservation for security incidents and proper training for personnel conducting security incident investigations (e.g. ISO 17799, Basel II Accord). Hence, lawyers from banks have to be deeply involved at this stage.

The rest of the requirements, reliability, accurateness, non-intrusiveness and completeness can be achieved with proper system replacement procedures (e.g. connecting alternative backup systems while the affected system is brought down for investigation) and implementing proper audit trails in key locations. Intrusion detection systems can provide useful information to a certain degree, but at the application level (and we already mentioned the prevalence of custom made applications within banks) secure audit trail systems must be integrated in the right places.

Regarding the identification phase of the incident response process, we know that the investigation needs to have at least a minimum of information regarding an incident (namely, that it probably exists and a starting point for the investigation). Since other tasks within the incident response process might actually require the results from an incident investigation to proceed, we already know that traditional sources of information for these tasks (e.g. intrusion detection systems and audit trails) won’t be enough.

One of the most important sources of information for investigations is feedback from human beings. Due to the targeted nature of some types of attacks aimed at banks, many of these might go unnoticed for traditional security controls (e.g. external phishing attacks against customers, social engineering attacks targeting specific employees). Incorporating these individuals into the sensor network is therefore essential to have effective detection methods for all types of security incidents.

The nature of human feedback should of course be considered. To reduce the amount of irrelevant/incorrect information, people must be properly trained to identify potential security issues, including how, when and what to report.

Another source of information that is gaining popularity is that produced by security intelligence activities. Incorporating this information into the identification phase of the incident response process requires an important amount of resources and an effective data processing design, but once it is properly set up, it should provide effective and quick detection of the most stealth and complex incidents taking place within organizations.

Security intelligence

Security intelligence is the process by which information from different sources is analyzed and correlated to produce relevant information of events that are difficult to detect, understand or analyze by using only one of these sources of information.

In respect to security incident investigations, security intelligence provides valuable input for these tasks and, at the same time, uses results from these investigations as input for its own. This cyclic relationship makes security intelligence an important partner of security investigation activities.

Banks have used security intelligence for several years already. The anomaly behavior detection systems deployed within several banks to detect things like credit card fraud and account misuse are good examples. Banks can actually benefit from this experience and extend the concept to include other types of uncommon or unauthorized activity that might affect information security.

Another example might help to clarify further how security intelligence can be applied to detect complex attacks. Suppose that an employee within an organization received a call from an alleged survey about workforce, asking him information about his job and offering a free CD with “useful software” as a prize. By itself, this might just seem a typical marketing strategy to create databases for potential customers. Let us suppose that employees within this bank were trained to report anomalous activity like this through. A security incident investigator could find a pattern by correlating information reported by some employees and deciding to “inspect” the contents of the CD and the information being gathered during the phone calls. What if this CD contained a custom-made trojan horse that was not being detected by antivirus software? What if this software was leaking information out of the bank by using covert channels within common outbound traffic, thereby avoiding detection or blocking from firewalls and intrusion detection systems as well? (E.g. connecting to web sites and leaking the information through forms within these Web pages).

In this hypothetical case, the investigator might identify the security incident quickly and start the incident response process to avoid additional damage. Furthermore, a quick reaction might allow investigators to gather other volatile information before they are deleted, which might prove useful for the investigation (e.g. Caller-ID records related to the phone calls from phone system’s logs might allow law enforcement to quickly locate the criminals).

Cases like this are real threats for organizations. To illustrate this, The Training Camp carried out recently an experiment that involved employees from several financial institutions located within London’s Square Mile. Employees were handed out CDs containing software that would report its execution to the researchers. The experiment concluded that several employees from these financial institutions (banks included) attempted to execute the application within the CD using their corporate PCs (despite a warning printed on the CD box about the risks of installing unauthorized third party software).

The investigation process

Sound practices for security investigations should be used during security incident investigations (e.g. NIST, ACPO and ENFSI guidelines). Some of these principles include:

• Preserve evidence integrity
• Document all your actions
• Train investigators properly
• Keep track of evidence at all times (chain of custody)

The basic investigation process involves the following basic steps:

• Incident detection (starts the process)
• Scope definition
• Information/evidence gathering
• Information analysis
• Results delivery

Within banks, the investigation process is usually not as linear previously outlined; it becomes rather a spiral process after the first step, with investigators going forth and back between scope (re)definition and results deliveries, refining the process at each cycle.

Regarding issues specific for banks (most of them due to regulatory requirements) there are some areas where investigators must be particularly careful:

Issues with incident notification: With complex organizations such as banks, it is better to have a department that centralizes all calls and information that could be potentially

Issues with scope definition: severe restrictions on the actions and time allowed for investigations within banks are the norm rather than the exception. Investigators should therefore be as specific as possible in terms of scope. As more information is available the scope can be narrowed to increase speed. However, investigators should still be careful to avoid overlooking relevant evidence. A breadth-first approach is therefore more appropriate than a depth-first approach. E.g. if fraud through network services is suspected, it makes sense to analyze network activity logs from several related devices first, instead on focusing on network activity, application activity, local access logs, and stored files of a single system before moving on to investigate other related systems.

Issues with the involvement of other personnel: apart from other information security personnel taking part in the incident response process, the complexity of business processes requires the involvement of other IT and non-IT personnel, such as system administrators, business unit managers and lawyers. The involvement of such personnel, if managed correctly, should also speed up the investigation by taking advantage of the knowledge and experience of people in their areas of expertise. Additionally, investigators should be aware of situations where external personnel should be involved as required by some regulations (e.g. law enforcement and third party auditors).

Issues with documentation: some regulatory requirements are very specific on the kind of information and level of detail required for any documentation regarding the investigation process. Even though many investigations are conducted internally and many of them are not expected to involve external personnel or even reach court, these situations can never be predicted. For this reason it makes sense to always maintain the same, high quality, documentation standards for all security incident investigations.

Technical issues: being able to unplug critical business systems to analyze them in a controlled environment is not likely to happen frequently during security incident investigations in banks. Investigators should then be prepared (with proper tools and training) to conduct live system investigations. Also, many times the investigation might involve massive storage systems (e.g. databases), for which getting full disk images is impractical (if not impossible). Investigators should therefore be familiar with such systems to be able to get specific pieces of information quickly (starting with the most volatile information). Finally, investigators should be aware of the best approaches to perform the investigation by considering the situation and resources involved in the incident (e.g. financial audits if financial information has been affected at application level, computer forensic techniques for many security issues at operating system and file system levels, malware analysis techniques if malicious software is involved, CCTV records and entry/exit logs analysis if physical access is involved).

Management issues: communication with top management and lawyers is essential. As soon as an incident turns out to be relevant both need to be notified since many decisions can only be taken by them (e.g. when to go public, notify customers about an incident or involve law enforcement).

CONCLUSIONS

Security incidents investigations within banks have particular requirements that make them significantly different from other investigations conducted in other types of organizations.

Although complex and resource consuming, possessing security incident investigation capabilities is almost mandatory for banks in many countries due to recent changes in regulations.

These investigations are an essential part of the incident response process in banks; their preparation is the most critical aspect to guarantee effectiveness and efficiency. Security incident investigations also require basic information to start; this information might not come from traditional information sources

Finally, a security incident investigation process is a valuable element for the security intelligence function within organizations. This integration plays an important role in the detection and prevention of the most stealth and complex security incidents.

> Read part 1 of this article


About the Author

Omar A. Herrera Reyna - CISA, CISSP

Omar Herrera is an information security officer working for the central bank of Mexico. He has previously worked as information security consultant for Deloitte and is member of the OISSG. He is experienced in technical information security assessments, risk analyses, incident response team management, technical security training and malicious software analyses.




Around the Network