Defence in Depth - Part 3 - The Least Privilege Principle

An application does not need to use the root (MySQL), sa (Microsoft SQL Server), postgres (PostgreSQL) or SYSDBA (Oracle Database) to connect to the database.

Likewise, it’s a bad idea to run daemons or services as root (Linux) or Administrator (Microsoft Windows), unless there is a specific, justifiable, and carefully considered reason to do so. An application should always be given the least privileges possible that allow it to work properly — any additional privileges should be disabled.

If an application is connecting to a database with a privileged user account, in the event of an SQL injection vulnerability, an attacker would be able to run SQL queries as a database administrator, and on some database servers, also execute operating system commands. By executing operating system commands, an attacker could have the ability to carry out a reconnaissance exercise on the internal network behind the firewall and escalate an attack further.

Running anything with administrative privileges defeats a tried-and-tested security model that’s been in place for years, since it allows an attacker or a rogue application to cause more damage in the event of a security breach. Applications and database connections should be run with restricted, non-administrative privileges, elevating privileges temporarily to modify the underlying system only on a per-need basis.

Log everything, revisit often

Several defence in depth strategies help prevent breaches in the first place, however a crucial aspect to any defence strategy is to know when an attack is underway and what has happened after an attack occurred. Mitigating the the effects of a security breach is only possible if attention is paid to early warning signs.

Logs are a crucial part of systems and applications. Through logs one can monitor performance, uptime, resource usage and other such data. Logs are also indispensable tools for monitoring security and detecting attacks. Logging is the closest thing to a time machine, so having comprehensive, detailed records of what happened when, could spell the difference between noticing a breach early and letting an attacker pull off a heist.

The obvious deduction here is not to ignore early warning signs, while the less obvious conclusion is the need to log absolutely everything and revisit those logs often. Naturally, this could present some technical challenges, especially to larger organizations, but it’s not impossible, especially with the ever-decreasing cost of storage and the various log management tools out there that help filter signal from noise.

In order to respond in time to the early warnings of a security breach, an organization first needs to know when it’s under attack and what has happened (or is happening) during the attack. One of the more effective ways to do that is to log everything and take action on what information logs reveal.