Call: +44 (0)7759 277220 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.

[Previous entry: "Oracle 23c And Removing Traditional Audit - Part 3"] [Next entry: "GDPR and Oracle Database"]

New GDPR Book and the Oracle Database



I received a copy of Jamal Ahmeds book The Easy Peasy Guide to the GDPR last night. Of course I have not had chance to read it fully yet BUT I did have a read of the introduction and recommendations and I also browsed many of the Articles. This is a good book for getting up to speed with GDPR as it states the actual text from GDPR for each Article and the re-writes that in much simpler English. I will post a review when I have read it all.

I have done work on GDPR in terms of helping customers to do what is needed in the Oracle database to help their companies comply with GDPR. Of course complying with GDPR cannot be done solely by doing data security things in just the database itself. GDPR requires you to protect PII data throughout the business. This is interesting as this is what I have been saying for over 20 years. Oracle security is not security of the Oracle software itself; it is security of the data that is held in the database; we need to use Oracle security features to achieve this BUT we must start with data.

GDPR has been around quite a while now and during talks with people at conferences and at customers I am still surprised that so few (At least from who I have spoken to) have done a serious amount of work for GDPR in the database. I see companies that employ lawyers and legal means to comply with GDPR BUT GDPR is not just a law there are practical consequences and data must be protected and audited as well. If data is stolen a legal agreement doesn't stop it being stolen.

The GDPR speaks to us through the Articles as to what can affect the security of data in an Oracle database. Here are some of the key examples that must be considered in Oracle:

  • Article 4: Defines data, identifiable persons, pseudo anonymisation and more

  • Article 35: perform a data impact assessment and include current security measures

  • Article 25: Data protection by design and by default

  • Article 32: Security of processing including pseudo anonymisation and encryption

  • Article 30: maintain records of processing activities

  • Articles 33 and 34: Data breach notification

  • Articles 16 - 21: Data subjects rights - the right to rectification, the right to be forgotten...

  • Articles 5,6,15: Retention, training, policies


This is a summary; the key things for me that should be done in any database never mind if the data is PII or not is data security by design and by default. This Speaks to me; this is something I would do to protect data irrespective of GDPR or not. Another clear message that should play into any data protection work is audit trails for the database itself. We must audit what goes on otherwise we don't know we are breached and without an audit trail its difficult to know how and why it happened.

GDPR is good; it make sense for securing any data not just PII

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