Effectiveness of Cyber Security Regulations in the US Financial Sector: A Case Study by Asim Kurt Research Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science in Information Security Policy and Management Thesis Advisor: Matthew J. Butkovic Technical Manager – Cybersecurity Assurance CERT® Division at the Software Engineering Institute Carnegie Mellon University Carnegie Mellon University H. John Heinz III School of Information Systems & Management Pittsburgh, PA May, 2015 Carnegie Mellon University H. John Heinz III School Approved and recommended for acceptance as a thesis in partial fulfillment of the requirements for the degree of Master of Science in Information Security Policy and Management Title Effectiveness of Cyber Security Regulations in the US Financial Sector: A Case Study Project Members Asim Kurt Thesis Advisor: Matthew J. Butkovic Print Name [email protected] e-­‐mail MSISPM Program Director: Software Engineering Institute CMU Dept/Company 4500 Fifth Avenue Pittsburgh, PA 15213-­‐2612 Address ___________________ Signature Richard A. Caralli Print Name ___________________ Signature Date Date Acknowledgements First and foremost, I would like to thank my family, especially to my wife for her endless support throughout my journey at Carnegie Mellon University. I would like to thank Turkish people for providing me this wonderful opportunity to study at this highly esteemed college. I hope to use the experience and the skills I gained here for the good of Turkish people and the humanity. My sincere thanks go to my advisor, Matthew J. Butkovic from the CERT Division of the Software Engineering Institute, for his continuous support and encouragement during my thesis work. His guidance helped me in all the time of research and writing of this thesis. Finally, a great deal of thanks goes to Heinz College faculty and staff for their guidance and support during my coursework. ii iii Effectiveness of Cyber Security Regulations in the US Financial Sector: A Case Study Abstract In spite of the numerous regulations regarding cyber security, data breaches are still a major problem in the US financial sector. Although there are many studies on data breaches focusing on economic impacts to companies and possible policy responses to solve the problem, none of them sufficiently investigated the effectiveness of the cyber security regulations in preventing the data breaches. In addition, studies regarding the causes of data breaches in the US financial sector provide conflicting results, making the problem more complicated. In this study, first we performed a case study by using two publicly available databases to reveal the actual threat patterns in the sector. Then we examined the effectiveness of cyber security regulations by conducting a gap analysis between security practices enforced by regulations and the practices recommended by experts in the field based on the actual threat patterns. Our results suggest that miscellaneous errors and insider misuse are the two most common causes of data breaches in the sector. Additionally, we found a large gap between enforced and recommended practices in the banking sub-­‐sector, indicating ineffective cyber security regulations. We recommend that regulators focus more on threats originating from the inside rather than the outside of the institutions in the cyber security regulations. iv Table of Contents 1. Introduction ................................................................................................................... 1 2. Literature Review ......................................................................................................... 5 a. Economic impacts of data breaches ................................................................................ 5 b. Causes of data breaches ...................................................................................................... 6 c. Policy response to data breaches ..................................................................................... 9 i. Ex-­‐post Regulations ............................................................................................................................ 9 ii. Ex-­‐ante Regulations ........................................................................................................................ 11 3. Regulations in the US Financial Sector and Mapping Results ..................... 13 Banks ........................................................................................................................................... 15 Investment companies ........................................................................................................... 17 Card payment companies ..................................................................................................... 18 Mapping regulations to security practices ...................................................................... 19 Mapping results ........................................................................................................................ 20 4. Enforcement Actions ................................................................................................ 25 Banks ........................................................................................................................................... 26 Investment companies ........................................................................................................... 28 Card payment companies ..................................................................................................... 30 5. Case Study: Threat Patterns in the US Financial Sector ................................ 32 Methodology .............................................................................................................................. 32 Findings of the case study ..................................................................................................... 36 Trends in threat patterns ..................................................................................................... 40 Banks ........................................................................................................................................... 41 Investment companies ........................................................................................................... 42 v Card payment companies ..................................................................................................... 43 6. Gap analysis ................................................................................................................. 44 Methodology .............................................................................................................................. 44 Gap analysis results for the banking sub-­‐sector ........................................................... 45 Card payment companies ..................................................................................................... 48 Regulation methodology and further discussions ....................................................... 48 Limitations ................................................................................................................................. 50 7. Summary, Conclusions and Future Work .......................................................... 53 Future work ............................................................................................................................... 55 Appendices ....................................................................................................................... 56 Appendix 1 – The list of regulations examined regarding cyber-­‐security in the US banking sub-­‐sector .................................................................................................................. 56 Appendix 2 – Mapping results for the banking sub-­‐sector ........................................ 57 Bibliography .................................................................................................................... 61 vi Table of Figures Figure 1: Total number of breach incidents in the US financial sector ............................ 38 Figure 2 :Trends in threat patterns: card skimming, crimeware, and insider misuse .................................................................................................................................. 40 Figure 3: Trends in threat patterns: miscellaneous errors, physical theft/loss, and web application attacks ............................................................................................................... 41 vii 1. Introduction Data breaches are becoming increasingly widespread among all industries. However the problem seems to be more prevalent in the financial sector in spite of the cyber security regulations. Breach incidents with confirmed data losses in the financial sector accounted for one third of all incidents in 2013, according to Verizon’s Data Breach Investigations Report [1]. Many researchers with backgrounds in economics, law, policy, and privacy have studied economic and policy aspects of the problem and recommended solutions to prevent data breaches from their disciplines. Still none of these studies have sufficiently focused on the effectiveness of cyber security regulations in the financial sector, which deviates from other business sectors with strict regulations. This study examines the effectiveness of regulations related to cyber security in the US financial sector by conducting a gap analysis between security practices enforced by regulators and the practices recommended by experts in the field based on the actual threat patterns. Data breaches in financial institutions are not uncommon. In October 2014, personal information of 76 million customers of JP Morgan Chase was stolen by hackers in one of the biggest data breaches in history [2]. Stolen information included names, email addresses, phone numbers, and home addresses of customers [3]. Not long after, in January 2015, another shocking data breach news story came from Morgan Stanley: this time 350,000 of firm’s wealthiest customers’ information was stolen by a malicious insider [4]. These two data breach incidents are recent examples of a major problem, which is increasingly making the news in the US. More interestingly, these incidents are occurring in financial institutions, which are supposed to be operating under heavy regulations and comprehensive supervision of federal regulators. What causes these data breaches and why can’t we prevent them happening despite the fact that financial institutions are operating under heavy regulations? Financial institutions require a huge amount of valuable data for their operations, such as payment card data, confidential personal information and financial account information. This valuable information makes financial institutions very attractive targets for cyber criminals and requires vigilant operations to avoid data breaches. Data breach incidents either caused by cyber criminals, malicious insiders or by reckless management practices, give rise to identity theft problems for individuals and financial damage to institutions. Since financial institutions cannot operate without possessing this valuable information, they need effective defense mechanisms to protect the valuable information and to prevent aforementioned damages. In the US, as in most countries, financial institutions are heavily regulated. Gramm-­‐Leach-­‐Bliley Act, Fair and Accurate Credit Transactions Act, and Bank Service Company Act are some examples of laws passed by the US Congress that includes information security related provisions for financial institutions. Federal agencies, those that are responsible for financial sub-­‐sectors like FFIEC, OCC, FRB, FDIC, NCUA, and SEC have also issued several regulations regarding 2 information security1. Moreover, even non-­‐governmental authorities like FINRA and PCI Security Standards Council have provisions or standards imposing new requirements for some members of the financial sector2. To sum up, in terms of information security, authorities have put forward a quite significant amount of effort to protect the US financial sector, by using regulations as a tool. However, despite all efforts we are still observing numerous security breaches happening in the US financial sector. A cyber security survey conducted by New York State’s Department of Financial Services [5] in 2013 revealed that most of the 154 institutions that participated in a survey experienced an intrusion or an attempted intrusion in the past three years. This statistic is also consistent with Identity Theft Research Center’s report [6], which disclosed that, in only 2014, 43 financial services company in the US experienced a data breach with confirmed data losses. Along with recent news about data breaches in major financial institutions, statistics provided in these reports show that we are not at the point that policymakers wanted us to be. This study aims to investigate the effectiveness of cyber security regulations regarding the US financial sector in preventing data breaches. For this purpose, first we examined the regulations to determine which security practices were enforced by these regulations. As a second step, we performed a case study by using two publicly available data breach databases to uncover the actual threat FFIEC: The Federal Financial Institutions Examination Council; FRB: The Board of Governors of
the Federal Reserve System; FDIC: The Federal Deposit Insurance Corporation; NCUA: The National
Credit Union Administration; OCC: The Office of the Comptroller of the Currency
1
2
FINRA: Financial Industry Regulatory Authority; PCI: Payment Card Industry
3 patterns that caused breach incidents in the US financial sector. Then we conducted a gap analysis between the security practices enforced by regulations and the practices recommended by experts in the field based on the actual threat patterns. A large gap between these two sets of security practices would indicate ineffective and misaligned regulations to prevent data breaches. The following chapter provides a literature review of the effects and causes of data breaches along with policy responses to these breaches. In Chapter 3, we will examine the regulations imposed on financial institutions and provide a mapping of these regulations to security practices. Chapter 4 looks into enforcement actions related to cyber security of financial institutions. Chapter 5 explains the actual threat patterns that caused data breaches in the US financial sector from 2010 to now, which were obtained from a multiple case study. In Chapter 6, we discuss the results of case study and provide the results of gap analysis. Finally, Chapter 7 summarizes the thesis and suggests some future work. 4 2. Literature Review In this chapter, we will review studies from researchers with various backgrounds relating to data breaches. Although our study focuses on federally regulated financial institutions in US, we believe studies about other industries and countries have potential to provide useful insights regarding our research question. We will start our review with the economic impacts of data breaches, continue with causes of breaches and finally sum up with policy responses to breach incidents. a. Economic impacts of data breaches A number of researchers studied the economic impact of security breaches on the stock prices of publicly traded companies in past years. However, findings of these studies are mixed. Campbell et al. [7] found a high negative reaction to breaches that involve unauthorized access to confidential information; similarly Cavusoglu et al. [8] suggested that companies lost 2.1% of their market value within two days of announcement of breach on average. However, later in 2006, with a broader data set Acquisti et al. [9] found that cumulative effect of data breach loses its significance after the day following the breach announcement, so there is a very short-­‐lived impact on stock prices. Finally in 2011, Gordon et al. [10] by using a more sophisticated market model with a comprehensive dataset found that investors’ attitude shifted after 9/11. Contrary to the pre-­‐9/11 period, researchers found that breaches related to information availability had an insignificant effect on stock prices over the post-­‐9/11 period. They concluded 5 that the impact of security breaches on stock returns diminished, since investors started seeing the breaches as “nuisance” rather than critical threats for companies’ survival. However, some reports assert that data breaches are affecting churn rates, the percentage of existing customers the firm loses in a certain period of time, and causing direct or indirect costs for financial institutions. In one of these studies, Ponemon Institute [11] found that, in 2014, financial institutions, from 10 different countries3, have experienced a %6.1 abnormal churn rate on average, which was one of the highest churn rates among other industries. The study also revealed that in 2014 average per capita cost of a data breach for a US company increased to $201 and average organizational cost raised to $5.85 million. Similarly, an information security survey by the UK’s Department for Business Innovation Skills [12] found that for large organizations average cost of the worst breach for UK companies nearly doubled in 2014 and ranged between $0.89 and $1.7 million. Despite varying amounts for countries and industries, these numbers show that data breaches can affect organization’s financial situation significantly. b. Causes of data breaches There are several reports and studies on causes of data breaches [1], [11], [13]–[16]. However, results of these studies are mixed due to: i.
lack of consensus on defining a data breach, 3 Study included 314 companies from United States, United Kingdom, Germany, Australia, France,
Brazil, Japan, Italy, India, United Arab Emirates, and Saudi Arabia
6 ii.
varying scopes and data collection methodologies used in studies and iii.
classification differences used to identify the causes or patterns regarding breach incident. Although a small portion of these reports provides sector specific data, we were not able to find them in many others. Additionally, many of these reports were sponsored by for-­‐profit companies that provide some sort of services or products to prevent data breaches, which raises doubts about the objectivity of reports. Despite limitations stated above, we believe these studies can provide some insights into causes of breaches in organizations. Some of the aforementioned reports include statistics on causes of data breaches for all industries rather than sector specific statistics. Ponemon Institute [11] reported that human errors (30%) and system glitches (29%) were root causes of more than half of all data breaches in 2014. Contrary to these outcomes, a UK survey conducted by PwC [15] disclosed the most common type of breaches for large organizations was infection by malicious software (73%) followed by incidents caused by insiders (58%). Finally, a Forrester study [14] found that inadvertent misuse by insider (36%), loss/theft of corporate asset (32%), and phishing (30%) were the common reasons for data breaches. To sum up, different classifications, scope and data collection methodologies brought up significantly different outcomes for causes of data breaches. There are also some studies, which provide sector specific statistics. One of these studies is Verizon’s renowned Data Breach Investigation Report 2014. 7 Verizon report [1] found that web application attacks (27%), denial of service (26%), and payment card skimming (22%) were the most common threat patterns against financial institutions in 2013. According to the report, 34% of all organizations that experienced a security breach in 2013 belonged to the financial sector, followed by the public sector (12%). Another notable study, with a focus on the financial sector, was based on a survey conducted in 2008 by the Australian Institute of Criminology4 [16]. However, findings from this study [16] suggested that malware was the most likely reason (45%) followed by phishing (12%), theft/loss of confidential information/hardware (12%) and insider abuse of access (12%) for incidents experienced by respondents during the reporting period. In contrast to Verizon report, the Australian study found denial of service attacks comprised only 1% and web application attacks were the root cause of 3% of all security breaches. On the other hand, financial institutions were found more likely to be victimized, compared to five other business sectors including healthcare, backing up Verizon’s outcome [1], [16]. In brief, even studies that focused on the financial sector have different conclusions regarding the causes of data breaches. Moreover, financial sector is a broad definition that covers various types of institutions. And some of these institutions are not federally regulated in terms of cybersecurity. Therefore, in this study by using publicly disclosed data breaches that we had to build up our 4 Involved 221 respondents from financial sector out of 4000 total companies among all business
industries.
8 own database for investigating the effectiveness of regulations in the US financial sector. c. Policy response to data breaches The proliferation of data breaches pushed policymakers to propose new regulations to prevent data breaches as well as attracted researchers to study their effectiveness. There are two options for security regulations; first is ex-­‐ante regulations, which deals with prior to breach precautions and the second is ex-­‐
post, which imposes liabilities after the breach. Ex-­‐ante regulations include safety directions and standards for companies to prevent a breach before it happens while ex-­‐post regulations include liabilities, litigations and fines to penalize the company after a breach. i. Ex-­‐post Regulations Data breach notification laws were a common response of state regulators that exemplifies ex-­‐post regulations. In 2003, the first notification law was enacted by California and over time 47 states, and the District of Columbia, have enacted similar laws [17]5. According to Winn [18] security breach notification laws (SBNL) are enacted by modeling “community right to know” laws, which were used to improve the efficacy of environmental legislations. Regulators’ goals for enacting SBNLs were clear; incentivize companies to invest more in security and to urge companies to protect customer data more aggressively [18]. 5
As of 1/12/2015
9 SBNLs received both support and criticism from researchers. Lenard and Rubin criticized SBNLs for bringing unnecessary burden on companies that outweighs its benefits, and impeding possible innovations by deterring companies from collecting customer information [19]. Winn [18] also examined the efficacy of SBNLs in improving information security from a regulatory perspective and tried to find out whether they could have been better or not. She pointed out that the obvious shortcomings of SBNLs were “non-­‐disclosing of information”. Since, laws create a powerful incentive for data owners not to disclose or disclose as little as possible6 [18]. According to Winn [18], along with a limited scope, SBNLs also have some design flaws such as not providing for audits or public enforcement to detect or penalize incompliance. This causes the cost of non-­‐compliance to become very close to zero. SBNLs also “create perverse incentives to invest in mitigating harms after they occur instead of prevention” [18]. In 2011, Romanosky et al. [20] investigated the effectiveness of breach notification laws in preventing identity theft cases for the first time. They gathered the number of consumer-­‐reported identity thefts from FTC7 for each state between 2002 and 2009. Findings showed that data breach notification laws were able to reduce the identity theft caused by breaches, on average, by 6.1 percent [20] There is however some evidence suggesting the effectiveness Since the enforcement of SBNLs was left entirely to public, authorities didn’t have an estimation
on the percentage of non-disclosing.
6
7
The Federal Trade Commission
10 of notification laws was short-­‐lived (6-­‐12 months) due to an increased awareness of consumers in the short-­‐term and becoming desensitized and ignorant afterward [20]. Another form of ex-­‐post regulation is holding the responsible party liable for its own negligence. In 2014, Romanosky et al. [21] investigated the litigation of data breaches from 2000 to 2010. They focused on finding out the types of breaches more likely to be litigated and lawsuits that are being settled among plaintiffs and defendants. Findings of this study showed that only 4 percent of data breaches are being federally litigated and half of them are being settled before trial, with a mean value of $2,500 for per plaintiff. They also found that among all types of personal information only the compromise of financial was significantly correlated with the probability of lawsuit [21]. ii. Ex-­‐ante Regulations As studies cited above show, solely relying on ex-­‐post regulations doesn’t seem sufficient to prevent data breaches especially for critical sectors like financial and healthcare. Therefore, policy makers in the US have enacted many ex-­‐ante regulations, such as Gramm-­‐Leach-­‐Bliley Act (GLB) and the Fair Credit Reporting Act (FCRA) for financial sector and Health Insurance Portability and Accountability Act (HIPAA) for healthcare sector. There are also some ex-­‐ante regulations that are mandated by self-­‐regulatory bodies in the financial sector, like PCI Security Standards Council and Financial Industry Regulatory Authority (FINRA). 11 Federal agencies that are responsible for supervising and regulating financial institutions supported cyber security laws with more detailed and technical regulations such as supervisory letters, examination procedures, and guidelines. We are aware of no research study focused on the effectiveness of this set of regulations. Finally, we would like to note one additional case study on financial institutions. Cummings et al. [22] produced empirically derived findings from insider and outsider computer criminal activity in the US financial sector. Main objective of the study was to identify observable technical precursors of insider fraud in the US financial sector and to recommend mitigation strategies. The study included 67 insider and 13 external fraud cases; which were selected from the US Secret Service’s cases between 2005 and 2012 [22]. It revealed very useful insights about insider threats that financial institutions face, however, researchers didn’t look at whether regulations were addressing the insider threat. 12 3. Regulations in the US Financial Sector and Mapping Results This chapter examines regulations regarding cyber security in the US financial sector and provides a mapping of these regulations to predetermined security practices. We will then use the results of this mapping to perform a gap analysis. A small gap between security practices, which are enforced by regulations, and the practices that are recommended to defend against actual threat patterns would indicate effective cyber security regulations. Contrary, a large gap between them would point to a misalignment of regulations with actual threats. In the US financial sector, there are various types of financial services, which create a very complex regulatory landscape. Commercial banks, thrifts, credit unions, insurance companies, investment advisers, brokers, payday loan companies, and credit rating agencies are just some examples of financial institutions in the US. However, not all financial institutions are regulated in the same manner. Some financial institutions are not regulated at all such as payday loan companies. Others are only regulated at the state levels, such as insurance companies and community banks. Many others are regulated by several different federal agencies. The variety of financial services produced a number of federal agencies and resulted in a complex regulatory landscape. 13 This study focuses on federally regulated financial institutions, which provide banking and investment related services. Table 1 provides a list of types of financial institutions that are covered in this study. We excluded institutions that are chartered and supervised by state regulators because it would require an exhausting examination of financial regulations for all states. In addition to federally regulated financial institutions, we included the card payment companies, which are regulated by a self-­‐regulatory body known as Payment Card Industry (PCI). Although these institutions do not comprise the whole US financial sector, we believe they represent an essential and significant part of the sector. Table 1 Financial institutions included in the study Type of Financial Institution National Banks Federally Chartered Saving Associations Federal Branches and Agencies of Foreign Banks State Member Banks8 Bank Holding Companies Credit Unions Brokerage Firms Investment Advisers Card Payment Companies Primary Regulator OCC OCC OCC FRB FRB NCUA SEC SEC PCI We divided the financial institutions covered by this study into three sub-­‐
sectors: banks, investment services (brokerage and investment adviser firms) and card payment companies. 8 These banks are member of Federal Reserve System, therefore they are also regulated by FRB
besides state regulators
14 Banks There are several regulatory authorities that establish provisions and standards regarding cyber security of banking services. OCC, FRB, FDIC, and NCUA are federal agencies responsible for regulating and supervising banking services in the US financial sector. In addition to these agencies, there is an interagency body, The Federal Financial Institutions Examination Council (FFIEC). This entity is empowered to establish uniform principles for the federal examination of financial institutions. Aforementioned federal agencies are members of FFIEC. Finally, Payment Card Industry (PCI), a self-­‐regulatory body established by major card schemes, establishes standards relating to card payment processes and systems. This study combines all regulations issued by these authorities to provide a full list of security practices that banking institutions have to implement. Federal regulations regarding cyber security of banking services include federal laws, regulations enacted by federal agencies, security bulletins, guidelines, and advisory letters issued by agencies [23]. Federal laws that have provisions related to cyber security are [23]: i.
Bank Service Company Act, ii.
Bank Protection Act, iii.
Fair and Accurate Credit Transactions Act, iv.
Gramm-­‐Leach-­‐Bliley Act, v.
Fraud and Related Activity in Connection with Computers, and vi.
USA Patriot Act. 15 A complete list of all federal regulations examined and used in this study for mapping regulations to security practices can be found at Appendix-­‐1. In addition to these regulations and guidelines, FFIEC provides “IT Examination Handbook” to its member agencies. The handbook comprises 11 booklets devoted to different domains of IT including information security, e-­‐
banking, and business continuity. It provides very comprehensive technical principles for institutions and examination procedures for bank examiners. Table 2 provides a list of booklets and the date of their last update. The notable thing in Table 2 is that information security and e-­‐banking booklets were last updated on 2006 and 2003, respectively. Table 2 Booklets in FFIEC's IT Examination Handbook Booklet Title Audit Business Continuity Planning Development and Acquisition E-­‐Banking Information Security Management Operations Outsourcing Technology Services Retail Payment Systems Supervision of Technology Service Providers (TSP) Wholesale Payment Systems Updated April 2012 February 2015 April 2004 August 2003 July 2006 June 2004 July 2004 June 2004 February 2010 October 2012 July 2004 Finally, banks are also subjected to PCI’s Data Security Standard (PCI DSS) if they are offering card payment services to their customers. However, only processes and systems that are related to card payment process have to be compliant with PCI DSS. This partial compliance requirement makes it very hard to obtain a full list of security practices compulsory for banking institutions. In 16 addition to this difficulty, in this study we wanted focus more on effectiveness of federal regulations rather than a self-­‐regulation (PCI DSS) that affects banks with a very limited scope. Hence, we used only federal regulations to conduct our gap analysis and disregarded PCI DSS for banking sub-­‐sector. We will discuss the details of gap analysis in Chapter 6. Investment companies Investment advisers and brokerage firms are primarily regulated by the SEC. Gramm-­‐Leach-­‐Bliley Act (GLBA) requires the SEC to establish appropriate standards to protect the security of customers’ non-­‐public personal information. However, contrary to banking federal agencies, SEC does not issue technically detailed regulations regarding cyber security. Instead, the SEC has almost repeated the GLBA’s provision related to the protection of non-­‐public personal information in Section 248.30 of Regulation S-­‐P (Privacy of Consumer Financial Information). The relevant section of Regulation S-­‐P, which was mandated as of July 2000, reads as follows: “Every broker, dealer, and investment company, and every investment adviser registered with the Commission must adopt policies and procedures that address administrative, technical, and physical safeguards for the protection of customer records and information. These policies and procedures must be reasonably designed to: (a) Insure the security and confidentiality of customer records and information; 17 (b) Protect against any anticipated threats or hazards to the security or integrity of customer records and information; and (c) Protect against unauthorized access to or use of customer records or information that could result in substantial harm or inconvenience to any customer.” [24] Instead of having detailed procedures, SEC penalizes the firms subjected to their jurisdiction after the breach if it concludes that the firm hasn’t adopted adequate policies and procedures. These enforcement actions will be discussed in the following chapter. Card payment companies Card payment sub-­‐sector is self-­‐regulated by PCI, which was founded by five major card brands: Visa, MasterCard, American Express, JCB International, and Discover. PCI Data Security Standards (DSS) is mandated and updated by PCI Security Standards Council. It comprises technical and operational requirements to protect cardholder data [25]. PCI DSS consists of 12 high-­‐level requirements and last been updated on November 2013 [25]. It applies to all entities that collect, store and transmit cardholder data and sensitive authentication data including processors (entities that process card data), issuers (card issuing banks), and acquirers (banks that process card payments on behalf of merchants) [25]. 18 Mapping regulations to security practices The aim of this study is to perform a gap analysis to examine the effectiveness of regulations enforced by regulators in the US financial sector. For this purpose, we need a comprehensive security framework, which is also proven to be successful in dealing with the certain type of threat patterns. So that, we can map all practices enforced by regulations to this framework. Then analyze the gap between security practices, which are enforced by regulators, and the practices recommended for defending against actual threat patterns. There are many cyber security frameworks that combine known good security practices. However, among these frameworks, we believe “The Critical Security Controls” framework, which is sustained and promoted by Council on Cybersecurity, is the best fit for this type analysis. This framework is developed by a large international community by using actual attack and effective defense information. Therefore, it consists of security practices, which have been proven to work. Critical security controls (CSCs) are regarded as a specific set of effective technical measures to prevent and mitigate damage against cyber threats[26]. Another major reason for choosing CSCs in this study comes from Verizon’s Security Breaches Investigation Report [1]. The report included nine basic threat patterns, which was used to identify 92% of all security breaches. Nine threat patterns include: 1) POS intrusions, 2) web applications attacks, 3) insider misuse, 4) physical theft/loss, 5) miscellaneous errors, 6) crimeware, 7) card skimmers, 8) cyber-­‐espionage, and 9) DOS attacks. In addition to these threat 19 patterns, Verizon provided a list of CSCs to defend against these nine patterns in the report, based on their collaboration with Council on Cybersecurity. This is a unique approach, which provides us a mapping of actual threat patterns and a list of security practices that would protect organizations against those threat patterns. Therefore, in this study we used these nine threat patterns to classify data breaches that occurred in the financial institutions and CSCs framework for mapping regulations to security practices. Table 3 Number of CSCs recommended for threat patterns Threat Patterns POS Intrusions Web Application Attacks Insider Misuse Physical Theft / Loss Miscellaneous Errors Crimeware Card Skimmers Cyber Espionage DOS Attacks All Threat Patterns Number of CSCs Recommended 13 5 8 3 2 9 -­‐ 9 4 36 Table 3 provides a list of threat patterns and the total number of CSCs recommended by Verizon and the Council on Cybersecurity to defend against those patterns. As seen from the table, 36 CSCs are defined as security practices to defend against all threat patterns. The full list of CSCs for each threat pattern can be found at [1]. Mapping results As discussed above, we were able to find technically detailed security regulations only for banking institutions and card payment companies. We tried 20 to map all requirements stated in regulations to 36 CSCs that are recommended for defending against threat patterns defined in Verizon report. We used three categories to define how a CSC is addressed by regulations: fully, partly and not addressed. If a CSC is fully addressed by regulations, it means most critical aspects of a CSC are met by regulations; nothing important is being left behind. If a CSC is classified as “not addressed” by regulations, it means regulations do not push institutions to implement that CSC at all. And the rest is classified as partly addressed, meaning some portions of the CSC are required by regulations but not all-­‐important aspects. Among 36 CSCs, 10 of them were fully and 19 of them were partly addressed by federal regulations imposed on banks. Table 4 provides a list of seven “not addressed” CSCs by federal regulations imposed on banking institutions. Some of “not addressed” CSCs are well-­‐known technical security practices, but they are not stated in regulations, such as operating critical services on separate host machines. Some others are newer technologies and also not mentioned in regulations, such as network-­‐based data loss prevention (DLP) solutions. Since these technologies are expensive and matured recently, it not surprising to see them “not addressed” in relatively outdated federal regulations. A complete list of fully and partly addressed CSCs can be found at Appendix-­‐2. 21 Table 4 CSCs Not addressed by federal regulations “Not Addressed” Critical Security Controls For in-­‐house developed applications, ensure that development artifacts are not included in the deployed software, or accessible in the production environment. Operate critical services on separate physical or logical host machines, such as DNS, file, mail, web, and database servers. Ensure that all service accounts have long and difficult-­‐to-­‐guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords. Deny communications with known malicious IP addresses, do not transmit packets from bogon source IP addresses through network perimeters Deploy NetFlow collection and analysis to DMZ network flows to detect anomalous activity. Configure access for all accounts through a centralized point of authentication, for example Active Directory or LDAP. Configure network and security devices for centralized authentication as well Use network-­‐based DLP solutions to monitor and control the flow of data within the network. Any anomalies that exceed the normal traffic patterns should be noted and appropriate action taken to address them. Table 5 summarizes the results of the mapping grouped by threat patterns for banking institutions. Likewise, Table 6 summarizes the mapping of PCI DSS to 36 CSCs for card payment companies. Table 5 Number of CSCs addressed by federal regulations for banking institutions grouped by threat patterns Threat Patterns POS Intrusions Web App Attacks Insider Misuse Physical Theft / Loss Miscellaneous Errors Crimeware Cyber Espionage DOS Attacks Recommended Controls Fully Addressed Partly Addressed Not Addressed 13 4 6 3 5 2 2 1 8 1 5 2 3 2 1 -­‐ 2 -­‐ 1 1 9 2 6 1 9 2 6 1 4 3 1 -­‐ 22 Table 6 Number of CSCs addressed by PCI DSS for card payment companies grouped by threat patterns Threat Patterns POS Intrusions Web App Attacks Insider Misuse Physical Theft / Loss Miscellaneous Errors Crimeware Cyber Espionage DOS Attacks Recommended Controls Fully Addressed Partly Addressed Not Addressed 13 7 4 2 5 2 3 -­‐ 8 3 1 4 3 1 1 1 2 -­‐ -­‐ 2 9 4 4 1 9 2 5 2 4 2 1 1 As seen from the tables above, none of the threat patterns are fully addressed by regulations in terms of CSCs to defend against those threats. Table 5 suggests that some threat patterns are better addressed than others in terms of CSCs. For example, to protect against DOS attacks 4 CSCs are recommended by Verizon and the Council on Cybersecurity; 3 of those 4 CSCs are required by regulations while the remaining CSC is partly enforced. On the other hand, for crimeware only 2 of 9 recommended CSCs are fully addressed, and one CSC is not mentioned in regulations at all. Table 6 also suggests similar results for PCI DSS. Not surprisingly, PCI DSS is addressing POS intrusions and crimeware threat patterns better than federal regulations imposed on banking institutions. We believe this is an indicator that shows federal regulations are lagging behind, 23 since POS intrusions and crimeware are threat patterns that evolved recently. In order to address evolving threats, regulations have to be updated. Although some federal regulations have been updated recently, many others are not up to date. For example, Information Security booklet of FFIEC’s IT Examination Handbook includes the most comprehensive security practices regarding banking institutions but it was last updated on 2006, as shown at Table 2. On the other hand, PCI DSS was last updated on November 2013; therefore it is better at addressing relatively new threats in terms of CSCs. Finally, since we are not aware of actual threat patterns that caused data breaches in financial institutions, at this point we cannot draw any conclusions about effectiveness of security regulations. Before investigating the actual threat patterns, we think it would be helpful to review the enforcement actions of authorities regarding cyber security. Since enforcement is also an important part of the regulation. After reviewing enforcement actions, we will continue with investigating actual threat patterns in the US financial sector. 24 4. Enforcement Actions Enforcement is a complementary part of regulation. Authorities use their enforcement power to penalize noncompliance with provisions stated in regulations. Therefore, enforcement actions show how serious the authority is in compelling institutions to comply with regulations. Additionally, institutions that are under the supervision of to those authorities see the enforcement actions as a guideline that explains how to comply with regulations. For example, when an agency penalizes an institution for not encrypting the laptops that contain customer information, it clarifies that to comply with those agency’s regulations all institutions should use encryption for their laptops containing customer information. This applies especially if the regulations have a blurry language and do not clearly state what authorities expect from institutions under their jurisdiction. In this we examined the enforcement actions of authorities regarding cyber security in the US financial sector. Although, we put a significant amount of effort to find out all enforcement actions regarding cyber security, this chapter does not claim to provide a full set for the US financial sector. The major obstacle for obtaining a full set is that federal agencies do not classify enforcement actions relating to their domains, such as cyber security or IT related issues. Therefore, to obtain a complete set, one has to examine all enforcement actions issued by the federal agencies, which can be a research study on its own. Nevertheless, we believe our findings can provide helpful insights to understanding the regulatory landscape in the US financial sector regarding cyber security. 25 Banks There are several types of enforcement actions that federal agencies can apply to banking institutions. At the highest-­‐level enforcement actions can be formal or informal [27], [28]. Informal actions are generally used if the overall condition is sound. They are not written or made public. Formal actions are generally used in more severe conditions and can take several forms including cease and decease orders, monetary penalties, and formal agreements between the institution and agency [27]. In our research, we were able to find three cases where federal banking agencies used their enforcement power regarding cyber security issues. All of these three cases involved third party service providers instead of banking institutions. Nevertheless, cases provide useful insights about priorities of federal banking agencies regarding cyber security. Below we provide a summary of each case. Case 1. Fidelity National Information Services (FIS) -­‐ 2011 In 2011, hackers broken into FIS’s network, a major card processing company, they cloned 22 debit cards and raised or eliminated ATM withdrawal limits of these cards [29]. They were able to pull out $13 million by using cloned cards from ATMs in eastern European countries [29]. After the breach, an inter-­‐
agency examination team conducted an interim examination of FIS and concluded “FIS executive management supervision and control over the risk management and information security function are unsatisfactory” [30]. Instead 26 of focusing on specific security measures, examiners pointed out insufficient direction and oversight of executive management [30]. As a consequence, the firm entered into a formal agreement with FFIEC by developing a detailed action plan to solve the issues regarding security [30]. Case 2. Bserv, Fundtech – 2013 FDIC and OCC entered into a joint cease and decease order because of “unsafe or unsound banking practices” of two third-­‐party services providers: Bserv and Fundtech[31]. The reason for this conclusion was operating without [31]: i.
an internal auditor or an integrated risk-­‐focused audit program, ii.
a comprehensive program to monitor and measure risk, iii.
effective business continuity and disaster recovery program, iv.
effective patch management procedures, and v.
effective log review program. Firms agreed to file progress reports to agencies and their clients (banking institutions) as well as increasing the participation of their boards to take more responsibility in establishing policies and supervising companies’ activities [32]. Case 3. Jack Henry & Associates -­‐2013 Jack Henry & Associates, which was providing core banking services for many community banks, was unable to get its processing center after Hurricane Sandy up and running in an appropriate time [33]. Agencies concluded that the firm had unsound practices relating to business continuity and disaster recovery [34]. As a result, the firm entered into a formal agreement to resolve the issues regarding business continuity and disaster recovery [34]. 27 To sum up, these three cases show that federal agencies are sensitive to third party service providers’ risk management processes, management oversight of security, business continuity planning, and disaster recovery programs. These cases also show that internal audit programs, patch management, and log review programs are also important areas that regulators focus on. Unfortunately, we were only able to access enforcement actions that are available to the public and none of these actions directly involved banking institutions. Investment companies Greenberg [35] reviewed seven data breaches experienced by dealer-­‐broker firms, which triggered enforcement actions by SEC and FINRA, a self-­‐regulatory body for brokerage firms. In five of seven cases, authorities applied sanctions to firms because of the violation of the Safeguarding Rule, which was introduced in the previous chapter. Although the Safeguarding Rule doesn’t include any technical details about information security, authorities interpreted the rule and deducted that the firm should have taken some precautions in advance to be compliant with regulations. In 3 data breach incidents provided by Greenberg [35], SEC issued ‘cease and decease orders’ and also fined the firms involved. In one case, SEC stated that “less than a page long” and vague supervisory procedure, which was simply reciting the Safeguarding Rule, was inadequate for protecting customer information. The agency added that the firm should have had written procedures for employees that explains what they should do in the event of a possible 28 breach incident. In another case, the Agency pointed out inadequate training regarding information security. Lastly, the Agency fined a firm for not following up on computer security issues. In this case, although the representative reached out the firm’s help desk because of a malware infection, the help desk only recommended to purchase anti-­‐virus software and did not follow up, which later resulted a data breach incident [35]. In two other cases examined by Greenberg [35], FINRA applied monetary sanctions to brokerage firms. In one case, FINRA concluded that, generic procedures, which did not have any requirements to encrypt the data on mobile devices, were inadequate to address provisions of the Safeguarding Rule. In the other case, FINRA fined a dealer, who copied all customer information of the firm, which he was leaving. Dealer’s action found to be a violation of the Safeguarding Rule because, according to the rule, dealer should have provided an option to those customers who did not want their confidential information to be transferred to a non-­‐affiliated party. Although SEC did not issue technically detailed regulations for safeguarding customer information, conclusions drawn in these cases provide some clues about what the Commission expects from firms to comply with the Safeguarding Rule. According to cases cited above, the SEC wants firms: i.
to have effective security policies and procedures that provide more details about the process and includes incident response, ii.
to provide cyber security training to their employees and monitor its effectiveness, 29 iii.
to maintain effective procedures to follow up security issues in a serious manner, and iv.
to encrypt mobile devices those contain confidential customer information. Card payment companies Although PCI Security Standards Council issues and maintains PCI DSS, the standard is enforced by individual card networks (e.g. Visa, MasterCard) and banks that are members of these networks. Each card network has its own security compliance programs, which have small operational differences between them. However, they all require the member banks, card processing companies, and the merchants to comply with PCI DSS. Since our study focuses on financial institutions, we looked for instances where a card network itself, a member bank, or a card processing company has been fined for noncompliance to PCI DSS. PCI’s monetary fines are not disclosed to public; therefore we were able to find only three cases involving card payment companies, which were removed from the card payment network. In one of these instances, Global Payments, one of the largest card processing companies in the US, has experienced a data breach, which involved at least one million card data [36]. The company was temporarily removed from Visa and MasterCard network as a consequence and was required to pass a new PCI DSS assessment [37]. After passing a DSS assessment, the company was brought back to the list of compliant companies [37]. The company’s size was effective in this 30 decision; since Visa and MasterCard did not want to risk putting this large company out of business [37]. Global Payments’ case was an exact copy of the Heartland Payment’s, in 2009. Heartland Payment was the fifth largest card processing company in the US, when they experienced the biggest data breach in the US history that time. Visa removed the company from its compliant companies list but the company was able to come back after 6 weeks [38]. However, in some cases card brands can remove a company permanently from their compliant list if they are convinced that the company cannot make it again. An example being CardSystems Solutions, a small card processor company based, which was removed permanently by Visa, in 2005 [39]. Card networks apply monetary sanctions at their discretion in the event of noncompliance. These sanctions start at $5,000 and climb up to $500,000 per month based on the contract terms [40]. The organizations are also are required to pass a new PCI DSS assessment after a serious breach incident. 31 5. Case Study: Threat Patterns in the US Financial Sector This chapter analyzes the actual threat patterns in the US Financial Sector. As discussed in Chapter 2, several studies have reported conflicting results on the causes of data breaches in the US financial sector [1], [12]–[15], [41]. Moreover, the financial sector is a broad definition that covers various types of institutions, some of which are not regulated in terms of cyber security. Additionally, there were some concerns about the objectivity of the studies because of their sponsorship. All of these reasons have pushed us to conduct our own threat analysis for the US financial sector. First, we will introduce our methodology and then report the findings of our analysis. Methodology Starting point of this study was to analyze all cyber security breaches that occurred in the US financial sector. However, we soon realized that finding complete and detailed information about security breaches for a certain time period would be almost impossible. Since they were mostly kept confidential and not revealed to the public unless a legal obligation compels institutions to do so. Because of this impediment, at the expense of leaving a certain portion of the problem out of our scope, we narrowed our scope to data breaches. The term data breach describes a situation where a personally identifiable information, such as name, social security number or confidential financial information like card data is exposed to unauthorized people [21]. Companies in 32 the US are required to disclose the data breaches they experienced to comply with the data breach notification laws, which are in effect in 47 states, and the District of Columbia. Along with other sources, these notifications are collected and classified by some organizations, such as Open Security Foundation, Privacy Rights Clearinghouse (PRC), and Identity Theft Resource Center (ITRC). In this study, we used data breach databases of PRC and ITRC to obtain a list of breach incidents that occurred in the US financial sector. During our analysis, we realized that neither PRC nor ITRC was able to provide a complete set of data breach incidents occurred in the financial sector. Hence, we merged two databases, which enabled us to acquire a more complete set. We limited our scope with breach incidents occurred between January 2010 and February 2015. Although PRC and ITRC databases had entries starting from 2005, we preferred to focus more on recent threat patterns rather than potentially obsolete ones. The difficulty of finding accurate and detailed information about the causes of breaches that occurred between 2005 and 2010 was another reason for our decision. Limiting our scope helped us to elaborate recent threat patterns in the US financial sector. After obtaining a list of victims in the financial sector, we classified them by their primary regulators9. A list of types of financial institutions used in the study and their primary regulators is provided at Table 7. The reason for this re-­‐
9 FDIC’s Institutions Directory available at: https://www2.fdic.gov/idasp/main.asp, NCUA’s Credit
Union Search available at: http://researchcu.ncua.gov/Views/FindCreditUnions.aspx ,for investment
companies SEC’s Investment Adviser Search available at:
http://www.adviserinfo.sec.gov/IAPD/Content/Search/iapd_Search.aspx
33 classification is to separate financial institutions that operate under cyber security regulations from other financial institutions, which are not regulated in terms of cyber security. Thus, we will be able to analyze the actual threat patterns regarding regulated financial institutions. Lastly, we categorized institutions into 3 groups: banks, investment companies, and card payment companies. Table 7 Primary regulators and groups of financial institutions Type of Financial Institution National Banks Federally Chartered Saving Associations Federal Branches and Agencies of Foreign Banks State Member Banks10 Bank Holding Companies Credit Unions Brokerage Firms Investment Advisers Card Payment Companies Primary Regulator OCC OCC OCC FRB FRB NCUA SEC SEC PCI Group Banks Investment Companies Card Payment In order to classify the causes of breach incidents occurred in the financial institutions, we used the nine threat patterns provided in the renowned Verizon report [1]. These nine threat patterns and their definitions are listed in 10 These banks are member of Federal Reserve System, therefore they are also regulated by FRB besides state regulators 34 Table 8. 35 Table 8 Threat patterns defined by Verizon [1] Card Skimmers All incidents in which a skimming device was physically implanted (tampering) on an asset that reads magnetic stripe data from a payment card (e.g., ATMs, gas pumps, POS terminals, etc.). Any malware incident that did not fit other patterns like espionage or point-­‐of-­‐sale attacks. We labeled this pattern “crimeware” because the Crimeware moniker accurately describes a common theme among such incidents. In reality, the pattern covers a broad swath of incidents involving malware of varied types and purposes. Cyber-­‐
espionage Incidents in this pattern include unauthorized network or system access linked to state-­‐affiliated actors and/or exhibiting the motive of espionage. DoS Attacks Any attack intended to compromise the availability of networks and systems. Includes both network and application layer attacks. All incidents tagged with the action category of Misuse — any unapproved or malicious use of organizational resources — fall within Insider this pattern. This is mainly insider misuse, but outsiders (due to Misuse collusion) and partners (because they are granted privileges) show up as well. Incidents where unintentional actions directly compromised a Miscellane
security attribute of an information asset. This does not include lost ous Errors devices, which is grouped with theft instead. Physical Theft/Loss Any incident where an information asset went missing, whether through misplacement or malice. POS Intrusions Remote attacks against the environments where retail transactions are conducted, specifically where card-­‐present purchases are made. Crimes involving tampering with or swapping out devices are covered in the Skimming pattern. Verizon [1] also provided a list of CSCs to effectively defend against these nine patterns, based on their collaboration with Council on Cybersecurity11. To exemplify, Table 9 provides the CSCs recommended by Verizon and Council on 11 A not-for-profit organization founded in the United States in 2010 to identify and strengthen the
skills needed to improve the performance of the cybersecurity workforce. The Council develops the
Critical Security Controls and also promotes the widespread adoption of the framework.
36 Cybersecurity to defend against web application attack threat pattern. A complete list CSCs for each threat pattern can be found at [1]. Table 9 CSCs recommended by Verizon and Council on Cybersecurity to defend against 'Web Application Attacks' threat pattern Implement automated patching tools and processes for both applications and for operating system software. When outdated systems can no longer be patched, update to the latest version of application software. Remove outdated, older, and unused software from the system. Test in-­‐house-­‐developed and third-­‐party-­‐procured web applications for common security weaknesses using automated remote web application scanners prior to deployment, whenever updates are made to the application, and on a regular recurring basis. Include tests for application behavior under denial-­‐of-­‐service or resource exhaustion attacks. Test in-­‐house-­‐developed web and other application software for coding errors and potential vulnerabilities prior to deployment using automated static code analysis software, as well as manual testing and inspection. In particular, input validation and output encoding routines of application software should be reviewed and tested. For in-­‐house developed applications, ensure that development artifacts (sample data and scripts; unused libraries, components, debug code; or tools) are not included in the deployed software, or accessible in the production environment. Require all remote login access (including VPN, dial-­‐up, and other forms of access that allow login to internal systems) to use two-­‐factor authentication. This unique approach was the major reason for us to use these patterns. It enabled us to acquire a list of recommended security practices, which are mapped to threat patterns and grounded in a sound basis not only in subjective opinion. Findings of the case study By using two databases, PRC and ITRC, we identified 132 data breaches, which occurred in regulated financial institutions between January 2010 and February 2015. Table 10 summarizes the total number of breach incidents experienced by different types of financial institutions. The largest group of 37 institutions that experienced a data breach were national banks followed by investment adviser companies. Table 10 Total number of breaches grouped by type of financial institution Type of Financial Institution National Bank Federally Chartered Saving Association (Thrift) State Member Bank Bank Holding Company Credit Union Brokerage Firm Investment Adviser Investment Adviser and Brokerage Firm Card Payment Companies Total No. Breaches 61 7 7 2 13 7 15 10 10 Group Banks Investment Companies Card Payment Figure 1 provides the trend for the total number of data breach incidents occurred in the US financial sector starting from 2010 to the end of 2014. As seen in the graph, the total number of data breach incidents was almost stable during the given period. Roughly 25 data breaches were recorded annually during this 5-­‐year period. 38 -­‐ All Threat Patterns -­‐ 30 25 20 15 10 5 0 2010 2011 2012 2013 2014 Figure 1 Total number of breach incidents in the US financial sector Table 11 gives the total number of data breaches grouped by threat patterns. According to our findings, the most common cause of data breaches in the last five years for the US financial sector is miscellaneous errors (26%). It is followed by insider misuse (21%) and physical theft or loss (15%). It is noteworthy that all these three patterns have the “people” component as the common denominator. As expected, we did not encounter a data breach caused by cyber-­‐espionage, DOS attacks or POS intrusions. DOS attack pattern is not suitable to data breach since DOS attacks only affect the availability of data. Second, POS devices belong to merchants and breach incidents that happen at the merchants are out of this study’s scope. Lastly, in cyber-­‐espionage trade secrets or intellectual properties of companies are generally targeted, which is also not quite compatible to a data breach incident as defined in this study. 39 Table 11 Number of incidents grouped by threat patterns Causes (Threat Patterns) Card Skimmers Crimeware Everything else Insider Misuse Miscellaneous Errors Physical Theft/Loss Web App Attacks Unknown Grand Total Total No. Breaches 12 17 1 28 34 20 5 15 132 Percentage Verizon Report 9% 13% 1% 21% 26% 15% 4% 11% 100% 22% 4% 5% 7% 5% 3% 27% -­‐ 73% The scope of our study does not overlap with other studies, which reported the causes of data breaches in the financial sector. However, one might expect to see at least a loose correlation between our findings and other studies, especially with the Verizon report since we used the same threat pattern definitions. But as Table 11 reveals there is no correlation between our findings and Verizon’s.. This might be a result of different scope selection and incident identification methodology. The Verizon report includes the breaches occurred in the year 2013 and covers 95 countries all around the world. Instead, our study examines a five-­‐year period and only includes the US. Also, as we discussed earlier, the term financial sector is vague and our scope is limited to financial institutions, which are regulated in terms of cyber security. Lastly, Verizon report identifies all types of security breaches, however, our study focuses on only data breaches with reported data losses. All these differences resulted in distinct outcomes and also justified our methodology to build our own breach database. 40 Trends in threat patterns 7 6 5 4 Card Skimmers 3 Crimeware Insider Misuse 2 1 0 2010 2011 2012 2013 2014 Figure 2 Trends in threat patterns: card skimming, crimeware, and insider misuse Figure 2 displays the trends for 3 threat patterns: card skimming, crimeware, and insider misuse between 2010 and 2014. As clearly seen from the graph, crimeware has a very neat upward trend, which shows that it has become a common cause for data breaches in recent years. In contrast to crimeware, card skimming has declined as time passes. Insider misuse, one of the prevalent causes of breaches in the sector, has fluctuated over time but still remains as a major problem. 41 12 10 8 Miscellaneous Errors 6 Physical Theft/Loss 4 Web App Attacks 2 0 2010 2011 2012 2013 2014 Figure 3 Trends in threat patterns: miscellaneous errors, physical theft/loss and web application attacks According to Figure 3 US financial institutions have experienced almost one data breach each year due to web application attacks. However, miscellaneous errors have caused much more damage than these attacks roughly causing 6 breaches each year on average. Another common cause of data breaches is physical theft/loss in the sector. It is surprising to see that, despite widespread use of encryption, institutions are still suffering from breaches caused by physical theft or loss. Banks Table 12 summarizes the data breach incidents occurred in the US banking sector, which is regulated by the FFIEC and its member agencies. Insider misuse (33%) has the highest occurrence, which means that 1 of every 3 data breaches is due to malicious insiders. It is followed by miscellaneous errors (25%), which are also caused by insiders but this time unintentionally. Findings also show that 42 for the US banking sector data breach incidents are more frequently originated by insiders (58%) rather than outsiders (42%). Table 12 Causes of data breaches experienced by banks Causes (Threat Patterns) Card Skimmers Crimeware Everything else Insider Misuse Miscellaneous Errors Physical Theft/Loss Web App Attacks Total Total No. Breaches 12 7 1 26 20 11 3 80 Percentage 15% 9% 1% 33% 25% 14% 4% 100% Investment companies Table 13 provides a summary of breach incidents experienced by the investment adviser and brokerage firms. As seen from the table, miscellaneous errors (28%), physical theft/loss (28%) and crimeware (22%) are common patterns for this group. Although ‘insider misuse’ is the most common cause of breach incidents for banks, very interestingly, we do not observe the same thing for the investment companies. Insider misuse has only caused 6% of all breaches in this group. This can be regarded as a sign that security practices addressing insider misuse are extensively implemented in investment companies. We will discuss whether this is happening because due to regulations, in the following chapter. 43 Table 13 Causes of data breaches experienced by investment companies Causes (Threat Patterns) Crimeware Insider Misuse Miscellaneous Errors Physical Theft/Loss Web App Attacks Total Total No. Breaches 7 2 12 9 2 32 Percentage 22% 6% 38% 28% 6% 100% Card payment companies We were able to identify only 5 data breach incidents for card payment companies. Crimeware accounts for 3 of them while the remaining 2 were miscellaneous errors. Since the sample size is too small, and services provided by card payment companies are relatively different from banks and investment companies, it is difficult to infer useful information from this table. However, we should note that there is no breach incident caused by insider misuse, physical theft/loss or web application attack for this group. Table 14 Causes of data breaches experienced by card payment companies Causes (Threat Patterns) Crimeware Miscellaneous Errors Total Total No. Breaches 3 2 5 Percentage 60% 40% 100% 44 6. Gap analysis This chapter introduces our methodology for the gap analysis then reports the findings for the banking sub-­‐sector. We will continue with a discussion on different regulation methods between sub-­‐sectors followed by the limitations of the study. Methodology Information security gap analysis is often used for examining the security posture of an organization by comparing the organization’s actual security practices with best practices [42], [43]. These best practices can be selected among many different frameworks, such as ISO 27001, NIST standards or CSC framework [43]. Instead of having one company and a security framework, in this study, we conducted a gap analysis between cyber security regulations enforced by regulator and security practices recommended by experts to defend against actual threat patterns in the US financial sector. We used the CSCs framework for our gap analysis, but as an alternative to accepting all security practices in the framework as “the best practice”, we focused on detailed CSCs recommended to defend against actual threat patterns. The list of recommended CSCs is provided by Verizon and Council on Cybersecurity, the organization responsible for promoting the CSC framework. Within this list, we selected the CSCs that will be required to defend against actual threat patterns that the US financial institutions have faced between 45 January 2010 and February 2015. By doing so, we obtained a small but effective set of security best practices to use in our gap analysis. The desired outcome of a gap analysis is to identify a full match or a small gap between best and actual practices. This outcome would show a strong security posture, which fulfills all aspects of known best practices. Similarly, in this study, a full match or a small gap between security practices, which are enforced by regulations, and the selected CSCs would indicate effective cyber security regulations. Contrary, a large gap between them would point to a misalignment of regulations with actual threats and ineffective regulations. We divided the financial institutions into three sub-­‐sectors after examining the regulatory landscape of the US financial sector: banks, investment companies, and card payment companies. We excluded the investment companies since there was no detailed technical cyber security regulation to conduct a gap analysis. We also did not conduct a gap analysis for card payment companies since we were able to identify only 5 data breach incidents, which severely limited us to find out actual threat patterns. Hence, we only provided the ‘regulation coverage’ for this sub-­‐sector. Gap analysis results for the banking sub-­‐sector Table 15 provides the results of the gap analysis for the US banking sector. The table lists the actual threat patterns sorted by number of occurrences as the cause of data breach incidents within our examination period (January 2010-­‐
February 2015). ‘Insider misuse’ has the highest occurrence (26) followed by miscellaneous errors (20) and card skimming (12) incidents. Out of 8 CSCs, 46 which are recommended to defend against insider misuse, only one CSC is fully addressed by regulations, while 5 others are partly addressed. ‘Miscellaneous error’ threat pattern is the second most frequent cause of data breaches in the US financial sector. However, one of the two CSCs is partly addressed, while the remaining CSC is not addressed for this pattern as well. Causes of data breaches (Threat Patterns) No. Incidents Percentage No. Recommended CSCs Fully Addressed CSCs Partly Addressed CSCs Not Addressed CSCs Regulation Coverage Table 15 Gap analysis results for banks Insider Misuse Miscellaneous Errors Card Skimmers Physical Theft/Loss Crimeware Web App Attacks 26 33% 8 1 5 2 44% 20 25% 2 -­‐ 1 1 25% 12 15% 11 14% 3 2 1 -­‐ 83% 7 9% 9 2 6 1 56% 3 4% 5 2 2 1 60% No CSC is recommended for this threat The term “regulation coverage”, displayed in the last column of the Table 15, is a simple proxy to indicate the level of regulation coverage in terms of CSCs and defined as follows: 𝑅𝑒𝑔𝑢𝑙𝑎𝑡𝑖𝑜𝑛 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = 1 ∗ 𝐹𝑢𝑙𝑙𝑦 𝐴𝑑𝑑𝑟𝑒𝑠𝑠𝑒𝑑 𝐶𝑆𝐶𝑠 + (0.5 ∗ 𝑃𝑎𝑟𝑡𝑙𝑦 𝐴𝑑𝑑𝑟𝑒𝑠𝑠𝑒𝑑 𝐶𝑆𝐶𝑠)
𝑁𝑜. 𝑅𝑒𝑐𝑜𝑚𝑚𝑒𝑛𝑑𝑒𝑑 𝐶𝑆𝐶𝑠
Overall, Table 15 shows a large gap between security practices enforced by regulations and the recommended CSCs. This large gap can be regarded as a sign of ineffective and misaligned regulations for the banking sector. Out of five 47 threat patterns, four have regulation coverage within the 25%-­‐60% band. The two most common threat patterns, insider misuse and miscellaneous errors, have the lowest regulation coverage levels, 44% and 25% respectively. Crimeware (56%) and web app attacks (60%) are relatively better than the most common two, but again their coverage levels also reveal that many recommended security practices are not enforced by regulators. Regulation coverage levels calculated for threat patterns were much lower than the levels expected from effective regulations, especially for the common threat patterns. In contrast to other threat patterns, Table 15 reports a relatively small gap for physical theft/loss. This might be a result of physical theft/loss being a well-­‐
known threat pattern and requiring more ‘traditional’ defense mechanisms. Since CSCs recommended for physical theft/loss include more traditional and widely used security practices (i.e. having backup systems, security training and using hard-­‐drive encryption in mobile devices). As mentioned in previous chapters, many regulations are not updated frequently, which results in better defending against traditional threat patterns rather than emerging ones. High regulation coverage level for physical theft/loss also suggests that it is possible to improve the regulation coverage for threat patterns. As seen on Table 17, we found high regulation coverage for DOS attacks as well. The common denominator for these two threat patterns is the familiarity of the regulators and the institutions with these attacks. Regulators know more about these attacks and enforce more effective provisions to defend against them. Therefore, we believe better regulation coverage levels for other patterns are achievable. 48 Card payment companies For the card payment sector, regulations are imposed by Data Security Standards (DSS). Table 16 provides regulation coverage levels for two threat patterns observed in this sector. Since we were able to find only five breach incidents occurred in the card payment companies, this table does not claim to provide the results of a complete gap analysis for this sub-­‐sector. Results indicate a better coverage for the crimeware threat pattern compared to banking sub-­‐sector. Contrary, none of the CSCs recommended for defending against miscellaneous errors, indicating a gap between DSS and recommended CSCs. Regulation Coverage Not Addressed CSCs Partly Addressed CSCs Fully Addressed CSCs No. Recommended CSCs Percentage Causes of data breaches (Threat Patterns) Crimeware Miscellaneous Errors No. Incidents Table 16 Regulation coverage for card payment companies 3 60% 9 4 4 1 78% 2 40% 2 -­‐ -­‐ 2 0% Regulation methodology and further discussions Table 17 lists all threat patterns sorted by their frequencies presented in the Verizon report. Among 9 threat patterns, 4 were excluded from the table for 49 various reasons12. However, the remaining 5 patterns reveal interesting statistics about cyber security regulations and data breach incidents. One might expect to see the same ratios for threat patterns reported in Verizon’s report and actual threat patterns for banking and investment companies in the US. However, as we discussed in previous chapters numbers show a discrepancy, which is probably the result of scope differences between Verizon report and our study. On the other hand, there are also significant differences in frequencies of actual threat patterns between banking and investment sub-­‐sectors as well. What can explain the difference in frequencies of some threat patterns between banking and investment sub-­‐sectors? In our opinion, regulation coverage levels and different approaches among regulators of these sub-­‐sectors might explain some of the differences. For example, physical theft/loss threat pattern has caused 12 percent of all breach incidents in the banking sector. The same pattern accounts for 28 percent of all incidents for investment companies. Since they operate very similarly, one might expect to see similar frequency ratios in these two sub-­‐sectors. Although we cannot provide robust evidence to support this causal relationship, low frequency in the banking sector might be a result of high regulation coverage for this threat pattern. Since, contrary to 12 We excluded DOS attacks, POS intrusions and cyber-­‐espionage since we did not observe any data breach incident due to these threat patterns in financial sector. (POS intrusions occur in merchants even they stole card data of bank customers.) Card skimming was also excluded because no CSC was recommended to defend against this threat pattern. 50 banking agencies, we know that the SEC does not provide technically detailed cyber security regulations, but pursue the companies following a breach incident. On the other hand, banks seem to be more prone to malicious insiders, which also might be a result of low regulation coverage for this pattern. Although we do not have concrete evidence to support these claims, they were noteworthy for discussion. Table 17 Comparison with Verizon report Patterns Web App Attacks Insider Misuse Physical Theft/Loss Miscellaneous Errors Crimeware DOS Attacks Cyber-­‐
espionage POS Intrusions Card Skimmers Regulation Banking Coverage Actual For Banking Threat Patterns Verizon Financial S. Threat Patterns Investment C. Actual Threat Patterns 60% 3% 27% 6% 44% 29% 7% 6% 83% 12% 3% 28% 25% 22% 5% 38% 56% 88% 8% 4% 22% N/A – Doesn’t cause data breaches 56% N/A – Less than %1 of total attacks 54% N/A – Less than %1 of total attacks N/A – No CSCs are recommended for this threat pattern Limitations Although we strived to collect information on every data breach incident that occurred in the US financial sector between January 2010 and February 2015, we are not certain the list is comprehensive. The main reason for this limitation is the lack of an official and consistent source for collecting information about data breaches in the US. To overcome this hurdle, we used two databases (PRC and ITRC). However, we are not certain whether these two databases provide a 51 complete set of breach incidents. Moreover, we are missing ITRC reports for 2010 and 2012. Although we contacted ITRC to obtain those reports, we did not receive a positive response to our request. Regulations in the banking sub-­‐sector are numerous and very complex in nature. Appendix-­‐1 provides a list of regulations used in this study for mapping regulations to the selected CSCs. Although we tried to create a comprehensive list of regulations, we might have missed some regulations or some provisions in the regulations listed. Some regulatory documents, such as FFIEC’s Information Security Booklet is hundred pages in length, which makes it difficult for a thorough study. But it is also true that if we have missed some provisions because they are stated very briefly or imprecisely, it is very likely that many banking institutions might encounter the same problem. For simplicity we used only three categories to show the level of addressing CSCs by regulations: not addressed, partly addressed and fully addressed. However, not all partly addressed CSCs are at the same level in terms of which portion of the CSC is not addressed. Some CSCs are addressed very briefly and large portions of CSCs remain unaddressed while in some situations most of the CSCs are addressed. Adding additional levels would increase the subjectivity and make the analysis more complex. Therefore, we included only three categories to identify the level of addressing by regulations. Despite the fact that threat patterns and the recommended security practices to defend against these threat patterns are created with collaboration between Council on Cybersecurity and Verizon, they are not unquestionable. One might 52 offer a different classification for threat patterns and better security practices to defend against these threats. This would change all of the findings of this study. However, we believe our study provides a reasonable assurance and has a sound basis since it is based on a collaboration of experts in this field and is not totally dependent on subjective reasoning Finally, the aim of this study was to get a comprehensive look at data breach incidents and the effectiveness of cyber security regulations in the US financial sector, including banks, investment companies, and card payment companies. However, since the SEC has not issued a detailed technical cybersecurity regulation, we could not conduct a gap analysis for this sub-­‐sector. We encountered a similar problem for card payment companies as well, because of the limited numbers of incidents identified in this sub-­‐sector. Therefore, we had to limit our scope with the US banking sector. Nevertheless, despite the limitations listed above, we believe our study provides useful insights into the effectiveness of cyber security regulations and its alignment with actual threat patterns faced by the US financial institutions, especially for the banking sub-­‐sector. 53 7. Summary, Conclusions and Future Work The aim of this thesis was to investigate the effectiveness of cyber security regulations regarding the US financial sector in preventing data breaches. For this purpose, first we examined the regulations to determine which security practices were enforced by these regulations. Second, we performed a case study by using two publicly available data breach databases to uncover the actual threat patterns faced by the sector. Then we conducted a gap analysis between the security practices required by regulations and the selected CSCs recommended by experts in the field to defend against those actual threat patterns. In contrast to many studies reporting the causes of data breaches [1], [13]–
[15], [41], our findings revealed that miscellaneous errors (26%) and insider misuse (21%) are the two common causes of breaches followed by physical theft/loss (15%) and crimeware (13%). In addition, trend analysis of the causes between 2010 and 2014 showed that while the card skimming incidents was declining, the crimeware has escalated into a major problem. We also discovered that different sub-­‐sectors, such as banking and investment companies face almost the same threat patterns with different frequencies. Although the aim of the study was to cover all financial institutions regulated regarding cyber security, lack of technically detailed regulations and limited number of data breach incidents restricted the scope of gap analysis to the US banking sector. Results of the gap analysis revealed a large gap between the security practices required by federal banking regulations and the practices 54 recommended to defend against actual threat patterns. We believe, this gap can be considered as a sign of ineffective and misaligned regulations. We found that the gap between regulations and recommended security practices is smaller for traditional threat patterns, such as physical theft/loss and DOS. On the other hand, we observed larger gaps for top two causes of breach incidents: insider misuse and miscellaneous errors. These two findings align with the outdated cyber security regulations we discovered in our examination. A better-­‐aligned security regulation framework should have provided smaller gaps for the most frequent threat patterns rather than older ones. In our opinion, the large gap we discovered is mainly the result of regulations being slow in keeping pace with the threat patterns regarding cyber security. Better regulation coverage levels for more traditional threat patterns supports this idea, Some portion of the gap is due to expensive and relatively immature technologies recommended by experts but not enforced by regulators. Data loss prevention technology is a good example for such a technology, Actual threat patterns faced by the US financial sector show that top three threat patterns, which accounts for 62 percent of all breach incidents, are caused by insiders either intentionally or accidentally. Because of this, we recommend the US financial authorities, especially in the banking sector, focus more on insider threats in cyber security regulations. This need is evidenced by two of those three patterns regarding insider threat have the lowest regulation coverage in the banking sector. Additionally, updating regulations more 55 frequently to keep pace with emerging threats and monitoring actual threat patterns in their sectors would certainly help to increase the effectiveness of regulations and correct the misalignment of regulations. Future work This study covers only the US financial sector including banks, investment companies, and card payment companies. Comparing the cyber security regulations and actual threat patterns of other countries would provide more insights to the problem at hand. It may also provide insights regarding the effects of different regulatory approaches, such as whether to depend more on ex-­‐post regulations instead of ex-­‐ante regulations for preventing data breaches. Although this study provides the actual threat patterns of data breaches these patterns are not necessarily the root causes of the problem. For example, a breach incident caused by a crimeware might stem from the top management’s unwillingness to invest in a basic antivirus solution even taking the risk of noncompliance. In this case, blaming ex-­‐ante regulations would be pointless. We should focus on either enforcement actions, which will immediately penalize the non-­‐compliance with frequent audits or ex-­‐post regulation. Although it requires accessing detailed insider information about incidents, a root cause study would help us to better understand the problem. 56 Appendices Appendix 1 – The list of regulations examined regarding cyber-­‐
security in the US banking sub-­‐sector Laws Bank Service Company Act Bank Potection Act Fair and Accurate Credit Transactions Act Gramm-­‐Leach-­‐Bliley Act Fraud and Related Activity in Connection with Computers USA Patriot Act Other regulations enacted by FFIEC FFIEC IT Exam. Hand. -­‐ Audit Booklet FFIEC IT Exam. Hand. -­‐ Business Continuity Planning Booklet FFIEC IT Exam. Hand. -­‐ Development and Acquisition Booklet FFIEC IT Exam. Hand. -­‐ E-­‐Banking Booklet FFIEC IT Exam. Hand. -­‐ Information Security Booklet FFIEC IT Exam. Hand. -­‐ Management Booklet FFIEC IT Exam. Hand. -­‐ Operations Booklet FFIEC IT Exam. Hand. -­‐ Outsourcing Technology Services Booklet FFIEC IT Exam. Hand. -­‐ Retail Payment Systems Booklet FFIEC IT Exam. Hand. -­‐ Supervision of Technology Service Providers (TSP) Booklet FFIEC IT Exam. Hand. -­‐ Wholesale Payment Systems Booklet Supplement to Authentication in an Internet Banking Environment Interagency Guidelines Establishing Information Security Standards Interagency Guidance on Authentication in an Internet Banking Environment Joint Statement Cyber-­‐attacks on Financial Institutions’ ATM and Card Authorization Systems 57 Appendix 2 – Mapping results for the banking sub-­‐sector CSC ID CSC
2-4
CSC
3-1
CSC
3-2
CSC
3-8
CSC
5-1
CSC
5-2
Explanation Addr. Deploy software inventory tools throughout the organization covering each of
the operating system types in use, including servers, workstations, and
laptops. The software inventory system should track the version of the
underlying operating system as well as the applications installed on it.
Furthermore, the tool should record not only the type of software installed on
each system, but also its version number and patch level.
Establish and ensure the use of standard secure configurations of your
operating systems. Standardized images should represent hardened versions
of the underlying operating system and the applications installed on the
system. Hardening typically includes: removal of unnecessary accounts
(including service accounts), disabling or removal of unnecessary services,
configuring non-executable stacks and heaps, applying patches, closing open
and unused network ports, implementing intrusion detection systems and/or
intrusion prevention systems, and use of host-based firewalls. These images
should be validated and refreshed on a regular basis to update their security
configuration in light of recent vulnerabilities and attack vectors.
Implement automated patching tools and processes for both applications and
for operating system software. When outdated systems can no longer be
patched, update to the latest version of application software. Remove
outdated, older, and unused software from the system.
Utilize file integrity checking tools to ensure that critical system files
(including sensitive system and application executables, libraries, and
configurations) have not been altered. All alterations to such files should be
automatically reported security personnel. The reporting system should have
the ability to account for routine and expected changes, highlighting unusual
or unexpected alterations.
Partly
For investigative support, the reporting system should be able to show the
history of configuration changes over time and identify who made the change
(including the original logged-in account in the event of a user ID switch,
such as with the su or sudo command). These integrity checks should also
identify suspicious system alterations such as owner and permissions changes
to files or directories; the use of alternate data streams which could be used to
hide malicious activities; as well as detecting the introduction of extra files
into key system areas (which could indicate malicious payloads left by
attackers or additional files inappropriately added during batch distribution
processes).
Employ automated tools to continuously monitor workstations, servers, and
mobile devices with anti-virus, anti-spyware, personal firewalls, and hostbased IPS functionality. All malware detection events should be sent to
enterprise anti-malware administration tools and event log servers.
Employ anti-malware software that offers a remote, cloud-based centralized
infrastructure that compiles information on file reputations or have
administrators manually push updates to all machines. After applying an
update, automated systems should verify that each system has received its
signature update.
58 Partly
Fully
Partly
Partly
Partly
CSC ID CSC
5-6
CSC
6-4
CSC
6-7
CSC
6-11
CSC
8-1
CSC
9-3
CSC
9-4
CSC
11-2
CSC
11-5
Explanation Addr. Enable anti-exploitation features such as Data Execution Prevention (DEP),
Address Space Layout Randomization (ASLR),
virtualization/containerization, etc. For increased protection, deploy
capabilities such as Enhanced Mitigation Experience Toolkit (EMET) that
can be configured to apply these protections to a broader set of applications
and executables.
Test in-house-developed and third-party-procured web applications for
common security weaknesses using automated remote web application
scanners prior to deployment, whenever updates are made to the application,
and on a regular recurring basis. Include tests for application behavior under
denial-of-service or resource exhaustion attacks.
Test in-house-developed web and other application software for coding errors
and potential vulnerabilities prior to deployment using automated static code
analysis software, as well as manual testing and inspection. In particular,
input validation and output encoding routines of application software should
be reviewed and tested.
For in-house developed applications, ensure that development artifacts
(sample data and scripts; unused libraries, components, debug code; or tools)
are not included in the deployed software, or accessible in the production
environment.
Ensure that each system is automatically backed up on at least a weekly basis,
and more often for systems storing sensitive information. To help ensure the
ability to rapidly restore a system from backup, the operating system,
application software, and data on a machine should each be included in the
overall backup procedure. These three components of a system do not have to
be included in the same backup file or use the same backup software. There
should be multiple backups over time, so that in the event of malware
infection, restoration can be from a version that is believed to predate the
original infection. All backup policies should be compliant with any
regulatory or official requirements.
Implement an online security awareness program that (1) focuses only on the
methods commonly used in intrusions that can be blocked through individual
action, (2) is delivered in short online modules convenient for employees (3)
is updated frequently (at least annually) to represent the latest attack
techniques, (4) is mandated for completion by all employees at least annually,
and (5) is reliably monitored for employee completion.
Validate and improve awareness levels through periodic tests to see whether
employees will click on a link from suspicious e-mail or provide sensitive
information on the telephone without following appropriate procedures for
authenticating a caller; targeted training should be provided to those who fall
victim to the exercise.
Apply host-based firewalls or port filtering tools on end systems, with a
default-deny rule that drops all traffic except those services and ports that are
explicitly allowed.
Verify any server that is visible from the Internet or an untrusted network, and
if it is not required for business purposes, move it to an internal VLAN and
give it a private address.
Partly
59 Partly
Partly
None
Fully
Fully
Partly
Partly
Fully
CSC ID CSC
11-6
CSC
12-1
CSC
12-2
CSC
12-3
CSC
12-4
CSC
12-5
CSC
13-1
CSC
13-7
CSC
13-10
CSC
13-14
CSC
14-5
CSC
16-1
CSC
16-12
(NE
W)
Explanation Addr. Operate critical services on separate physical or logical host machines, such
as DNS, file, mail, web, and database servers.
None
Minimize administrative privileges and only use administrative accounts
when they are required. Implement focused auditing on the use of
administrative privileged functions and monitor for anomalous behavior.
Use automated tools to inventory all administrative accounts and validate that
each person with administrative privileges on desktops, laptops, and servers is
authorized by a senior executive.
Configure all administrative passwords to be complex and contain letters,
numbers, and special characters intermixed, and with no dictionary words
present in the password. Pass phrases containing multiple dictionary words,
along with special characters, are acceptable if they are of a reasonable
length.
Before deploying any new devices in a networked environment, change all
default passwords for applications, operating systems, routers, firewalls,
wireless access points, and other systems to have values consistent with
administration-level accounts.
Ensure that all service accounts have long and difficult-to-guess passwords
that are changed on a periodic basis, as is done for traditional user and
administrative passwords.
Deny communications with (or limit data flow to) known malicious IP
addresses (black lists), or limit access only to trusted sites (whitelists). Tests
can be periodically carried out by sending packets from bogon source IP
addresses (non-routable or otherwise unused IP addresses) into the network to
verify that they are not transmitted through network perimeters. Lists of
bogon addresses are publicly available on the Internet from various sources,
and indicate a series of IP addresses that should not be used for legitimate
traffic traversing the Internet.
Require all remote login access (including VPN, dial-up, and other forms of
access that allow login to internal systems) to use two-factor authentication.
Fully
To limit access by an insider, untrusted subcontractor/vendor, or malware
spreading on an internal network, devise internal network segmentation
schemes to limit traffic to only those services needed for business use across
the organization's internal network.
Deploy NetFlow collection and analysis to DMZ network flows to detect
anomalous activity.
Have security personnel and/or system administrators run biweekly reports
that identify anomalies in logs. They should then actively review the
anomalies, documenting their findings.
Review all system accounts and disable any account that cannot be associated
with a business process and owner.
Partly
Configure access for all accounts through a centralized point of
authentication, for example Active Directory or LDAP. Configure network
and security devices for centralized authentication as well.
None
60 Partly
Partly
Fully
None
None
Fully
None
Partly
Partly
CSC ID CSC
16-13
CSC
17-1
CSC
17-6
CSC
17-9
CSC
18-1
CSC
18-2
CSC
18-3
CSC
19-4
Explanation Addr. Profile each user's typical account usage by determining normal time-of-day
access and access duration. Reports should be generated that indicate users
who have logged in during unusual hours or have exceeded their normal login
duration. This includes flagging the use of the user's credentials from a
computer other than computers on which the user generally works.
Deploy approved hard drive encryption software to mobile devices and
systems that hold sensitive data.
Conduct periodic scans of server machines using automated tools to
determine whether sensitive data (i.e., personally identifiable information,
health, credit card, and classified information) is present on the system in
clear text. These tools, which search for patterns that indicate the presence of
sensitive information, can help identify if a business or technical process is
leaving behind or otherwise leaking sensitive information.
Use network-based DLP solutions to monitor and control the flow of data
within the network. Any anomalies that exceed the normal traffic patterns
should be noted and appropriate action taken to address them.
Ensure that there are written incident response procedures that include a
definition of personnel roles for handling incidents. The procedures should
define the phases of incident handling.
Assign job titles and duties for handling computer and network incidents to
specific individuals.
Define management personnel who will support the incident handling process
by acting in key decision-making roles.
Partly
Segment the enterprise network into multiple, separate trust zones to provide
more granular control of system access and additional intranet boundary
defenses.
Partly
61 Partly
Partly
None
Fully
Fully
Fully
Bibliography [1] Verizon, “2014 Data Breach Investigations Report,” 2014. [2] Reuters, “JP Morgan Hack Exposed Data of 83 Million, Among Biggest Breaches in History,” Reuters, 02-­‐Oct-­‐2014. [3] Sharone Tobias, “2014: The Year in Cyberattacks,” Newsweek, 31-­‐Dec-­‐2014. [Online]. Available: http://www.newsweek.com/2014-­‐year-­‐cyber-­‐attacks-­‐
295876. [Accessed: 08-­‐Apr-­‐2015]. [4] K. Dugan, “In-­‐House Hacker at Morgan Stanley Stole Data on Bank’s Wealthiest Clients,” New York Post, 05-­‐Jan-­‐2015. . [5] New York State and Department of Financial Services, “Report on Cyber Security in the Banking Sector,” May 2014. [6] ITRC, “ITRC Breach Statistics 2005 -­‐ 2014.” ITRC. [7] K. Campbell, L. A. Gordon, M. P. Loeb, and L. Zhou, “The economic cost of publicly announced information security breaches: empirical evidence from the stock market,” Journal of Computer Security, vol. 11, no. 3, pp. 431–448, 2003. [8] H. Cavusoglu, B. Mishra, and S. Raghunathan, “The Effect of Internet Security Breach Announcements on Market Value: Capital Market Reactions for Breached Firms and Internet Security Developers,” Int. J. Electron. Commerce, vol. 9, no. 1, pp. 70–104, Oct. 2004. [9] A. Acquisti, A. Friedman, and R. Telang, “Is there a cost to privacy breaches? An event study,” 2006. 62 [10] L. A. Gordon, M. P. Loeb, and L. Zhou, “The impact of information security breaches: Has there been a downward shift in costs?,” Journal of Computer Security, vol. 19, no. 1, pp. 33–56, Jan. 2011. [11] Ponemon Institute, “2014 Cost of Data Breach Study: Global Analysis,” May 2014. [12] Department for Business, Innovation & Skills, “Cyber essentials scheme,” Apr. 2014. [13] Identity Theft Resource Center, “Identity Theft Resource Center Breach Report Hits Record High in 2014,” 12-­‐Jan-­‐2015. [Online]. Available: http://www.idtheftcenter.org/ITRC-­‐Surveys-­‐Studies/2014databreaches.html. [14] Heidi Shey, “Understand The State Of Data Security And Privacy: 2013 To 2014,” Forrester, Oct. 2013. [15] PWC, “2014 information security breaches survey: technical report,” Department for Business, Innovation & Skills, Apr. 2014. [16] Kim-­‐Kwang Raymond Choo, “Cyber threat landscape faced by financial and insurance industry,” Trends & Issues in Crime & Criminal Justice, no. 408, pp. 1–
6, Feb. 2011. [17] NCSL, “Security Breach Notification Laws,” SECURITY BREACH NOTIFICATION LAWS, 12-­‐Jan-­‐2015. [Online]. Available: http://www.ncsl.org/research/telecommunications-­‐and-­‐information-­‐
technology/security-­‐breach-­‐notification-­‐laws.aspx. [Accessed: 11-­‐Feb-­‐2015]. [18] J. K. Winn, “Are Better Security Breach Notification Laws Possible,” Berkeley Tech. LJ, vol. 24, p. 1133, 2009. 63 [19] T. M. Lenard and P. H. Rubin, “Much ado about notification,” Regulation, vol. 29, p. 44, 2006. [20] S. Romanosky, R. Telang, and A. Acquisti, “Do data breach disclosure laws reduce identity theft?,” Journal of Policy Analysis and Management, vol. 30, no. 2, pp. 256–286, 2011. [21] S. Romanosky, D. Hoffman, and A. Acquisti, “Empirical Analysis of Data Breach Litigation,” Journal of Empirical Legal Studies, vol. 11, no. 1, pp. 74–104, Mar. 2014. [22] A. Cummings, T. Lewellen, D. McIntire, A. P. Moore, and R. F. Trzeciak, “Insider threat study: Illicit cyber activity involving fraud in the US financial services sector,” 2012. [23] FFIEC, “FFIEC IT Examination Handbook InfoBase -­‐ Appendix C: Laws, Regulations, and Guidance.” [Online]. Available: http://ithandbook.ffiec.gov/it-­‐
booklets/information-­‐security/appendix-­‐c-­‐laws,-­‐regulations,-­‐and-­‐
guidance.aspx. [Accessed: 09-­‐Apr-­‐2015]. [24] Gramm-­‐Leach-­‐Bliley Act -­‐ Protection of nonpublic personal information, vol. § 6801. 1999. [25] PCI, “Payment Card Industry (PCI) Data Security Standard.” Nov-­‐2013. [26] Council on Cyber Security, “The Critical Security Controls for Effective Cyber Defense.” . [27] Ronald R. Glancz and Meredith Boylan, “Overview of Federal Bank Enforcement Actions,” 2012. [28] OCC, “Policies and procedures manual.” 09-­‐Sep-­‐2011. 64 [29] Brian Krebs, “FDIC: 2011 FIS Breach Worse Than Reported — Krebs on Security,” 04-­‐Jun-­‐2013. . [30] D. Morrison, “Citing ‘Unsatisfactory Risk Management,’ NCUA Asks Credit Unions to Evaluate Relationship With FIS,” 10-­‐Apr-­‐2012. [Online]. Available: http://www.cutimes.com/2012/04/10/citing-­‐unsatisfactory-­‐risk-­‐
management-­‐ncua-­‐asks-­‐cr. [Accessed: 17-­‐Mar-­‐2015]. [31] OCC and FDIC, “In the Matter of FUNDTECH, BSERV -­‐ Consent Order.” 14-­‐Feb-­‐
2014. [32] E. R. Marshall, C. D. Miller, J. W. McGuinness, B. S. Polsky, H. P. Reichwald, and B. VanBrackle, “FDIC, OCC take action against third-­‐party service provider | Lexology.” [Online]. Available: http://www.lexology.com/library/detail.aspx?g=7bee192d-­‐6d41-­‐44d0-­‐9926-­‐
9629f67a62a5. [Accessed: 12-­‐Apr-­‐2015]. [33] Chris Cumming, “OCC Takes Action against Tech Firm Jack Henry, Frees Six Banks,” American Banker. [Online]. Available: http://www.americanbanker.com/issues/178_244/occ-­‐takes-­‐action-­‐against-­‐
tech-­‐firm-­‐jack-­‐henry-­‐frees-­‐six-­‐banks-­‐1064505-­‐1.html. [Accessed: 12-­‐Apr-­‐
2015]. [34] FDIC, OCC, and FRB, “Formal Agreement -­‐ Jack Henry & Associates.” 04-­‐Dec-­‐
2013. [35] Kenneth L. Greenberg, “United States: Cybersecurity Troubles At Financial Firms – Seven Regulatory Actions To Consider,” 04-­‐Nov-­‐2014. [Online]. Available: 65 http://www.mondaq.com/unitedstates/x/347068/data+protection/Cybersec
urity+Troubles+At+Financial+Firms+Seven. [36] J. Silver-­‐greenberg, “After Data Breach, Visa Removes a Service Provider,” The New York Times, 01-­‐Apr-­‐2012. [37] “Processor Global Payments Prepares To Close the Book on Its Data Breach,” The Digital Transactions, 08-­‐Apr-­‐2013. [Online]. Available: http://digitaltransactions.net/news/story/Processor-­‐Global-­‐Payments-­‐
Prepares-­‐To-­‐Close-­‐the-­‐Book-­‐on-­‐Its-­‐Data-­‐Breach. [38] Linda McGlasson, “Heartland Back on Visa’s List as PCI Compliant,” 06-­‐May-­‐
2009. [Online]. Available: http://www.bankinfosecurity.com/heartland-­‐back-­‐
on-­‐visas-­‐list-­‐as-­‐pci-­‐compliant-­‐a-­‐1444. [Accessed: 14-­‐Apr-­‐2015]. [39] E. Dash, “Visa to Bar Transactions by Processor,” The New York Times, 19-­‐Jul-­‐
2005. [40] PCI Compliance Guide, “PCI FAQS.” [Online]. Available: https://www.pcicomplianceguide.org/pci-­‐faqs-­‐2/. [41] Ponemon Institute, “2013 Cost of Data Breach Study: Global Analysis,” May 2013. [42] Chris Sell, “How To Conduct An Information Security Gap Analysis,” CIO, 28-­‐Jan-­‐
2015. [Online]. Available: http://www.cio.com/article/2876708/security0/how-­‐to-­‐conduct-­‐an-­‐
information-­‐security-­‐gap-­‐analysis.html. [Accessed: 21-­‐Apr-­‐2015]. [43] Michael Mullins, CCNA, “Perform a gap analysis of your organization’s security,” TechRepublic, 22-­‐Sep-­‐2005. [Online]. Available: 66 http://www.techrepublic.com/article/perform-­‐a-­‐gap-­‐analysis-­‐of-­‐your-­‐
organizations-­‐security/. [Accessed: 21-­‐Apr-­‐2015]. 67