On this page, we will share best practices in securing the use of Fineract.   Since Fineract is a financial application with PII (personally identifiable information), it is vital that it is secured in production whenever it is setup.  If you are a small financial entity, bank, credit union, microfinance organization, or non-banking financial institution, the project urges you to identify and work with the vendors that work regularly with Fineract and are regular contributors to the security fixes.  In this way, we encourage a community of contributions that keep the overall solution secure.  Open source gets the benefit of many people reviewing the code and suggesting issues and solutions - let's ensure that virtuous cycle can work by supporting those working on security at Fineract.  

Members of the Security team can be reached at Security AT Fineract.apache.org.  The reporting mechanisms for vulnerabilities and exploits are there, not on the public dev list.  

See apache security practices for more information. https://security.apache.org 

OPTIONS for Securing the Fineract Infrastructure 

Run it isolated and/or disconnected 

In the world of Microfinance or small banking operations (in some geographies), it is possible that you can run Fineract on a private network, or isolated from the internet by being hosted locally and securing all connections.  This could involve establishing a VPN with limited ports open, and only accepting connections within that VPN.  At the far end of this spectrum, is running it isolated and air-gapped as a backend accounting system, where there is no internet connection on that device.  In such scenarios, you are limiting the vectors of attack to just those employees you give access to.  You are also limiting the functionality to accounting and basic operations, so this is rarely appropriate.   Even in these scenarios, it is important that you establish reviews of logs and accounts on a periodic basis to determine if any internal fraud is occurring.  Such things should be part of your operational manual.  There are a number of resources available for this topic, please find them online.  For fineract in particular, be mindful of the set up of approvals and and the Access you give to each person or role in your organization.  

Running it connected but behind Firewalls and DMZs

It should be clear that running it on the internet directly, without API monitoring and filtering, is a bad idea.  This is especially true if your fineract instance is connected to a payment mechanism of any kind.  Imagine an exploit being used to gain access and then to send funds from an account to an outside merchant or bank. An attacker could drain an account before you can detect the issue.  And, then it will depend on the payment scheme rules whether any of those funds are recoverable.  

There are multiple ways to enhance the security that is built into Fineract, but none of them are bullet proof and so you must have defense in depth. One key thing is to run the fineract instance behind an API gateway, and to prevent certain API patterns or calls that are likely to be fraudulent.  The important thing is to recognize that while you may not be a target institution now, at any moment this can change, and your IP will be listed on the dark web as a potential target for exploit.  Your IT team must also have ways to quickly turn off services to limit the damage.  

Fraud Prevention 

Even if you have secured your infrastructure, you will need the ability to monitor fraudulent traffic, and then to stop that fraud in real time. Fraud can occur even when your infrastructure is good, but a user account has been accessed through a phishing attack or similar vector. And, in the world of real time payments and multiple payment types and channels, there is a need for additional real time monitoring, and inline processing of potential fraudulent transactions.  Detection and blocking needs to occur in real time and then resolution can occur more leisurely with additional manual and help desk interventions.  

If you are a small institution and you are getting into this situation, you should consider having holds on all payment and transfers built into your process,  until you can enable effective tools.  

There are a number of fraud prevention tools that are available in market from fraud prevention vendors.  When looking for solution providers, the ideal scenario is a vendor with longevity and a track record in your market for detecting recent fraudulent activities.  Pattern detection is a key part of this, and for that, it is important to be able to get enough data from your systems to identify the anomalies.  

There are a number of GitHub projects that cover algorithms for conducting ML on transactions to detect anomalies.  There is also an open source project, Tazama, which provides a kind of framework for your own logic and algorithms: https://github.com/frmscoe/docs.   

Fraud exploits are on the rise, supercharged by AI tooling.  AI tooling can also be used to fight these trends, but it is an ever escalating area of concern for financial providers globally.  

Self Service APIs 

It is recommended that you disable the Self Service APIs to avoid any potential exploits there.  Apps should not be developed to use those APIs.  

There is a way to run those APIs endpoint (re-written but consistent) in a separate isolated component, where there is a way to control the ingress and egress of data.  Once that component is linked up with authenticated users with a fully designed authorization scheme, then the APIs can be accessed.   This is an area of exploration by the project.  Currently, Fineract should not be run in a way that allows access to those APIs.  

If you are a Fineract contributor, please feel free to suggest edits to this page.