Database Hardening by DBA.nl: Your Oracle Database as Fort Knox

In almost every organization the most important and most structured data is located in a few critical tables within your (Oracle) databases. The database becomes your Fort Knox, your last defense against the theft of your most important data.

On 25 May 2018, the General Data Protection Regulation will be introduced in the Netherlands, the Dutch answer to European legislation ‘GDPR’. You are probably already familiar with this legislation. You may even be designated as a “Data Protection Officer” (DPO) within your organization. A title with responsibilities. But how do you deal with this?

Oracle Netherlands has started using various Enterprise Edition components when it comes to data security, these components are often associated with significant costs. However, did you know that there are also plenty of things that you can even tackle in a Standard Edition environment, in many cases even without impact on application use?

At DBA.nl we use our many years of experience with complex database environments to be able to offer you advice and service regarding your database security. The steps below provide guidance for your database hardening:

1. Determine and limit where your “gold” is. Your most important information.

If you have not yet done so, it is important to map out as soon as possible in which locations your most important information is located. To this end, it is useful to create a classification in important information.

Guidelines have been drawn up within the GDPR for what kind of ‘personal data’ this is. The authority personal data says about this:

There may also be other data which are not regulated by law, but which you would like to see protected. Think of credit card details or passwords of end users. The first step is to determine where your “gold” is. Which databases, applications and servers have access to such sensitive information.

In practice, system and application administrators and/or Enterprise architects often know well which databases contain this sensitive information. However, access to backups, automated backup copies, non-anonymized test and development databases and application servers is often forgotten. DBA.nl therefore advises, among other things, to apply anonymization scripts to OTA databases, to visualize where and for how long backups are stored, and to clarify in which tables within the database the most sensitive information is stored. The latter is often difficult.

2. Create a guest list for your database and update it regularly.

Institutions such as Fort Knox maintain a guest list of who comes in at what time and when they might leave. Within your database it is important to monitor which applications and users have access to your environment. It is also necessary to ‘block’ users and applications that no longer need access to your database. This includes employees who are no longer employed, applications that have been replaced or updated and rights packages for users or applications that are no longer needed.

3. Map out which doors need to be opened (and close the rest).

When an authorized employee, for example a cleaner, walks into Fort Knox, it is not a problem. After all, the cleaner has sufficient security clearances to clean the corridors of the complex. However, when this cleaner takes “service entrance 3” every day at 08:00 to start his work, it is of course nonsense to keep both the front door and all service entrances in the complex open all day.

This is often what happens within databases. In accordance with its function, the database must be accessible for applications from other servers. However, it is not necessary to give every application or user access to the entire database through all possible entries.

In practice we see that it is difficult to keep track of which entries your database has and which are used: What limitations does the listener have and by which users can the listener limitations be adjusted? Which links are available? Which applications can all access your databases. From which application servers is access to your databases necessary? Are data connections encrypted?

4. Monitor and determine what is done with monitoring information.

Inside Fort Knox there are cameras everywhere that keep track of what is happening inside the Fort. If you have the (free) database auditing component enabled in your database, the same will happen there.

In practice, however, the difficulty is not turning on the monitoring, but the interpretation of this data and acting on suspicious behavior: It is as if there are cameras inside Fort Knox that are on, but no one is looking at the camera screens. This monitoring information can often be viewed retrospectively, but there is no trigger for this to happen. This means that monitoring is effectively turned off and deviant behavior (for example the cleaner who suddenly comes in at 11:00 through another service entrance and is carrying a drill instead of a vacuum cleaner) is not detected. This while precisely in a digital environment these notifications can be automatically drawn up and digitized.

Another extreme that often happens is that too much information is monitored. After all, your database is intended to facilitate frequent consultation and writing of data. This doesn’t seem intuitive. After all, complete data gives the illusion of complete control. However, if the security system issues a notification every few hours, these notifications will soon be ignored. The risk that the burglar in Fort Knox will behave in the same way as the cleaning lady is minimal. More importantly: This can’t hurt. It is often more practical to focus on fluctuations in behavior. Good support for database audit files gives you the opportunity to easily adjust this yourself and to be notified of fluctuations in database behavior.

How can DBA.nl help you with this?

The security scan developed by DBA.nl offers you a one-off overview of user access, auditing and technical vulnerabilities of your databases. You will receive a report on the steps to be taken and a full assessment of your database hardening, including listener.

We can also support you in setting up effective database auditing jobs and we can map out both the used and open database access options for you.

Finally, we can support you during the implementation of Oracle’s advanced options. See this article for this.