Financial institutions are heavily regulated. They are required to implement security programs following regulations such as SOX, GLBA, SEC, NASD, etc. In fact, most of these organizations are required to execute an annual security assessment as a key compliance measure. Because an annual assessment may not discover all vulnerabilities, these organizations should be prepared to deal with security incidents involving physical facilities, network infrastructures, systems, applications, and most importantly, data.
Obviously, an entity that has no proactive mechanism to detect data, information, or system compromise wastes enormous amounts of time and money addressing an actual compromise without a response plan. To be able to deal with computer or IT related compromises, certain measures should be implemented by the institution. The following outlines example precautionary steps recommended for a bank, but some of the measures are valid for any institution.
Preparing for the inevitable
A banking institution must involve all of its resources in its security operation, including people, process and technology. Consider the following:
Planning: This involves identifying the financial institution's business assets, identifying the risks, and developing plans for mitigation. Planning here involves determining what security measures need to be in place. Example of planning activities include developing a security policies and procedures document, developing change management plans, instituting a contingency plan and incident response plan (forensics), etc. This phase of the security process also requires the identification of security technologies that need to be in place to meet business requirements.
Implementation: This stage requires the actual installation or deployment of a security technology that would provide secure communication end-to-end, as may be required. Technologies offering various levels should be in place – firewalls, proxies, content filtering, VPNs, IPDS, etc. Once implemented, these technologies must be constantly reviewed and tested following best practices for the banking business.
Monitoring and response: Active monitoring is an absolute requirement. Having the best security protection technologies serve no purpose unless each of those devices is proactively monitored. While banks sometime cover the monitoring of networks and systems, back-end and other applications may not be too vigilantly monitored. Monitoring any device that stores, processes, or transmits information is crucial for after-the-fact investigation or other root-cause analysis. Adequate personnel need to be staffed and charged with the monitoring activity. Monitoring means logging critical data or events, including affected network, email, system, application applications, and everyone's activity – with no exception. In fact, recent requirements by NASD, SEC, GLBA, SOX, etc. require that banks and other financial entities perform archiving of communication, such as emails. Logging everyone's activity satisfies this requirement and keeps bank officials out of trouble.
Further, logs should be proactively reviewed. Automated mechanisms should be implemented to disseminate summarized reports of log events.
An area that is often overlooked is the monitoring of applications and operations performed by banking application software. At a minimum, a summarized list of actions of interest may be desired – delivered through email or other manual process execution.
Measurement: This involves identifying the weakness in the security process or program, which may be accomplished through risk assessment, vulnerability assessment, penetration testing exercises, testing of the contingency planning, incident response plan, and so forth, on a proactive basis. The result of this effort is used to determine what areas of the bank's security operation need to be enhanced.
Education and training: To get the bank employees involved in the security process, they must be provided user awareness training at least twice yearly. Through this process, employees are informed of the risks associated with computers and the internet, and their roles and responsibilities to protect data.
Here are some other best practices that a bank can implement to fortify its security posture:
Synchronize systems time: It's important to synchronize all systems with some trusted time server internal to the organization. This is required should a security incident occur and events from different systems need to be correlated. Besides, correctly setting system time helps your case should you end up in civil or criminal litigation.
Collect and preserve log data: Collecting and preserving the financial institution's log data is crucial when an after-the-fact investigation is warranted. When properly collected, with accurate time stamps of each entry, your organization would be covered when questioned by authority or other investigative bodies. Data can be collected centrally to a server – there are pros and cons to this approach.
Due to the discrepancies between systems and the fact that a common central logging server cannot be implemented in the real-world, each medium that captures log data must follow these guidelines:
While the implementation of the techniques listed above helps in the fortification of an organization's security process, a key element that is often missed and should be included into any security process is an incident response plan. A security incident is a breach that compromises confidential information, alters information, or makes data or information inaccessible. An incident response plan is the process of monitoring for and detecting security events on an information system while implementing appropriate responses to these incidents. Formulating a bank's incident response plan is an absolute requirement to enable the bank to monitor, detect, and contain a potential compromise of its assets.
The following are benefits of a sound incident response plan:
Form a security incident response team: While a formal Security Incident Response Team (SIRT) team is recommended, it must be championed by an incident response manager or coordinator. This manager need not be an executive within the organization, and can be a staff member whose primary role is to coordinate and manage the incident response process. Members of the forensics team in a bank may include representatives from the following departments: risk management, IT, legal, PR (if outside communication would be required), security, compliance department, internal audit, operations, and other groups relevant to the financial institution.
Once a team has been formed, each member needs to be adequately trained on their role in recognizing security incidents, reporting, and containment.
Train all users about incident and reporting: All users of a financial institution, as part of their security awareness training, should be trained on detecting and responding to security incidents. In other words, if a bank's employee detects an incident, what should they do? Incident response should be everyone's responsibility -- everyone should be thought of as a member of the SIRT.
Reward employees for participating in the program: Employees should be rewarded for detecting and reporting security incidents in order to encourage employee participation in the program.
Thoroughness of the incident response plan
It is recommend that an incident response plan be thorough – not simply covering network or system-borne attacks, but attacks that go beyond these areas, including users, applications, and actual data. Assuming that a teller in a bank is a target and his/her system is compromised because he/she opens a Trojan in an email attachment, how does the bank respond to these types of incidents?
In security, if you can't assess or gauge how well a security element is working, it would be difficult to assume that such an investment is providing the anticipated ROI for the institution. To this end, an assessment is required. This assessment can be carried out by in-house staff or by a third-party consulting firm.To be truly effective, use the third-party without the knowledge of personnel responsible for detecting incidents within the company.
Areas to test
As discussed previously, testing the incident response plan may not have to be done at one time for the entire organization. While this approach would work for a small banking operation, we suggest for larger banks breaking the testing into appropriate parcels focused at specific groups, applications, or data of a specific customer. Testing should cover the following areas:
Testing can be done in a variety of ways. The key thing to recognize is to look into your corporate environment and run tests that simulate a breach. A thoroughly executed infrastructure penetration test can be implemented here. With a penetration test, the testers can attempt to evade IPDS, firewalls, and other tests that would cause the monitoring systems to ignore serious network attack simulation.
What about attacks at the application and data level? An IDS may not be able to detect these, especially the attacks that occur through a VPN or other encrypted tunnels such as SSH, SSL, etc.
Testing could be broken down into various stages by targeting specific areas. For instance, testing could be targeted at core banking applications. Does the organization detect failed login attempts or unauthorized access?
Forensics procedures to institute for possible litigation
To determine that an intrusion has occurred requires proactive monitoring of systems, applications, and data. Sometimes, these factors may not be able to determine a successful compromise. Anomalous or “usual” behavior/activity may be the symptom of a compromise. Sometimes, a compromise may not even be noticed unless different data and events are correlated. To detect a breach quickly, the bank must define what constitutes a compromise and ensure that the parameters for detection are in place, working, and producing the desired actionable items quickly. Detection might be in the form of email alerts, pagers, or even a manual reporting mechanism.
Once it has been determined that a compromise has occurred, the bank must begin the investigation of the incident. Without a forensic incident response plan (FIRP), a bank may not be prepared for this task. Upon quick determination of the breach, the source and nature of the intrusion or compromise would dictate whether or not to shutdown a system.
Information gathered as described above will become useful in the next phase – forensically collecting and preserving the evidence.
First, you must know the source of the breach. Depending on the scope of damage, get the compliance department, risk management group, and the IT department involved. Law enforcement may be contacted, depending on the FIRP of your institution. Care should be exercised here because contacting law enforcement could require shutting down some of your services, which may remain down until replacement systems are deployed. So, unless you want an extensive service outage or unwanted publicity, be cautious as you seek outside help – FBI, local law enforcement, press, etc.
Evidence should be collected in a forensically sound manner, following procedures that can withstand the scrutiny and rigor of litigation and to avoid being inadmissible in court. First, you need to know what type of forensic evidence can be found for the event – money laundering, fraudulent wire transfer, insider trading, etc. – to narrow the scope of the investigation. Evidence in a computing device comes in two forms – volatile and non-volatile or persistent evidence. As the name suggests, volatile evidence are data that is stored in medium that when power is lost to the “suspect” computing device, the information is lost -- this includes memory, cache, etc. On the other hand, persistent evidence is data that remains intact regardless of power outages. Examples include devices such as hard drives, flash drives, or USB devices.
What type of evidence should you collect during an investigation? This really depends on the scope. For a fraudulent wire transfer operation that occurred, the suspect system may be gracefully disconnected or shutdown to begin the forensics process. On the other hand, for a compromise or attack that is ongoing, volatile data must be carefully forensically collected first, then the system can be shut down and persistent evidence collected.
To properly collect evidence and avoid contamination or destruction, follow these simple guidelines:
Once the evidence has been forensically collected, it is necessary to perform analysis on one of the forensic images. Note that, we do not want to perform our analysis on the original copy of the hard drive (“best evidence”), but rather, we want to work on one of the forensic copies we created.
Suppose that we are investigating a successful penetration of a bank's backend database system by an outsider. We may be interested in knowing activities that preceded the actual database attack, source IP addresses, user names/IDs used, web pages that may have triggered the compromise, event time, etc. Consequently, we may implement the following guidelines during our investigation:
Forensics investigation is about excavating evidence and providing the facts. Do not step beyond your bound or extend your scope. This approach is time consuming, expensive, and may be illegal!
Create a report that is easy to read and understand by laypeople and legal counsel that may be assigned. Ensure that this document is adequately peer-reviewed. The report should explain technical terms because it may be read by other attorneys or judges who may not understand technical jargon.
Conclusion
To conduct computer forensics well and produce results that are defensible in the courts, banks must plan for data breaches, develop forensics incident response plans to reduce their risk of data breaches and mitigate the possibility of law suits. Proactive measures today reduce reactive responses in the event of a breach.
Inno Eroraha is the president of NetSecurity Corporation, a digital forensics, security consulting and training company. For more information go to www.netsecurity.com or call 703-444-9009 or toll free at 866-664-6986.
Obviously, an entity that has no proactive mechanism to detect data, information, or system compromise wastes enormous amounts of time and money addressing an actual compromise without a response plan. To be able to deal with computer or IT related compromises, certain measures should be implemented by the institution. The following outlines example precautionary steps recommended for a bank, but some of the measures are valid for any institution.
Preparing for the inevitable
A banking institution must involve all of its resources in its security operation, including people, process and technology. Consider the following:
Planning: This involves identifying the financial institution's business assets, identifying the risks, and developing plans for mitigation. Planning here involves determining what security measures need to be in place. Example of planning activities include developing a security policies and procedures document, developing change management plans, instituting a contingency plan and incident response plan (forensics), etc. This phase of the security process also requires the identification of security technologies that need to be in place to meet business requirements.
Implementation: This stage requires the actual installation or deployment of a security technology that would provide secure communication end-to-end, as may be required. Technologies offering various levels should be in place – firewalls, proxies, content filtering, VPNs, IPDS, etc. Once implemented, these technologies must be constantly reviewed and tested following best practices for the banking business.
Monitoring and response: Active monitoring is an absolute requirement. Having the best security protection technologies serve no purpose unless each of those devices is proactively monitored. While banks sometime cover the monitoring of networks and systems, back-end and other applications may not be too vigilantly monitored. Monitoring any device that stores, processes, or transmits information is crucial for after-the-fact investigation or other root-cause analysis. Adequate personnel need to be staffed and charged with the monitoring activity. Monitoring means logging critical data or events, including affected network, email, system, application applications, and everyone's activity – with no exception. In fact, recent requirements by NASD, SEC, GLBA, SOX, etc. require that banks and other financial entities perform archiving of communication, such as emails. Logging everyone's activity satisfies this requirement and keeps bank officials out of trouble.
Further, logs should be proactively reviewed. Automated mechanisms should be implemented to disseminate summarized reports of log events.
An area that is often overlooked is the monitoring of applications and operations performed by banking application software. At a minimum, a summarized list of actions of interest may be desired – delivered through email or other manual process execution.
Measurement: This involves identifying the weakness in the security process or program, which may be accomplished through risk assessment, vulnerability assessment, penetration testing exercises, testing of the contingency planning, incident response plan, and so forth, on a proactive basis. The result of this effort is used to determine what areas of the bank's security operation need to be enhanced.
Education and training: To get the bank employees involved in the security process, they must be provided user awareness training at least twice yearly. Through this process, employees are informed of the risks associated with computers and the internet, and their roles and responsibilities to protect data.
Here are some other best practices that a bank can implement to fortify its security posture:
Synchronize systems time: It's important to synchronize all systems with some trusted time server internal to the organization. This is required should a security incident occur and events from different systems need to be correlated. Besides, correctly setting system time helps your case should you end up in civil or criminal litigation.
Collect and preserve log data: Collecting and preserving the financial institution's log data is crucial when an after-the-fact investigation is warranted. When properly collected, with accurate time stamps of each entry, your organization would be covered when questioned by authority or other investigative bodies. Data can be collected centrally to a server – there are pros and cons to this approach.
Due to the discrepancies between systems and the fact that a common central logging server cannot be implemented in the real-world, each medium that captures log data must follow these guidelines:
- Physically secure the device
- Log access to it
- Allow only the auditing team to read the data
- Prevent direct modification to the log data
While the implementation of the techniques listed above helps in the fortification of an organization's security process, a key element that is often missed and should be included into any security process is an incident response plan. A security incident is a breach that compromises confidential information, alters information, or makes data or information inaccessible. An incident response plan is the process of monitoring for and detecting security events on an information system while implementing appropriate responses to these incidents. Formulating a bank's incident response plan is an absolute requirement to enable the bank to monitor, detect, and contain a potential compromise of its assets.
The following are benefits of a sound incident response plan:
- Provides a method to monitor and quickly identify a potential security breach
- Specifies a step-by-step process of how to handle an incident – i.e., specifies what to do when a security incident occurs
- Specifies how to contain and reduce the risk of damage to an organization
Form a security incident response team: While a formal Security Incident Response Team (SIRT) team is recommended, it must be championed by an incident response manager or coordinator. This manager need not be an executive within the organization, and can be a staff member whose primary role is to coordinate and manage the incident response process. Members of the forensics team in a bank may include representatives from the following departments: risk management, IT, legal, PR (if outside communication would be required), security, compliance department, internal audit, operations, and other groups relevant to the financial institution.
Once a team has been formed, each member needs to be adequately trained on their role in recognizing security incidents, reporting, and containment.
Train all users about incident and reporting: All users of a financial institution, as part of their security awareness training, should be trained on detecting and responding to security incidents. In other words, if a bank's employee detects an incident, what should they do? Incident response should be everyone's responsibility -- everyone should be thought of as a member of the SIRT.
Reward employees for participating in the program: Employees should be rewarded for detecting and reporting security incidents in order to encourage employee participation in the program.
Thoroughness of the incident response plan
It is recommend that an incident response plan be thorough – not simply covering network or system-borne attacks, but attacks that go beyond these areas, including users, applications, and actual data. Assuming that a teller in a bank is a target and his/her system is compromised because he/she opens a Trojan in an email attachment, how does the bank respond to these types of incidents?
In security, if you can't assess or gauge how well a security element is working, it would be difficult to assume that such an investment is providing the anticipated ROI for the institution. To this end, an assessment is required. This assessment can be carried out by in-house staff or by a third-party consulting firm.To be truly effective, use the third-party without the knowledge of personnel responsible for detecting incidents within the company.
Areas to test
As discussed previously, testing the incident response plan may not have to be done at one time for the entire organization. While this approach would work for a small banking operation, we suggest for larger banks breaking the testing into appropriate parcels focused at specific groups, applications, or data of a specific customer. Testing should cover the following areas:
- Compromise of core banking application
- Data access
- Systems
- Network
- Facility
Testing can be done in a variety of ways. The key thing to recognize is to look into your corporate environment and run tests that simulate a breach. A thoroughly executed infrastructure penetration test can be implemented here. With a penetration test, the testers can attempt to evade IPDS, firewalls, and other tests that would cause the monitoring systems to ignore serious network attack simulation.
What about attacks at the application and data level? An IDS may not be able to detect these, especially the attacks that occur through a VPN or other encrypted tunnels such as SSH, SSL, etc.
Testing could be broken down into various stages by targeting specific areas. For instance, testing could be targeted at core banking applications. Does the organization detect failed login attempts or unauthorized access?
Forensics procedures to institute for possible litigation
To determine that an intrusion has occurred requires proactive monitoring of systems, applications, and data. Sometimes, these factors may not be able to determine a successful compromise. Anomalous or “usual” behavior/activity may be the symptom of a compromise. Sometimes, a compromise may not even be noticed unless different data and events are correlated. To detect a breach quickly, the bank must define what constitutes a compromise and ensure that the parameters for detection are in place, working, and producing the desired actionable items quickly. Detection might be in the form of email alerts, pagers, or even a manual reporting mechanism.
Once it has been determined that a compromise has occurred, the bank must begin the investigation of the incident. Without a forensic incident response plan (FIRP), a bank may not be prepared for this task. Upon quick determination of the breach, the source and nature of the intrusion or compromise would dictate whether or not to shutdown a system.
Information gathered as described above will become useful in the next phase – forensically collecting and preserving the evidence.
First, you must know the source of the breach. Depending on the scope of damage, get the compliance department, risk management group, and the IT department involved. Law enforcement may be contacted, depending on the FIRP of your institution. Care should be exercised here because contacting law enforcement could require shutting down some of your services, which may remain down until replacement systems are deployed. So, unless you want an extensive service outage or unwanted publicity, be cautious as you seek outside help – FBI, local law enforcement, press, etc.
Evidence should be collected in a forensically sound manner, following procedures that can withstand the scrutiny and rigor of litigation and to avoid being inadmissible in court. First, you need to know what type of forensic evidence can be found for the event – money laundering, fraudulent wire transfer, insider trading, etc. – to narrow the scope of the investigation. Evidence in a computing device comes in two forms – volatile and non-volatile or persistent evidence. As the name suggests, volatile evidence are data that is stored in medium that when power is lost to the “suspect” computing device, the information is lost -- this includes memory, cache, etc. On the other hand, persistent evidence is data that remains intact regardless of power outages. Examples include devices such as hard drives, flash drives, or USB devices.
What type of evidence should you collect during an investigation? This really depends on the scope. For a fraudulent wire transfer operation that occurred, the suspect system may be gracefully disconnected or shutdown to begin the forensics process. On the other hand, for a compromise or attack that is ongoing, volatile data must be carefully forensically collected first, then the system can be shut down and persistent evidence collected.
To properly collect evidence and avoid contamination or destruction, follow these simple guidelines:
- Avoid writing to or modifying the “suspect” system – doing this could result in crucial evidence been rendered inadmissible.
- Collect everything that may be relevant to a case. For instance, if you were to perform a forensics analysis on a PDA device, it may be wise to collect all the power supplies and cradle for the device.
- Use trained forensics employees – don't wing it or you risk your evidence being tossed out in court. Alternatively, you may consider retaining outside forensics and electronic discovery consultants to assist you.
- Use a chain of custody form that shows possession or transfer of evidence in the investigation.
- Use “court-sanctioned” or recognized forensics tools
- Validate each piece of evidence, using hashing algorithms – SHA1 or MD5.
- Create forensics images of the suspect system. A forensics image is a bit-by-bit copy of the suspect hard drive. This copies both unallocated and allocated slack space containing deleted files, etc. In a system with terabytes of data, forensically imaging the drive may not be possible as it may take years and may be very expensive. In this case, logical file copy may be acceptable to a court. At least two images are recommended.
- Don't attempt to install applications into the suspect system.
- Do not modify the system as this may be considered evidence tampering.
- Make a note of why you took every action you took during the investigation.
Once the evidence has been forensically collected, it is necessary to perform analysis on one of the forensic images. Note that, we do not want to perform our analysis on the original copy of the hard drive (“best evidence”), but rather, we want to work on one of the forensic copies we created.
Suppose that we are investigating a successful penetration of a bank's backend database system by an outsider. We may be interested in knowing activities that preceded the actual database attack, source IP addresses, user names/IDs used, web pages that may have triggered the compromise, event time, etc. Consequently, we may implement the following guidelines during our investigation:
- Execute a forensics tool and perform an analysis of the drive and look for evidence (information defined above).
- Create a “bookmark” of evidence gathered. You can refer to items in the bookmark easily instead of reanalyzing the forensic image. Artifacts bookmarked can easily be used in the report.
Forensics investigation is about excavating evidence and providing the facts. Do not step beyond your bound or extend your scope. This approach is time consuming, expensive, and may be illegal!
Create a report that is easy to read and understand by laypeople and legal counsel that may be assigned. Ensure that this document is adequately peer-reviewed. The report should explain technical terms because it may be read by other attorneys or judges who may not understand technical jargon.
Conclusion
To conduct computer forensics well and produce results that are defensible in the courts, banks must plan for data breaches, develop forensics incident response plans to reduce their risk of data breaches and mitigate the possibility of law suits. Proactive measures today reduce reactive responses in the event of a breach.
Inno Eroraha is the president of NetSecurity Corporation, a digital forensics, security consulting and training company. For more information go to www.netsecurity.com or call 703-444-9009 or toll free at 866-664-6986.
