When you (or anyone) designs a database and application then you design the code and the tables and views and data models and everything. Guess what? you are also supposed to design the hardening and security of the data in that application and database but inevitably this is never done as there is always a focus on functionality, performance and service levels.
Applications that I see that use an Oracle database also often treat the database as a simple box that they do not care about; To the customer it is just a blind data store and they (the customer/owner) feel it is someone else's security problem or they assume the designer made it secure without actually checking themselves whether the data is indeed secure.
A lot of applications using a database clearly do not take data security as seriously as I do. If a database and application already exists then there is usually no appetite to change the design or database or harden it; usually because of fears that the functionality will be broken or the performance degraded by adding security to the data itself.
This is made worse by a lack of security knowledge around Oracle databases or databases in general. There is also usually no business driver to spend money to secure an Oracle database unlike performance issues where there is a clear requirement to make the applications function properly to maintain the business.
We can summarise a number of problems to solve in our goals to drive towards secure data
- Legacy and commercial databases don't usually exhibit much security at the data level
- Lack of appetite to fix the security of the database that exists already for fear of breaking the database or applications or creating performance issues
- Lack of specific Oracle data security knowledge in security teams or DBA teams
- Vendors won't spend money as they can't get more money from their existing customers to fix their own products
- Internally often there is no budget or money to drastically improve security of data as there is no business driver. An actual breach will change that of course but in advance of a breach; no chance!
How do we solve the problem of fixing legacy (existing) database security?
This is a major issue and at a simple level there are two options:
- Detection and Prevention: Locate all the security issues in the database and fix them so that the database and application are protecting the data that they process and store
- Detection and Prevention: Detect attacks as they approach the database - maybe from SQL Injection sourced in the application by an attacker or a SQL*Plus user connecting to multiple accounts or a support person making changes to the database in production, or??
As you can see both are really classed as detection and prevention. On one side we can review a database and find out the set of security issues and develop a cost effective plan to fix those issues and prevent an attack because the gaps are closed. On the other side we can detect threats as they happen in a database that has not been fixed and secured and report these and potentially also prevent them. In this case it would be via an intrusion detection and prevention system.
Interesting that both angles are really the same but work in completely different ways. In one case we spend a little money to understand the problems (review and vulnerability scanning) and a lot of money fixing the issues to prevent attacks and in the other we can spend a lot of money to purchase IDS/IPS/Database Firewall software and then configure and set up to track database activity; we also need to buy licenses and this is the ongoing cost also quite high. As we know Oracle have included a SQL Firewall in the database in 23c. My three part papers on the SQL Firewall are available.
Which is the best approach?
Fixing has low upfront cost and complexity and high back end costs. Blocking traffic and actions has medium up front cost and complexity and medium to high back end cost.
We can do both solutions of course!
In both cases neither is a one stop process that is done once. We need to revisit hardening and we also need to revisit threat detection. New knowledge, versions of applications and database and changes occur so we must constantly update our data security.
There are products and features available from third parties and Oracle themselves to help protect data in a database. Oracle for instance focuses on the addons such as Database Vault or VPD or Encryption, masking and more; third parties focus in providing products to help analyse and secure data in databases. Some third parties provide network scanning and IDS / IPS / Firewall technologies
What about the cloud?
A lot of companies are moving data and their Oracle databases to the cloud. Whilst this makes sense from a budget perspective and that the cloud infrastructure is probably better in security terms than some on site data centres the fact that a database is badly designed and insecure on-premise doesn't magically change when that database is moved to the cloud. A database no matter where it is must be secured at the database level in terms of securing the data that is held and processed.
The ideal goal in terms of securing existing databases and particularly those going to the cloud is to just click a button and it is then secure or select a service with no customer input to it's setup except click deploy/install and we are protected.
We are not there yet and these ideal goals are hard to achieve with a click of a button but we can analyse and secure databases and we can detect attacks and do the work to secure databases piecemeal. Anyone running an Oracle database can do this. The key is to create a plan and understand what you budget is and what you want to achieve and what you can achieve with your budget.
This is planned to part one of three articles. The next parts coming soon are:
- Review an Oracle Database for Security Issues and establish what needs to be done to secure your data with a discussion on how you can harden your databases
- Detecting Attacks Against an Oracle Database
#oracleace #23c #21c #19c #cloud #oracle #security #lockdown #databreach
