Security Measures Deployed to Protect DHIS2 Databases:
At a physical level, the servers are housed in a CCTV-monitored facility with multiple
levels of biometric security; physical access to the servers is by appointment only with
the ID/Passport numbers being verified against the account details or account owner,
and visitors are escorted at all times.
On a software level, a number of measures are in place:
Security measures to control access to servers:




Each server has a different set of usernames and passwords, generated
randomly and stored securely in KeePass. Only the SWD team have access to the
file, with the exception of one or two of the Mx Team and the Data Management
Team lead.
Passwords are required across our infrastructure to consist of a minimum of 8
(eight) characters, and must contain a combination of Upper- and Lower- case
alphanumeric digits. This means that our standard passwords are on average 46bits in depth, and impossible to guess (i.e. because they are random, they do not
contain birthdates or similar personal info). No two passwords are the
same. KeePass ensures this. Brute force attacks are thus the only viable
possible method of "cracking" our password security, and these are easily
identifiable based on the volume of packet data they generate.
All servers are routinely monitored by Hetzner's Network monitoring team;
they report any unusual behaviour to the System Administrator directly, by
mobile phone if necessary. They additionally take steps to secure HISP servers
from virtual "attack", when such an event is identified, automatically, by blocking
the traffic from its source - as happened in late 2013, when a concerted bruteforce attack on one of our servers (originating in Vietnam) was blocked.\
HISP-SA servers all use Comodo's secureDNS (8.26.56.26) as a primary
DNS. Comodo scan traffic through their secureDNS using packet-introspective
filters, allowing them to determine if any traffic passing through is malicious in
content; this means that viruses and other known malicious invaders are usually
halted before they reach our servers.
Security measures to control access to databases:




Databases reside on a series of PostgreSQL Database Servers. Each physical
system has its own Db server, meaning that even in a worst-case scenario if one
server were to somehow be compromised, the "damage" would be limited to only
those databases residing on the affected server.
The Database servers are routinely configured to IGNORE all requests from any IP
address that is not known to be a HISP web server "linked" to the specific Db
Server (with the exception of pgremote users access, which is restricted to nonLIVE databases). This makes it technically impossible to hack one of our Db
servers unless one were to first somehow gain control of an associated web
server.
Our Database servers are all hosted on Ubuntu 12.04 LTS virtual servers. Ubuntu
has some of the toughest Operating-System - level security of all operating
systems in the world, as it is based on a UNIX core; as such, it is highly resistant
to viruses and "hacking" attempts. We will soon be updating all our systems to
the latest Ubuntu 14.04 LTS version, once we have completed our DHIS2 version
audit and "normalisation" upgrade plan.
Access to the Db Servers is tightly controlled from a username and best-practice
point of view; the DHIS2 application for example uses a separate, non-super-user
account to interact with the Db server. Only one super-user account exists for










each Db server, and it is used only by myself and a select set of members of the
SWD Team.
Remote access to the databases is possible only to "Staging" and "Training"
databases; the LIVE databases are not accessible remotely, under ANY
circumstances (not even by our own team).
We use a reverse-proxy servlet on each webserver, allowing us to secure the
communications traffic on Tomcat's ports; this means that traffic between Tomcat
(the web server) and the Db server is far more difficult to intercept.
Our Db Servers listen on a non-standard port; we do not use the default of
5432. This means that the servers are less prone to automated "bot-style"
probes and hacking attempts.
Regular updates to the servers - including Ubuntu, PostgreSQL, Tomcat, Java and
DHIS2 itself ensure that any vulnerabilities are routinely "patched" in updates
released by the software owners.
Hetzner also monitor the world for vulnerability announcements affecting popular
operating systems such as Ubuntu, and post alerts when such an event occurs to
my email. We then schedule updates as required.
The console communications that happen between HISP Technical and the Db or
Web servers is secured using SSH encryption, preventing interception of
commands, data and passwords between a desktop/laptop client and the servers.
We are rolling out SSL encryption for secure communications between users of
the web application and their browsers. This will prevent "snooping" or
interception of a user's username and password when logging into DHIS online.
We will also shortly roll out a new firewall to all HISP Ubuntu-based servers that
will "lock down" unused ports and stealth the servers further from probing and
bot-style attacks.
Backups have been upgraded to include 46-bit encryption in all backup files,
which are posted to a secure FTP server. Even if the FTP server were somehow
compromised, attackers would then have to peel away the encryption on the data
itself before they could get at any useful information.
Finally, because we use an encrypted KeePass file that is stored on a secure FTP,
we can change passwords for any system at will; all users (with access) across
our organisation can then synchronise their KeePass file with the master on the
FTP to propagate changes and updates.