TODO: security goals, see threat model
See the Mifos Architecture diagrams These recommendations are based on the next generation system architecture.
TODO: outline security architecture fitting inside of Mifos' architecture.
TODO: the following list will be changed significantly by 27-AUG-2009.
TODO: Here are the security components and how they work.
TODO: Mifos uses a "bitmap" of roles and permissions that allows a user to perform actions that can be fine grained filtered.
TODO
TODO
(Rationale: Micro-finance organizations and their branches can be very small and run out of an apartment or other available location, and operate in remote areas. It is likely that computing infrastructure has less-than-ideal location and is an easy target for theft, especially for hardware such as memory. Comment: perhaps this and other 'why' statements should move to the threat model or another location)
(formatting may be off for now...krishnan)
At the moment, the default user 'mifos' (having 'Admin' privileges) is not forced to change the first-use password, whereas other users are. Include this user within all policies for other users, including forced change of first-use password.
Self-service password reset is the ability for a user to regain access to the system in the event they cannot recall their password. By setting up (a few) challenge-response questions, they can verify identity to the system which then allows them to set a new password.
(Considering that most MFIs do not have in-house e-mail, and that Mifos does not currently support e-mail communication with staff, it seems impractical for Mifos to try and e-mail users with change password links or reminders.)
Have Mifos force users to change passwords at a particular frequency (configurable for the organization by an administrator). The chosen frequency can only vary between certain hard limits (such as a lower limit of one week and an upper limit of 90 days). Only accept new passwords that differ from the existing password by a certain number of characters.
Include a blurb that provides brief information about password policies within Mifos on relevant screens.
(FUTURE) #. Provide a facility for administrators to review an exception log An exception log captures and reports events that may be considered suspicious.
(For now, we will include both packaging as well as installation recommendations here. Do we need to talk about deployment in different environments?...krishnan)
Add simple recommendations to secure the server, including a list of services to allow, a recommended firewall policy, and access via key pairs for administrators on the server, a policy concerning the application of patches, etc.
Bundle a default self-signed certificate to use with Mifos out-of-the-box.
Include simple instructions to generate and use public and private key pairs, to generate and install a self-signed SSL certificate, and to generate a CSR for obtaining certificates from a public Certificate Authority
Considering that Mifos may be deployed for organizations and locations that may lack the necessary skills to secure an installation, it is recommended to make relatively simple additions to the installation procedure for Mifos to secure it, such that users would have to deviate from the recommended installation to operate Mifos in an insecure fashion.
All user access via the browser must use SSL, at least in production environments.
Setup SSL security in MySQL and tunnel communication between the Mifos Java application and MySQL using SSL certificates. (To
TODO: Please see Prioritized Threat Tables in the ThreatModel for mitigation mechanisms.
(Krishnan to add material following Password Policies and Deployment Recommendations)