Introduction
The financial services industry is rapidly transforming. Fintech appsec teams must ensure that they have the right tools in place to keep up with these changes while also protecting their systems from threats like account takeover attacks, third-party integration abuse, and API abuse. This guide will outline what I consider the top three fintech security risks so that you can better understand how to protect your own organization’s applications and data from attack! Each threat detailed below warrants dedicated defense-in-depth measures, which I’ll cover in more detail in the future!
Threat #1: Online Banking Account Takeover
Its purpose is to gain access to legitimate accounts, where you store money and sensitive information. Once an account is compromised, it can result in loss of funds and loss of trust. This is usually due to compromised credentials (user/pass, access/refresh tokens, etc), password spraying attacks, and social engineering. To protect your users from this threat, security functions should be built into the application. Supporting a login history function can give users visibility to provide assurance of legitimate usage.
Login history should list the most recent successful logins and general location based on IP address. To further mature this control, login anomaly detection should alert users of unordinary login attempts. The organization can even opt to block attempts based on risk scores.
When an attacker has compromised a financial account, the most obvious attack vector is to perform fraudulent money transfers. Sensitive transaction step-ups, like OTP, can provide an additional layer of security against this. This calls to question the balance of security and user experience. This is where risk scoring based on user activity anomalies can play a part. An attacker can forge IP location, so that shouldn’t be the only factor considered. You can consider typical transaction amounts, recipients, and a whole host of other considerations. Every choice is a risk decision. Determine what’s acceptable for your organization.OTP naturally brings in the usage of multi-factor authentication. SMS isn’t the best option, but it’s better than nothing. Providing options for users to implement software authenticators like Google Authenticator gives users additional control over their finances.
Threat #2: Third-Party Integration Security Risks
3rd party integration security risks involve the use of third-party software that is integrated with a financial institution’s website or mobile app. These integrations are often used to provide functionality that would be too difficult for an organization to build internally, such as sending email campaigns, processing payments through payment gateways, etc. The increased use of these 3rd party services has made them a target for cybercriminals looking to exploit security vulnerabilities in order to commit fraud or steal personally identifiable information (PII). This opens the door for supply chain attacks, targeted at your partners to forge your organization’s usage or inject malicious code into your environment.
While vetting these third parties is critical, it can be difficult because many vendors don’t include enough detail about their product and how it works in their documentation. This makes it difficult for appsec teams to know what exactly they need for security testing before integrating with a new vendor. In addition, companies often outsource this vetting process which means that someone else might not understand your business processes well enough before making recommendations on which vendors are best suited for your appsec requirements.
When selecting new vendors you should consider the following:
Risk profile based on service provided
- Integration method (embedded SDK, server-side requests to 3rd party, private VPCs, front-end library, etc.)
- 3rd party organization’s security posture
- Supported security controls
Based on these factors, you can determine what security controls are appropriate based on the risk presented. For example, a 3rd party service that handles payment processing may include webhook functionality when a payment has been posted. This would be a high-risk integration that includes server-side requests to a 3rd party. Beyond the routine compliance reports, what type of security controls are offered? We may want to consider IP allow-listing, request signature verification to our webhooks, mTLS support, and alerting of replayed event IDs. If not all security controls are supported, determine what you can do to fill these gaps. If it’s an embedded SDK, is code signing supported to validate the integrity? If this has been compromised, have we appropriately isolated the environment and restricted permissions? The list goes on.
Setting aside resources to perform proper due diligence early will save your organization time and reduce risk in the long run.
Threat #3: API Abuse
APIs are the foundation of how applications interact with services. An API Fuzzer is a type of black box testing tool that interacts with the API endpoints. A black-box tester has no knowledge of or access to the internals of the target system. An effective fuzzer is based on the attacker’s ability to generate payloads. Using exploit databases, an attacker can programmatically generate massive lists that replace every possible data input.
API Fuzzing is used when you want to test an application’s data inputs (eg: account numbers and passwords) from outside its firewall using automated tools such as Burp Suite Pro or Zap Proxy, This type of testing determines whether any unexpected behavior occurs due to malformed input provided during processing which can result in business logic flaws and potentially reach your internal assets through attacks like server-side request forgery and remote code execution.
After doing a bit of inventory of API calls by interacting with your app, a subset of compromised accounts, script deployment across a handful of cloud resources, proxy chaining, and randomized request rates, an attacker can stand up an automated attack and wait as long as needed to find API endpoints of particular interest.
Rate limiting won’t be sufficient in this instance. With fintech apps, handling money movement is the basis of your business. That’s always going to be a desirable target. As your user base grows, so does the reward of a successful attack.
API Security is an area of its own. Beyond internal processes like security design reviews, secure code reviews, and penetration testing, we can additionally deploy proactive security controls that detect and prevent active threats. API security tooling should be capable of correlating error rates, request rates, request count from IP/user ID, and identification of malicious or anomalous payloads. By actively identifying fuzzing attempts, the organization can take appropriate action. Gather and track this data and you’ll get a picture of your threat landscape over time. Use this to allocate appropriate resources.
Conclusion
Due to the nature of fintech apps, they will always be a high-value target. As we’ve discussed, there are a number of cyber risks, but there are also ways to mitigate them. As an industry, we must always be evolving how we protect users and their data.
In summary:
- Integrate login history, anomaly alerting, and expand authentication options to protect the application from account takeover (ATO).
- Go beyond compliance and assess third-party integration security controls. Identify what gaps are present and what action you can take against them.
- Actively identify and protect against API fuzzing attempts. Don’t be afraid of the data, learn from it.
I hope that this blog post has given you some meaningful insight. I will touch on these topics in more detail in future posts. Let me know your thoughts on this topic. If you have any questions or would like to chat, please don’t hesitate to reach out!
Originally published at https://www.linkedin.com.
