Call: +44 (0)1904 557620 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

ERP Oracle Database Security

I did a talk at the UKOUG in 2020 about ERP security and its affects on Oracle database security. I have just uploaded the slides from this ERP Security talk to our website so you can download and have a read. I have also updated our Oracle Security white papers page and added this talk slides.

My experience of auditing Oracle databases that are supporting ERPs such as JD Edwards, EBS, Peoplesoft, SAP and more is that often there is a tendency to not consider the database as part of the overall security of these systems. Often the security is driven from the ERP level and via settings and configuration at that level and little thought is given to the security of data at the database level. The company and others view the Oracle database as a sealed unit that cannot be changed, looked at or tampered with; i.e. security. At a high level an ERP can be looked at in a security way for Conflicts of interest. Separation of Duties, Fraud, limits, menus, access controls, business level controls, compliance and more. All of this is measured and controlled at the ERP level BUT the controls and settings are mostly stored in an Oracle database and usually that database does not have deep levels of security (sealed unit problem). Most users and security and admin access the ERP at the ERP level.

The security issue is obvious; no audit trails in the database to see what is happening directly in the database. Data thieves don't care about following the ERP route to the data they are happy to go direct to the file system or the database and there are often no controls at the database level either so access is easy. I discuss the threats to the data by direct access outside of the ERP. I show how data can be stolen and where the ERP owner should focus to make sure that the data in the Oracle database that hosts the ERP can be secured.

I show a simple example for instance in a JDE database where almost all tables have INSERT, UPDATE, DELETE and SELECT granted to PUBLIC; so any one who gets direct access to the Oracle database can change or read any data including security data.

If you run an ERP on Oracle you must consider locking and securing the Oracle database.

#oracleace #dbsec #erp #oracle #database #security #gdpr

Oracle Forensics Response

I have spoken a few times on this blog about forensics and Oracle and in 2021 I did a talk at the UKOUG about Oracle forensics. I have just posted the slides from that talk just now to our site. This is OracleIncident Response and Forensics and I have also updated our Oracle security papers page and added a link to these new PowerPoint slides.

The talk is about what to do if there is a breach of an Oracle database. This covers the response process which is in essence a checklist of actions to take when there is a breach and also some suggestion of who should be involved and why. The first step is to assess what if any incident has occurred and if we can prove the incident is real then we must hand over control to the incident co-ordinator. This person manages the process and who is involved and what access is granted and allowed. I discuss this process in details so please have a look at the slides.

The next step is to do Live Response. This is the process of gathering the evidence in the correct order so that the evidence gathering itself does not affect the evidence! So in simple terms you may want to gather SQL statements that have been executed to see if any of them are dodgy BUT gathering the SQL statements means running SQL so this affects the historic statements. We discuss this and other issues in the area of gathering evidence in the slides.

The final part of a breach response and analysis is the process of actual forensic analysis of a breach that has occurred in the Oracle database. This means placing the evidence in time line and assessing if its relevant to the investigation and what part does it play and what other evidence must be gathered or sought. We aim to ask certain questions:

  • Was there a breach?

  • How did they get in?

  • Who did they get in as?

  • What did they do?

  • Did they change anything?

  • What could they have done with the reach they had if they had more skill?


The slides cover a lot more material and they are new to my site, so please have a look

#oracleace #oracle #database #forensics #security #gdpr #liveresponse #databreach

Database Vault without Database Vault

I did a talk in Slovenia in 2022 that explores the questions, "What is Database Vault?" and "What can we do if we don't have Database Vault?". I have posted the slides to our website today and the talk is Database Vault without Database Vault and I have also updated our Oracle Security white papers page and added a link to this talk.

This is an interesting talk and its split into two halves. The first part looks at what is Database Vault, what are its main components and also a little on hacking database vault.

The second half of the talk is the more interesting part and is focused on how can we achieve the same results or close to them if we don't have database vault. The obvious case for the need to do this would be in a database that is Standard Edition where we cannot use Database Vault. The other key element is doing it for free with standard security features of the database. Lets be clear, we cannot 100% simulate Database Vault for free as Database Vault is built into the Kernel C code and cannot easily be bypassed because of this. We can however get similar effects for some of the ideas in Database Vault using views/code/contexts and also triggers and also by careful design of users and privileges and use of users such as SYS and SYSTEM. If we would like the better security of Database Vault and don't have it or cannot use it this is a start for what we can do.

This is a great talk and I enjoyed writing it and presenting it. The slides are new on my site, please have a look

#oracleace #23c #dbsec #oracle #database #security #vault #lockdown

Create Onion Layers of Security

I did a talk in 2022 called CreatingOnion Layers of Security and as you can see from the previous link I have posted a pdf of my MS PPT slides to our website. I have also added the talk to our Oracle security white papers page.

This talk outlines a little history of securing Oracle databases and focuses on the message I have given may times in talks and here that we are securing data not Oracle the database. Of course we use Oracle the database features to secure the data BUT the focus is to secure data and not to simply tick a box that we have secured Oracle.

The talk goes on to discuss all of the layers we can implement to help secure data; this includes OS security, hardening of the database (parameters, defaults etc) and then user security - i.e. least rights for every user of the database and then data security; the problem from the others side. We need to limit access to the data completely. We must also consider access controls; i.e. who can access the database and why and when and how and limit that access. On top of all of these we can use context based security models such as Database Vault, TSDP, OLS and more BUT we can also do the same or similar using the features of the database ourselves. On top of that we must layer a proper and useful audit trail.

Finally we could consider what I talked about in the last blog post which is adaptive audit and adaptive security. The slides linked above give a lot more details on this subject and a good overview of what is needed at a high level to secure data in an Oracle database

#oracleace #dbsec #23c #oracle #database #security #audit #databreach #lockdown

Adaptive Audit and Adaptive Security

I did a talk at the beginning of the year virtually in Slovenia at a security conference. The slides are available and I have added the paper also to our Oracle Security White Papers page.

I have spoken about this subject many times over the years and its one that I particularly like. The idea is that you could have different levels of security or different levels of audit trails dependant on the current circumstances in the particular database that the adaptive security or audit trails refers to or across the estate.

A good example would be in Sherlock Holmes (the modern one) where Moriarty is stealing the crown jewels in the Tower of London and the sirens go off and the whole room is locked down and doors closed and shutters down and the police and security services are heading in. This is what I would think about with adaptive audit trails and adaptive security in the database.

Audit trails could be expensive in terms of cpu and storage of the trails themselves if we had a much more detailed audit set up running all of the time.

The audit trail is an important part of any database forensics investigation. If we find a breach without an audit trail it becomes much more difficult to get to the answers of how they go in, why, what did they see or steal and what could they have done with more time and effort. With a detailed audit trail it is of course much easier to answer questions like this. BUT, the compromise, do we need really detailed trails all of the time or could be be running at defcon 5 and when a breach is suspected move to defcon 4 or happening move to defcon 1.

We can do this with adaptive audit trails. Include enough events that we for sure detect an attack but when its detected up the level of audit trails; even more than once. Then we get minimal audit and storage and CPU requirements most of the time and during the attack we get whats needed for a forensic analysis.

The idea can be adapted to Oracle database security as well. As the attack is confirmed we can also lock down the database security much more. The same effect as the Tower of London. The database being attacked could also signal other databases in the estate to also raise their audit trail levels and also raise the security.

There is a problem of course; there always is a problem!! If someone who is attacking knows that this model exists he/she could simulate enough of an attack that causes the audit trails to rise and security to lock down in all databases causing a Denial Of Service for users of the applications that run in the databases.

This is a very interesting area for me; have a look at the MS PPT above

#oracleace #dbsec #23c #adaptive #oracle #security #audit #audittrails #databreach #forensics

Securing Data in Oracle Databases

I have been going through my laptop and found that I have quite a few presentations on my laptop that have not been uploaded to our website so I have decided to start to upload a few one by one.

The first presentation is called "Securing Data". This is also posted to our Oracle Security white papers page.

This talk is a high level view of securing Oracle and includes why to do it and examples of fines and breaches as well as a detailed discussion of what is involved and the steps needed. This is a pdf of the MS PPT slides from this talk. I first gave this talk at the Oracle Security day in London hosted by UKOUG and this was the key note speech by me. This is a slightly later version of that talk, this time given this year in an online event.

#oracleace #dbsec #oracle #database #security #23c #ukoug

GDPR and Oracle Database

I wrote a short blog post last week regarding GDPR and the Oracle database and discussed at a high level the main articles that could affect your security plans for an Oracle database.

As I said last week GDPR Speaksto users of Oracle that data security matters, data security should be by default and data security should be always enabled. It also Speaks of the need to have useful and usable audit trails so that if you are breached; ideally you know straight away and either block it and stop it or stop it and react as close to the event as possible BUT if you have decent audit trails you can know how the breach happened and how the attacker got in and of course plug the gaps.

If you have a good data security regime and have planned and implemented it and you have found all important (in the case of GDPR PII) data and protected it with pseudonymisation or encryption then the impact should be less - I am not the ICO or a lawyer so cannot speak for them BUT for sure if you don't have data security or an audit trail or encryption and don't know where your data is and record how its accessed and used (audit trails) then you will have a big problem with GDPR

I did a talk a couple of times in the past about GDPR and Oracle and the slides are here - GDPR for the Oracle DBA.

#oracleace #23c #dbsec #oracle #database #security #gdpr