Pete Finnigan's Oracle Security Weblog

I recently released part one of a three part post about securing data in an Oracle database. That post was titled "Securing Insecure Oracle Databases" and can be read by following the link.

As we discussed in the first post there are two tracks that we can follow to secure data in an Oracle database. The first is to review the database for security issues and then fix them and therefore secure the data in the database. The second is to use some software or blocking tactics and prevent an attack from getting to the database. For the second option we also really need to know the current security state of the database before we can design and implemented rules and tools to prevent attacks. These could be Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), Database Activity Monitoring (DAM) solutions and more. In essence these are barriers to stop attacks. These products/tools on their own cannot prevent all attacks and some must be prevented by good security design in the first place. For instance if you have granted SELECT, INSERT, UPDATE and DELETE to all users and with admin rights then SQL Injection is not needed if most staff have direct access to the database.

Before we can secure any database we need to first of all recognise that we are not securing Oracle (the database), we are securing data that is held - or not - in a database. That is the goal, to secure the data.

So before we can secure any database (data) we need to know the current state of the security so that we can assess what is right and what is wrong. We should do this by performing a detailed audit of a single relevant database. We do not need to audit every database at this point as the purpose is to get a clear picture of the current data security in a relevant database. That database should be production so that its relevant. If you audit a copy or a test system it is not used so there is no evidence of use or abuse of that database.

The next stage is to review any existing security standards, guides, baselines that exist in the company; ideally there would be an Oracle or database standard but its unlikely, most companies do not have one already. BUT, any existing overall security standard can feed into this process; particularly any access and use policy that stipulates rules around authentication, permissions etc

We should not be starting to fix anything at this stage BUT we must know what budgets we have in terms of time and money. If we create the most fantastic security policy with 200 counter-measures in it then its useless if we have only one day a week available for fixing for 6 weeks. It sounds like an oxymoron BUT its better to focus what you can do based on your budget; its realistic. If you create a 200 clause security standard and only have limited time and no one managing it; then the time will not be spent wisely. Its better to understand your budget and spend that time to improve the data security as much as possible for the budget that you have; and then next year or next project improve and improve again going forwards.

We must create a data security policy based on budget, time, what we found in the audit and existing standards. This can be a data security policy document but it should also be a baseline standard or even scripts to secure new databases. Put a stake in the ground and from this point forwards all new databases should be secured; in this way the security of data does not get worse. Also its easier to start to build secure databases as this can be part of the build process; this is easier than fixing existing databases.

Once you have a standard / policy for secure Oracle databases then you must go around and audit every database to test them against this standard.

We then must think about securing all of the existing databases. This also is not an easy task if you have hundreds or thousands of databases. This can be done manually but it would not be practical especially when database security often needs to be re-applied after lock down. This is often due to upgrades, patches and maintenance of the applications and database that resets security back to insecure settings.

We must plan fixing and strategies carefully.

At a high level securing a database consists of these groups of tasks; 1 - patching, 2 - hardening, 3 - actual data security. The actual data security can be broken into a number of sub-categories as well a) database access controls, b) user privileges, c) data access controls. Finally we can layer context-based-security; either home grown or products from Oracle such as Database Vault, TSDP, VPD, OLS etc

Securing data is expensive in time and effort; this is why data security should be part of every database project and planned in from day one and continued until the database is de-commissioned.

In the next post we will discuss the third part of this series and cover monitoring

#oracleace #23c #21c #19c #oracle #database #security #databreach #audit