Scenario On Boarding Customers at Foremost Global Financial Group - mccright/FCCSCybersecurityInput GitHub Wiki

Scenario #1: On-Boarding Customers at 'Foremost Global Financial Group' (FGFG)

  • Foremost is a global financial services enterprise.

  • FGFG provides organizations and individuals investment, insurance, retirement products and services.

  • FGFG maintains a global customer base.

  • Our scenario is associated with their retirement services division (FRS).

  • Retirement products and services are regulated by national & state governments.

  • The retirement products and services is competitive & evolving rapidly. Providers are driven to reduce internal/operational expenses while at the same time providing positive interactions with covered employees at every contact point (browser, mobile device, phone, and surface mail).

  • Employers contract with FRS on behalf of their employees.

  • Employees may get a range of retirement investment opportunities -- generally FRS customers choose to enable a default monthly contribution from & for each employee. Employees would need to opt-out if that was their desire. Therefore, most employee's FRS accounts tend to accumulate money.

  • In the process, employers share a collection of demographic information about each of their employees.

  • The nature of that data also makes this business the target of national & state privacy/data security laws and regulations.

  • In financial services, it is critically important to link only the authorized individual(s) to any given account, and to maintain strong resistance to granting anyone else access to that account.

  • Because it is impossible to 'know' the party on the other end of any Internet-enabled interaction, the initial customer 'on-boarding' process can be a high-risk interaction in some business contexts.

FRS uses the employer-supplied demographic data to help identify given individuals when they initially point their browser at the FRS web site or download the FRS mobile app, and traverse a 'question-answer' on-boarding process to establish a new FGFG identity and link that new identity to their pre-established retirement account.

FRS provides 401(k) services to thousands of companies and millions of employees. While every company is unique, the life-cycle of any given employee's relationship with FRS tends to fall along a number of continuums. For example:

    Engaged <-----------------------------------> Disengaged  
    Financial planner <-------------------------> Not a planner  
    Tech savvy <--------------------------------> Tech challenged

Tech savvy, active, engaged, financial planners tend to explore & interact with our platforms as soon as they are available.
As a result, the demographic data about them tends to be accurate, and initial on-boarding into our systems tended to go smoothly and result in relatively safer Internet-facing retirement participant accounts.

Tech challenged, passive, disengaged participants continue living their lives as before. FRS, and retirement in general, remains a vague and distant concept. These participants tend not to interact with FRS systems until some trigger, some life-event that brings new relevance to retirement savings & investing (this could be a financial emergency, starting a family, reaching retirement age, etc.).
As a result, more or less time will pass between our initial employer on-boarding and this employee's initial on-boarding into our systems. During that time, a broad universe of life, employer, and data changes can occur.
Achieving the FRS goal of providing positive interactions with every covered employee at every contact point is a challenge with this group. They have ignored or just missed communications about their retirement plan and how to use FRS services.
FRS expects calls, emails, surface mail, and sometimes chat sessions from this group -- and expects that they will not always go as smoothly because we have not built an active relationship with them.
Regardless of those challenges, FRS is paid fees for this business and possesses the employee's retirement money and owes them excellent service.

ACTORS & COMPONENTS:

Identity data brokers               Contract Quality Assurance  
  
                            Attacker  
  
Authorized End user  
  
FRS web site        FRS call centers        FRS 'back room' employee processes  
  
FRS applications    FGFG applications  
  
FRS data stores    FGFG APIs --> FGFG data stores

Key Infrastructure and Operations Assumptions and Realities:

  • FGFG maintains a number of relatively independent subsidiaries. FGFG provides some 'shared' infrastructure and services across all its subsidiaries. Some of these include identity management, authentication, coarse-grained web application access control, log management, security operations (which includes a certain amount of incident identification, triage, and management), database management, firewalls, data centers, servers.
  • FRS is engaged in a highly competitive and rapidly evolving industry. One of their key metrics is customer/participant sentiment -- 'happier' more satisfied is better.
  • FRS management expects little 'friction' in any retirement product/service customer interaction and 'exemplary' ease-of-use for all customer-facing systems. At the time of this scenario, new retirement customer/participant on-boarding identification depended on the customer knowing their full name, tax ID, their company name, their phone number, and their mother's maiden name.
  • FRS applications are integration in a way that requires the FGFG authentication infrastructure prompt new users (users who don't currently have an identity established in the FGFG enterprise systems) for one or another new customer on-boarding application.
  • FGFG enterprise web authentication infrastructure includes top-tier endpoint finger-printing & geolocation capabilities, and can infer user patterns of access. The system also enables enterprises to create policies that use this data to describe expected versus unexpected patterns of activity and policy violations can initiate alarms or other actions. FGFG has 'tuned' this system to be 'friendly' to customers and to generate few alarms (alarms result in investigations, which consume resources).
  • FRS call center representatives are incented to complete calls quickly and to have them result in positive caller responses (FRS does customer follow-up surveys). In addition, representatives also receive calls from individuals having a broad spectrum of cultural & educational backgrounds -- resulting in a broad range of vocabulary, accents, financial literacy, etc.
  • FRS and FGFG applications, installed on company servers in company data centers, tend to 'trust' inputs coming from 'internal' hosts and tend to omit logic that might detect, log or alarm on potential abuse cases.
  • FRS database management assumes that data is 'cleansed' by applications prior to arrival.

Over time, some passive, disengaged retirement participants leave a trail of temporary, discarded, and forgotton email addresses.
Some also changes phone numbers and plans without informing their employer nor FRS.
Others also move from one street address to another, even one country to another, they may get divorced, add a child to their family with a new partner, and they may speak an Arabic dialect at home and know English as a distant fourth language -- all without updating their employer or FRS.
The name that their employer is known by can also evolve over time.
All of that and more can add material confusion and uncertainty to the initial on-boarding interaction for some individuals.
FRS has evolved their processes to help compensate for the difficulties imposed by characteristics like these in order to maximize efficiency, to on-board the maximum percentage of new employees who need no 'special' handling, and to help ensure that this initial interaction with FRS is a positive one.

Your assignment: What could go wrong?

  • Carefully review the scenario material.
  • Make some assumptions about each of the actors & components in this system and describe likely points of vulnerability.
  • What are the most important vulnerabilities?
  • Propose and describe in some detail an attack against this business.
  • How would you add attack resistance and attack awareness (alerting & alarming) to address the most important of the vulnerabilities in the scenario above.

One Model FUBAR (many are possible):

  • Internet-interactions are mediated by layers of abstraction, technology, distance, time, automation and more.

  • This adds complexity and uncertainty to the FRS participant on-boarding processes.

  • These issues are exaggerated when dealing with one of those 'dormant' retirement accounts (the ones waiting for a disengaged individual to on-board and use FRS systems).

  • In this scenario, assume that a hostile actor decides to attack 'unused' or 'dormant' retirement accounts.

  • Their goal is to extract as many financial assets and as much personal data as is economical while assuming minimum risk.

  • They engage in a certain amount of reconnosance, learning that FGFG web login infrastructure makes it easy to determine whether an individual associated with an FRS account has already worked through their on-boading process, or not.

  • They explore the FRS site to document the new Retirement customer on-boarding process. In doing so, they learn the types of information that new Retirement customers are asked to provide during on-boarding.

  • Knowing the data they need, they buy FRS customer lists and associated demographic data from data brokers. This is not a big investment.

  • They hire contractors in a South East Asian country to 'quality check' the list against FRS systems -- looking for 'useful' accounts, accounts that are not yet associated with a validated identity. The contractors return a vetted subset of the original list.

  • They hire contractors in another Asia Pacific country to 'on-board' the available accounts using the purchased data -- establishing an identity now under the control of the attacker. The contractors return a subset of the previous list containing 'working' username/password pairs, security question/answer pairs, and associated account balances. Because of data inaccuracies & inconsistencies this on-boarding was not always straight foreward and the contractors sometimes had to call FRS 1-800 numbers for on-boarding help.

  • They slowly explore and document the account functionality for given employer groups -- learning that some have different business rules in place for address changes, bank routing number changes, loan amounts, and impediments to making 'whole account' withdrawls.

  • Finally, they quickly order a wide range of loan amounts, one against each account, requesting a check to be sent to an address input in the request form.

  • FRS completed a number of the hostile actor's transactions before one of the 'dormant' retirement account holders called an FRS 1-800 number asking why they received a 'password change' letter in the mail -- which led to an investigation and identification of unauthorized activity on the account (and others).

  • The hostile actors received enough of the requested checks to result in what they considered a useful net profit for the exercise.

  • FRS replaced the lost funds in all the 'hacked' accounts.

  • FRS conducted a thorough investigation of what happened (which was technically challenging because of 'unfriendly' logging practices and a lack of relevant analysis automation).

  • FRS reported the breaches to all relevant parties (individuals, employers, regulators, etc.).

  • FRS employer on-boarding, employee on-boarding, and identity verification processes were re-engineered.

NOTE:

Other common approaches might have incorporated spearphishing (with links or attachments), drive-by compromise, 'hacking' one or more of the FRS web or mobile applications, compromising another FGFG subsidiary application and then exploiting assumptions about trust between different subsidiaries' applications...
FUBAR == "Fouled up beyond recognition."

LEADER RESOURCES:

BSIMM Definitions of Architecture Risk Analysis - Builds an ARA definition by describing a set of increasingly mature risk analysis practices: https://www.bsimm.com/framework/software-security-development-lifecycle/architecture-analysis/
Legacy U.S. CERT Definition & Best Practices Document on Architecture Risk Analysis: https://www.us-cert.gov/bsi/articles/best-practices/architectural-risk-analysis/architectural-risk-analysis
"Threat Modeling Cheat Sheet (OWASP)" https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Threat_Modeling_Cheat_Sheet.md
OWASP Cheatsheet Collection: https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets
OWASP Application Security Verification Standard (ASVS) attempts provides a basis for designing, building, and testing technical application security controls, including architectural concerns, secure development lifecycle, threat modelling, agile security including continuous integration / deployment, serverless, and configuration concerns: https://github.com/OWASP/ASVS
FINANCIAL SERVICES SECTOR CYBERSECURITY PROFILE DOWNLOADS
Financial Services Sector "Cybersecurity Profile:" https://www.fsscc.org/Financial-Sector-Cybersecurity-Profile [280 "diagnostic statements"]