|Oracle Database Security Best Practices
|Many us us do not like the phrase "best practices" because the phrase conjures up the belief that there is only a single right way to do something. In Oracle there are a lot of different ways to do almost anything.
That said, you need to start somewhere and the idea behind this page is to give you a starting point. If you know a different way, or a better way, please let us know if you know a better way, to solve a security issue ... by all means test it thoroughly and use it.
Here at DBSecWorx we try to address security issues through optimizing configuration not by purchasing expensive products. That doesn't mean there is anything wrong with a lot of products. Some of them are invaluable assets. It just isn't where we choose to focus our efforts, because there is a multi-billion-dollar industry out there promoting those solutions, and almost no one else is talking about the basics.
|How Should I Work With My CISO and My Management?|
|When talking about security with your CISO and your management start from the following perspective:
So where to start? Here are are thoughts:
|How Should I Work With Vendors?|
|Before you meet with anyone selling anything ... tear through their website. Learn about what products the company sells and what those products do.
Also, and equally if not more importantly, compile a long list of what the product could do, should do, but does not claim to do.
When you meet the account representative ask them a carefully crafted question about something you know their products do not do or that you are highly confident they cannot possibly understand: Then listen carefully to their response.
Here's one I use but make up your own:
"A number of our primary production databases contain materialized log tables that contain PII information. Do you have something that will help us monitor who is accessing them?"
Well aside from the fact that there is no such entity as a "materialized log table" the question seems perfectly reasonable.
And our guess is that they will tell you that they have something they sell for hundreds of thousands of dollars that will solve that problem.
Keep what you just learned to yourself but be sure to communicate what you know to your management in a factual way devoid of emotion.
Do not be afraid to ask questions about what the product(s) likely cannot possibly do. For example:
"How does your product protect us from the glogin exploit?"
"How does your product monitor use of query rewrite?
"How does your product prevent misuse by admins with escalated privs?
If history is a guide then your management is going to squander millions of dollars buying something that sounds good from a guy that plays golf with them and that will do absolutely nothing to enhance real-world security. You did your best. Skip the beer, get a snifter of cognac, keep your mouth shut, and live to fight another day.
|How Should I Work With Auditors?|
|There are a couple of things you need to know about auditors. And, once you know them, you need to not share the fact that you know them with those auditors.
Rule 1: Auditors have never, in their life done your job
Rule 2: Auditors have no idea whether what you tell them is even vaguely connected with the truth
Rule 3: The auditor was trained to ask questions from a list created by someone that bears essentially no relationship to anything involving serious security
Rule 4: The questions the auditor asks may relate to previous versions and the answers the auditor expects may be technically incorrect
Rule 5: If the auditor finds out you are aware of Rules 1 through 4 you do not deserve to have your job
The best way to work with auditors is to understand that passing the audit is critically important to your management and to study all of the audit criteria which are always, from our experience, published and publicized.
Be sure that you are prepared with an answer to every question asked that demonstrates compliance. For example: If asked whether your data is encrypted the only correct answer is "yes". But is that encryption at rest and provided by the storage array? Is that encryption in place because of licensing Oracle Advanced Security and enabling Transparent Data Encryption (TDE)? Is that encryption due to encryption with DBMS_CRYPTO, or in the application? Are backups encrypted? Is network traffic encrypted? How about network traffic to DR? How about network traffic to the backup appliance? Answer the questions as generically as possibleDo not go into detail about what "is" and "is not" and if you can possibly answer a question with the words "Yes" and "No" then do so.
Does every database I manage encrypt its data? Yes!
|What Should I Do Today?|
|Find one object in a development database with privileges granted to PUBLIC and do the research required to drop the grant||Here is a list of Oracle built-in packages that
by default, and unnecessarily putting your database at risk, have EXECUTE
granted to PUBLIC. Work from this list to get things started
|What Should I Know About Every Database I Help Manage?|
|1. Who has access to the file system||
|2. Who has the ability to log into the database with with escalated privileges?||
|3. Who has the ability to log into the database with a command-line tool?||
|4. Identify every explicit grant of system privileges to PUBLIC||
|5. Identify every explicit grant of object privileges to PUBLIC||
|6. Identify every explicit grant of a role to PUBLIC||
|7. View your SQLNET.ORA files and see if they they contain the minimum configuration items to create a secure environment.||