As John Verry and I discussed in a recent virtual CISO podcast episode, many people think of database security as they think of bank vaults. They secure the perimeter, place the valuables in the vault (database), and then assume those valuables are as safe as if they are in the bank vault.
How Database Security and Bank Vaults Differ
If a thief gets past the physical security at the bank (doors, locks, window bars, alarms, they will still have a very difficult time getting in to the vault. (unless it is an inside job — more on that later).
But when we think of a database as a bank vault, we are missing an important difference. Bank vaults have a single point of entry, and it is secured by a complex locking mechanism that will thwart all but the most talented criminals.
Databases on the other hand, have many points of entry. Numerous administrator accounts, potentially hundreds of database user accounts, application accounts, operating system accounts that have access to the underlying data files, accounts in other databases that have access to database links into your database, network sniffers, the list goes on and on.
The Manufacturer Takes Care of That! Or Do They?
A bank vault manufacturer ensures that all of the seams on the vault are sealed properly and that all of the walls are resistant to power tools. They ensure that, in essence, there is only one point of entry. Providing more than one point of entry would render the safe less secure and would render the safe less useful.
Manufacturers of database software, on the other hand, work hard to provide as many points of entry as possible. User accounts, web services, database links, export utilities. Providing only one point of entry would render the database much less useful.
If Not the Manufacturer, Then Who?
It is clear based on these competing interests that the database software manufacturer is not and cannot be responsible to secure the database. Nor can the database host, whether this is an MSP or cloud provider that provides the server on which the database runs, or the database host in a PAAS (platform as a service — think RDS or Aurora) environment. All of these parties must provide as many points of entry as possible in order to make the databases valuable to the broadest set of customers.
Database and security professionals with a clear understanding of all of the entry points, and who work closely with the data owners or data security team, are required, in order to bring the security of a database even within reach of that of a bank vault.
More on the Inside Job
I promised more on the inside job earlier: Whether we are talking about a bank vault or a database, an insider with bad intent can render many security controls ineffective.
In a bank, an insider with the vault combination can easily bypass the most challenging part of getting to the valuables. They don’t even need a blow torch or explosives.
With a database, it is more complicated than that: An insider with a password can easily bypass both the perimeter security and the database security. At first glance this makes the database appear less secure than the bank vault, and it is — most of the time.
How to Close the Gap
There are many things that can and must be done in order to ensure that a database is and remains secure, including patching to remove known vulnerabilities, ensuring proper Disaster Recovery is in place and ensuring that encryption at rest and in transit is used. This article is about how a database differs from a bank vault, so I will only mention the points relevant to that comparison here.
In order to close the gap between the security of the bank vault and that of the database, we must eliminate or lock all unused entry points, and restrict access and track use of the remaining entry points.
While databases have many entry points, when configured properly, most enterprise-level database tools have very granular levels of control. Combining these granular levels of control with solid security procedures, we can significantly tighten the security of the database.
Some Examples:
- Restrict the time of day that a user has access to and the machine that is being used to connect to the database with a particular username.
- Audit all activity in the database, including the username, machine used, activity, timestamp, and other information, and take action quickly if we see activity that looks suspicious in order to reduce damage.
- Insist that all privileged database users have individual usernames, that they are protected by two-factor authentication, and that their passwords are robust.
- Have procedures in place and enforced to remove access immediately as part of the termination process for employees or contractors.
These practices, together with others, can render a database as safe (or perhaps even safer) than a bank vault.
But when a database instance is spun up by a developer with no Database Administration or security expertise, it is more accurate to compare the database to a cash register at the local convenience store than to a bank vault.
Listen to the conversation that John Verry and I had about this and other database security topics, and let us know what you think about how well people are protecting their critical data assets.
For more information or to schedule a consultation, please click here to contact Buda Consulting.
