This document is an outline of the attacker's goals and capabilities that we need to consider for Mifos security. The threats in this document can be used to develop the Mifos security recommendations document.
Threats to the following components of a typical Mifos deployment are considered:
The following threats are considered out of the scope of this document:
Note0: A stretch goal could be to make it hard to attackers to use the data in the database.
Note1: Informative notes on the physical security of the system can be inserted.
Note2: There's not much we can do to prevent attacks on other systems by using the data on a Mifos database beyond telling people not to use the same username/password on Mifos that they have on other systems.
The following steps outline in chronological order a new user (a Loan Officer) being added to the system and using it. These were extracted from the Mifos user manual
There is no additional setup steps and the Loan Officer can proceed to immediately add clients. The Loan Officer does the following:
The typical administration setup scenario for new Loan Officer are as follows:
See chapter 3 of users guide for more details (comment: the user guide is outdated...)
Physical outline: Two colocated machines
Network access:
The web/application server allows incoming connections from the outside world on the following ports
The database server allows incoming connections from the outside world on the following ports:
Additionally, the firewall allows incoming connections from the web/application server to the database server on the following ports:
Depending on the environment and OS used, additional ports may be opened between the web/application server in the DMZ and a server in the secure subnet such as DNS, NTP, etc.
The web/application server and the database server are on different subnets, typically with the web/application server in the DMZ and the database server in a secure subnet, behind a firewall allowing the connections above.
Note3: Mifos is not connected to any financial systems, it is only used to track transactions that were made in the real world. Thus, the attacker's incentive is now based on identity theft, competitive advantage and denial of service. A successful attacker would have enough information to deplete a client's bank account.
Note4: Recommend a method to minimize the threat of initial login credential compromise. E.g., if the initial credentials have to be sent via email, make Mifos automatically create a password that is intentionally hard to remember, thus giving the user an incentive to change the password. Recommend good password policy
Note4.5: ssh must use private/public key pairs. Password authentication and root log on must be disabled.
Note5: For additional scenarios, see the Mifos user manual
TODO This section needs some clean up
What property do we want to ensure, against what adversary?
Attackers
Who is the adversary?
csv-table:: User Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation
1-1, 1, Compromised Loan Officer login credentials (either by the LO or during transit from Head office), force password change upon first login. (see Mifos user manual chapter 1.3) 1-2, 3, Compromised client bank account information (depends on 1-1), 1-3, 2, Compromised client identity information (SSN; gov ID; address; phone; email) (depends on 1-1), 1-4, 4, Compromised client loan information (subset of 1-2?), 1-5, 8, Inaccessible system due to malicious activities, 1-6, 5, Scavenging of old data (leads to thread 1-1; 1-2 and 1-3), Secure deletion of old storage hardware (best practices) 1-7, 7, Activity analysis, 1-8, 6, Loss of equipment containing private information. (e.g. laptop stolen with password saved in browser), good password policies. (e.g. first letter in random phrase. Don't save password in browser.) 1-9, N/A, Loss of equipment containing private information. (e.g. laptop stolen with password saved in browser), Same as 1-8
csv-table:: Database and Application Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation
2-1, 1, compromise of backup user, Perform backups from a secure box using only secured communication channels. 2-2, 2, Compromise of backup user's private key, 2-3, 3, SQL injection, Sanitize inputs 2-4, 4, Access to execute arbitrary code (from limited account and root), Ensure system is fully patched (good patching policies). Open only ports that are absolutely necessary and time limiting them as needed. 2-5, 5, Access to read data. (remote) Any malicious user with access inside the firewall and credentials to the database. (local) Theft of physical hardware hosting the database., 2-6, 6, Access to write (tamper) data. (Same as 2-5) 2-7, 7, Access to destroy data (subset of 2-6), regular offline backups 2-8, 8, Compromise of data flowing between the web server and the database. Requires that the attacker has access to at least the DMZ network, protect data between web server and db. TLS tunnel? 2-9, 9, Compromise of backup data, 2-10, 10, Configuration error, best practices document
csv-table:: Web Server Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation
3-1, 1, Access to replace valid software with malicious one, 3-2, , (subset of 3-1) Access to execute resident code (from limited account and root), 3-3, ,(repeat of 3-2) Access to execute arbitrary code (from limited account and root), 3-4, 2, compromised Operating System, good patching policy. 3-5, 3, Access to read data (secret configuration; e.g. SQL creds), 3-6, , (same as 3-6) compromise of Mifos software, Good backup policy 3-7, 4, Exploitation of side vectors to get to Mifos data. In a central hosted cloud Mifos would probably run in a virtual machine. A malicious process with access to another virtual machine on the same physical machine could do some damage depending on strong the checks on the hypervisor are. Another side vector is Tomcat. A vulnerability in that software could lead to a compromise of Mifos data to no fault of Mifos., Secure policy on virtualized components. Strip down all unnecessary software (recommend baseline like PCS) semi-automatic software update mechanism. (Tough. Need to avoid loss of service due to patching on very heterogeneous networks.)
3-8, 5, Software error (bug), 3-9, 6, Configuration error. (Leaving default tomcat page...etc), 3-10, 7, Unauthorized remote access to server. Typically through compromised credentials of maintenance and support staff., web server account set to a limited one with privs only to complete tasks needed. 3-11, ,(repeat of 3-10) Compromise of administrative credential (e.g. administrator; software update; remote administrator), 3-12, 8, Scavenging of old server (physical machine), 3-13, 9, Physical theft of server or parts thereof., 3-14, 10, Loss or compromise of Logs, remote storage of critical logging information. Note: sanitize log info. print user ID and not what the user typed.
csv-table:: Network Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation
4-1, 1, Eavesdropping of information, use TLS 4-2, , (subset of 4-1) Modification (tampering) of information, 4-3, , (subset of 4-1) Replay of information, 4-4, 2, Man in the Middle during legitimate communication, appropriate warning messages. CAcert and don't ignore warning. Bullet proof docs for installation and maintenance of certs to minimize (or eliminate warning messages) 4-5, 4, compromise of credentials for remote maintenance, 4-6, 8, Corruption of time information to falsify timestamps, Authenticated NTP with NIST. http://tf.nist.gov/service/auth_ntp.htm 4-7, 9, Exploitation of side vectors (other running programs) to get to Mifos data., Firewall with only port 80 (if necessary) and 443 open. Put Web server in DMZ. 4-8, 10, Denial of service, 4-9, , (subset of 4-8) Flooding of requests TODO define requests, 4-10, , (subset of 3-8) Vector for remote exploitation. (Software bug),
References and tools ====