Fundamental Oracle Security

June 2023 – Oracle 19C

Image from https://unsplash.com/@kellysikkema

Frequently I turn up at companies to resolve performance issues and migrate and upgrade systems. However, I have spent a fair bit of time recently working on security, from audit to helping with ransomware issues. The profile of security has increased significantly in recent years and I find that many companies are not even doing the basics. This is a short series of blogs showing the steps that everyone should be taking when commissioning new databases before a drop of code has been deployed. It can also be retrospectively added to existing databases, but that will take longer as there are many opportunities to cause an outage when implementing new security features.

DO NOT THINK BAD THINGS WILL NOT HAPPEN TO YOU!

Given enough time, they will. Make it harder for the hackers and data thieves, especially those within your organization.

The hard part of security is getting everyone to play by the rules. This is especially true of DBA’s, who can generally bypass any implemented security – and frequently do in the name of making their job easier to do. It’s true, minimising the level of security makes your job easier, but also makes the job of hackers easier too. Hackers aren’t all sat in dark rooms on foreign shores saying “Use SQL to corrupt their databases…”. Many data breaches are internal to your organization. Do you have sufficient monitoring and auditing to catch anyone extracting (large quantities of) your data, and the structures in place to prevent them from externalising it from your organization?

What standards are you looking to enforce? There are quite a few out there. You initially don’t want to be too extreme – switching from loose to very locked down in one step is quite dramatic and will alienate users and administrators alike. A good starting point is to take steps toward compliance with the Center for Internet Security (CIS) Benchmarks. You could then look at the STIG requirements (from the US Department of Defense Security Technical Implementation Guide) for further inspiration, or PCI-DSS standards used by – but not limited to – the payment card industry. For many organisations it will be difficult to comply with CIS standards, never mind anything more stringent – but getting close to compliance will make your systems harder to hack and will keep your data more secure. You also need to consider if you are overburdening the teams with excessive rules and processes to access your systems. The more layers and complexity you introduce, the more people will find workarounds to make their lives easier. Find the right balance.


Implementing Security

Oracle provide a lot of security features as part of the basic license, and a few cost options to enhance security and auditing too. This blog series will largely concentrate on what you get bundled with Enterprise Edition. However, you need to implement the features! No point having locks if you don’t use them!


There are many steps to take when securing a database. Click on each title to view the relevant blog post:

Fundamental Security Part One – User Profiles

Fundamental Security Part Two – Password Complexity and Defaults

Fundamental Security Part Three – Unused and Historic Accounts

Fundamental Security Part Four – Permissions Checking

Fundamental Security Part Five – Observability

Fundamental Security Part Six – Network Encryption

Fundamental Security Part Seven – Data Encryption At Rest

Fundamental Security Part Eight – Unified Audit

2 Responses to Fundamental Oracle Security

  1. Pingback: Fundamental Security Part One – User Profiles | Neil Chandler's DB Blog

  2. Pingback: Fundamental Security Part Eight – Unified Audit | Neil Chandler's DB Blog

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.