DBSecWorx: Security "Best" Practices

Oracle Database Security Best Practices Versions All

Overview

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:

Your CISO doesn't believe you have anything useful to contribute to a discussion about security because that person's entire view of the universe is based on firewalls, email, auditing, and end-points
Your CISO does not have one hour's training on database security and being C-Level is not going to welcome an "in-house expert" making that apparent
Your management is going to focus on passing audits ... not security ... because they do not have sufficient education to know the difference
Your management is going to do what the CISO advises

If you want to improve the security of data and databases in your organization, and we hope you do otherwise why are you reading all of this, you need to start by establishing your credentials and credibility: Not just once but repeatedly.

So where to start? Here are are thoughts:

Link this website in your browser
Also link Pete Finnigan's website
Purchase, preferably with company funds so they know you are interested in the topic, books on database security
With permission from your manager ask your CISO's office to recommend a class you can take to learn about security. It may have minimal education value but it will start building your internal credentials and credibility
Send email from time-to-time, not daily or weekly, when you learn about a successful attack and can point out how your organization might be vulnerable to the same attack (be sure to stick to the facts ... no emotion ... no hyperbole)
Explore attending security conferences even if they do not have direct relevance to data and data security ... they undoubtedly won't
Learn about the full range of available security technologies and products so you know what they do ... and equally importantly ... what they cannot do

Then, start looking into changes that will improve security but have no requirement to engage purchasing: There are thousands of possibilities from the simple to the complex. DBSecWorx's Resources page will provide you with many opportunities to close the attack surface solely by improving database configuration.

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

DBMS_CRYPTO_TOOLKIT	DBMS_SQLDIAG	UTL_HTTP
DBMS_DEBUG_JDWP	DBMS_SQLQ	UTL_I18N
DBMS_METADATA	DBMS_UTILITY	UTL_INADDR
DBMS_NETWORK_ACL_UTILITY	DBMS_WARNING	UTL_RAW
DBMS_PREPROCESSOR	DBMS_XSLPROCESSOR	UTL_SMTP
DBMS_PROFILER	UTL_ENCODE	UTL_TCP
DBMS_SQL_TRANSLATOR	UTL_FILE	XS_ACL
DBMS_SQL_TRANSLATOR_EXPORT

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 SELECT privilege FROM dba_sys_privs WHERE grantee = 'PUBLIC' ORDER BY 1; -- there should be any ... if there are this is a high priority

5. Identify every explicit grant of object privileges to PUBLIC col obj_name format a30 SELECT owner, table_name AS OBJ_NAME, privilege FROM dba_tab_privs WHERE grantee = 'PUBLIC' AND type NOT LIKE '%JAVA%' ORDER BY 1,3,2; -- the resulting list will likely be close to 5,000 rows. Llikely the overwhelming -- majority of these grants should not exist in a secure environment as they are -- totally unnecessary. SELECT owner, table_name AS OBJ_NAME FROM dba_tab_privs WHERE grantee = 'PUBLIC' AND privilege = 'EXECUTE' AND type NOT LIKE '%JAVA%' ORDER BY 1,2; -- these approximately 2600+ objects are the ones that should be focused on first

6. Identify every explicit grant of a role to PUBLIC SELECT granted_role FROM dba_role_privs WHERE grantee = 'PUBLIC' ORDER BY 1; -- there should be any ... if there are this is a high priority

7. View your SQLNET.ORA files and see if they they contain the minimum configuration items to create a secure environment. -- for a stand-alone database more $ORACLE_HOME/network/admin/sqlnet.ora -- there should be any ... if there are this is a high priority more $GRID_HOME/network/admin/sqlnet.ora -- for all databases. If your databases are like most you might find one or two of these. -- and as almost all are included in your default license from Oracle you have no excuse -- for not doing the research to find of what these do and implementing many of them -- valid node check forces connection attempts to be from valid sources valid_node_checking_registration_<listener_name>=on regisration_invited_nodes_listener=(<<comma_delimited_list_of_ip_addresses/subnets) -- parameters that fight Denial of Service attacks inbound_connect_timeout_listener=<integer> max_all_connections_listener=<integer> max_reg_connections_listener=<integer> queuesize=<integer> rate_limit=yes ... or rate_limit=<integer> sqlnet.expire_time=<integer> sqlnet.inbound_connect_timeout=<integer> sqlnet.recv_timeout=<integer> sqlnet.send_timeout=<integer> tcp.connect_timeout=<integer> tcp.queuesize=<integer> -- limit the listener attack surface admin_restrictions_listener=on names.directory_path=<ezconnect | ldap | nis | tnsnames> remote_registration_address_listener=off save_config_on_stop_listener=false sqlnet.allowed_logon_version_client=<version_number> sqlnet.allowed_logon_version_server=<version_number> sqlnet.crypto_checksum_client=required sqlnet.crypto_checksum_server=required sqlnet.crypto_checksum_types_client=(SHA256) sqlnet.crypto_checksum_types_server=(SHA256) sqlnet.encryption_client=required sqlnet.encryption_server=required sqlnet.encryption_types_client=(rc4_256) sqlnet.encryption_types_server=(rc4_256) -- use the following to assist in deugging exercises sqlnet.client_registration=<any_alphanumeric_string_up_to_128_characters_long> tnsping.trace_directory=$ORACLE_HOME/<directory_path> -- entries you absolutely do not want to see in your SQLNET.ORA file default_service_listener=on -- clearly, also, if you are using LDAP, Active Directory, Kerberos, Radius, or similar -- identity management products you should find those entries in sqlnet.ora as well.