Mobile Banking Malware: Protect Your Finances

Mark Lucas, Vice President, Chief Information Security Officer, Coalfire

The prolific rise in smartphones, tablets and other portable devices has greatly expanded the ways in which we interact with personal and professional services. The public can now singlehandedly use their mobile device to pay for things with the ease of flashing their cell phone. Unfortunately, this rapid expansion of convenience and service also expands the threats.

Increased Threat to Banking Systems from Mobile Applications and Platforms

This threat has continued to grow as more banks and financial institutions begin to implement mobile banking. The FFIEC was concerned enough about this issue last summer and released a security bulletin warning financial institutions of the increased threats to the banking system from mobile applications and platforms. While this bulletin has been much discussed in financial services security circles, it is important to revisit the important points of this letter and understand some additional key activities that institutions should perform. Below are some important activities that each institution should perform before engaging in mobile banking:

  1. As the FFIEC identified last summer, the most important activity any financial institution can perform to address these issues is a strong risk assessment… with a caveat: The way in which you have traditionally completed your risk assessment may not be good enough. With mobile platforms, you are dealing with an entirely new threat vector that most organizations have not incorporated into their analysis. It is highly recommended to begin by reviewing your threat analysis processes within your risk assessment and ensuring that these processes identify specifically the threat agents and threat actions that can be conducted within a mobile environment. Update if necessary. The more detailed your threat analysis is within your risk assessment, the more detailed (and focused) your risk assessment findings will be- especially in the areas where you see the most detailed threats.

  2. Staying within the risk assessment process, how well does your organization understand the ways in which mobile applications interface with your core processing systems? A detailed threat analysis is vital, but will only take you so far if you don't understand the precise applications, services, and interactions that are taking place between the mobile client and your core. Map these out in detail and ensure that your threat analysis examines these assets accordingly.

  3. With better threat analysis and an understanding of the involved assets you should be capable of creating a more refined risk assessment that brings the security shadows of mobile banking into the light. Understand that the likelihood of these risks are apt to be high- perhaps higher than risks associated with traditional online banking. After all, hackers and attackers will go after the weakest link. If that link is your mobile banking tools, you can be sure to see some malicious activity focused there.

Security Management in the Short-Term

All institutions participating with mobile banking should complete the above tips. However, because of the time involved with the above tips and the work required, if you have already jumped into the mobile ebanking market, it is still important to manage your security in the short-term, until further steps can be taken. Better risk analysis process will help you in the long run, but in the short-term there are some immediate activities you can conduct:

  1. Verify that the author of your mobile banking tools has conducted an independent audit or controls assessment of their mobile ebanking tools. For most, this necessarily requires an examination of the mobile application in a lab setting and reviewing critical controls (like the security of data stored on the local client, client authentication methods, data transmission security, etc). This is not a new process. Applications accepting or processing credit card payments must be assessed by a qualified, independent examiner (PA-DSS) in order to sell their software products. See what controls your vendor has "baked" into their software and if these controls have been audited.

  2. Make sure your mobile ebanking clients require two factor authentication for account access and additional authentication for EFTs or wire transfers. This is just good practice. You have to assume that mobile devices will be exposed to unauthorized individuals (they will be lost, stolen, or left unattended). Saving user passwords or permitting unauthenticated EFTs is a recipe for disaster- it's only a matter of time before the first customer comes to you with an issue.

  3. Ensure that only mobile ebanking clients certified to work with your core can work with your core. All third-and fourth-party software technology interacting with your core systems need to be formally certified (and individually identified) by your core vendor. This is especially troublesome for financial institutions that provide ebanking web services (APIs) or mobile websites. Third-party software agents can build client software that "wraps around" these services and presents your ebanking services within their own code. Work with your core or mobile e-banking solution provider to understand what you can do to control these relationships.

The realm of mobile ebanking is an exciting and fascinating new trend, but like all things new, it still needs time to solidify its role in the marketplace. The good news is that the altogether new industry can, with the right steps put in place, prove to be extremely influential to both consumers and institutions alike. As this new trend shifts into high gear, the demand for security within such technology will also grow- along with those who will try to interfere with it. By taking the appropriate steps from the very beginning you can assure that your ebanking will be less vulnerable to risks.

Mark Lucas


Mark Lucas — Vice President, Chief Information Security Officer, Coalfire

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS