In part 1 I talked about introduction to the security world and important terms. In this post I will introduce database security, what it means and what we can do about it.
Link to the previous post: part 1 – general introduction to security
The database is the heart of the organization’s data. People want to lay a hand on it to get sensitive information (such as credit card information or salaries of employees) or change data (such as money transfers or billing). Another option is simply take the database down, so all the applications that use this database will be down.
Some people might say that this is the reason that their database is not exposed to the internet and by that they protect it from attacks. This is important, as the database server should not indeed be connected to the internet (too many do, though), however, a hacker can access in other ways. One of the famous hacks lately was to RSA Security in 2011. In this breach, the hacker used an email that contained malware and managed to get one of RSA’s employees to open it. The malware installed itself, allowing the hacker to access the network from inside. The hacker then could access servers that were not connected to the internet.
So even if the database server is not connected to the internet, we need to secure it, because an attacker can use an internal machine to connect to it, and because we also need to secure it from internal “attackers” (malicious or not).
One aspect of protecting our database is the infrastructure layer. In this section I include the OS (users, passwords, etc.), the network (access control, listener configuration) and the database itself (the installation, database features and more).
There are also issues outside of the database server itself. For example, we can secure our database server perfectly, but give everyone access to our database backups.
I till discuss this in the next post.
Another aspect of protecting our database is the application layer. We can secure our database as much as possible, but if the application that connects to it has DBA privileges and allow any user to execute anything, we lost the war before it even began.
Under this “application” section I include application permissions, application SQL and PL/SQL code, passwords, etc. I also include here the developers and their access to the different databases. Note that I won’t include actual code security (like C and Java known issues, etc.)
I will talk more about this topic in the forth post (after the infrastructure one).
Besides the application and the infrastructure, there are some other things that should be taken into account, regulations for example. Many organizations today should be compliant to regulations such as PCI if they store credit card numbers, HIPAA for health care information, etc. These regulations require certain actions to be taken on the database and environment. I think that any organization that needs to comply with any regulation, should take another step forward and harden and secure its environment and database as well as it can, and not only to comply.
Another topic here will be security products that provide access control, auditing and alerting mechanisms. They usually provide a very good protection, eliminate some hardening steps, and provide an active guard against attacks.
The last topic is duplication of the database. Many organizations protect their production database, but then copy it for development or QA purposes. The copied database contains the exact same information as the production one, but is far less secure. The best practice here is to scramble the sensitive data so the database is usable but contains incorrect or unusable information. There are several tools for that, including our very own JumbleDB.
In this post I talked a little bit about database security. It was still a theoretical discussion, but we need to understand this world and concepts before really talking about the details, which will be in the next post.