The insiders' edge for 40 Act industry executives!
an InvestmentWires' Publication
Wednesday, December 12, 2018
Are You Adequately Assessing Your Software Vendors For Cybersecurity Risks?
Every chief information officer in the mutual fund industry is no doubt familiar with the guidance on cybersecurity risk issued by the SEC's Office of Compliance Inspections and Examinations and in FINRA's 2018 Regulatory and Examination Priorities Letter. From our perspective as software providers to the mutual fund industry, one of the ways we see CIOs acting on this guidance is by evaluating how their third-party partners might pose potential risks to the sensitive data they are working hard to protect.
Assessing third-party risk is an essential part of every security analysis, from FINRA's Small Firm Cybersecurity Checklist to standards outlined by ISO 27001 and as evaluated under the System and Organizational Controls (SOC) exams conducted by major accounting firms.
So, what does assessing third-party risk actually entail? How do fund companies and broker dealers know if they have adequately and appropriately assessed their risk?
We'd like to share our perspective on those questions, speaking as both a provider to mutual fund companies and as a software developer that, for our own business, relies on some key vendors. We've framed our comments around four key questions that come up regularly in third-party assessments.
Mutual fund CIOs may already be familiar with most or all of the issues we'll note here. But because security requires all users working together — from IT to the back office to customer service — we think it's healthy for all users of mutual-fund software to have a basic understanding of what goes into making systems secure ... or insecure.
Also, we've observed over time that the mutual fund industry is a step or two behind the banking and brokerage industries — not surprisingly, as those are subject to additional layers of regulation. Because our own work involves subaccounting, we are heavily involved with SOC exams and emphasize bank- and brokerage-type security practices such as multi-factor authentication. (Our advice? Donít "turn off" those features!)
Within the mutual fund context, further improvements are of three basic types:
-Unauthorized cash outs
-Trade repudiation risks
-Compromise of corporate or individual retirement portfolio
-Breach of personal banking information
-Breach of beneficiary information
With respect to evaluating your third-party vendors, be sure to stay especially focused on those and other high-level risks you may define. Consider answers to questions from your third-party providers — which may include the four sample questions weíve laid out below — in that risk-specific framework.
Q1: How do you authenticate users? Once authenticated, how do you ensure users see only what they are authorized to see?
Authentication is the process of a person proving his or her identity. Authorization, in turn, refers to what access that particular person should be granted in use of the application. In other words, once users are authenticated in the system, authorization rules determine 1) the data they are allowed to view and 2) the specific actions they are allowed to take regarding that data.
Most security breaches these days relate to failures of authentication — that is, hackers successfully impersonating a legitimate user, not "breaking in" through network vulnerabilities. In addition to enforcing strong passwords, we strengthen authentication protocols through layered security programs and techniques such as multi-factor authentication, advanced device fingerprinting and IP restrictions. Application should also require strong authentication for high-risk transactions within the system. And, of course, suspicious activity needs to be tracked and followed up.
As for authorizations, there are two cardinal rules. First, don't give sensitive-data access to people who don't need it. And second, don't enable users to change their own authorizations. To put these rules into practice, we thoroughly categorize and define all sensitive data. We then create and enforce Access Control Lists (ACLs) that group users together based on what type of data they should be able to access. We ensure reasonable hurdles are in place to adding new users to an ACL or moving a user from one group to another. We make sure no users are added by cloning an existing userís access, and we regularly review user permissions.
Q2: What's your disaster recovery plan? Do you have near real-time failover systems in place?
Disaster recovery planning starts by knowing things will fail. How will users handle a simulated system failure? How quickly can services switch over to an alternate data center? How efficient is data restoration in a simulated data-loss scenario? As we create "what if" scenarios, we assess probability of occurrence, business impact, overall business risk, and mitigation opportunities and strategies. We then evolve disaster recovery tests to match both high-probability events and high-business-impact events.
Simulating both types of scenarios helps minimize turmoil in the event of a real disaster. We require senior staff to participate in simulations and, for all users, regularly introduce low-impact failures into routine events. Then we up the ante by hiring third-party vendors to try to break our systems and force a disaster-recovery response.
Q3: How do you protect data when it is (1) at rest, (2) in transit and (3) in use?
Data needs protecting in all its phases. For example, don't carefully protect data delivery but store unencrypted data on vulnerable network drives!
Q4: Do you have application development policies in place — and do you follow them?
In our case, a secure application development policy is incorporated within our SOC and therefore is audited by external accountants. Software development is highly complex — especially on a multi- faceted product developed by a large team over many years.
It may be difficult for non-developers to evaluate a third-party vendor's application development policy. The following list of basic components may help. Does the policy:
FINRA and the SEC both call for taking a risk-based approach to cybersecurity. In that spirit, we'll close with four brief suggestions that, to us, can help you mitigate some of the highest-risk scenarios faced by mutual fund families. They are:
1. Choose software vendors you have confidence in;
2. Monitor user-access audit trails;
3. Don't turn off higher-security features such as two-factor authentication; and
4. Pay attention to data at rest, in transit and in use.
Prithvi Hariharan serves as chief technology officer for Envision Financial Systems.
Printed from: MFWire.com/story.asp?s=59028
Copyright 2018, InvestmentWires, Inc.
All Rights Reserved