When an enterprise begins actively monitoring its network to establish its security posture, an often-overlooked component of an enterprise’s security posture is vulnerability management. The core of that component is vulnerability scanning and subsequent remediation through patch management. Vulnerability scanning is an important part of a well-established vulnerability management program for a multitude of reasons, but the 2 main reasons are:
Scanning allows you to identify threats and weaknesses within all the devices within your network to include: routers, switches, endpoints, printers, servers and web applications. Detecting vulnerabilities and taking corrective action is important to your overall security posture and essential in protecting valued data assets from internal and external threats. An enterprise must remember, however, that maintaining an effective vulnerability management program is an ongoing process. When it comes to vulnerabilities, malicious actors benefit from automation, crowdsourcing, big data, mobile, low cost cloud computing, and other resources as much as an enterprise’s security team does. Only the bad guys have the advantage; malicious actors need to find just one unpatched vulnerability, whereas a security team must find and patch all vulnerabilities. Though a host may be safe today after a spotless vulnerability scan, a malicious actor could discover a serious vulnerability tomorrow. The result can become a game of Whack-A-Mole — an endless cycle of identifying vulnerabilities and then racing against the clock to patch them before malicious actors develop exploits for them. Therefore, an enterprise should strive towards continuous vulnerability scans to discover those constant incremental changes. An enterprise might not have the scanning infrastructure or human capital needed to conduct and analyze continuous scans of its network environment, so it may need to explore outsourcing solutions that can do this cost efficiently. Continuous vulnerability scans not only help organizations determine whether they are fixing the flaws they discover, they also help companies identify trends in the performance of the vulnerability management program, information which security managers and other executives can use to justify current and future budget allocation.
What is a vulnerability scan?
A vulnerability scan is often confused with a penetration test and the two mistakenly often used interchangeably, but they are quite different tests and processes within your vulnerability management program.
A vulnerability scan is performed by using commercial software package to scan an IP address or range of IP addresses for known vulnerabilities. A scan typically consists of four stages:
It’s important to keep in mind that a vulnerability scan is dependent on a database of known vulnerabilities to test; similarly, anti-virus software operate with the same dependency. Obviously, there are vulnerabilities that are unknown to the public at large called 0-day vulnerabilities and these scanners will not detect and offer remediation.
There are different types of vulnerability scans and each operates with a different level of thoroughness and activity. A simple vulnerability scan checks the Windows Registry and software version information to determine whether the latest patches and updates have been applied. More comprehensive and thorough vulnerability scan, such as the kind that HLC performs, involves the aforementioned simple scan and additional functionality to execute malicious code to determine whether a vulnerability is exploitable.
Vulnerability Prioritization and Patch Management
The aforementioned scan results in a report that lists out discovered vulnerabilities, their severity, and remediation steps. After vulnerabilities are identified, they need to be evaluated so the risks posed by them are dealt with appropriately and in accordance with an enterprise’s vulnerability management strategy. A vulnerability scan will provide different risk ratings and scores for vulnerabilities, such as Common Vulnerability Scoring System (CVSS) scores. These scores are helpful for enterprise to which vulnerabilities it should focus on first, but the true risk posed by vulnerabilities should consider these factors:
● Is this vulnerability a true or false positive?
● Could a malicious actor directly exploit this vulnerability from the Internet?
● How difficult is it to exploit this vulnerability?
● Is there known, published exploit code for this vulnerability?
● What would be the impact to the business if this vulnerability were exploited?
● Are there any other security controls in place that reduce the likelihood and/or impact of this vulnerability being exploited?
● How old is the vulnerability/how long has it been on the network?
Patch Management is important for the security of your enterprise and imperative to a successful vulnerability management program. There are times when patches are released just to fix a functionality issue, but often they are released to fix security issues. As soon as a piece of software is released malicious actors attempt to exploit software through vulnerabilities; when successful, there’s a subsequent need for patches and a patch management process. Patches protect your network and data from constantly-evolving malicious actors and they can only do their job if you have a system in place to discover and analyze through a vulnerability scan and manage and apply patches through a patch management process.
Stressing the importance of vulnerability scanning and patch management, malicious actors, who are looking to infiltrate and compromise networks, are using vulnerability scanners to identify weaknesses and find the easiest path to their desired goal. While a vulnerability scan and patch management are not a perfect security solution, they are tools that can help proactively identify issues and resolve them before attackers have a chance to exploit them. Most importantly, a vulnerability scan is important to an effective vulnerability management program and an enterprise’s overall security posture. However, the results of a vulnerability scan are only as valuable as the willingness to accept the results, act and remediate them. Simply identifying vulnerabilities might be enlightening, but in and of itself it does truly little to reduce your risk or improve your security.
Enslaved As Miner Against Your Will? Recent Malware Attacks May Have Your Systems Mining Crypto Without Your Knowledge
In the past few months, HLC has been noting a decided uptick in one type of malware: crypto currency mining. While our solutions have prevented these infections, the malware is often embedded into .png picture files, making it appear all the more innocuous to the user who is inadvertently infected.
Since the introduction of Bitcoin in 2009, the popularity and adoption of cryptocurrencies as an asset class has grown at a rapid pace. Once reserved for black market activity, hobbyists, mathematicians, and computer geeks, cryptocurrency is now becoming a global topic of interest with a market capitalization of ~$400 billion and continuing to rise with Initial Coin Offerings (ICO) to further fund the development of projects related to cryptocurrencies. Unfortunately, the anonymity provided by digital currencies has become quickly abused for illegal extortion, as was the case during the various ransomware outbreaks we’ve witnessed in the last few years. As the value of cryptocurrencies has increased significantly, a new kind of threat has become mainstream and replaced ransomware extortion: cryptocurrency mining malware. Malware creators target outside computing power because the price of a dedicated cryptocurrency mining machine easily exceeds thousands of dollars. The emergence of cryptocurrencies that can be mined by average computers has attracted malware creators and has contributed to the widespread abuse we are witnessing globally.
What Is Crypto Mining and How Do You Get Infected?
Cryptocurrency mining is a record-keeping service that is done using computer processing power. Transactions are recorded in blockchains, which function as a public ledger. The consistency and completeness of the blockchain is maintained in an unalterable state by miners, who repeatedly verify and collect newly broadcast transactions, called blocks. Cryptocurrency mining malware comes in many forms, for many different operating system and application platforms, but the common theme among all of them is threat actors leveraging the computing power of as many compromised devices to maximize cryptocurrency mining profitability. It is critically important for the malware creator that the cryptocurrency mining malware infects as many systems as possible, to control a larger pool of CPU resources for mining. Let’s investigate the numerous common malware delivery methods for cryptocurrency mining.
The Wannacry ransomware, a highly publicized malware, exploits the leaked EternalBlue and DoublePulsar vulnerabilities and was modified to by different malware groups to leverage the same vulnerabilities to infect hundreds of thousands of Windows servers with a cryptocurrency miner, ultimately generating millions of dollars in revenue. Other vulnerabilities, such as a flaw with Oracle’s WebLogic Server (CVE-2017-10271), were also used to deliver miners onto servers at universities and research institutions. Servers are a favorite among malware creators because they offer the highest hash rate to solve the mathematical operations required by cryptomining. Existing malware families like Trickbot, which is distributed via malicious spam attachments, added a cryptocurrency miner module to its payload. Another commonly used malware delivery method is fake software patches for highly publicized vulnerabilities such as Spectre and Meltdown. The favorite malware group is SmokeLoader and cryptocurrency miners have become the most commonly installed malware payloads.
Indicators of Compromise: Identifying Infection
There are 3 common IoC (Indicators of Compromise) on every infected victim’s device.
First, for cryptocurrency mining to occur, the malware runs background processes on the infected host that results in the significant over-usage of its resources, and subsequently its performance slows down significantly. Common symptoms are an overheating system due to constant CPU & GPU over usage, drastic system performance degradation, and hardware malfunction. Open a resource monitor on your computer to check if CPU usage is abnormally high; on a Mac that’s Activity Monitor, and on Windows it’s Task Manager. Additionally, the worst part is that there is no residual file, also known as fileless malware, meaning it is very difficult to detect and impossible for standard signature based anti-malware software. What is fileless malware? Just as the name suggests, fileless malware is a variant of a malicious code which affects your system without leaving an installed file on the victim’ s device. Fileless malware is written directly into the device’s working memory, RAM. You may think a simple reboot will remove the malware, however, the malware code is also injected into commonly running processes such as service.exe, chrome.exe, to sustain life after each reboot.
Second, in order to achieve maximum profitability mining cryptocurrency, malware must connect to a C&C (command & control) server to download the cryptocurrency mining software and execute without leaving a file. Most importantly, the malware must add the compromised host to a mining pool network. This abnormal network traffic is a common identification method to confirm you’re a victim of cryptocurrency mining malware. All mining software must be able to connect to either the cryptocurrency network or a mining pool to exchange data, in other words its proof-of-work. Without this connection, it cannot get the data it needs to generate hashes, rendering it useless. Malware creators will add network rules to block the ports associated with exploited vulnerability to close the proverbial door behind it for other potential attacks. This is done to keep the infected system to itself and close it off to any other malware targeting the same vulnerability. Not only are malware creators mischievous, but apparently greedy.
Third, websites have become the biggest culprits of cryptocurrency mining campaigns, specifically CoinHive and its derivatives. Coinhive is a cryptocurrency mining service that relies on a small chunk of computer code designed to be installed on Web sites. The code utilizes all of the computing power of any browser that visits the site in question, enlisting the machine in a bid to mine cryptocurrency. Coinhive is pitched as a way for website owners to earn an income without running intrusive or annoying advertisements. However, Coinhive’s code has emerged as the top malware threat because the code is installed on victimized websites. If you surf to a particular website without additional browser tabs, no other applications running and notice a huge spike in CPU usage while on that website, then it is likely running a cryptocurrency mining campaign such as CoinHive unbenounced to its visitors. Commonly, cryptocurrency mining malware will automate and force the visitation of these particular websites in foreground and background browser tabs to generate cryptocurrency revenue.
By now, you’ve learned that cryptocurrency mining malware is something you want to avoid. How do you avoid infection? And what should you do upon learning you’re infected?
You didn’t think you would make it through this article without yet another reference to common sense, right? As previously described, the numerous methods for cryptocurrency mining malware center around making careless mistake such as installing trojanized mobile apps via your App Store of choice, Apple App Store or Google Play, opening an attachment with malicious malware, or surfing to a website with malicious code installed. Since no one reading this is going to be happy with the gratuitous common sense takeaway, here some other simple steps to take if you’d like additional protection to ward off pesky cryptocurrency mining malware:
First, avoid mobile apps with low or limited app reviews. Apple has an extensive mobile app review process, but trojanized apps still find a way through the process as we saw with the XcodeGhost malware that was installed in over 4000 mobile apps. Review the mobile app developer’s logo and profile to confirm the legitimate mobile app you’re about to download is not merely a copy of a legitimate app with malware added by a malicious actor. This practice is more prevalent on Google Play because of the open source policy and developer freedom that Android practices, which results is less oversight of mobile app distribution.
Second, install a trusted browser-based extension to detect CoinHive website code. Common Chrome browser extensions to block CoinHive code are Miner Dectector, Coin-Hive Blocker and No Coin. These browser blockers review a website’s code and alert an end user that CoinHive and other common cryptocurrency mining code has been detected/blocked. Similarly, to malware mobile apps, ensure that the browser extension you are installing is indeed not a knock off of a trusted browser extension because there are always malware creators are looking for any method to get you to make that careless mistake.
Third, while your standard anti-virus software is rendered useless against fileless cryptocurrency mining malware, it can protect you against the necessary network traffic to participate in a cryptocurrency mining pool. Large anti-virus software companies have the scalable resources to identify and research cryptocurrency mining campaigns and thusly, are constantly updating their host firewall rules to ensure that network traffic to aforementioned command and control cryptocurrency mining servers is blocked. This feature eliminates the need for users to tediously monitor cryptocurrency mining pools and update their hosts file to redirect network traffic to those C&C servers.
As we’ve discussed, cryptocurrency mining malware has gone mainstream and will only continue to increase in deployment and proliferation thanks in large part to cryptocurrencies’ values and the inability to confidently detect. As we face this increasing threat, we must remain vigilant in proactive steps taken to avoid and remediate cryptocurrency mining malware. Those steps require previously discussed common sense steps combined with relying on a trusted provider like HLC to help you navigate pre and post malware infection troubles. That powerful combination is necessary in the continued escalating battle against cryptocurrency mining malware and other emerging malware types.
So many different IT systems and devices, so little time for compliance. Small and medium-sized enterprises (SMEs) represent up to 99% of national economies and a huge market for IT products. The wide variety of systems in use in the SME sector makes it a breeding ground for vulnerabilities and cyberattacks. Yet so far, suitable solutions to help SMEs be compliant in information security have been lacking.
SMEs are generally budget constrained and have little time to stay on top of IT configurations and security settings. Regulators remain unsympathetic – information security is a cost of doing business. Companies that do not audit or assess their security or cannot otherwise prove appropriate information security controls are subject to fines and sanction, putting their hard earned reputations at risk. Automating monitoring and reporting of system and device compliance can make a significant difference. It can reduce effort and increase reliability, helping SMEs meet their compliance obligations more easily and cost effectively, while reinforcing the confidence of their partners and clients.
Compliance and Security Challenges Facing SMEs
On its own, one small or medium-sized business may not have a large IT installation. IT infrastructures and security profiles, however, will vary considerably from business to business. What makes one company compliant cannot be copied over to another company. Even 1% of noncompliance can then be enough to make a company vulnerable to cyberattacks or incidents, which is why auditors are so fastidious when they check.
IT vendors do not always help matters either. Their IT products are usually destined for a wide range of uses, meaning that restrictive security settings may not be part of default configurations. Some vulnerabilities even exist right ‘out of the box’. Between new and legacy systems, there are hundreds of types of machines. According to end-user needs, there are then thousands or more possible configurations. This complexity increases yet again with combinations of cloud systems and on-premise data centers, as well as other devices used by external users and advisory networks that all need to be connected.
To compound the problem, the specialist knowledge to ensure compliance is lacking in many SMEs. Even when an SME has employees who know about compliance with industry standards and who know about information technology, there is no guarantee that all this knowledge exists in one person. Different individuals often have separate areas of expertise, leaving a gap between regulatory requirements and IT actions.
Options for Assessing and Improving Compliance
Unlike annual fire safety inspections, information security compliance is a continual activity. IT vendors constantly update the versions of their operating systems and systems, making a compliance a moving target. Cybercriminals are a round-the-clock threat. Thanks to internet, hackers from halfway across the world can threaten a company’s data center, day and night.
There are several ways that SMEs might approach their information security compliance, each with its limitations. There is unfortunately no “silver bullet”. A better solution is a program that combines different approaches, using the advantages of each one and avoiding or compensating for the limitations. Here are some primary elements:
Smart Automation, Key to Efficiency and Affordability
Vulnerability scans and checklist assessments, coupled with periodic controls assessments, stand out as the approaches with the potential for covering the most compliance at the least cost. This is largely due to the possibilities of automating them and the extensive databases of information available for use with them. What cannot be automated will need to be accomplished manually. Examples include penetration testing and security hardening of proprietary developments that do not feature in standard checklists. These automated and manual procedures should also be integrated into a larger information security program for prevention and remediation of IT security threats and incidents, with end user security awareness training, endpoint protection, firewalls, SIEM, intrusion detection systems, and other measures as appropriate.
As well as offering wide coverage for compliance and the software audit trails to prove it, there is another advantage to automated solutions. They force hackers and cybercriminals to ‘up their game’ or to seek another easier target. In many cases, attackers choose the second option, preferring not to waste time attacking an organization that has already extensively checked and corrected vulnerability and compliance issues. Automated checking can also be extended across onsite and in-cloud systems, as well as mobile computing devices such as smartphones, tablets, and laptops. In addition, automated solutions may offer benchmarking to show how an organization’s security posture compares with the rest of the industry. Good posture makes for good public relations. This can help improve the organization’s corporate image as being secure and responsible in matters of information and data protection and privacy.
For SMEs or other organizations with limited technical expertise in-house, an automated solution for information security compliance must also offer suitable user-friendliness. Administrators or users should be able to see the security and compliance status of their company at a glance, for example, via an intuitive dashboard. They should also be able to easily achieve optimal security settings across systems and devices, independently of their location. Continually monitoring configurations, the solution must also immediately alert users or management to changes in configuration, especially those that result in non-compliance. Additional functionality such as checking that necessary security scans are being done regularly and verification of disk data encryption can also contribute to a well-rounded view for an SME of its security and compliance posture.
Responsibilities and Results
While smart software can go a long way to help ensure compliance and security, the organization and its users always retain the final responsibility. An automated solution can find issues, flag them, and even suggest ways to remediate them. Users then make or authorize suitable changes. A software solution does not in itself guarantee compliance, although it can provide valuable records of compliance settings and changes.
Nonetheless, all enterprises and organizations, and SMEs especially, can take advantage of such a solution for faster, better, more affordable compliance and security checking. By leveraging vendor and government checklist data and monitoring IT security essentials effortlessly via a suitable software application, they can meet requirements of auditors and regulators and significantly reduce the risks of IT system and network attacks.
Not In Compliance With NYDFS’s Cybersecurity Regulations? Helpful Guidance From HLC On What To Do Now.
You have been busy. Your company has clients to service and business to win. Maybe you were vaguely aware of the New York State Department of Financial Services’ (“NYSDFS”) cybersecurity regulation that went into effect last March but now the deadline has passed for filing the cybersecurity annual certification and you did not submit. Not only that, but maybe you didn’t do anything to comply. Of course, there is also the reminder you recently received from New York State underscoring your non-compliance….
The first step is obvious: deflect blame. Target prospects include anyone from your organization, your vendors, politicians, lawyers (obligatory), and New York State itself.
If you have already received the notice, then it is likely that you need to comply. There has been some confusion about the need for individuals to comply versus firms, since the requirements apply to both. Covered companies may comply on behalf of affiliates, subsidiaries, employees, and contracted individuals (e.g., registered representatives) but may not comply on behalf of third party providers that are entities. This means that third party providers who are regulated by NYSDFS may still be subject to the regulations even if they have employees who are in compliance through the information security program of another Covered Entity.
Another important point to remember is that it does not matter if you are located out of state. If your firm must register with the NYSDFS to conduct covered businesses within New York, then you must comply with the regulations.
Is My Business Partially Exempt?
After you have determined that you are subject to the regulation, the next question you need to ask is whether you are eligible to file for a partial exemption (which you may also be delinquent on…sorry). If you are, then you only must comply with the major requirements indicated by the red boxes below. If you are not, then red and blue are your colors.
Partial exemptions are available if your firm: (i) has less than ten employees and contractors; (ii) less than $5mm in gross annual revenues; (iii) less than $10mm in year-end total assets; OR (iv) if your firm effectively has nothing to do with Nonpublic Information, as defined in the regulations.
If you know you are covered by the law, qualify for an exemption and have not filed, then you should do so now. Log in here:
https://myportal.dfs.ny.gov/web/cybersecurity and file now…I’ll wait.
Whether or not you are exempt, the next step is to start to comply and first step there is to get an information security risk assessment done. This is not a DIY project unless you have in house information security professionals. You should hire an experienced cyber security assessment firm to assist. In addition, if you are not partially exempt, you will need to ensure that a vulnerability scan and penetration test is done on your systems. Even if you are not partially exempt, you should perform vulnerability scanning and penetration testing anyway as it is an industry best practice for any information security program.
The risk assessment is generally the first step towards assessing where your gaps are and a security program, if not in place already, is best to flow from the results of a risk assessment. The assessor should also provide your firm with a prioritization map to facilitate your response. In addition, a qualified third party information security risk assessor should be able to provide your firm with direction as to how it can address the gaps identified, including those specifically required by New York’s regulations.
While a risk assessment is in process, you should also assess (or compile) your policies and procedures since this process will require your active engagement from the beginning. Do not simply adopt off the shelf information security policies and procedures without fully understanding how they will apply within your organization. The regulations require that your policies be based on the findings from the risk assessment, so if your firm just adopts form policies without any review or customization, it is effectively documenting non-compliance with the regulation. Again, you should consult experienced third parties with regards to crafting such policies.
The areas that your policies will need to cover include:
Once you have established your course of action as set forth above, you should reach out to NYSDFS and advise that your compliance certification will be delayed but you are taking the above actions (excepting blame deflection) to correct.
Having managed to correct this one lapse, make sure to keep an eye on the forthcoming regulatory timelines. Implementation of controls respecting audit trails, data retention, data encryption, application security and user monitoring is required by September 3rd of this year. By March of next year, covered firms will need to certify that they have implemented a Vendor Risk Management program.
In February, 2015, HLC’s “The Convergence of AML and Cybersecurity” post noted “customer activity that may be a possible basis for a Suspicious Activity Report (SARs) should also be viewed as a potential information security breach…similarly, a detected cybersecurity breach may be the first indicator of a financial crime.”
In October, 2016, Department of Treasury’s Financial Crimes Enforcement Network (FINCEN) published an advisory (the “October Advisory”) directing financial institutions to start reporting “cyber-enabled crime and cyber-events” through SARs, making the reporting of those connections mandatory. With regards to cyber-enabled crime, the October Advisory effectively restates the existing requirement. SAR statistics for the securities and futures industry for the first two months following its release don’t suggest any attributable change in reporting behavior. The significance of the “cyber-enabled crime” restatement for firms is its guidance on what cyber-crime related data must be included in the SAR. Of course, there is the broadening of the reporting requirement to include “cyber-events” which is the focus of this piece.
The inclusion of the “cyber-event” reporting requirement was largely without prior notice, which is notable as it includes events that do not directly impact financial transactions. While an e-mail compromise advisory issued in early September (the “September Advisory”) pushed out the interpretative edges of reportable e-mail compromise attempts, the industry was not given a deadline to work towards as they are accustomed to receiving from FINRA and SEC. In fact, even FINCEN’s own reporting structure has not adapted to the new requirement. Reporting financial institutions will generally need to report “cyber-events” under the “Other” sub-category for “Other Suspicious Activity.” This structure makes it hard to determine whether the uptick in the “Other” reporting activity during the first two months following the October Advisory is attributable to increased reporting of “cyber-events” or other factors, particularly since neither month represents a high-water mark for “Other” SAR reports.
Irrespective of the readiness of the securities and futures industry for this requirement, it is here. Registered Investment Advisors do not have SAR reporting obligations yet, although proposed rulemaking aims to change that.
What Is A Cyber-Event?
The October Advisory defines a cyber-event as “an attempt to gain unauthorized access to electronic systems, services, resources or information” and further, “if a financial institution knows, suspects, or has reason to suspect that a cyber-event was intended, in whole or in part, to conduct, facilitate, or affect a transaction or a series of transactions, it should be considered part of an attempt to conduct a suspicious transaction or series of transactions.” This is a broad construction of “attempt.” To ensure clarity, both the October Advisory and the related FAQs state that the reporting obligation extends regardless of whether the attempt was successful. Further, the monetary threshold for SARs is largely inapplicable as a limiting factor as financial institutions must consider in aggregate the funds “involved in or put at risk” by the cyber security event.
Reporting Scope and Implementation
At a SIFMA AML conference on February 8th and 9th, FINCEN confirmed that “pinging” was not considered a cyber-event, suggesting that untargeted attacks were not reportable. In the FAQ, this was referred to as scanning and probing of networks. While FINCEN did not clarify whether an untargeted phishing email (an email designed to trick the recipient into taking an unauthorized action, such as exposing data or systems) constitutes a probe or scan, the September Advisory suggests that FINCEN is focused on emails demonstrating evidence of social engineering (i.e., the sender researched its recipient to lend credibility to its email and its illegitimate purpose), such as information relating specifically to the recipient, the recipient’s business or the recipient’s personal and/or professional network, including relationships related to such network such as commercial customers, executives or suppliers. Both regulators and industry panelists at the conference, however, affirmed that financial institutions should broadly interpret what constitutes an “attempt to gain unauthorized access.”
The October Advisory and related FAQs also stated that firms are “required to file complete and accurate reports that incorporate all relevant information available” including “information that describes the technical details of electronic activity and behavior.” The FAQ’s break out five categories of information including source and destination information, file information, subject user names, system modifications and involved account information. Complying with this requirement will force firms to adopt new processes to collect and integrate such data into their SARs reports. The need for such specificity is ironic for a SAR report that is sub-classified as “Other” under an “Other” category.
Recognizing that the reporting process could be a burden to many firms, FINCEN does permit financial institutions that are subject to “large numbers of cyber-events” to report them through “a single cumulative SAR filing when such events are similar in nature” or “are believed to be related, connected or part of a larger scheme.” This effectively reduces the number of filings, but still requires one larger filing.
Readiness and Exposure
Based on preliminary data, it appears that the securities industry was not ready for this requirement. To date, a handful of large retail firms have dominated SAR reporting and perhaps are further along in their processes. With the new cyber-event reporting requirement, however, the rest of the securities industry will become a larger component of SAR filings over time. Along the path to getting there, firms (and possibly RIAs) that are not prepared or particularly focused on the new cyber-event SAR requirement will be cited and fined. As noted my recent “AML and Microcaps: New Challenges, New Solutions” post, last year the SEC published an enforcement against a broker solely in connection with their failure to file SARs. As part of its Examination Priorities for 2017, the SEC has indicated that they will “continue to assess broker-dealers’ compliance with SAR requirements and the timeliness and completeness of SARs filed.”
The SEC, however, is not the only regulator focused on SAR filings…FINCEN’s October Advisory (and SAR reporting requirements generally) will be enforced in different ways by a number of financial regulators (e.g. SEC, FINRA, OCC, CFTC, NFA). Further, cyber events are auditable from system log files and, like any reporting violation, intent does not need to be proven; violations are binary.
Firms need to identify whom in AML has cyber event reporting responsibility and ensure that they are receiving the requisite information to enable them to file SARs correctly. Moreover, firms need to ensure that SARs incorporate adequate descriptions and are filed on a timely basis. As for investment advisors, they get a pass…for now.
The scope and complexity of both cyber attacks and responses are going to increase. Thus, the regulatory exposure of financial firms due to gaps in their cyber-event reporting processes will also increase.
Despite the additional burdens, we need to be mindful that the purpose to this reporting is to use the data collected to protect financial firms and their customers from cyber-enabled crimes. In the words of an unnamed senior industry executive expressing the nonchalance that many have on cyber security beyond the need to meet regulatory requirements, “Oh yeah, there’s also that.” Perhaps we should just focus on making sure that the industry gets the new requirements...
Last week, the SEC’s Office of Compliance, Examinations and Inspections (“OCIE”) released its third cybersecurity National Examination Program Risk Alert (the “September Alert”) inside of eighteen months, heralding in a second round of cybersecurity sweeps and greater general examination focus on the issue.
Moreover, with these alerts the SEC is effectively developing best practices guidelines for financial services firms and a failure to adhere to them may expose a firm to increased litigation risk as well. The SEC’s focus on the active engagement of boards in the monitoring of information security programs underscores the increasing need for financial services firms, particularly those that hold retail or non-institutional customer accounts, to ensure that cybersecurity expertise is a represented skill set on their boards.
Broadly, the September Alert covers:
• Governance and Risk Assessments
• Access Rights and Controls
• Data Loss Prevention
• Vendor Management
• Incident Response
This piece will address how the SEC’s approach to cybersecurity has evolved since last April’s Risk Alert (the “2014 Alert”) and not cover all the areas raised in that alert. Additionally, the need for documenting compliance is emphasized throughout the September Alert and firms, particularly those that do not have a Chief Information Security Officer, need to be careful that their technology functions (whether outsourced or managed by a CTO/CIO) are adequately documenting their information security prevention and detection practices, in addition to their information security policies and procedures.
Governance and Risk Assessment
Both board level engagement (noted above) and management accountability are newer themes raised in this Alert. Greater emphasis is also placed on a firm’s formal risk assessment process and the weighting of the various risks identified therein. Vulnerability scans and penetration testing are also, and rightfully, a recurring SEC theme.
Access Rights and Controls
The SEC has broadened its focus from customer access in the 2014 Alert to internal as well as external access controls. The SEC is fairly prescriptive here respecting the auditable data points that firms need to monitor and track, such as changes in access rights resulting from terminations of service or changing roles, as well as tracking how long it takes for such changes to be adjusted thereafter. Access requests, even password resets, must occur in accordance with defined and monitored processes. Moreover, the SEC anticipates that firms will have the ability to track breaches or attempted breaches of data access rights, particularly those relating to confidential information, by developing network behavior baselines that are monitored for anomalies.
The SEC has shifted its lexicon from “authentication” to “multi-factor authentication” respecting access controls. Further, firms will need to have a risk assessment process for determining which systems do and do not require multi-factor authentication. What’s next, exponential authentication? Maybe, consider biochronometrics .
The SEC also raises the need for firms to consider implementing a Mobile Device Policy and justify its decision if it does not implement one. This policy, to the extent not addressed elsewhere, will need to address encryption, access controls, tracking, acceptable use, as well as deactivation of mobile devices.
With regards to responding to customer issues, the SEC appears to be moving away from an expectation that firms will have policies for addressing cyberattack loss responsibilities and toward expecting firms to retain and log their response to customer complaints. Both alerts focus on cybersecurity insurance and it seems apparent that many firms, particularly those who hold non-institutional accounts, are effectively required to either contract for cybersecurity insurance coverage or self-insure.
Data Loss Prevention
In the summary of this section, OCIE leads with patch management and configuration policies. The failure of firms to implement sufficient controls in these areas will be easy for examiners to identify and cite firms for. Additionally, such failures are a clear signal to examiners that a firm’s enforcement of information security policies is deficient.
Notably, both in the summary and the appendix to the September Alert, the SEC has pivoted their focus away from the protection of systems towards the protection of data. This does not mean that system protection is not important, but rather that the SEC is recognizing than even secure systems will experience unidentified vulnerabilities that can impact sensitive data and therefore, firms need to contemplate such failures in devising their preventative and detective controls. The importance of this point is highlighted throughout the September Alert, particularly with regards to the need to implement controls to detect and respond to the exfiltration and unauthorized distribution of data.
Data classifications, the mapping of such classifications across internal and external systems and the assessment of risks in making such classifications, are all raised as expected data loss prevention controls and highlight the need for heightened understanding of the firm’s security controls surrounding data processing.
Vendor Management and Training
Both the 2014 Alert and the September Alert focused on due diligence, contractual requirements and monitoring of vendors. New to the September Alert are requests for any information security risk assessments that a firm’s vendors have performed; performance statistics and any other reports provided by vendors handling sensitive information; and the change management program respecting changes that could have a security impact on the firm or the firm’s sensitive data. Further, the SEC requests information related to a firm’s contingency plans for those vendors providing services linked to the security of sensitive data.
Many of the same themes raised in the 2014 Alert with regards to training are raised in the September Alert. This continues to be an important area, as even secure systems fall victim to inadvertent breaches caused by staff members.
In the 2014 Alert, the SEC focused on incident detection, response and remediation. The current alert also focuses on these points but puts a finer point on monitoring for the loss of sensitive information (as noted above) as well as on regular testing of the incident response plan (much like firms might test their business continuity plans). Specifically, firms should consider engaging in table top exercises that involve vendors as well as internal staff. Equally important is extending this testing to the identification of the incident’s causes, including what logs and alerts will be reviewed.
This will not be the last risk alert relating to information security and is indicative of an increased focus that financial regulators will continue to have on systems compliance and integrity generally. Whether or not they are adequately prepared at the moment, technology risk is a rapidly growing area for financial regulators and their approach to information security will inform the regulatory approach of regulators respecting technology risk for years to come.
On February 2nd, the SEC, FINRA and the North American Securities Administrators Association (NASAA) all released cybersecurity reports and alerts.
The SEC and NASAA alerts provided valuable benchmarks for brokers and investment advisers with regards to cybersecurity practices. FINRA’s report provided both benchmarks as well as deeper coverage of the kinds of controls that their members should be contemplating, many of which have been addressed in my prior blogs, articles and white paper.
FINRA’s report on cybersecurity included a case study reference relating to AML, an oft neglected component of cybersecurity discussions. Although cybersecurity typically focuses on the protection of a potential target’s systems, the attack supply chain generally also includes an enabler. Where the purpose of the cyber-attack is U.S. market manipulation, that enabler will be a U.S. regulated entity. The enabler may also help cyber criminals move funds to other institutions in foreign jurisdictions with weaker compliance standards.
In their case study reference, FINRA summarized two AML-related actions. Both actions involved the opening of accounts for higher risk foreign customers. In both cases, those customers then engaged in a pattern of fraudulent trading whereby they would hack into customer accounts at other broker-dealers and trade in a manner (usually involving thinly traded securities) designed to benefit their own accounts and harm the accounts that they hacked into. For example, one customer engaged in a “pump and dump” scheme whereby they would buy shares, then cause the accounts they hacked into to purchase those shares before selling out their shares for a profit. FINRA found, in both cases, that the firms that opened the cyber criminals’ accounts did not have: (i) AML policies and procedures adequately tailored to the firm’s business in order to detect and report suspicious activity; or (ii) a reasonably designed customer identification program.
AML has been a priority for FINRA absent cybersecurity for some time. For example, in their 2015 Regulatory and Examinations Priorities Letter, FINRA cited reaffirmed AML as a priority and noted that they would be increasingly focused upon: (i) the adequacy of a firm’s processes to identify suspicious transfers to and from cash management accounts and to verify the purpose of the activity in these accounts; and (ii) the monitoring of DVP/RVP accounts for suspicious transfer as well as whether adequate due diligence is occurring respecting registration of securities. The market manipulation that occurred in the cited case studies above is just one of FINRA’s major concerns, the primary others being microcap fraud and insider trading. Nonetheless the seriousness with which FINRA views violations of AML has implications for firms that enable cyber criminals, even inadvertently.
The SEC and FINRA are taking AML violations very seriously. One year ago, FINRA levied an $8,000,000 fine against Brown Brothers Harriman and suspended their AML compliance officer despite his having established an AML oversight practice and warning his superiors about the problematic activity. The SEC recently fined Oppenheimer $20,000,000 for AML violations. While both actions related to the trading of unregistered securities, both were cases in which the firms’ failures to act as “gatekeepers” to identify bad actors resulted in substantial penalties and reputational damage under current AML regulation.
In light of the threat of inadvertently becoming an enabler of cyber criminals, the AML due diligence processes should incorporate searches for whether the prospective customer and associated persons have been linked to hackers or cyber-attacks, particularly higher risk prospects. Such searches should leverage the information sources that a firm’s cybersecurity function uses. In addition, the monitoring of transactions of riskier customers needs to be adjusted accordingly. For example, a hacker with control of multiple accounts has greater control of the timing of the transactions that damage its victims and thus can more rapidly cause a spike in the price of a security. Thus, on boarding and transaction supervision needs to be adjusted accordingly.
The importance of AML to cybersecurity and vice versa goes beyond preventing cyber criminals from opening accounts or limiting their activities within an account. The first indicators of either an information security breach, suspicious transaction(s) or funds movement(s) can provide valuable information to each function. Customer activity that may be a possible basis for a Suspicious Activity Report (SARS) should be also viewed as a potential information breach. Such activity may be the first indicator of a hacked account and instantly relevant from a cybersecurity perspective. Similarly, a detected cybersecurity breach may be the first indicator of or otherwise relevant to a financial crime from the perspective of an AML compliance officer. For example, during a distributed denial of service (DDOS) attack on a system (where cyber attackers effectively bombard a system with the attacks, often to distract from another more nefarious purpose) the AML function should be on heightened alert as to other suspicious activity relating to customer and even firm accounts. This argues for cooperation respecting incident detection, as well as on boarding clients, across the functions.
AML has been an established function across financial firms for a longer period of time than cybersecurity has. It generally resides within the general compliance function or its own separate function. Information security, on the other hand, is usually initially viewed as residing within the technology and/or security functions, although typically with a layer of compliance oversight in regulated firms. A firm’s compliance office is thus clearly best positioned to facilitate greater coordination between these two functions. In short, facilitating greater coordination across these two functions is a cost effective measure that will yield an improved information security and AML environment.
As in past years, the SEC and FINRA (as well as other regulators) released their examination priorities for 2015 in early January. Compliance and legal professionals can now pore over the language of these priorities to assess where their firms need to focus in the coming year. While there may be more than one candidate for top honors, cybersecurity has emerged as an area that will receive increased scrutiny from regulators in the year ahead.
SEC Examination Priorities
To understand what has changed, we can look back to the priorities published in 2014. When the SEC’s Office of Compliance, Inspections and Examinations (OCIE) published its National Exam Program Examination Priorities 2014, it listed “Technology” as a National Examination Priority (NEP) initiative. Within the description of “Technology” it merely listed “information security” as an area that would continue to be examined. Their focus, however, increased just a couple of months later after the SEC sponsored a Cybersecurity Roundtable. Within a couple of weeks following the Cybersecurity Roundtable, the SEC published its “OCIE Cybersecurity Initiative” NEP Risk Alert that included a sample request for information that OCIE might use in conducting information security examinations of an initial group of 50 registered brokers and investment advisers. In the months that followed, investment adviser clients reported that these examinations had indeed extended beyond the initial group.
Given this backdrop and the prevalence of high profile cybersecurity breaches in the news (including, of course, the cybersecurity breach experienced by JP Morgan in October of last year), it is unsurprising that cybersecurity is more heavily emphasized in the National Exam Program Examination Priorities 2015. This year, OCIE listed “Cybersecurity” as one of four market wide risks that it will focus on in the year ahead. OCIE notes that transfer agents should also expect examinations to focus more on cybersecurity as well.
FINRA Examination Priorities
FINRA, in their 2014 Regulatory and Examination Priorities Letter, listed “Cybersecurity” as its own category. In that letter, FINRA noted that their “primary focus” was the “integrity of firms’ policies, procedures, and controls to protect sensitive customer data.” FINRA was non-committal as to how and if cybersecurity would factor into its examinations and investigations. Within the month, however, FINRA initiated a sweep of a number of brokers and published its request letter (see my earlier blog, Significant Developments In Cyber-Security and Their Impact on the Financial Services Industry). Further, late last year, FINRA began hiring examiners with technology expertise with the purpose of intensifying its scrutiny of brokers’ cybersecurity practices in 2015.
As anticipated, FINRA’s 2015 Regulatory and Examinations Priorities Letter makes clear what was not in 2014. The first sentence under its “Cybersecurity” listing states “FINRA examiners will review firms’ approaches to cybersecurity risk management.” FINRA goes on to note that they will be providing more guidance in the first half of this year as to how firms should proceed, specifically with respect to “the use of frameworks and standards, the role of risk assessments, the identification of critical assets, and the implementation of controls to protect those assets based on the scale and business model of the firm” (for a more detailed discussion of these areas, readers should download Information Security Risks: Internal Systems, Vendors, and The Cloud , a white paper published by Hess Legal Counsel and Aponix in September of last year). Notably, FINRA focuses on the ability of broker dealers to comply with books and records retention requirements under Rule 17a-4(f), promulgated pursuant to the Exchange Act, in the event of a cyber attack. Rule 17a-4(f) addresses the WORM (write once, read many) requirements that brokers must adhere to with respect to electronic storage of its books and records.
Immediately following FINRA’s listing of cybersecurity as a priority, FINRA listed “Outsourcing” which is a new examination priority. FINRA notes that their examinations will specifically address what the broker is doing to ensure their vendor’s compliance with securities laws and rules that the broker is responsible for. Moreover, FINRA states that it will be focusing on the due diligence and risk assessment that its members undertake with regards to their service providers, as well as supervision of these providers. Given the exposure that firms have to information security threats through outsourcing, the placement of this risk after cybersecurity cannot be accidental. Irrespective, firms need to consider outsourcing risks as part of their information security program.
The Implications of Reg SCI for Non-SCI Entities
Late 2014 also saw the adoption of Regulation Systems Compliance and Integrity (Reg SCI), a regulation designed to require certain critically important firms to implement comprehensive policies and procedures for critical technology systems. While the regulation only covers a limited group of 44 entities that are largely exchanges, certain ATS’s and clearing firms, the SEC noted in its release that it might consider broadening the scope of the regulation to other categories of market participants such as “non-ATS broker dealers, security-based swap dealers, investment advisers, investment companies, transfer agents and other key market participants.” As a practical matter, I don’t foresee Reg SCI ever becoming an issue for most broker dealers, investment advisers or investment companies. With that said, however, the SEC is clearly signaling that broader regulation of the technology of regulated financial entities is a real possibility. In addition, the SEC is currently advancing measures that would require publicly owned companies to disclose more information about their cybersecurity vulnerabilities and, at the very least, I believe we can anticipate that the SEC and/or FINRA will eventually require greater disclosure from regulated financial entities respecting their cybersecurity vulnerabilities.
While larger firms have already implemented information security programs, many small and mid-size shops are neither sufficiently prepared for a cybersecurity breach nor the questions that the examiners will be asking them in the months and years to come. With the regulators being so explicit about their intent to scrutinize this area, compliance and legal professionals in all firms should recognize that they can no longer wait on specific legislation to compel their response. Their firms will have to answer to the regulators, whether as part of their examination process or a known breach, respecting their information security programs.
In late June, BAE Systems revealed that it had stopped an ongoing cybercrime whereby cybercriminals had installed a malicious computer program on the servers of a large hedge fund, crippling its high-speed trading strategy and sending information about its trades to unknown offsite computers.
While BAE Systems’ claims were later revealed by the Department of Homeland Security to have been a hoax intended to drum up business (the executive who made the claims in a televised interview is apparently “taking some time away from the business”), the scenario contemplated and threats represented highlight the evolving sophistication of cybercriminals over the past few years. Consider also that financial firms aren’t eager to publicize, particularly to the general media, that they have been victimized by cybercrime due to loss of investor and client confidence, litigation risk, and reputational damage…even through a third party like BAE Systems.
The primary threats that cyber attackers pose and have posed for a number of years have been identity theft and/or system disruption. Identity theft typically involves breaching or intercepting systems containing or receiving sensitive data which the attacker could use to access funds or more sensitive information. A system disruption might be used to create the security breach that enabled such information to be compromised or alternatively, to damage the network or organization. The primary thread in both of these threats is that the attack occurs at a time proximate to the breach or attempted breach.
The “Advanced Persistent Threat” or “APT” is a term used to describe a newer, more pernicious, threat wherein an unauthorized person gains access to a network and stays there undetected for a long period of time. Once inside the network, the attacker infects a number of the target’s systems and hijacks one of target’s servers to act as its “command and control” server to feed information back to the cyber-criminal for further analysis. Through gathering this information, the cyber-criminal is able to further explore the system’s vulnerabilities and penetrate with additional malware customized to the target’s processes. The goal of the cyber-criminal is not to disrupt the systems of the organization…in fact, they are very interested in keeping them up and running, perhaps even protecting the organization from other security breaches. The goal of the cybercriminal in this case, is to remain undetected within the organization’s systems for an extended period of time so that it can continue to benefit from the information it is gathering. Lastly, once an APT is detected, it may not be simply enough to remediate the issue on the identified and impacted server or network component as the APT may have entrenched itself in multiple components of a target’s systems and simply alter its activities as necessary to continue to operate within the network. Such a threat is a threat to the business processes of any organization and should be of grave concern to any financial services organization. So, instead of the criminal breaking into your house to vandalize or steal your valuables then endeavoring to leave unnoticed, the criminal is now taking up residence in your house, observing your daily activities and choosing his opportunities to take advantage of when you expose yourself through your routines.
In the case of BAE System, the hedge fund was apparently sophisticated enough to program their own algorithms, deploy a proprietary OMS and use internal IT to determine improper file transfers. Perhaps enhancements to their information security program could have prevented the breach or enabled them to detect their vulnerabilities sooner. On the other hand, there is a limit to what an organization can and should do to protect itself from such risks. Any information security program must prioritize protections and responses for the greatest enterprise risks first and even then, eliminating all vulnerabilities associated with such priorities might be too costly in terms of resources expended and the impact on other business operations. I often note in my presentations on cybersecurity that it is not a question of if you are going to be breached, it is merely a question of when. Nonetheless, organizations without the capabilities of BAE’s hedge fund client or, even more so, a best practices approach to cybersecurity, may be exposed more frequently, for longer periods and be slower to react to such breaches.
In a blog I wrote respecting cyber security a couple of months ago (Significant Developments in Cyber-Security and Their Impact on the Financial Services Industry), I concluded with a six point high level outline for addressing cyber security threats within your organization. The first step was to assess the risks within your organization. Part of that assessment must include mapping of the systems and processes within your organization that handle confidential and sensitive information. That assessment must include not only internal systems and processes, but dependencies that your organization has on third party providers. Armed with that map (and hopefully, an ongoing process for keeping it up to date), an organization should prioritize in accordance with its greatest risks and then ensure that it has the resources to tackle the task of building a program, filling any gaps in its capabilities, testing and monitoring the program and ensuring organizational buy-in. It is important to emphasize that the risks identified with regards to your third party providers will require a different approach and there may be a tendency to naturally focus more on what the organization has within its immediate control, irrespective of priority. That is a mistake.
By way of example, the vast majority of advisers, brokers and funds deploy third party order management systems(OMS’s) to access a myriad of trading venues as the basic business of trading venue connectivity and reconciling FIX messaging can often be an inefficient use of resources. What if, however, the cyber criminals that attacked BAE’s client had instead infiltrated the systems of its third party OMS provider? Perhaps the OMS provider had a large number of investment adviser, hedge fund or broker clients and, over a series of months, found ways to trade ahead of those clients, but not so much that any of them noticed. How would IT personnel within each of those clients gain the requisite visibility to determine that something was going on? Moreover, how would the broker dealer, investment adviser or fund know whether their provider had adequate security measures with unless they were able to verify the efficacy of such measures on an ongoing basis? Many advisers, brokers and funds shy away from such questions because either they assume that there is safety in the masses, that other clients will address these issues for them or that they are not big enough to get any meaningful response. Worse still is the self-serving assumption that their third party provider will be properly motivated to incorporate all the necessary controls as part of the license fee the client already pays.
Years before I worked to deploy a best practices information security program in my role as a General Counsel for an exchange under the watchful eye of the SEC, I worked with a number of OMS providers on security issues, largely on a re-active basis. Back then, the terms “information security” and “cyber attack” were not standard terms in everyone’s lexicon and our response was to fix the “bug.” In one instance, an employee of a customer who had administrative access to their licensed OMS discovered the ability to view the trades of a number of other customers by logging in as a “Super User.” By accident, the OMS provider had replicated a security access profile across all customers on the server that effectively treated all customers on that server as a separate office of the same company. I also discovered that “fix the bug” did not mean that there had been a comprehensive undertaking to assess whether other servers were similarly affected. Scattered SAS 70 requests from customers, not even specifically related to security, were seen as necessary evils but our initial responses to such requests were “no one else is requesting that” or “this is how everyone does it” and this usually sufficed to disarm the requester. ..and this point isn’t reserved just for OMS providers. Simply put, organizations cannot afford to be naïve about the threat to their organization and processes when it comes to their most sensitive information. Put another way, don’t wait for your assumptions to be dismantled by a breach to wake to the potential threats that cyber criminals pose to your organization.
Organizations need to rethink the way they approach vendor risk management in light of the today’s cybersecurity threats. Simply hiring a contract lawyer to incorporate security clauses into your contract (although I don’t want to minimize the importance of that) may not sufficiently address the risk to your organization. If your or your clients’ confidential or sensitive information is being processed by a third party provider, your lawyer either must be sophisticated in assessing the information security processes and procedures that your vendor employs and/or must be working alongside a technology adviser who can perform such an assessment. Further, having liability provisions built into your contract is meaningless (or at least in the context of breach with significant ramifications for your business) if your provider does not have the ability to absorb such a cost. This touches on a related point, which I will cover in a future blog, respecting the need to consider requiring insurance for information security breaches for your vendor (and your own organization as well for that matter).
Ultimately what is required is that your organization: exercise the requisite due diligence with your third party providers handling confidential or sensitive information, develop a more fulsome understanding of your third party provider’s information security practices and how such practices tie into yours. This means an initial technology risk assessment and an ongoing process for monitoring such risk on a periodic (presumably, annual) basis.
Lastly, make sure that you have an understanding with your vendor respecting what they must do in the event of the inevitable breach. This should flow from your organization’s obligations either under contract, law or your own policies and procedures in the event of such a breach, particularly under state law if third party personally identifiable information (PII) is involved. If PII is involved, the last thing you want to address following a breach is your vendor’s inadequate or non-existent forensic analysis when the clock is ticking on your legally mandated notification that will have significant ramifications on your client base, reputation, and ability to manage the breach, never mind the litigation risk involved.
The growing sophistication of cyber criminals presents increasing risks to the financial services industry. The vast majority of financial services organizations will experience one or multiple cyber security breaches during its existence; many of those will initially be undetected. Organizations must continue to adapt to the risks of this ever evolving menace and we all need to become more literate in the risks presented, as well as the methods for prevention and response.