Handbook expanded to cover mobile financial services and their potential threats

Finally, a commitment!

The FFIEC recently issued a new appendix (Appendix E) to its IT Examination Handbook to address mobile financial services (MFS), which cover a wide variety of services from banking institution smartphone applications to third party payment systems such as Apple Pay.

While MFS appear similar to existing computer and internet based services used by financial institutions, and in many cases merely serve as interfaces to existing backend systems, they present new and unique risks that institutions must be aware of.

Examples of MFS provided by Appendix E include:

• Short Message Service (SMS) banking, wherein a customer may use text messaging to get status updates regarding their account or to receive one-time passwords for authentication.
• Mobile-enabled websites, which are variants of the financial institution’s web presence specially formatted for display on smaller devices. Users may need to navigate to these sites directly, or the institution’s site may use code to detect the device being used and display the appropriate version.
• Mobile applications, which are downloadable applications tailored specifically for the device in question, providing a more user-friendly display of data and account services than would be possible with either SMS or a mobile-enabled website.
• Wireless payment technologies, which allow customers to use their smartphones to make payments at point of sale (POS) terminals or to individuals. These technologies may take the form of a unique account specific to the wireless payment service (billed to the user’s mobile carrier or a linked financial institution) or as a “mobile wallet,” where the details of existing physical cards are stored electronically.

It is important to note that while MFS are often seen as entirely new technologies, they tie-in to existing retail payment channels and require an account at a financial institution for funding: they are not an independent means of payment. Rather, MFS are instead an entirely new risk vector for financial institutions, as they provide consumers a new way to access (and potentially disrupt) existing banking systems.

To that end, the FFIEC has identified multiple risk factors for each of the example MFS mentioned above and detailed them in Appendix E, before going on to provide controls that financial institutions can use to mitigate those risks. Because MFS can often require working with entities outside of the financial sector, including mobile carriers and application developers, there may be a lack of knowledge about the compliance requirements facing financial institutions. In addition, consumers may be unaware of the additional risks MFS may present. In both cases, financial institutions may need to work on communicating these risks and requirements as part of their mitigation efforts.

More specifically, the FFIEC suggests general operational controls that institutions should be considering, including:

• Appropriate controls to verify a customer’s identity when enrolling for MFS.
• Appropriate authentication of MFS users once enrolled to prevent fraud, with examples including biometric or out-of-band (e.g. a one-time text verification message if the user is performing an action through a web portal) methods. Additionally the FFIEC suggests MFS not rely on single factor authentication methods entirely.
• Application development life cycle steps including architecture review and threat modeling, secure coding techniques and detailed code analysis. Additionally, institutions should update applications through secure channels and in a timely fashion, and applications should not retain any sensitive consumer data such as user names and passwords.
• Applications should use their own set of login credentials separate from those used to access the device itself, and should automatically log users out after a set period of inactivity.
• Logging and monitoring for all MFS activities which can identify unusual behavior.

In addition to these general operational controls, Appendix E includes suggested controls for the specific types of MFS outlined in the introduction.  For SMS technology, the FFIEC suggests redacting customer information (such as account numbers) due to the inability to encrypt text messages sent via SMS, and also limiting the amount of functionality a customer can access solely via text. Additionally, customers should be made aware of how to avoid phishing messages through SMS.

For mobile-enabled web sites, the FFIEC has a number of suggested controls:

• Customer training on how to identify compromised sites and how to verify they have reached the resource they intended, how to choose a complex password and the proper methods for securing their mobile devices (e.g. auto-wiping devices after a set number of incorrect password attempts).
• Requiring web developers to follow a secure development lifecycle and to follow the guidelines established by the Open Web Application Security Project.
• Detection of the mobile web browser being used to determine whether proper security controls are being implemented, denying use of browsers that do not meet minimum standards.
• A number of mitigating controls for web design to reduce the risk presented by redirect attacks including hard coded URLs, URL verification, whitelisted URLs and frequent vulnerability scans.

Controls for mobile application risk mitigation include:

• Policy enforcement and device fingerprinting tools to prevent application use on insecure operating systems, including deprecated versions and jailbroken/rooted devices. Additionally, methods to depreciate older application versions that no longer meet security requirements.
• Security awareness training for consumers to help them identify insecure application updating techniques (e.g. A link to a website sent via SMS as opposed to using the operating system’s own application store).
• Making sure applications do not store sensitive consumer information, such as credit card numbers, directly on devices unless adequately protected through encryption or storage within a secured space within the device filesystem. Information should be stored by applications only when necessary.
• Securing the backend servers that power the MFS application to prevent unauthorized access.
• Use of online forums, vendor cites and organizations such as US-CERT to maintain awareness of new vulnerabilities, in addition to periodically testing how their MFS works with other mobile services.

The FFIEC also recommends that financial institutions work with mobile payment vendors to minimize potential risks, encouraging the following controls:

• DDoS mitigation (through traffic filtering).
• Use of trusted platform modules when available, secure protocols such as SSL/TLS, tokenization to limit transmission of account information, authentication of both users and applications and encryption whenever possible.

Appendix E goes on to detail ways financial institutions can reduce compliance and reputation risk associated with MFS, including consulting with legal counsel to ensure contracts and disclosure agreements cover the new technologies, and making sure controls are in place concerning the storage and transmission of customer details by MFS.

With more consumers relying on mobile financial services to conduct their business and more financial institutions integrating them into their portfolio of services it is well worth the time of your security team to look into the changes presented by this new appendix.