Start with the Data and Secure UP!

In my experience of reviewing customer databases for security vulnerabilities, security settings or coding issues. These are the top three I have encountered:

Combine the rise in data breach with a lack of proper, thorough and well-designed data security, as well as a lack of audit and accountability, it should be no surprise that data is stolen and we do not immediately know when and why, or by whom

Securing data in an Oracle database can be broken into a number of layers – these fall into two categories, general hardening and actual data security:

- Patching: Security patches improve the overall security stance of the database but generally do not secure the actual data specifically.
- Hardening: Following checklists such as those of the CIS or USA STIG is beneficial and also indicative of a security regime but again these measures do not specifically address security of your data.
- User Security: Understanding exactly who accesses your database and how and with what rights and then adhering to the principle of least privilege will improve your data security immensely.
- Data Security: Complementary to user security, is data security. You must understand exactly who and what can access your data. Controlling data access controls will help secure that data.
- Access Controls: Oracle provides a wealth of functionality and options to limit who and what can connect to the database and then to what objects and resources within the database. Deep control over these factors will provide deeper data security.
- Context Based Security: Finally Oracle allows us to control at a cell or row level or a schema level deep access controls based on factors that allow, for instance, Fred to see data on Friday between 2:00pm and 2:15pm and only if he uses a specific application and authenticates via single sign on. This is the most powerful and detailed way to control access to data.

How do we implement these ideas, with what and how? The starting point should be to assess existing data security policy if it exists, or create one if it does not. A detailed security assessment of a database bringing in a review of user’s rights and data types and access controls should be performed.

This assessment can be done as manually or aided by tools such as PFCLScan to assess the database in detail for vulnerabilities.

Data can be encrypted and protected with tools such as TDE and Oracle Database Vault and even keys managed by Oracle Key Vault. Specific sensitive data can be located and masked with Oracle Data Redaction, or for non-production environments with Oracle Data Masking or tools such as Delphix. Vulnerable PL/SQL code can be located and protected with tools such as PFCLCode and PFCLObfuscate.

Detailed relevant audit trails should be designed and implemented to ensure that breaches can be alerted and tracked. If the worst happens then a detailed Oracle forensics and incident response approach should be created; I wrote the book on this!

Protecting an Oracle database and the data within it is a combination of consulting, policy creation, useful third-party tools, Oracle security products and expertise.

Knowledge sharing is very important, and I have singled it out separately here. Database security suffers from a lack of knowledge in what can be done to secure data in Oracle and what the issues and threats are. Oracle is a complex beast and understanding why and where issues occur and then what to do, is important. I have been educating people about Oracle security successfully for many years.

What about the cloud? Whether the cloud is Oracle Cloud Infrastructure or Amazon Web Services, Microsoft Azure or Google Cloud Platform, or indeed any cloud that supports an Oracle database, there are many layers to be concerned about, but the first is the database, the application and its data. A database in the cloud is just the same security wise as a database on-premises. Of course the cloud brings its own nuances, but infrastructure-as-a-service, or platform-as-a-service, all still mean using or deploying an Oracle database into a cloud. The same issues above need to be considered as they are indeed the same whether the database is in the cloud or not. Because of cloud we also need to be aware of producer/consumer issues as well as the possibilities to secure the cloud infrastructure itself, but the database security remains the same.

Finally, good security design underpins everything; it’s the rock. Even great products need to be designed, configured and implemented securely.

Let us help you ‘Secure UP’ now!

PeteFinnigan.com are the experts in Data Security on Oracle Database and DSP- Explorer are the experts in Oracle Database Services and Oracle Licensing and we frequently work together, to deliver a winning combination for our customers. 

About The Author

Pete Finnigan is a widely regarded expert on the subject of securing data in Oracle databases. Pete was very influential in setting the standards used across industry to harden and lock down Oracle databases. He created the SANS Oracle security step-by-step guide that was the original source for the Centre For Internet Security standard for securing Oracle databases.

This standard is closely reflected by other standards for Oracle such as NIST, USA DoD and ISACA. Pete speaks regularly at conferences worldwide and is the author of a number of books on Oracle Security.

He runs his company PeteFinnigan.com Limited which provides training on all aspects of securing Oracle, Security health checks, Forensics, consultancy and design and also sells three software products; PFCLScan to perform your own database security health check and PFCLObfuscate to protect the IPR in your deployed PL/SQL and PFCLCode to review PL/SQL for security issues.