As a long time Oracle database specialist, I've noted below a few simple ways to make it more difficult for hackers to break into an online database. These suggestions may give developers headaches, but they work. Comprehensive database security clearly depends on which database system is used and its physical and logical configuration (network, clustering, cloud, etc.); the ideas described below should be implementable on any of the more common database systems.
As always, these points are "in the opinion of the author" and may be disputed by knowledgeable professionals. We techies love to argue. :)
- Find and disable all default, easy-access pathways prior to deployment. Many databases ship with deliberate, built-in vulnerabilities the implementers are expected to know and disable as part of the initial configuration. A surprising number of applications are built and deployed without closing these holes. Big culprits here would be default passwords (or none at all) for administration or superuser accounts, and user accounts with passwords set by the users themselves, without any kind of password policy enforced by the database. The solution is fairly simple for both. For the admin/superuser security, google the database system used, as in: "How to lock down database X?". There will be plenty of results, so look first for the ones from the software supplier and from legitimate security organizations who publish articles on such subjects. For user accounts, force the users to follow password policies prior to getting access. Lock that database down tight!
- Client program design. Regardless of whether the database is accessed directly from a web client, indirectly via a mobile app, middleware, a compiled desktop program or the command line, the database must be protected from malicious intruders and creative (legitimate) users. At a minimum, this requires some rather serious discipline on the part of the application developers (see here for the classic counter-examples). This is the part of the article most likely to raise eyebrows (or perhaps pitchforks and torches): the client applications must never access database tables directly. Does the application need to list the contents of a table? All of it? Write views (named, stored SQL, with a name different than the table, allowing limited access) for each category of user and each use case. Does the application need to add data, or update existing data? Write stored functions and procedures to make this happen, automatically document who, what, when and where it happens, and allow the applications to only do these types of operations through the stored programs, never directly. Users of the applications do not need to know anything about the database; if possible, they shouldn't even know that there is a database.
- The weakest links. Make onboarding of new users automated and possible only by authorized methods, and offboarding (in case of termination of employment) easy, automated, comprehensive and rapid. There should be automated, mandatory disabling of idle users after a suitable period of time, mandatory, periodic password changes, database-enforced password policies and sufficient audit trails for forensic tracking in case of breaches. Security policies must be enforced by the software, preferably by both the applications and the database.
- Comprehensive encryption. Most modern databases allow encryption of the entire database, which protects against an attacker downloading an entire database for later vulturization. Decryption only happens through the authorized applications, and any data input by users is immediately encrypted before it is stored. The encryption should be strong enough so that brute-force attacks take years longer than the expected lifetime of the application.
Alert readers have already realized that the above list is short, covers only some software setup and design issues, and that realistic application security requires more than is described here. Not mentioned above: firewalls, network security, VPNs, operating system security, policy, physical security, and many, many more. The list is long and difficult to implement all at once. The above points fall under the category of basic, common and often discounted, overlooked or ignored security rules. Note that the number and magnitude of security breaches reported today is large and still increasing, in part courtesy of the above design flaws.
That being said, the items in this list should form a part of the regular, routine due diligence customers shopping for software solutions should consider. Folks in the organization who are responsible for data security should know everything possible about the applications used by the organization. The above points are red flags, often overlooked, and to be avoided if possible.
What if these issues are present in a deployed application? Clearly, they should be investigated, quickly, quietly and thoroughly documented. Once that is done, the issues can be prioritized for resolution as part of ongoing software maintenance. Typically, the sooner this is done, the better.
Overlogix can raise red flags for customers willing to hear about security concerns, although as system builders, we don't currently do security audits. Instead, we make breaches as difficult, time-consuming and expensive as possible. Audits are left to certified security audit organizations. We remind customers that audits follow standards that may be out of date, and point out vulnerabilities we find. The bad guys out there are motivated, inventive, and often very good, making it difficult to keep up with the bleeding edge of genuine security.
