As we close out 2021 and plan for 2022, one thing is clear. The mobile channel has once again been the fastest growing channel for financial activity. As the mobile users have increased their number of financial transactions and activities, they have also become targets by those looking to exploit them. In addition, mobile apps are often used to gain access to back-end systems. Let’s take a look at the financial security standards and regulation in the new year that will highlight the challenges organizations face in protecting this rapidly growing channel and the rest of their organization.
Top 2022 Financial Security Regulations
To help reign in increased cyberattacks and fraud, banks and financial organizations need to comply with new and existing reporting requirements in 2022. These include:
Reporting Cyberattacks within 36 hours to the FDIC, FRB, OCC
- Banks in the US will be required to notify federal regulators of any cybersecurity incidents within 36 hours of discovery. This requirement takes effect April 1, 2022, although enforcement will not begin until May 1, 2022.
- For more information on the November 18, 2021 announcement by the Federal Deposit Insurance Corporation (FDIC), the Board of Governors of the Federal Reserve System, and the Office of the Comptroller of the Currency (OCC), see this article.
Identifying and controlling risks associated with banking or financial apps to the Federal Financial Institutions Examination Council (FFIEC)
The FFIEC publishes the FFIEC IT Examination Handbook (IT Handbook) to provide guidance to examiners, financial institutions, and technology service providers on identifying and controlling risks associated with retail payment systems and related banking activities. In its IT Examination Handbook specifically for mobile applications, mobile application risk is described as:
- Ability to download applications for application stores not authorized by the manufacturer that have malicious code
- Distribution of malware through applications
- End user’s ability to access root user privileges (e.g. rooting) or removing the manufacturer’s device controls (e.g. jailbreaking), which may lead to the user downloading apps from untrusted sources and introducing malware onto the device in the process
- Personal information, including usernames, passwords, email addresses are stored in the clear
- Access to back-end databases using information gathered through mobile apps that have not been properly secured
- For more information on how to address these risks, see this article.
Additional Cryptocurrency Wallets and Exchanges to Face Regulation
On October 28. 2021, the Financial Action Task Force (FATF) issued guidance requiring countries to assess risks associated with decentralized exchanges, stablecoins, NFTs and P2P platforms. Wallets are used to hold and transfer cryptocurrency, and they are increasingly under attack and regulatory oversight as virtual assets and cryptocurrency increase adoption. Certain types of virtual Asset Service Providers (VASPs) host wallets on behalf of end users and are subject to regulation that banks and other financial institutions face. Many users predominantly use their wallets on mobile devices.
- Owners and operators of Decentralized Exchanges can be considered Virtual Asset Service Providers (VASPs) and therefore subject to regulation all VASPs face.
- Jurisdictions need to supervise stablecoin projects before they launch.
- Regulators should pursue a risk-based approach for unhosted wallets. Unhosted wallets are wallets where the private keys that control the funds are held by the user rather than an exchange or another centralized entity. One risk-based approach might be for VASPs to restrict or even prohibit their users from transacting with unhosted wallets.
Challenges Financial Organizations Face in Complying with Regulations
Due to the pandemic, people accelerated their use of mobile wallets and apps to transact at an even faster rate than ever before. Countries around the world saw a dramatic increase in the use of mobile banking apps and wallets. As this trend continues, bad actors have used and will continue to use malware to give themselves special access to accounts and wallets. Along with targeting mobile apps, bad actors have also used mobile apps to obtain API keys, usernames and passwords, accessing and back-end servers and attacking them. Mobile wallets are targets themselves AND used to target other systems in the organization.
As organizations face (1) an increase in attacks to the increased use of mobile apps (2) increase in sophistication of attacks on a mobile channel they don’t have the resources to address, they will need solutions that can help them quickly and efficiently identify the risks and attacks—and defend against them. See these pages for more information on how Appdome can help your organization secure your mobile apps and prevent fraud.
- Mobile App Security for Consumer Facing Apps
- Mobile App Security for Enterprise Apps
- Mobile Fraud Prevention
- Mobile Malware Prevention
- Mobile Piracy Prevention
Top Banking and Financial Security Standards
Financial standards continue to develop and used to address the changing nature of banking and those who make financial transactions. While PSD2 legislation in Europe may have spurred the development of open banking projects, open banking initiatives will continue to proliferate in 2022 as organizations around the world seek to reach the unbanked, the underbanked and new demographics. UK Open Banking and other regulations like it require banks to provide APIs to third party providers using defined API standards. Other countries such as the US and China have a market-driven approach where individual banks and fintechs define and deliver APIs. A third model is in Singapore where the Monetary Authority of Singapore allows banks to define their own APIs but keeps an API registry of banks that provide APIs.
Most of the focus for security in these open banking initiatives is on basic things such as authentication, authorization and encryption. While these things are important, they are not enough. Let’s first look at what these standards are and then the challenges organizations face:
OWASP API Security Top 10 – OWASP released this top 20 list to raise awareness of API security vulnerabilities so that all organizations (including banks and financial services) can proactively address them.
|OWASP API Security Vulnerability||Why a Vulnerability|
|Broken Object Level Authorization||Exposed endpoints that handle object identifiers (access control issue)|
|Broken User Authentication
|Authentication mechanisms (e.g. ability to identify client/user) that are implemented incorrectly|
|Excessive Data Exposure||Object properties exposed without consideration of each property’s individual sensitivity|
|Lack of Resources and Rate limiting
|When APIs don’t impose restrictions on size or number of resources requested by a user, leading to Denial of Service, API server performance issues|
|Broken Function Level Authorization||Attackers gain access to other users’ resources and/or administrative functions due to authorization flaws|
|Mass Assignment||Attackers modify object properties they are not supposed to|
|Security Misconfiguration||Insecure default configurations, error messages exposing sensitive information|
|Injection||Attacker’s malicious data tricks the interpreter into executing unintended or unauthorized commands.|
|Improper Assets Management||Exposed debug endpoints or deprecated API versions|
|Insufficient Logging and Monitoring||Allows attackers to further attack systems, pivot to more systems to tamper with, or destroy data|
- In mTLS both client and server present and validate certificates to avoid MITM and spoofing attacks.
- EIDAS is an EU standard for electronic identification which PSD requires. The standard specifies using ASN.1 data format to carry extra attributes.
- OAuth 2.0 is supported in banking initiatives such as Berling Group and used widely as an authorization framework for delegated access to APIs, where authorization grants are exchanged for access tokens.
- OpenID Connect is used on top of OAuth to provide further proof of authentication with an ID token.
- FAPI (Financial-grade API describes security provisions for the server and client in financial APIs.
4. Data sharing
- FDX (Financial Data Exchange) API is designed to enable data sharing without screen scraping. FDX uses OAuth 2.0 and OpenID Connect to allow customers to manage access to their banking data. For example, one company uses FDX to allow banks to allow their customers to provide consent-based access to account data without requiring the user to share their credentials with third parties.
While the above standards are important, what’s missing is a standard for client-side or mobile apps. As worldwide usage of mobile apps continue to grow rapidly, there needs to be a client-side API standard. Let’s explore the issues stemming from the lack of client-side API standard in more detail.
Challenges Organizations Face with Current Banking and Financial API Security Standards
Current banking and financial API standards lack client-side API standards for security. Why is this an issue? Mobile apps contain hundreds of APIs that make thousands of calls to back-end servers daily. When unsecured APIs attach to mobile apps, they often allow cybercriminals to compromise the mobile app and the API backend, and make it easier for them to steal transaction and personal information. There are 3 main gaps as a result of not having client-side API standards.
- By allowing unsecured APIs to take over mobile apps, problems arise, including exposure of privacy-sensitive and transaction data, and authentication parameters in URLs; outdated protocols enabling attacks on third-party servers.
- It’s harder for clients to authenticate in a way for the OAuth server to trust that it is the correct application. There are no client-side standards today for uniquely identifying mobile apps.
- Some organizations that have implemented gateways may address some of the client-side API vulnerabilities. But gateways will not address a number of issues. Because there is rarely a single “gateway” point where protection can be enforced, mobile apps are an increasingly vulnerable area for organizations.
Application developers need an automated way to build comprehensive security and mobile fraud prevention into mobile apps in the absence of client-side security standards, without having to put a gateway in front of the API. Organizations need a way to communicate to each other what security features have been added and in what release. Without SDKs or coding, Appdome provides app makers an automated way to build security into their software development lifecycle.
For more information on why organizations need to go from DevOps to Mobile DevSecOps to and build security into the software development lifecycle, please see this article. To understand how Appdome address the security gaps with banking and financial API standards, please see this blog.
To see Appdome in action, please contact Appdome for a demonstration!