«June 2011 BITS A DIVISION OF THE FINANCIAL SERVICES ROUNDTABLE 1001 PENNSYLVANIA AVENUE NW SUITE 500 SOUTH WASHINGTON, DC 20004 202-289-4322 ...»
Operating system and application security standards should be established that, if followed, will ensure compliance with FI objectives for access to system programs, facilities, and data. These standards should be enforced with automated compliance-checking software, and that software should be monitored for integrity. All operating system and software security patches should be applied to any system for which they are available. Where vendors no longer support software patch processes, or do not commit to fixing security vulnerabilities in a given commercial product, FIs should consider alternative software vendors or versions for which security patches are available.
FIs should also consider what may constitute evidence of malware intrusion in their technology environment, and identify patterns of activity that it may be possible to log and automatically detect in a manner that would trigger an incident response. Where it is not feasible to automate detection, manual log review procedures may be necessary to identify evidence of intrusion. Candidates for log monitoring include, but are not limited to, failed outbound email server connections attempts, network scanning, and excessive domain name queries . Due care should be exercised to ensure that the logs are collected as expected, and that they are archived with integrity.
Metrics on software change control, network periphery control, vulnerability management, and log management, as well as digital identity and incident response metrics, should be devised and employed as part of a comprehensive security management strategy. These metrics should be generated and reviewed as part of continuous operations monitoring processes and used in the course of daily security management.
© BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report
5.3 Cross-Industry Anti-Malware Roles and Responsibilities Though FIs are a high value target for malware-based exploitation, the financial sector does not operate in cyberspace in isolation. Other institutions are not only targets for malware, but more importantly, they are exploited as the means by which attacks are perpetrated against FIs. Any device capable of running operator-installed software is a potential attack vector, and much of the software run by FIs is not under FI control. This distinction has been characterized as the managed versus unmanaged device issue. Yet even in cases where FIs manage electronic devices, software updates may be delegated to vendors and are usually accomplished via automatic downloads.
A business or technology partner that provides software or electronic processing that is used to support customer relationships is generally referred to as a “third party” to distinguish it from the two-party relationship an FI has with its customer. The decisions third parties make about their own anti-malware practices have a direct impact on the efficacy of FI anti-malware strategies, sometimes with grave consequences. It is therefore imperative that the financial services sector set clear requirements for third party stakeholders.
Moreover, the Internet ecosystem that FIs inhabit is populated by service providers that are not currently considered third parties in the traditional sense of the term. These are technology operators that facilitate Internet communications between FIs and customers, but are not contractually or otherwise bound to specifically support FI services. Figure 14 illustrates that FIs operate in an Internet environment that is facilitated by Internet Service Providers (ISPs), Internet eXchange Points (IXPs), and administrative institutions such as Internet Corporation for Assigned Names and Numbers (ICANN), among other technology operators.
Figure 14: Financial Industry Cyber Ecosystem
These facilitators run critical aspects of Internet operations that may yield attack vectors. A good example of this dependency involves domain name service providers. Internet domain names are registered by FIs and are administered internally or through third party domain name service providers. Administrators correlate domain names to numeric network addresses of computers © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report owned and operated by or on behalf of the FI. Customers know only the FI domain names, not the IP addresses, and therefore must rely on the domain name system to direct them to legitimate FI network resources. However, perpetrators of cybercrime exist in the same ecosystem, and may be expected to attack any vulnerable component if that attack vector could provide information that may ultimately lead to a successful attack against an FI. For example, if a provider of domain name services to a customer or FI business partner is corrupted, then those customers and business partners who type an FI domain name into their browser may be directed instead to a malicious site.
In such cases, criminal operations are beyond the FI scope of operations, and correspondingly beyond its ability to quickly detect or respond.
A recent exercise tested the ability of financial institutions, card processors, businesses, and retailers to respond to major cyber attacks against payment systems . Attack vectors used against the financial industry in the exercise included many of those described in Section 4. Over 600 FIs, card processors, retailers, and business customers participated in the exercise, and all reported that they would have been severely negatively impacted from the attack. For example, most participating financial institutions (58%) don’t have a contingency plan focused on Distributed Denial of Service (DDoS) and a majority of those that do rely on Internet Service Providers to provide mitigation. Yet a recent Arbor network survey of ISPs reveals that a full 50% of their DDoS mitigation strategies are known to further degrade service, essentially completing the attack as a first step toward defense .
The decisions that domain name service providers and other cyber facilitators make with respect to anti-malware practices have a direct impact on the efficacy of FI strategies. It is therefore important that each FI set clear requirements for security practices at service providers as part of any cyberrelated service level agreement. These practices should not simply refer to financial industry standards, but should specify that service providers must create and maintain continuous security situational awareness and defense capabilities that correspond to the risk that malware may present to the integrity of the contracted-for services. Where service providers do not share traditional thirdparty relationships with FIs, such requirements must nevertheless be articulated in order to provide a basis for defining due diligence on the part of service providers, and potential corresponding claims of negligence.
Table 4 is an example of reasonable expectations that FIs may have for Internet ecosystem technology providers who may or may not be traditional third parties for the financial services industry. The first column in Table 4 lists examples of the types of these businesses generically by product or service. The second column identifies technology controls that the provider in the corresponding row may reasonably be expected to perform in order to minimize potential damage due to malware. The third column classifies the control in the second column according to the information security industry triad of prevent, detect, recover. The word “prevent” in the third column indicates that the control activity identified in the second column may prevent a “malware event” before it happens. The word “detect” in the third column indicates that the control activity identified in the second column contributed to FI capability to discover when a “malware event” occurred. The word “recover” in the third column indicates that the control activity identified in © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report the second column may reduce the risk of harm to the ecosystem from a participant that has been infected, and/or improve the capability of an FI to disinfect a device after a “malware event” has occurred.
Table 4 includes stakeholders who could be partnering with FIs and their other customers to improve the ecosystem’s overall resistance to malware. The table highlights the unique contribution of each contributor to each phase of the anti-malware cycle. The intent of this section is to not list all the things currently being done or that could be done, but to place focus on behaviors that are either rare or non-existent, but if more widely adopted, would reduce the risk of harm to FIs from malware-enabled exploitation.
Table 4: Potential Role of Technology Providers in Minimizing Malware Risk to the Internet Ecosystem
Internet Service Internet Service Providers (ISPs) should ensure that their prevent Providers networks do not allow traffic that spoofs IP addresses.
6. Conclusion Malware is both insidious and pervasive. The financial services industry is a prime target, making it imperative for financial institutions to prepare to face malware attacks and prevent financial loss, damage to reputation, reduction in customer assets, data breaches, regulatory oversight, and/or lack of management control over technology assets. FIs should recognize that malware operators rely on a strong and stable financial industry in order to profit from crime. They are unlikely to target critical transaction processing systems for fear that their own fraudulent transactions will not be processed.
Unless there is a hostile intent to cause damage, as in a nation-state declaration of war, malware operators are likely to maneuver between the seams of authorized business processes, and inject just enough variation required to execute their criminal mission. Moreover, although crimeware and state-sponsored cyber attacks and campaigns are the most visible form of attack, FIs should recognize the increasing threat from both external and internal sources, and take practical measures to detect and defend against potential internal malware interference with business process.
FIs should evaluate their vulnerability to the malware described in this report and implement © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report appropriate safeguards to minimize any potential for damaging impact. This should not only include the implementation of layered preventative measures, but also measures to detect the presence of malware and a plan to respond to malware once it is detected. The plan should be exercised periodically as is done for business continuity and disaster recovery planning purposes. Response plans should be integrated into the financial institutions’ overall crisis management process so that highly impactful attacks are responded to with the appropriate level of senior management involvement and oversight. Integrating the plan within the overall crisis management process will ensure that escalation points are defined, governance processes are in place, and there are representatives from the appropriate functional units that might be called upon to assist in management of the response and communications to stakeholders.
© BITS/The Financial Services Roundtable 2011. All Rights Reserved.
Appendix A. Terms and Definitions
Botnet: a collection of bots that receive instructions from the same “master” program Data Host: company that maintains servers on the Internet that process data for customers using a standard technology such as web or email servers
Footprint: with reference to a software component is used to indicate the physical characteristics of a file such as its size, the file names as well as the operating system’s resource utilization. These characteristics help to uniquely identify the various software components encountered during the investigative process.
Jabber: a communications protocol used for instant messaging Kernel: operating system component that serves as a bridge between software applications and system services provided by hardware, and typically designed to facilitate a trusted channel between the OS user and system-level functionality Malware: malicious software, any and all software that is deployed with malicious intent Operating System: software that directly manages and controls interaction with hardware devices that combine to compose a computer, provides common services to applications, and makes resources available to users Phishing: email-born malware propagation systems Rootkit: enables privileged access to a system and the ability to hide that access by subverting the provided authentication, authorization, and audit functions
Zero-Day: modifier for the word threat or attack, meaning that the vulnerability that is used by the threat agent is not known to potential victims Appendix B. Acronyms
Jennifer L. Bayuk, Jennifer L. Bayuk, LLC Doug Cavit, Microsoft Eric Guerrino, Bank of New York Mellon James Mahony, PNC Financial Services Group Brett McDowell, PayPal William Nelson, FS-ISAC Rick Snevel, KeyBank Peter Staarfanger, Synovus BITS thanks VeriSign’s iDefense organization for providing key research material which made a substantial contribution to this effort.
BITS Staff Lead: Greg Rattray
About BITS BITS addresses issues at the intersection of financial services, technology and public policy, where industry cooperation serves the public good, such as critical infrastructure protection, fraud prevention, and the safety of financial services. BITS is the technology policy division of The Financial Services Roundtable, which represents 100 of the largest integrated financial services companies providing banking, insurance, and investment products and services to the American consumer. Roundtable member companies provide fuel for America's economic engine, accounting directly for $92.7 trillion in managed assets, $1.2 trillion in revenue, and 2.3 million jobs. For more information, go to http://www.bits.org/.
Appendix D. Citations
1. Krauss, L. and E. MacGahan, Computer Fraud and Countermeasures. 1979, Englewood Cliffs, NJ Prentice-Hall.
2. Stoll, C., The Cuckoo's Egg. 1989: Doubleday.
3. Mell, P., K. Kent, and J. Nusbaum, Guide to Malware Incident Prevention and Handling, SP800-83.
2005, National Institute of Standards and Technology.
4. International Telecommunication Union, ITU Study on the Financial Aspects of Network Security:
Malware and Spam. 2008.
5. Cloppert, M., Evolution of APT State of the ART and Intelligence-Driven Response, in US Digital Forensic and Incident Response Summit 2010, SANS: http://computer-forensics.sans.org.
6. Jacobs, A. and M. Helft, Google, Citing Attack, Threatens to Exit China, in New York Times. 2010.
7. Zeltser, L., Analyzing Malicious Software in Cyberforensics, J. Bayuk, Editor. 2010, Springer.
8. The VeriSign® iDefense® Malicious Code Operations Team, IFrame Attacks – An Examination of the Business of IFrame Exploitation, firstname.lastname@example.org, Editor. March 28, 2008, VeriSign® iDefense®
9. The VeriSign® iDefense® Intelligence Operations Team, Notable Malware for 2010. April 21, 2010, VeriSign® iDefense®
10. Menn, J., Fatal System Error. 2010: Perseus Books Group.
11. Geer, D.E. and D.G. Conway, The Owned Price Index. IEEE Security & Privacy, 2009. 7(1): p.
12. Jakobsson, M. and Z. Ramzan, eds. Crimeware: Understanding New Attacks and Defenses. 2008, Safari Technical Books.
13. Koffman, S., USSS Malware Update for FS/ISAC. March 14, 2011.
14. Panda Labs, PandaLabs Annual Report 2010, www.pandasecurity.com.
15. FS-ISAC, Threat Viewpoint, Advanced Persistent Threat. 2011.
16. Krebs, B., ‘Stuxnet’ Worm Far More Sophisticated Than Previously Thought. KregsOnSecurity.com, September 22, 2010.
17. Wingfield, N. and B. Worthen, Microsoft Battles Cyber Criminals in Wall Street Journal. 2010.