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 

Also, we recommend you familiarize yourself with the OWASP foundation and the "Cheat Sheet" series https://cheatsheetseries.owasp.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.  We strongly advise against using any APP that connects to those APIs without revising the architecture as described, except in a test or demo environment.  


Additional Good Practices

(Thank you Yash Sancheti for these suggestions) 

User Education and Training:

Educating and training your team is another limb of your organizational cybersecurity defense. Equipped with engaging security awareness training sessions, end-users can be prepared with both knowledge and skills on how to identify potential security threats and react to them. You can get more information from some of the resources offered in the course during CISA Training: https://www.cisa.gov/c

Regular Security Audits and Compliance Checks:

Regularly conduct routine security audits and compliance checks. This can be helpful in finding all the vulnerabilities and their fix prior to exploitation, thereby helping to reduce the exposure window. A combined automated tool with manual expert reviews provides complete coverage.  There are multiple vendors available that scan for compliance with existing security standards.  We don't recommend any vendor in particular, but for pointers you can look at https://owasp.org/www-community/Vulnerability_Scanning_Tools 

Key Management and Data Encryption Strategies:

Implement strong data encryption strategies to protect sensitive information. Key management should be something that your IT team does, utilizing best practices.  Just like a physical key, you should keep it in a secure location with limited access and take special care not to copy it to digital locations that can be scanned or found, including email systems.  Make sure you have procedures in place.  

You would probably want to encrypt the data at rest with AES-256 and in transit via TLS 1.3.  And remember, key management to encryption is the key.  Every cloud providers provides key management services that help you manage and secure your keys.

examples:  

https://aws.amazon.com/kms/

https://cloud.google.com/docs/security/key-management-deep-dive 

https://learn.microsoft.com/en-us/azure/security/fundamentals/key-management

Secure Coding Practices:

Secure code by following secure coding practices and standards, such as OWASP's top ten, for any kind of vulnerability at the code level. Use tools like SonarQube for finding security problems in your source code through static application security testing (SAST) prior to deploying an application. Note that SonarQube has already been integrated into our automation build process.  

Apache Software Foundation has an account with SonarQube and fineract scans can be found in that account.  

Implementing Multi-factor Authentication (MFA):

Enhance your security layers with MFA. One such approach, built on three things: something the user knows (like a password), something the user has (like a security token), and something the user has (biometric verification, for example). When MFA is used, it adds another layer of security. Solutions such as Duo Security may be a good implementation for MFA.

Leverage Community Support:

You should stay engaged with the Fineract community to stay on top of security updates, patches, and best practices. Also, look for the possibility of collaboration with cybersecurity firms that would help you increase the capability of your threat detection and response system. Such relationships may avail specialized skills, technologies, and intelligence that may strengthen the security posturing of your organization. 


see  Apache Fineract Security Report 

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




  • No labels