Pete Finnigan's Oracle Security Weblog

Firstly I was very pleased to announce that I have been made an Oracle ACE Pro again for the year to come. I just received the Oracle ACE tee shirt, polo shirt, jacket and of course the ACE Certificate. The Oracle ACE program is great and brings together a lot of enthusiasts for the technology. Of course I specialise in Oracle database security and everything related to that subject. From security auditing, audit trails, secure coding on PL/SQL, forensics of databases and all of the features and technologies that relate to securing data in an Oracle database covering such features from time to time as Database Vault, VPD, OLS, TDE, Masking, Encryption and much more.

You can always read about what I am looking at here in this blog and also on all of our social media channels on Twitter (X), Facebook, LinkedIn, YouTube, Instagram and Threads where we also bring Oracle security content.

I am also interested in PL/SQL and write in languages such as PL/SQL, vb.net, Lua, C and others to a lesser degree. I keep promising to publish my series on writing a language interpreter in PL/SQL for a simple language and I will publish it. We have been very busy of late with the new versions of our software so this series will come as soon as we get a gap in the schedule to edit the content and then post.

We have also been digressing lately with the website dealing with broken links - we wrote a tool to find these and its worked well; we find more broken links than some other software we tested. We have also started to prepare the website for HTTPS. I know its still HTTP and some people message me from time to time to tell me this. The only reason to make the change really is because Google insists.

The site is not dynamic and we don't collect an data personal or any other data so there is nothing to protect as such BUT we are working on the change but the site is large (depending on how you count what is a valid page/file we have between 6.5k and 10k pages. Some such as .sql files are displayed as tools, examples but they are not web pages hence the counting issue. We get around 200k visitors a month to the website and have around 42k connections/followers on social media so we need to be careful with any big changes.

Onto TDE; a week or so ago David posted a short article on LinkedIn extoling the virtues of TDE and why people should use it to protect data. The post didnt have a title as such but stated "I use storage encryption, do i still need to encrypt the database". This is a short article and the main point that I got was the fact that PCI-DSS states that storage encryption is not sufficient to protect the data as the transparent nature of the storage encryption means that if an attacker gains access to the server then he/she can read the files and in particular the data files.

My comment was:

"
Hi David, Thanks for the short article. I agree TDE is useful but as you say "anyone who has access to the host can access data without logging onto the database" - The access is much narrower than this though. The access that would cause an issue is access to the datafiles and usually this is only the software owner - often called "oracle" or in the OINSTALL group. This access is usually limited as I say to the software owner so if you as an attacker have access to "oracle" then the problem is bigger. Then the attacker can simply do "sqlplus / as sysdba" and access all data transparently decrypted.

Similarly at the database level if the application grants access to the data that should be protected to public then any database user can access the data as its transparently decrypted.

You need a more rounded solution; with database permissions, connect protections, OS level restrictions on access to "oracle" and more

You should also implement a comprehensive audit trail in the DB and OS on the data that should be protected
"

The same issue in effect applies to TDE as per storage encryption; this is Oracles storage encryption and as such it transparently decrypts the data for viewing via any SQL interface. So if you have access to the server as Oracle then you can access the database as SYSDBA and read the data as can any user who is able to access the application.

The key message for me is that this is a layer below/above? storage encryption and the attacker needs privileged access to exploit it unless the application is lax in permissions and allows everyone to see data.

As I said in my comment on Davids article we need a layered approach to protect access to the OS and the database and also around data security itself and permissions and access designs.

Lets be clear TDE is a good product and useful but its a tool and as such must be combined in a complete design to protect the data at all levels


#oracleace #sym_42 #ukougtag #ukoug #oracle #security #tde #encryption #datasecurity #databreach