Few, if any, other repositories for data and meta-data within an organization exceed the importance and value of its databases (DBs). In fact, databases often provide a home for an organization’s personnel information, financial data of all kinds (pay, taxes, purchases, income, and other monetary transactions), and data describing its physical inventory and assets. Thus, it’s not unfair to observe that most of the data that defines “who, what, where, when, and why” for an organization is likely to reside in a database. All of this goes to explain why DB security is vitally important to an organization’s health and its ability to conduct business.
Principles that drive DB security are well-understood
In the realm of database security, informed professionals understand that while basic security principles definitely apply, they can (and often do) take a database-specific slant. Thus, any enumeration of such principles will often play to the special circumstances involved in defining database metadata (often called a “database schema” to emphasize its scope and coverage for some specific and related collection of data) and in setting up and managing a database engine of some kind (which may be on-premises, in one or more clouds, and various permutations on those themes).
That said, here are how some of these basic principles play into the world of database security.
1. Principle of least privilege (aka PLP)
In general, PLP means providing the minimum of access rights and user privileges necessary to perform some specific task, run an application, or work with database contents, software or infrastructure elements. As with other PLP situations, periodic review to avoid “privilege creep” (gradual accumulation of more rights and privileges than are really needed) is essential.
But in general database designers and database administrators (DBAs) should grant only rights and privileges that users, applications, and services need, and no more than that.
2. Platform hardening
Across the board, platform hardening requires a deep understanding of a platforms vulnerabilities and its attack surfaces, so that organizations can take pre-emptive measure to address known potential weaknesses. Among other things this means uninstalling or disabling features or services that you don’t need or use. It also means resolutely enforcing password discipline, especially when it comes to changing well-known passwords and their associated accounts (best to delete them if you don’t use them).
Make sure all security controls that the database engine offers are enabled, and set to maximum tolerable levels. Checks on hardening success are covered further in the upcoming “monitoring and auditing” item.
3. Data protection
Data and metadata for the database should be encrypted both in motion and at rest (and this applies to backups and snapshots, too). Data and meta-data should include security tags or classifications to permit full-blow security policies and protections to apply. Data protection also includes monitoring its access and use, export and exfiltration, especially wholesale copying activity not readily explained or understood.
4. Monitoring and auditing
The old saying goes “If you don’t monitor it, you can’t measure it.” This applies equally to database security among other kinds of security. For databases this should include:
- Tagging and auditing of access to anything private, sensitive or confidential (and may be required for compliance or governance reasons anyway)
- Logging, monitoring and occasional auditing (or automated reactions to anomalous use) of administrative privileges and access, including database set-up and configuration
- Database account management
- Database access and usage patterns, and more.
This same principle also applies to periodic security audits that may include Red Team or white hat penetration testing, ongoing attack surface monitoring and management, and regular reviews of logs and audit trails.
5. Protecting network access using firewalls
Protecting the links that provide access to a database is crucial, as is the notion of “deny access by default, allow access only by deliberate exception.” Firewalls should surround databases and any applications that access them, especially web-based applications. The only valid inbound traffic should come from well-known application or web servers with a legitimate reason to access the database.
Database firewalls should also block outbound connections unless some specific, short-lived reason exists to allow them (and known to be subject to audit and review). A web application firewall is a key ingredient in this mix, because insidious attacks – such as those using SQL injection, for example – might otherwise serve to export, delete, or alter database contents. Where a database firewall might let such attempts through, a web application firewall will not. That makes it an essential element in securing database access, whenever web applications are involved.
6. Platform isolation
This principle refers to keeping database engines separate and distinct from other types of servers. One one’s own premises, this principle translates into dedicating hardware resources to the database engine, apart from those provided for other servers and services.
In the cloud, this may not be possible, but cloud users should assure themselves that their cloud provider(s) are delivering sufficient process and resource isolation to databases to prevent processes related to other applications, services and servers from sniffing or accessing database contents or transactions.
7. Attack surface management
An attack surface is anything related to an application or service (both terms apply to database engines and applications that use them) that provides a focus for attack. Managing attack surfaces means:
- Monitoring threat intelligence (in this case as it relates to databases and related clients, applications, and services) to understand if the current threat landscape includes any applicable items. If so, the organization will need to mitigate or remediate such threats on a schedule consonant with the risks they pose.
- Applying security patches and fixes to such database engines, clients, applications, and services as needed (often, as part of a regular maintenance schedule, or as part of an automated attack surface management environment).
- Managing physical security for databases, by keeping database servers in secure, locked, access-controlled (and -monitored) environments.
Conclusion
While this is not a complete or comprehensive treatise on database security principles and practices, the foregoing list hits most of the high points in this arena. Certainly, security deserves a top-of-mind share in establishing how an organization deals with databases across their entire lifecycles. Those who follow best principles and practices of database security are certainly subject to reduced risk – a situation in which all well-run and successful organizations would like to find themselves.
