Fintech newcomers and disruptors are reimagining the traditional financial services space. But these startups must address the same security concerns that have plagued incumbents if they want to make a significant impact. In the financial industry, security sells. App security is no longer a discussion between IT teams and developers—it’s a key topic in board rooms and a major part of a financial institution’s growth strategy.
According to CSO’s US State of Cybercrime Survey, 58 percent of companies say their top security executives brief their boards of directors on cyber issues at least quarterly. The number of companies that don’t keep their boards in the security loop has declined, from 29 percent in 2017 to 19 percent in 2018.
Alors que les applications de gestion de patrimoine, les technologies de paiement, les services bancaires mobiles, les plateformes de prêt et de crowdfunding font leur apparition, la sécurité est mise au premier plan – à juste titre.
What security concerns should fintech companies consider when developing their apps? How can they keep the workflow secure when they must enable data-sharing between multiple stakeholders while managing customer access to a diverse set of services?
The Intersection of Revenue, Reputation, and Risk Management
Each Fintech app is unique. Often with their own personality and different take on providing financial services. Even when they appear superficially similar, they will be built to a different architecture. What connects them all, though, is that they handle sensitive personal and financial information. If they weren’t operating on each individual customer’s own data, what value would these apps bring?
This flow of personal and financial data needs to be handled in a highly secure manner. There are compliance considerations under financial regulations and privacy laws. Perhaps even more critical, fintech companies must consider that customer trust – the cornerstone of their business – can be quickly destroyed by a data breach.
Securing the data flow can become a complex matter when dealing with fintech apps. Even a simple, informal data flow mapping exercise will quick reveal that sensitive data is moving out of the secure cloud and into an ecosystem which the fintech has no control over.
This data is potentially touched by a range of players including:
- The mobile device
- The mobile operating system
- The app stores and associated messaging services
- Third party software installed on the mobile device
- Open WiFi hotspots
- And many more
The data-sharing between all parties involved must be seamless—invisible and frictionless to the end user to provide an optimal in-app experience. However, the entire data workflow must be secure in order to achieve compliance, protect revenue, and maintain consumer trust.
Security means more than encrypting the channel. It means authenticating the end-points (guarding against Man-in-the-middle attacks) and ensuring that these end-points can’t be compromised (protecting against Man-in-the-device attacks).
Security must be a priority at every stage of the workflow, especially during instances where escalated privileges may be abused, when APIs communicate with the backend, or when using third-party SDKs.
One of the most common ways to attack Android apps is to find vulnerabilities that make it possible to escalate privileges. In operating systems based on Unix, the highest user privilege is to have “root access.” In iOS, this is achieved through “jailbreaking” the device.
In order to build safe, secure fintech apps, developers must get ahead of hackers trying to take advantage of escalated privileges. This means securing apps with a proactive approach and moving beyond the inherent risks of relying on operating system sandboxes for protection.
Once successfully jailbroken/rooted, a phone becomes a higher risk environment, allowing a hacker to more easily exploit weaknesses and design flaws, such as credit card numbers stored without being encrypted, weak PINs, and vulnerable tokens.
Even without escalating privileges, it is easy to tamper with source code and repackage it with malware. Malware is often used to siphon off sensitive information, including:
- Cryptographic keys
- Sensitive credentials and personal information such as credit card numbers and email addresses
- Proprietary information about your source code
Client devices are a vulnerable attack vector because they communicate with backend servers, potentially leaving your entire operation exposed to “man-in-the-middle” attacks. Protecting the client device communication is key to safeguarding valuable data.
Man-in-the-middle attacks occur when hackers insert themselves in the middle of the communication (e.g., by compromising a WiFi hotspot, an attacker can sit undetected in the middle of the communication). With these attacks, a customer assumes that he/she is interacting directly with the intended component/service, but the attacker “in the middle” is eavesdropping or changing the information to their benefit.
For a typical Fintech app, communication encryption is a combination of industry standard Transport Layer Security (TLS) and bespoke application layer security. By analyzing the app, an attacker can reverse engineer the protocol and find the cryptographic keys used to secure it. The communication protocol is fundamental for any MFS. If an attacker understands how the communication protocol works, they can discover and exploit its vulnerabilities.
Third Party Components
Are There Vulnerabilities in Your Fintech Apps?
Many fintechs delay the implementation of app security, assuming it will be too difficult or costly. However, if you choose the right security partner, the reality couldn’t be further from the truth. In fact, Cisco’s Annual Security Report found that 53% of respondents outsource security services because it is more cost-efficient than building in-house technologies (and it is much more cost-efficient than bypassing security altogether and dealing with the astronomical repercussions).
Common security concerns with fintech apps include:
- Insecure coding practices
- Exposed or misconfigured APIs
- Exposed personal data
- Scalable credentials stuffing