MutualFundWire.com: Are You Adequately Assessing Your Software Vendors For Cybersecurity Risks?
MutualFundWire.com
   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:

  • Basic best practices common to all industries. These typically include basics such as firewalls, routers, access control lists, comprehensive authentication and authorization mechanisms and strong password requirements, to name a few.


  • Risks specific to financial services. The threat matrix for a retail service like Amazon is quite different than that for a financial services firm. Financial trading and related business scenarios bring risks that require, at minimum, a basic threat matrix developed with business stakeholder inputs. This process yields a summary business risk view that all executives should know and understand.


  • Risks specific to mutual funds. Taking a structured risk management approach means focusing your efforts on your actual risks. Mutual funds should target risk-mitigation activities based on the probability and business costs of each risk. Each security investment needs to be commensurate with each calculated risk and the aggregation of related risks. In the mutual fund industry, the highest-level risks include:

    • -Unauthorized cash outs
    -Unauthorized trades
    -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!

  • Data at rest: Data at rest refers to all data residing across multiple devices over a period of time. This also includes copies of backups that may be stored on external devices or offsite on the cloud. Keeping track of data at rest across multiple devices is the first step towards protecting it. Protecting data often involves a multi-layer strategy using physical and logical access controls. The files and content themselves need to be encrypted. It is important to stay current on encryption methods. Some encryption algorithms deemed effective only a few years ago are no longer secure.


  • Data in transit: Data in transit refers to the data that is typically transmitted between networks, is in motion within a network or ready to be processed within devices on the network. Examples of data in motion includes file transfers, emails and communication between various tiers of an application. Encryption of data and usage of encrypted connections for data transmissions are typical ways organization protect data in transit. Some of the examples of encrypting the connections include SSL, HTTPS and TLS.


  • Data in use: Data in use refers to the data currently being added, viewed, updated or deleted by the application and its users. Drive your system providers to mask sensitive fields in views. Ensure that the application follows the principle of "least privilege" — that is, ensuring a user has access to nothing more than is needed to fulfill that user's role.


    • 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:

  • Define each software module and assign a risk ranking to each one?

  • Delineate how people in different roles should contribute to development? Examples include business analyst, developer, architect, quality control engineer.

  • Prescribe using recommended versions of certified open-sourced software?

  • Call for vendor analysis, including support offered and business stability?

  • Incorporate third-party application security testing — both dynamic and static — to identify vulnerabilities in the code?

    • Closing Thoughts


    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
    Back to Top