OracleHardeningGuideV3indexName of precautionary measureThe threat that it mitigatesDescription of how to do itPotential DBA Discussioncriticalityplatformversion1.00.00Host Operating System security Issues1.01.01Oracle software permissionsattacker taking control of files that should be owned by Oracle accountCheck OS file permissions in $ORACLE_HOME/bin and $ORACLE_HOME and should all be owned by ORACLE and group membership checked and recorded.OTHER group was able to edit the binaries used to run oracle then a denial of service could be easily mounted. Also malicous binaries could be written over the actual b inaries.ls -alR > recursivels.txt$ORACLE_HOME/bin set to 0755and all other $ORACLE_HOME to 0750cat /etc/passwdno one should need write access to the files in the bin so there should not be discussion on this point. It is possible to run with tighter permissions though this should be tested and support from Oracle verified.1ALLALL1.01.02Lock Oracle accountattacker taking over the oracle account and using it maliciouslypasswd -l time to lock and unlock when needed1ALLALL1.01.03Do not name Oracle software owner account "oracle"attacker knowing the account name makes it quicker to attack that accountuse a different OS account name for Oracle software ownermay be difficult after the fact as scripts may be hardcoded with this data2ALLALL1.01.04Limit access to software owner accountlack of identity trail i.e. who is it that is logging on as oraclesudo to oracleDBA do not want to use sudo so could disable remote login instead so have to su2UnixALL1.01.05Use separate owner for listener from database softwareattacker gaining control of listener allows control of databaseIn UI select custom install and use different account for listenerfrom fresh install no discussion needed on this point.2ALLALL1.01.06secure or remove DBSNMPDBSNMP can read user$ as it has the SELECT ANY DICTIONARY privilege . It has a default account/pass so common way into the database. DBSNMP is the user account that the Oracle Intelligent agent uses which has to be able to login remotely and automatically for the intelligent agent functionality to work.either drop DBSNMP DROP USER DBSNMP CASCADE; or run $ORACLE_HOME/rdbms/admincatnsnmp.sql/ change username/password is minimum. For high security should remove the DBSNMP binary from the $ORACLE_HOME/bin as this is SUID.Also change the DBSNMP password in snmp_rw.ora fileDBA wants to use intelligent agent --> at least change the password for DBSNMP to a secure password. ALTER USER DBSNMP IDENTIFIED BY "SECURE PASSWORD"; See auditing weak passwords later.11.02.02set umask value to a secure valuemeans that files created by the ORACLE acount will have secure permissions by default.bash-2.05$ umask 022If files may need to be read by those outside of the OSDBA group then could set 027 but depends on how many people are in the OSDBA group and how structured. If only two in OSDDBA/SYSDBA group then maybe 027 might be more time efficient but our recommendation is 022.1UnixALL1.02.03Check owner and group for all files in $ORACLE_HOME---1UnixALL1.02.04Windows file permissions and type.This will prevent malicious access to the Oracle software on the server as long as the normal Windows hardening procedures are also taken.set file type to NTFSORACLE user account created to own the Oracle software should not be called "oracle"The user should be a local admin and not a domain user.This user should be made part of a group not called ORA_DBA.Remove everyone using inherited permissions.none needed1WinALL1.02.05Location of temp directories TMP_DIR, TMPDIR and TEMPOracle installation requires a temp directory. Should not use /tmp as permissions are open. Therefore set TMP_DIR and TMPDIR variables to more secure locations which only ORACLE account should have permission to read, write and execute .mkdir /u01/tempTEMP=/u01/temp; export TEMPTMPDIR=/u01/temp; export TMPDIRnone needed1UnixALL1.02.06Check windows groups used for ORACLE_HOME and ORACLE_BASE---1WinALL1.03.01Audit membership of OSDBA and root groupshould not contain root account or other low privileged users as OSDBA maps to SYS AS SYSDBA which is the most powerful user/role combination in the Oracle database. OSDBA can shutdown the whole database. Also make sure ORACLE is not a member of the root group.cat /etc/group adduser Adds username to the group groupnamethere may be additional discussion on who exactly will be a member of the OSDBA group which is a business decision. Need to have more than one person but not much more. Users that do not need complete power should access as SYSOPER for maintenance or as a low privileged Oracle db account directly. Least privilege is the key.1ALLALL1.03.02Ensure Oracle is not in the root group---1UnixALL1.03.03Dont use dba name for the OSDBA groupdba is the generic group name for the OS dba group and this should not be used as it known and would make attacking the OS easier.groupadd none needed1UnixALL1.03.04Dont use the name ORA_DBA for the OSDBA group on Microsoft.manually create a group that is not called ORA_DBA for the ORACLE groupcontrolpanel>admintools>compmanagement>groupsnone needed2WinALL1.04.01Check trace file permissions---3ALLALL1.04.02Remove tkprof from production dbtkprof is used to read trace files and should be used off the production serverdelete tkprof binary from $ORACLE_HOME/binif absolutely needed could keep on production server but would need v.good reason such as no other place to read the trace files which had to be read there.3ALLALL1.04.03disable the otrace utilityotrace has known security issues and also performance issues as the .dat files it uses can grow to be very large.CD to the $ORACLE_HOME/otrace/admin directory of yourinstance and remove or delete the dat files related to otrace.process.datcollect.datregid.datOnce these are removed/deleted you should restart yourinstances and listener and otrace will be disabled.none needed2ALLALL1.04.04Check permissions of the datafilesThe datafiles (.dbf) hold the actual persistent data and need to be protectedThe database file location is usually in the parent directory of the control files which can be found by select name,value from v$parameter where name='control_files';These permissions should be 600 if ORACLE is to run the db.If a different user from ORACLE is used but in the same group then permisssions should be 660.1ALLALL1.04.05Regulary audit Oracle log filesIn order to recognise suspicious activity in the database the dba should monitor all log files which are kept historically for a set period of time.This process necessetates the archiving of log files and when space is an issue deleting logs of a certain age so that there is rotation. It is worth correlating with SYSOG and IDS logs using timestamp as the central unifier of these logs. Therefore strong synchronisation of timestamp is required. This should be done using GPS or CDMA to give an accurrate internal stratum 0 source not via untrusted NTP from external source.DBA may wish not correlate logs. The first time this is done takes along time but once a process is in place it can be automated. Time synchronisation will also be important for single sign on if and when implemented so it is a good idea to implement time syncrhonisation anyway.3ALLALL1.04.06Check for sensitive temporary files---2ALLALL1.04.07Check for tertiary trace files---2ALLALL1.04.08Check for remote data access files (RDA)RDA files contain a lot of internal connection details and are uploaded to oracle support in an insecure manner. This input should be sanitised before sending to Oracle support.A perl script could be used to parse the RDA files before sending to Oracle Support. This is a current research project at GIAC and more information will be available from this URL in the near future. http://www.giac.org/certified_professionals/listing/gsoc.phpThe local copy of the RDA files should be deleted after they have been sent.none needed3ALLALL1.04.09Raw device permissionsOracle raw devices should have minimum permissions so only Oracle can use them.ls -al device/disk/volumeif using veritas volume manager or similar then will have to use the tools supplied with that software.1UnixALL1.05.01Usernames/ passwords in process listIn UNIX the usernames and passwords that scripts are being run under may show when running the ps -ef command. This is a well known issue as an attacker could simply read these credentials and then impersonate that user.hide.c available from oracle metalink support allows the username/password to be hid from the ps -ef command.Metalink notes 136480.1 and 1009091.6Should restrict use of the PS command using OS permissions.who gets permissions to ps is the question here. Root has it and ORACLE may need it as well as OSDBA and OSOPER. It should be limited below these users.1UnixALL1.05.02Restrict the ps command---2UnixALL1.05.03Restrict shell history files for usernames and passwordsshell history recalls the previous commands but could also show an attacker a username password combination e.g sqlplus scott/tigerrestrict shell history by reducing the HISTSIZE environment variable to as low an amount as is appropriate for your environment for each user.none needed2UnixALL1.06.01Secure network communicationsTNS sends much information in the clear such as the version number of the database. SQL*PLUS username/password via Oracle Authentication is encrypted but it has been broken by NGS and our recommendation is to use SSH for client to server communications and IPSEC for permanent server/server connections. Oracle Advanced Security is a more expensive option to the above. This is a link that discusses the weaknesses of Oracles network authentication mechanism. http://www.fors.com/eoug97/papers/0356.htmPutty is a free and popular client that can be used for client connections. http://www.chiark.greenend.org.uk/~sgtatham/putty/Need to edit the tnsnames.ora file and port forward using putty# TNSNAMES.ORA,Network Configuration File:C:\oracle\ora90\network\admin\tnsnames.oraPLSQL =(DESCRIPTION = (ADDRESS-LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = localhost) (PORT = 7774)))(CONNECT-DATA =(SERVER = DEDICATED)(SERVICE-NAME = plsql) ))

then:ssh -L 7774:venus:1521 venusDBA may say that this is a lot of work on each client. The option is Oracle Advanced Security which is expensive or to - as it is. An advanced attacker can sniff traffic and gain the plain text of the password if they have the hash of the password that is being used. It is a business and context decision as to whether the risk of malicious sniffing and unencryption warrants the extra work/cost of securing each client. A high security network should take this precaution.2ALLALL1.06.02set ORA_ENCRYPT_LOGIN to TRUEset DBLINK_ENCRYPT_LOGIN to TRUEAn attacker can force a second non-encrypted login which is defended by setting this parameteredit the text file init.ora to include the statement ORA_ENCRYPT_LOGIN=TRUE;DBLINK_ENCRYPT_LOGIN =TRUEnone needed3ALLALL1.06.03Secure password transmission on the server---1ALLALL1.06.04Secure password transmission on the client---1ALLALL1.06.05JDBC thin minimum permissionsjdbc thin drive transmits clear text error message including username and encrypted password and possibly used therefore set minimum privileges for users with thin client access.REVOKE privilege from USERnone needed1ALLALL1.07.01Permissions on Oracle SUID and SGID files3UnixALL1.07.02Remove SUID and SGID files in $ORACLE_HOMEolder versions of oracle 8 have many SETUID and SGID binaries most of which can be removed either by permission or completely. Dbnsmp is SUID root and should either be removed or changed.chmod -s binarynamenone needed3UnixALL1.08.01Check environment variables for usernames and passwordThe users environment may contain usernames and passwords to make scripts work easilyit is possible to read a users environment remotely so these should be audited and any that are not absolutely essential removed. Use the $env command or system>advaneed>environment variables.discussion about what is essential. Can use scripts that prompt the user to input their password manually as compromise.3ALLALL1.08.02Audit the machine for scripts containing usernames and passwordsautomated scripts have to work as a user which may be hardcoded into a script. Check cron jobs too.#!/bin/bash/find $ORACLE_HOME -name "*" -print | while read filenamedo echo "filename "$filename >>user.lis egrep -I 'connect|sqlplus' $filename >> user.lis2>/dev/nullIt may be the case that an automated script with a password is required then encrypt the password or at the very least limit the permissions so that it cannot be read by an unauthorised user.2ALLALL1.08.03Audit cron for usernames and passwords---2UnixALL1.08.04Audit client machines for configuration files containing usernames and passwords---2ALLALL1.08.05Remove db creation scriptsThe database configuration assistant can be used to create databases but also creates scripts with username /passwords that are insecure.audit the $ORACLE_HOME for this scripts and remove them and also remove the database configuration assistant or dbca which is in $ORACLE_HOME/bin.none needed2ALLALL1.09.01Use O/S auditing facilitiesOS auditing can be useful for Oracle to see what the OSDBA, OSOPER groups and ORACLE user have been doing.Tripwire can be used to monitor the state of the oracle files. Oracle basic auditing can be set to log to the OS instead of sys.aud$. This is recommended as the DBA cannot directly alter this auditing log.none needed except that use of tripwire should be tested thoroughly before installation to make sure that it does not interfere with the smooth running of the server. If it does then manual checksumming of the oracle binaries can be carried out, recorded and then checked at agreed intervals.2ALLALL1.09.02Save log files to a separate server using Syslog or Windows event viewercorrelated log analysis is a growing requirement in large enterprises so that events can followed over many systems. This may be a hack or a system failure. This requires synchronised time.save Oracle logs to syslog in a central remote loghost server. Syslogng is also worth looking at for this purpose.May be too time consuming for the benefit but this is potentially very beneficial in all but a completely trusted network environment.2ALLALL1.09.03Integrity check O/S files used by Oracle---2UnixALL1.09.04host based IDS---3ALLALL1.09.05Review expected processes regularlya process list can show programs that are not meant to be running. One of these may be maliciouslsof will list the processes on UNIX and can be compared to known list of good processes.none needed2ALLALL1.10.01monitor and set control file permissionsattacker editing the control files which are needed for Oracle to workto find OS Location select name from v$controlfile; .ctl files read/write by ORACLE onlynone needed2ALLALL1.11.01Check who is creating trace files and audit their presencetrace files can contain sensitive data such as the ability to read internal database structures and be dumped by anyone with ALTER SESSION privilege. Audit the presence of check files to make sure no unauthorised user is doing so and that no unauthorised user can read trace files created./bin/bash/ find $ORACLE_HOME -name "*.trc" -print | while read filename; do echo "FILENAME IS "$filename >> trc.lis; egrep -i 'Image' $filename >> trc.lis 2> /dev/null; doneaudit the presence of trace files:select name, value from v$parameter where name like '%dump_dest%';Then ls -al that directory to see who can read them. Also check for trace files outside of the usual destination using find $ORACLE_HOME -name "*.trc" -exec ls -al {} \; - printmaybe DBA does not want to run a large find command on the machine while in production as may slow it down. Therefore can check the trace files manually and check for ALTER SESSION privileges.3ALLALL1.11.02Audit trace files for attempts to read database internal structures---3ALLALL1.11.03Ensure no user has ALTER SESSION and ALTER SYSTEM privilegesALTER SYTEM allows the trace and dump directories to be changed and ALTER SESSION privilege allows the database structures to be dumped.select grantee, privilege from dba_sys_privs where privilege in ('ALTER SYSTEM', 'ALTER SESSSION');DBA ROLEs should be ignored as they need these privileges.should be no discussion on this but users may need to kill their own sessions therefore use kill command on UNIX or orakill.exe on windows to replace the ALTER SESSION capability1ALLALL1.12.01Audit for export file existenceAttacker may either export the db's data including SYS.USER$ passwords or be able to read a legitimate export which could be imported into the attackers own database.find $ORACLE_HOME -name "*" -print | while read filename do egrep -I 'EXPORT' $filename >>exp.lis 2> /dev/null doneRunning this find command on all files will slow down the machine whilst it is being done. This should be done whilst the machine is offline. Also change the passwords after a full export/import between machine environments e.g. production to development.1ALLALL1.12.02Changing database passwords after full import---1ALLALL1.13.01Locate archive log files and check no user except ORACLE can read themThe redo logs are a record of the SQL commands needed to return the database to a previous state and may be archived preferably remotely in order to facilitate a backup recovery. This data is precious and should be protected.select log_mode from v$database; select name, value from v$parameter where name like '%arch%';The archive logs can take up a lot of space so a remote dedicated storage is safer and easier to manager in terms of disk space. Access to these logs should be strictly controlled as they can allow the database to be reinstated on a separate machine especially if the database structure is known.2ALLALL1.13.02Save archivelog files to disk---2ALLALL1.14.01Audit external tablesExternal tables are a link to the OS which allow database user to modify OS file and OS user to modify database file if the permissions allow. Therefore the permission/privileges of these external tables should be checked at both ends. This is not as serious as the UTL_FILE but should be checked.example: SQL> select table_name, default_directory_name from dba_external_tables;TABLE_NAME DEFAULT_DIRECTORY_NAME------------------------------ ------------------------------SALES_TRANSACTIONS_EXT DATA_FILE_DIR

SQL> select * from all_directories where directory_name = 'DATA_FILE_DIR';

OWNER DIRECTORY_NAME------------------------------ ------------------------------DIRECTORY_PATH--------------------------------------------------------------------------------SYS DATA_FILE_DIR/u01/app/oracle/product/9.2.0/demo/schema/sales_history/ls -al /u01/app/oracle/product/9.2.0/demo/schema/sales_history/SQL> select grantee,privilege from dba_tab_privs where table_name='DATA_FILE_DIR';

GRANTEE PRIVILEGE------------------------------ ----------------------------------------SH READnone needed2ALL>= 9i1.15.01remove access to native PL/SQL compilation in productionNative PLSQL compilation allows PLSQL to be compiled via a C compiler to native code. This is dangerous as access to this functionality would allow execution of other binary files and to wrap exisitng PLSQL packages with their own code.v$parameters should be set to false or null.plsql_native_c_compilerplsql_native_library_dirplsql_native_library_subdir_countplsql_native_linkerplsql_native_make_file_nameNative PLSQL runs quicker so development team may require this functionality.Both requirements can be met by setting the parameters for the developer as the PLSQL needs compiling and then setting it back. This should be a rare occurance and therefore not take up too much itme.1ALL>= 9i1.16.00Be aware of key files containing hashes or passwords or other sensitive information3ALLALL1.17.01Password protected listener can be shut down via the OS on WindowsPsservice allows a windows service to be shut down remotely. Therefore secure the ORACLE accountpsservice tool from sysinternals http://www.sysinternals.com/utilities/psservice.htmlWhere Windows is being used migrate towards 2003 OS1WinALL2.00.00Oracle Authentication2.01.01Audit database users activitiesat the database level above the OS are users as well that should be monitored. Users such as SYS that are not meant to be logged in most times can be checked to see if they have a session openSELECT * FROM v$session;none needed3ALLALL2.01.02Audit application database loginsThird party application user management is often required. Sometimes however it can be managed by the database. Applications store their passwords in the database anyway so this link has to strong anyway. It is often possible to bypass application security by logging in directly as the application user.oracle label security can be used to as a solution to this problem.check the security of the web application to the database. An audit can useful in these situations. What encrytion is used by the application. Is the database security stronger the application password security.3ALLALL2.01.03Check users database passwordsstrong memorable passwords are essential and the profile features of oracle can be used to control password lifetime, reuse, lock time and gracetime. Use of profiles is heavily recommended.Need to use the Password management features of Oracle to allow constant checking for compliancy.Run a password cracker on the checksums for the passwords from sys.user$ to see if they are strong. NGS SQuirreL for Oracle has one of the fastest.It is also common for some users to set the password to be the same as the user which is covered by SQuirreLSQuirreL allows password auditing without actually viewing the passwords.1ALL>= 82.01.04prevents users from sharing account IDsusers may use the same login and password for convenience or to hide their identity. This make saccountability impossible.alter profile default limit sessions_per_user 1;none needed2ALLALL2.01.05Use proxy authentication to help resolve SSO issues---3ALL>= 82.02.01Audit default database accountsOracle comes installed with many default accounts which are set with a default password. 10g release 1 and 2 are improving the security of these accounts by locking the default ones but they still come with default passwords. 8i and 9i have many default accounts that are unlocked with default known passwords and have high privileges assigned such as being able to read the password hashes from sys.user$. There are also many default accounts for third party applications that use Oracle. This list of default accounts includes users and roles.These default accounts need to be audited for which can be done using products such as NGS SQuirreL for oracle which has over a 1000 entries. There is a list of common default usernames in the appendices of this report. Default accounts that are not required should be dropped. Defaults accounts that may be required should be locked and password changed.ALTER USER ACCOUNT UNLOCK;WKSYS and DBSNMP are two of the most commonly used default accounts as they have strong privileges and are often overlooked.Default accounts is a pretty clear subject so should not be too much discussion. The main stumbling block is DBSNMP as this is used as the account that the Oracle intelligent uses to gather data remotely as part of Oracle Enterprise Manager (OEM) which is a GUI tool for managing many servers in an easy way.see the securing DBSNMP section.1ALLALL2.02.010Modify Oracle scripts for default accounts that are used---1ALLALL2.02.02Add password management for default accountsdefault accounts may not have password management features enabled as the profile has to be changed and the profile assigned to the user/role. It is important that accounts be protected from an attacker attempting to brute force an account.ALTER USER defaultaccount PROFILE myprofile;The default profile is often used and should have password management features enabled using:ALTER PROFILE DEFAULTLIMIT FAILED_LOGIN_ATTEMPTS 5PASSWORD_LIFE_TIME 40PASSWORD_REUSE_MAX 10PASSWORD_REUSE__TIME UNLIMITEDPASSWORD_LOCK_TIME 1PASSWORD_GRACE_TIME 3;The exact composition and settings of a profile are flexible to the policy and business need. As a minimum there should at least be a default profile with password management features enabled though the values would be negotiable. If there are many contexts then different profiles should be implemented to satisfy all groups needs.1ALLALL2.02.03Audit internal alias login---2ALL>= 8i2.02.04Audit non database Oracle passwords---2ALLALL2.02.05Change sys password and system passwordThe SYS and SYSTEM password are default user accounts as well and are set with the default passwords such as manage and change_on_install. This should be included in a default password audit but may be overlooked so it is worth explicity checking these accounts due to their sensitivity.Additional to running a password cracker or default password check it is recommended to explicity change the password to a new secure password so that it is known 100% that the password is secure using the advice in item named "Audit users accounts for weak passwords"There may be some resistance to changing the SYS and SYSTEM passwords to a known secure password but this should be ignored unless exceptionally good reason. Changing these passwords should be a matter of course as they will become more insecure over time . These passwords should be changed each month anyway. Changing them should not inconvenience the DBA and it will ensure they are secure and able to change.1ALLALL2.02.06Change---1ALLALL2.02.07Create business process to audit default accounts regularly---2ALLALL2.02.08Disable remote login password file parameterThis parameter is set to NONE prior to 8.1.7 and EXCLUSIVE after that. It should be checked that the value has not been changed.SELECT value FROM v$parameter where NAME='remote_login_passwordfile'; should return NONE or EXCLUSIVE. If not change the init_SID.oranone needed2ALLALL2.02.09Check use of system tablespace by default and SYSTEM users.It is possible for accounts such as ordsys to have tablespaces using SYSTEM which if allocated without a quota could be filled up by the account and DoS the machine.select username, default_tablespace, temporary_tablespace from dba_users; this will provide a list of tablespaces with SYSTEM. Change these with the following SQL.ALTER USER ORDSYS DEFAULT TABLESPACE tools TEMPORARY TABLESPACE temp;none needed3ALLALL2.02.11Audit known default role passwords---1ALLALL2.03.01Audit users accounts for passwords same as username- this- this- this2ALLALL2.03.02Audit users accounts for weak passwordsOracle passwords are by default limited to 30 characters that can be used and the variety of each character is limited to alphanumerics a few special characters all upper case. Given this fact they are susceptible to being cracked.An example of this problem is shown in this paper by Josh Wrighthttp://www.sans.org/info/911/In order to set a secure password inoracle it is recommended to use a quoted password which allows for ctrl UNICODEcharacters to be used in each of the 30 places.ALTER USER PAUL IDENTIFIED BY "passwordincludingnumbersandctrlchars";"This makes the password very difficult indeed to crack."As well as making the pasword secure it is possible to set up alias' for the accounts so that users actual username is never known.auditing accounts for weak passwords can take along time so it is recommended to automate this process either using an SQL script locally or a remote testing application such as NGS SQuirreL for Oracle which is available as a free trial from http://www.ngssoftware.com/squirrelora.htm2ALLALL2.03.03Lock dormant database accounts and remove after time delay- this- this- this3ALLALL2.03.04Stop personal data exposure on users accounts---5ALLALL2.03.05Use obfuscated naming convention for users accounts---5ALLALL2.03.06Use LDAP for external authentication---4ALL>= 9i2.03.07Tie db accounts to usersWith leaving staff and contract workers it is possible that there are accounts in the db that are not being used termed "dormant".There should be a process that can identify accounts that are not being used anymore so that they can be removed.This is a hypothetical example given that hr_table contained a column of valid_users:(select name from sys.user$)minus(select valid_users from hr_table);The result would be invalid users.This point clearly needs implementing the only question should be how which would be business process decision. It would be useful to allocate a business process owner so that could be responsible for removing leaving accounts and checking this has been done in Oracle.2ALLALL2.04.01Secure remote password login fileusers such as SYS, INTERNAL and users granted SYSDBA/SYSOPER have their password recorded in $ORACLE_HOME/dbs/orapwcheck the permissions on this file and change to -rw-r----- if necessary.none needed3ALLALL2.05.01Change SID and service name for third-party applications---4ALLALL2.06.01Check separate applications authentication systemsSeparate applications often have their own authentication system which may provide a weak point of entry. It is worth querying the database tables for these passwords.select object_name object, object_type type, owner ownerfrom dba_objectswhere owner'SYS'and ((object_name like '%USER%'and object_name not like 'USER_%') or object_name like '%USR%'or object_name like '%PASSWD%'or object_name like '%PWD%'or object_name like '%PASS%')and object_type in('VIEW','TABLE')unionselect table_name object, column_name type, owner ownerfrom dba_tab_columnswhere owner'SYS'and (column_name like '%USER%'or column_name like '%USR%'or column_name like '%PASSWD%'or column_name like '%PWD%'or column_name like '%PASS%')/no problem running the query but problem when passwords are found so have to prepare for this. It may be the case that the auditor should not view the passwords depending on privacy policy.If weak passwords are found this way then need to secure the tables that contain the passwords and talk the application provider.3ALLALL3.00.00Oracle Access Controls3.01.01Check utl_file_dir parameterUTL_FILE_DIR is the location on the OS that UTL_FILE package points to from Oracle database. This should not be set to "*", the location of the trace directories, "/tmp", "/" or other locations where important scripts lie. The reason being that UTL_FILE could be used to open a script and then saved as empty which would render the script useless.select name, value from v$parameter where name = 'ult_file_dir';Also revoke access to UTL_FILE and only grant to those db accounts that require the OS access.3ALLALL3.01.02Check dbms_backup_restore package permissionsThis package can copy, alter and delete files and so needs to be controlled tightly.select privilege, grantee from dba_tab_privs where table_name='DBMS_BACKUP_RESTORE';revoke access as needed.none needed3ALLALL3.01.03Audit Java access to the O/SJava can be used to access the OS from Oracle so Java permissions should be checked and if not needed should be revoked completely.select Count(1)from dba_objectswhere object_type Like '%JAVA%';--if this returns more than 3000 java is installed.

This query will show the privs given wiithin Java select grantee,type_name,name,kind,actionfrom dba_java_policywhere grantee not like 'JAVA%'and grantee'SYS'/Then revoke privs not need using dbms_java.revoke_permissionremove Java completely if not needed using $ORACLE_HOME/javavm/install/rmjvm.sqlBusiness decision as to what Java permissions are required if Java is being used at all.2ALL>= 83.01.04Be aware of how Java and Oracle interact---2ALL>= 83.01.05Secure Con TextOracle Context allows a database user to access external files.The functionality is owned by CTXSYS which unfortunately also has PUBLIC execute on many of the packages and tables.if context is not being used then drop CTXSYS user DROP USER CTXSYS CASCADE;If it is being used then can just lock CTXSYSALTER USER CTXSYS ACCOUNT LOCK;Revoke all access to CTXSYS packages from PUBLIC.none needed3ALL>= 83.01.06Remove oo4o if not needed---2ALL>= 73.02.01Remove PUBLIC select on ALL_USERSALL_USERS is a view like DBA_USERS but intended for anyone to use which is why PUBLIC is granted select on it. This view does show the usernames and this information is part of the way in which the password algorithm works as the username is the salt used to encrypt the password. See the end of SECOPs book.revoke select on all_users from public;Will also need to test that the low privileged accounts that should not see the usernames cannot actually see them by logging in as them and testing. This is because the privilege hierarchy may inherit the ability to select from a different route.none needed3ALLALL3.02.02Secure all ALL_% views---4ALLALL3.03.01secure or remove extprocExtProc enables external access to C libraries on the OS from the database and from the Listener remotely if enabled which it is by default. This is inherently insecure and additionally NGS has found buffer overflows in the fixes that were made to subsequently secure Extproc.http://www.ngssoftware.com/advisories/ora-extproc.txthttp://www.oracle.com/technology/deploy/security/pdf/plsextproc_alert.pdfhttp://www.oracle.com/technology/deploy/security/pdf/2003alert57.pdfPlease see the Shellcoders handbook page 406-10 for more detail of the buffer overflow.Also see Database Hackers Handbook page 89Also see security the Listener further on in this guide.To remove Extproc:-Remove the entries from the listener.ora file-Remove entries from any tnsnames.ora-Delete the extproc binary-Revoke create / alter (any) library privileges-Revoke create / alter procedure privilegesTo secure Extproc:-Create a separate user for the extproc listener-Remove extproc entries from listener.ora and tnsnames.ora- Create a new seperate listener for extproc-use valid node checking on the new extproc listener and restrict to IPC protocol only.For DBA here is seperate Extproc listener if needed but try to avoid Extproc if possibly can.

LISTENER EXT =(DESCRIPTION LIST =(DESCRIPTION =(ADDRESS-LIST =(ADDRESS = (PROTOCOL = IPC) (KEY= EXTPROC)))))SID-LIST EXT =(SID-LIST =(SID-DESC =(SID-NAME = PLsExtPr0c)(ORACLE-HOME = /export/home/uOl/app/oracle/product/9.0.1)(PROGRAM = extproc)))1ALL>= 83.04.01Understand Data Access Descriptor administration---4ALL9iAS3.05.01Check access to catalog rolesOnly DBA should have access to the catalog roles SELECT_CATALOG_ROLEEXECUTE_CATALOG_ROLE'DELETE_CATALOG_ROLEselect grantee,granted_rolefrom dba_role_privswhere granted_role in ('SELECT_CATALOG_ROLE','EXECUTE_CATALOG_ROLE','DELETE_CATALOG_ROLE');revoke as needed.none needed.3ALLALL3.05.02Check access to dba role viewsViews pre-fixed by the lettes DBA are for the use of the DBA and should not be viewable by non DBA users. Unauthorised access should be revoked.select grantee,privilege,table_namefrom dba_tab_privswhere table_name in ('DBA_ROLES','DBA_SYS_PRIVS','DBA_ROLE_PRIVS','ROLE_ROLE_PRIVS');none needed.3ALLALL3.05.03Password protect admin roles---4ALLALL3.05.04Check role hierarchy depth---4ALLALL3.05.05Adopt role naming conventions---5ALLALL3.05.06Create a role to manage users accounts---5ALLALL3.06.01Database in archivelog mode?Preferably, in order to allow complete Point In Time recovery the database should be in ARCHIVELOG mode which means that the redo logs are kept so that the database can be reinstated to a previous state.It is also preferable that the ARCHIVELOGs are kept remotely so that if the local machine becomes unusable the logs are not affected.This query is for general parameter values.SELECT * FROM v$parameter ORDER BY name;This query is specifically for archivelog mode and whether it is switched on.select log_mode from v$database;Not aware of any good reasons not to do this. Disk space is a bad reason given the fall in disk prices.2ALLALL3.06.02Check user_dump_dest is valid---4ALLALL3.06.03Check background_dump_dest is valid---4ALLALL3.06.04Check core_dump_dest is valid---4ALLALL3.06.05Check that global_names is true---3ALLALL3.06.06Check that log_archive_start is set to true---4ALLALL3.06.07Check max_enabled_roles less than 30In order to limit the Role inheritance heirarchy set max_enabled_roles to 25 or soSELECT * FROM v$parameter where name ='max_enabled_roles';set in init.ora-3ALLALL3.06.08Check that os_authent_prefix is set to (null string).If os_authent_prefix is set to (null string) then a user can either logon externally or internally not both. External is insecure and should be seperated in this manner.SELECT * FROM v$parameter where name ='os_authent_prefix';set in init.ora2ALLALL3.06.09Check that os_roles is set to false---4ALLALL3.06.10Check that O7_dictionary_accessibility is set to false---1ALLALL3.06.11Check that remote_os_authent is set to falseIf true then can log in without oracle authentication. This can be hacked easily from a non windows machine as it relies on the way that the username is formed.SELECT value FROM v$parameter where name ='remote_os_authent';set in init.oranone needed.3ALLALL3.06.12Check that remote_os_roles is set to falseCan be spoofed remotely so need to disableSELECT value FROM v$parameter where name ='remote_os_roles';set in init.oranone needed.1ALLALL3.06.13Periodically confirm parameters in database are the same as the configuration fileThe init.ora file is a flat file which may not actually be loaded into the memory the database so it is worth checking the two. There is also the trick of adding parameters at a the very bottom of an extended init.ora file which may not show when a text editor is used.SELECT * FROM v$parameter ORDER BY name; and compare with the init.ora filenone needed.3ALLALL3.06.14Check IFILE and the contents of files pointed to by IFILEIFILE parameter allows additional parameters to be contained in a separate init.ora pointed to by the first. Avoid use of this functionality where possible and check to see if it is being used or not. If so check the second parameter file to see what parameters are being set.search the init.ora for an IFILE parameter and follow that up by inspecting any addional parameter file.none needed.3ALL>= 9i3.06.15Audit remote_listenerIf the system is not using a remote listener then check to see if the remote_listener parameter is null.SELECT value FROM v$parameter where name ='remote_listener';set in init.oranone needed.3ALL>= 9i3.06.16Check that pfile and spfile can only be written to and read by the software owner.---2ALLALL3.06.17Audit exempt access policy privilegeexempt access policy privilege can be used to circumvent fine-grained security. Check for unauthorised granting of this privilege.select grantee,privilegefrom dba_sys_privswhere privilege = 'EXEMPT ACCESS POLICY';none needed.2ALL>= 9i3.06.18Check record locking parametersSERIALIZABLE set to FALSE and ROW LOCKING set to ALWAYSSELECT * FROM v$parameter where name ='serializable'; Not In 10g r2set in init.oranone needed.2ALLALL3.06.19Check for SQL92_securityUser must have SELECT to DELETE and UPDATE.SELECT * FROM v$parameter where name ='sql92_security';set in init.ora2ALLALL3.07.01Non sys objects in system tablespaceCheck for non sys owned objects in the system tablespace that are not default Oracle objects.select owner,segment_name,segment_typefrom dba_segmentswhere tablespace_name='SYSTEM'and owner'SYS';There will probably be SYSTEM and OUTLN objects which are default with Oracle but this check is looking for objects from other users which are out of place.1ALLALL3.08.01Check for users who have dba privilegethis is most powerful role and should not be widely used so check for users and roles that have it.select grantee from dba_role_privs where granted_role='DBA';Revoke from accounts that do not need itrevoke dba from accountname;Compromise to taking away DBA role is to strip down the privileges of this role so it is not such a security risk.1ALLALL3.08.02users or roles granted ALL PRIVILEGES or too many privilegesA user could be granted ALL PRIVILEGES which is the opposite of least privilege and should be avoided.Check for all privs:(select count(*) from system_privilege_map)intersect(select count(*) from dba_sys_privs group by grantee);Check for number of privs in case too many.select count(*) from system_privilege_map;select count(*),granteefrom dba_sys_privsgroup by grantee;The DBA role and SYS user will have this privilege.1ALLALL3.08.03ANY privilegesANY privileges are to be avoided as it is not accurate to need.select grantee,privilegefrom dba_sys_privswhere privilege like '%ANY%';revoke where possiblecreate any directory does not have a non ANY version but most privs can be assigned more precisely so revoking ANY privileges should be enforced strongly. The DBA role and SYS user will have this privilege.1ALLALL3.08.04WITH ADMIN or "WITH GRANT" privilegesWITH ADMIN or "WITH GRANT" privileges allow the grantee to pass on the privilege to any other user. This should be avoided and monitored.select grantee,granted_rolefrom dba_role_privswhere admin_option='YES'unionselect grantee,privilege from dba_sys_privswhere admin_option='YES';Do the same query 'WITH GRANT';The DBA role and SYS user will have this privilege.2ALLALL3.08.05Check for privileges granted WITH GRANT---2ALLALL3.08.06system privileges grantedsystem privileges tend to be more powerful and so should audited in case unauthorised users have them.select grantee,privilegefrom dba_sys_privswhere grantee not in ('SYSTEM','SYS','PUBLIC')and not exists (select 'A' from dba_roles where role=grantee)busines processs required to match the allocation of system privileges to the business requirement.1ALLALL3.08.07Check for application objects owned by privileged users---2ALLALL3.08.08Check for direct access granted to tables and objects rather than through ROLESIt is generally preferable to assign privileges to ROLES and ROLES to users rather than privileges to users. This is debatable though given the disadvantages of roles already highlighted so this item is not critical.These users have direct privileges.select distinct grantee, table_name, privilege from dba_tab_privs where grantee in((select grantee from dba_tab_privs)minus(select role from dba_roles));This is debatable given the disadvantages of roles already highlighted so this item is not critical.3ALLALL3.08.09CREATE LIBRARY privilegeCREATE LIBRARY privilege can be used to access the OS and escalate privilege and so this privilege should be revoked if not completely needed.select grantee,privilegefrom dba_sys_privswhere privilege='CREATE LIBRARY'none needed should be enforced.1ALLALL3.08.10Use roles to access underlying database objects---3ALLALL3.08.11Audit access privileges on objects---2ALLALL3.08.12Use Integrity constraints---3ALLALL3.08.13Use triggers to insert critical data---3ALLALL3.08.14Restrict users to one role at once---2ALLALL3.08.15BECOME USER privilegeBECOME USER privilege allows one user to act as another and should be closely monitored.select grantee,privilegefrom dba_sys_privswhere privilege = 'BECOME USER';none needed.2ALLALL3.08.16CREATE ANY DIRECTORY privilegeCREATE ANY DIRECTORY privilege allows a user to make a bridge between the DB and OS which is a potential security weakpoint and so this privilege should be monitored. There is no CREATE DIRECTORY so it is just CREATE ANY DIRECTORY.select * from dba_sys_privs where privilege='CREATE ANY DIRECTORY';The DBA role and SYS user will have this privilege.2ALL>=9i3.08.17CREATE ANY JOB privilegeCREATE ANY JOB privilege allows the grantee to run PLSQL jobs as another user and should be closely controlled.select * from dba_sys_privs where privilege='CREATE ANY JOB';The DBA role and SYS user will have this privilege.2ALL>=10g3.09.01Check for EXTERNAL users and also DBAExternal users have already been addressed in the OS section but an extra check is to see which users have the password of 'EXTERNAL'.EXTERNAL users should have absolutely minimal privileges as it is possible to spoof their logins. No SYSDBA or SYSOPER users should be allowed to have EXTERNAL passwords.select usernamefrom dba_userswhere password='EXTERNAL';

select usernamefrom dba_role_privs, dba_userswhere username=granteeand granted_role='DBA'and password='EXTERNAL';none needed as previously addressed.2ALLALL3.09.02Check for external users who are dba---1ALLALL3.09.03Check for external users who have ALL PRIVILEGES---1ALLALL3.09.04Ensure external users have the least privileges possible---2ALLALL3.09.05Do not use remote host based authentication---2ALLALL3.09.06Check that no external users have SYSDBA or SYSOPER---1ALLALL3.10.01Revoke public execute privilege on utl_fileUTL_FILE is used to bridge between the oracle database and the supporting OS and can be used to exploit the OS especially on Windows which has had problems limiting UTL_FILE to the $ORACLE_HOME.REVOKE ALL ON UTL_FILE FROM PUBLICnone needed - not negotiable1ALL>= 83.10.02Revoke public execute privilege on utl_tcputl_tcp can be used to connect from an Oracle database over the network to another database and is a common way for a hacker to move from machine to machine. PUBLIC does not require these privileges.REVOKE EXECUTE ON UTL_TCP FROM PUBLICnone needed - not negotiable1ALL>=8.1.73.10.03Revoke public execute privilege on utl_httputl_tcp can be used to connect from an Oracle database over the network to another database and is a common way for a hacker to move from machine to machine. PUBLIC does not require these privileges.REVOKE EXECUTE ON UTL_HTTP FROM PUBLICnone needed - not negotiable1ALL>=8.1.73.10.04Revoke public privilege on utl_smtputl_tcp can be used to connect from an Oracle database over the network to another database and is a common way for a hacker to move from machine to machine. PUBLIC does not require these privileges.REVOKE EXECUTE ON UTL_SMTP FROM PUBLICnone needed - not negotiable1ALL>=8.1.73.10.05Audit public execute privileges on sys owned packages.SYS owned packages can be ran as SYS by any user with execute privileges unless INVOKER rights are specified which is not the default. PUBLIC as a role is a blunt instrument as it is too wide in most cases. Iit is difficult to maintain least privilege when the PUBLIC role is assigned privileges. This is especially the case when the privileges are to SYS owned objects which have the ability to run as SYS much like SUID in UNIX binaries.It is advised when developing internal packages that auth_id current_users is used instead of definers rights to make the risk of the package being used less critical.This SQL will identify packages that are both owned by SYS and have EXECUTE granted to PUBLIC(select object_name from dba_objects where owner ='SYS' and object_type='PACKAGE')intersect(select table_name from dba_tab_privs where grantee='PUBLIC' and privilege='EXECUTE');Some packages need PUBLIC execute but many should not. Many recent PLSQL injection attacks are targetted at SYS owned definer rights PLSQL packages that PUBLIC has execute upon. Therefore execute should certainly be revoked on PUBLIC packages unless absolutely necessary. In either case the use of PUBLIC execute on SYS owned packages should certainly be audited, controlled and in the future deprecated.1ALLALL3.10.06Revoke the public execute privilege on dbms_random.---2ALLALL3.10.07Revoke the public execute privilege on dbms_lobDBMS_LOB can used to access files on the OS due to a bug in the way it handles relative paths. EXECUTE should be revoked from PUBLIC anyway but this is even better reason.REVOKE EXECUTE ON dbms_lob FROM PUBLIC;none needed - not negotiable1ALL>= 8i3.10.08Revoke any privileges on dbms_sql and dbms_sys_sql grantedThese packages should not have PUBLIC EXECUTE privileges as they can be used to trick DBA into executing commands as invoker. This was more of a threat when security models pre 8i worked on definer rights only.REVOKE EXECUTE ON dbms_sql FROM PUBLIC;none needed - not negotiable1ALLALL3.10.09Audit packages available via a database link---1ALLALL3.10.10Use invokers rights PL/SQL procedures---2ALLALL3.10.11Check DIRECTORY objectsDIRECTORIES from an Oracle point of view are links to the OS and should be monitored as part of an audit. Directories tend to be left behind after they are used and no longer needed which is a medium security risk.SELECT * FROM all_directories; andSELECT * FROM dba_directories;Un needed ones can droppedDROP DIRECTORY directory_nameNeed to be able to verify which directories are actually needed.2ALL>= 83.10.12Revoke execute privileges on sys.initjvmauxThis package can be used to used to escalate privilege and so should not have privileges granted on it. By default it should have no privileges.select grantee, privilege from dba_tab_privs where table_name ='INITJVMAUX';none needed2ALLALL3.10.13Revoke public execute privilege on dbms_jobdbms_job can be used to run scheduled jobs at a certain time which is useful for an attacker so that there scripts run unattended.Revoke execute privilegeREVOKE EXECUTE ON DBMS_JOB FROM PUBLIC;none needed - not negotiable2ALLALL3.10.14Revoke public execute privilege on dbms_schedulerthe dbms_scheduler has had a number of attacks directed at it and should preferably not be used at all. For certain the default execute privileges that PUBLIC posesses on the package should be revoked.revoke execute on dbms_scheduler from public;none needed - not negotiable1ALL>=10g3.10.15Revoke public execute privilege on owa_utilThe OWA_UTIL PL/SQL application exposes a number of stored procedures, which may beaccessible anonymously via the web.revoke execute on owa_util from public;This is will cause mod_plsql to stop working which will require execute being granted to the account used by the appserver to work again.2ALLALL3.11.01Use ROLES instead of directly granted privileges where possibleIt is better to organise privileges via ROLES than USERs directly as ROLES can be GRANTED and REVOKED en bulkROLES granted to ROLES can cause an obfuscated hierarchy of privilges which can make it difficult to work out what privileges a user actually has so this item in the guide should be tempered with the proviso not to layer ROLES too deeply.2ALLALL3.11.02Access tables through packages or roles.---4ALLALL3.12.01Change system users default tablespace.---1ALLALL3.12.02Change users default and temporary tablespaces---2ALLALL3.13.01Revoke the RESOURCE role from usersRESOURCE has more privileges than are required for instance UNLIMITED TABLESPACE which can cause a DoS.1ALLALL3.13.02Revoke the CONNECT roleCONNECT has more privileges than required to connect to the database. Revoke the connect role and replace with a stripped down version that has CREATE SESSIONSelect * from dba_sys_privs where grantee='CONNECT';

GRANTEE PRIVILEGE------------------------------ ----------------------CONNECT CREATE VIEWCONNECT CREATE TABLECONNECT ALTER SESSIONCONNECT CREATE CLUSTERCONNECT CREATE SESSIONCONNECT CREATE SYNONYMCONNECT CREATE SEQUENCECONNECT CREATE DATABASE LINKto identify those with CONNECT you can use this query.select grantee from dba_role_privs where granted_role='CONNECT';Thorough testing of the new ROLE to replace CONNECT would require time and testing.2ALLALL3.13.03Add passwords to administrative rolesIn high security environments powerul roles such as DBA should be passworded. Please note that a passworded role granted to another role does not need a password anymore from the other role. Also password management features do not apply to roles so roles have weaknesses too.CREATE ROLE dba_role IDENTIFIED BY "S0^Sorry"; or alter role dba identified by "S0^Sorry";See which roles are passworded.select *from dba_roleswhere password_required='NO';discretionary2ALLALL3.13.04Revoke all from PUBLIC that's not neededPUBLIC role has privileges that can be accessed by any valid database account. As such all ROLEs and privileges not required should be revoked.This query will identify all ROLES and privs granted to PUBLIC.select 'SYSTEM','SYSTEM',privilegefrom dba_sys_privswhere grantee='PUBLIC'unionselect 'OBJECT',table_name,privilegefrom dba_tab_privswhere grantee='PUBLIC'unionselect 'COLUMN',table_name,privilegefrom dba_col_privswhere grantee='PUBLIC'unionselect 'ROLE','ROLE',granted_rolefrom dba_role_privswhere grantee='PUBLIC';This will take a long time and needs to be broken down into stages. The main amount of results will be the object privs form dba_tab_privs. Prioritise the others first and then prioritise SYS owned objects and objects that have known vulnerabilities.2ALLALL3.14.01Set password lifetime in profile to 60---3ALL>= 83.14.02Set password grace time to 3---3ALL>= 83.14.03Set password reuse max to 20---2ALL>= 83.14.04Set failed login attempts to 5---3ALL>= 83.14.05Set up profiles for database usersAs well as pass management Profiles allow for session management which can help defend a session from attack. These profile parameters should be set up and different values set in different profiles for each security level of user.Parameters that can be set and will increase security are:CPU_PER_SESSIONPRIVATE_SGASESSIONS_PER_USERCONNECT_TIMEIDLE_TIMEagreeing how long a session can be left idle before it is disconnected is the main issue here and it depends on the power of the account and security context of the environment being used. DBA accounts should cut out more quickly and have less sessions per user normally.3ALLALL3.14.06Set up general profile parameters---2ALLALL3.15.01Set _trace_files_public to falseSet _trace_files_public parameter when set to true can allow any user to read the trace files so explicitly set this to false.set this paramete in the init.ora filenone needed3ALLALL3.15.02Review initialisation parametersParameter value changes can be missed and have a large affect there fore they should be checked especially as some parameters are hidden.This SQL will list all parameters:select pin.ksppinm called, pcv.ksppstvl itsvaluefrom sys.x$ksppi pin, sys.x$ksppcv pcvwhere pin.inst_id=userenv('Instance')and pcv.inst_id=userenv('Instance')and pin.indx=pcv.indxand translate(pin.ksppinm,'_','^') like '^%';Alternatively an OS level checksum of the init.ora file would also verify more easily the state of the parameter file. Try to explicitly declare hidden parameters so that they are known. For example _system_trib_enabled set to FALSE will switch off all SYSTEM triggers which may be used for auditing actions on objects. This should be explicitly set and monitored.none needed3ALLALL3.15.03Ensure system triggers fire---1ALL>=8i3.16.01Audit tablespaces for Rogue objects and whether autoextensible.An applications tablespace should not have objects owned by another user within it because if the object grows in size it may cause an denial of service on the application . Autoextensible tablespaces can also grow and deman too much disk space so this should be monitored.This query will find the autoextensible tablespacesselect tablespace_name from dba_data_files where autoextensible='YES';none needed3ALLALL3.17.01Check each user has a tablespace quotaIn order to stop a user from taking up too much tablespace and possibly causing a DoD accidentally or maliciously a quota should be imposed that will limit the size of that users tablespace.Check the users from this query and assign a quote where appropriate.(select name from sys.user$)minus(select username from dba_ts_quotas);none needed3ALLALL3.17.02Establish different users for schema management and data management---3ALLALL3.18.01Set up naming conventions for schema owners and administrators and users---5ALLALL3.19.01Check for triggers on others tablesIt is possible to steal data from another schema using a trigger. Triggers should be audited in order to find triggers in a schema owned by someone else.This query will find triggers not owned by the schema owner.select owner, trigger_name, table_owner, table_name from dba_triggers where ownertable_owner and owner not in ('SYS','SYSTEM');none needed2ALLALL3.20.01Audit access to critical sys/dba owned tables and views with oracle passwordsuser$, link$ and dba_users view allow access to the password hashes which in combination with the username makes decrypting the hash feasible.This query will select the users and roles that can select the hashes. (select grantee from dba_tab_privs where table_namein('USER$','DBA_USERS'))UNION(select grantee from dba_sys_privs where privilege in('SELECT ANYDICTIONARY','SELECT ANY TABLE'))UNION(select grantee from dba_role_privs where granted_rolein('DBA','OLAP_DBA','OLAP_USER','SELECT_CATALOG_ROLE'))ORDER BY GRANTEE; This query includes users who have SELECT ANY TABLE which is a privilege that should be revoked.The permission of select any table is required by the DBSNMP account for the intelligent agent to work which may be a factor in keeping this privilege IF the Intelligent agent functionality is to be kept.1ALLALL3.20.02Audit access to all dba and sys owned views---1ALLALL3.20.03Revoke SELECT ANY TABLE---1ALLALL3.21.01Revoke object creation privileges from all but schema owners and DBAsobject creation should be limited to the schema of the owner and to privileged accounts such as DBA. Object creation privileges such as create table should be revoked for non-DBA and non-schema owners.revoke create any table from user;the schema owner will still be able to create tables in their own schema but not others. There needs to be a very good reason to not do this for all but high privileged users.2ALLALL3.21.02Audit general users object accessdue to privilege inheritance with ROLES it is easy for a user to be able to see objects they should not. The best way to test this thoroughly is to login as that user and see what can be seen.This query will return the privileges of a user.select 'SYSTEM', privilegefrom dba_sys_privswhere grantee='SCOTT'unionselect table_name,privilegefrom dba_tab_privswhere grantee='SCOTT'unionselect table_name,privilegefrom dba_col_privswhere grantee='SCOTT'unionselect 'ROLE', granted_rolefrom dba_role_privswhere grantee='SCOTT';time intensive. If time pressured and not v.high security then better to approach from the direction of identifying the sensitive objects and seeing who has privileges on them rather than this method which looks at everything an individual can see and have to be repeated for each individual.2ALLALL3.22.01Audit views to ensure correct accessVIEWs can by design be used to update the underlying table if update is granted on the VIEW. This should be monitored. On top of this is the fact that there has been a bug in Oracle whereThis SQL will identify VIEWs which allow base table to be edited.select grantee,table_name,privilegefrom dba_tab_privswhere exists (select 'x' from dba_views where view_name=table_name)and privilege'SELECT'unionselect grantee,table_name,privilegefrom dba_col_privswhere exists (select 'x' from dba_views where view_name=table_name)and privilege'SELECT'/

Also it is possible to bypass Oracle object security on underlying tables from a view as below(from David).SQL> connect / as sysdbaConnected.SQL> create table ttt (n number, text varchar2(20), constraint n_pk primarykey(n));Table created.SQL> insert into ttt (n,text) values (1,'abc');1 row created.SQL> grant select on ttt to scott;

SQL> connect scott/tigerConnected.SQL> create or replace view vvv as select a.n, a.text from sys.ttt a joinsys.ttt b on a.n = b.n;View created.SQL> select * from vvv; N TEXT---------- --------- 1 abcSQL> insert into vvv (n,text) values (2,'eee');1 row created.none needed2ALLALL3.23.01LOCK SYS and SYSTEM and create new DBA accountsThis measure when combined with a less obviously named new DBA account will help to secure the database from unauthorised privileged access.alter user system account lock; or can also set the password to an impossible password using an impossible password like this:SQL> alter user sys identified by values 'no-decrypt';

User altered.

SQL> select password from dba_users where username = 'SYS'; PASSWORD ------------------------------no-decryptNote that SYS AS SYSDBA cannot be locked in this way so strenght in depth with the other measures needed especially OSDBA access from OS.2ALLALL3.24.0107_DICTIONARY_ACCESSIBILITY =FALSESELECT ANY TABLE privilege should be revoked but if a user does have it then the setting of 07_DICTIONARY_ACCESSIBILITY =FALSE would mean that they could not SELECT from the data dictionary which holds important metadata about the database including passwords.This can be used prevent DBA's reading critical data as well.07_DICTIONARY_ACCESSIBILITY =FALSEnone needed2ALLALL3.25.01Prevent the dba from reading application data---4ALLALL3.26.01Audit integration and server to sever communications---2ALLALL3.27.01Disable unneeded TCP ports.Ports 2100 and 8080 were added to 9iR2 as part of the XDB server and represent an additional attack surface which if not needed should be removed.remove the line dispatcher=(PROTOCOL=TCP) (SERVICE=orat92XDB)none needed2ALL>=9iR23.28.01Audit and secure statspackPUBLIC has privileges on STATS$% tables and should be revoked and GRANTED back individually.select * from dba_tab_privs where grantee ='PUBLIC' and table_name like 'STATS$%';revoke as necessarynone needed2ALL>= 8i4.00.00Auditing4.01.01Configure audit and storage.basic Oracle Auditing can either be to the OS or to the DB which is easier but the OS is more secure as the OS is harder for a DB user to delete and will less likely affect the running of the DB if the Audit logs get very large. SYS.AUD$ is the database table that takes the auditing logs which since it is on a SYSTEM tablespace and allowed to grow could DoS the whole database. Moving AUD$ away from SYSTEM tablespace is not supported by Oracle but can be done.The other major issue with auditing is the problem with performance as the more that is audited the more resources are taken away from the running of the server. It has often been the case that all auditing is switched off in order to aid performance. This is not recommended. Auditing of most important actions should be made as a minimum. These are all actions by SYS and actions on critical system tables such as SYS.USER$ by everyone.Please see Oracle Privacy Auditing by Arup Nanda for more detail on Auditing on Oracle.It is recommended to log auditing to the OS. Select value from v$parameter where name = 'audit_trail';Set to OSPlease note on Windows OS trails are recorded to the Application Event Logs.It is recommended to audit at least all SYS actions.Select value from v$parameter where name = 'audit_sys_operations';Set to TRUE (this parameter is new in 9iR2)Plus to audit certain critical actions like selecting the password hashes. This is object auditing which would look like this:AUDIT SELECT ON SYS.USER$ BY ACCESSPlease note that compliance with data standards such as Sarbannes Oxley, HIPAA and GLB act require the ability to audit to Row Level sensitive data.There can be much discussion on Auditing and the recommendations here represent the bare minimum that a server should have and should not represent a detriment to the performance of the server. Addtionally auditing can be added from here and is highly flexible and complex. Of major importance is the purging strategy as the more AUDIT the more logs and where to store them. Please see Oracle Privacy Auditing by Arup Nanda for more detail on Auditing on Oracle.1ALLALL4.02.01Audit failures on critical objectsThe failure of any user to update a critical table is classic auditing priority and can be done easilly. The more users who are likely to be affected by this then the less it should be done due to performance hit.For example:audit update on sys.salaries whenever not successful;As long as the action being audited should not occur often and the action is critical then it is justified.2ALLALL4.02.02Use triggers to capture login events---2ALLALL4.03.01Audit create sessionAuditing create session would be used to catch the time that users logon and off. It would generate a lot of audit. The same principle follows for these audit actions:Audit grant,drop, alter,create user, create role,Not difficult to do as just issue this command.AUDIT SESSION';Will this affect performance. Best to test beforehand on dev server or at a time when contigencies have been put in place.3ALLALL4.03.02Audit use of all---3ALLALL4.03.03Audit the use of all drop statements---3ALLALL4.03.04Audit the use of all alter statements---3ALLALL4.03.05Audit the use of create user---3ALLALL4.03.06Audit use of create role---3ALLALL4.03.07Audit all create statements---3ALLALL4.03.08Review audit logsThe audit logs are easily readable via a view called dba_audit_trail.As someone is going to need to read and react to this audit this is another reason for selectively auditing the most important events in the DB. Aslong as redo logs are being archived off the databases state can always be inspected using Logminer http://www.giac.org/certified_professionals/practicals/gcfa/0159.php or reinstated.select * from dba_audit_trail; This is a large view and there fore best read through a client like SQLDeveloper from Oracle or SQL Tools which is a free client. http://www.sqltools.net/Some audit has to be done and therefore some review of audit logs has to be done.The question is how much and how often which is a business decision sensitive to the security needs of that department.3ALLALL4.03.09Use Log Miner to audit in the case of forensics---4ALLALL4.04.01Configure basic audit---2ALLALL4.04.02Limit users who can change the auditAuditing is a sensitive subject especially when auditing privileged users.The auditing role should be limited to a small group and separate from the main DBA function so that they are independent.This query shows users with audit privileges.select grantee,privilegefrom dba_sys_privswhere privilege like '%AUDIT%';should be unnegotiable. Please note that the newest functionality in Oracle database called database vault is specifically designed to withhold some control from senior DBA as this concept of everyone being accountable to policy is of current concern. http://www.oracle.com/technology/deploy/security/db_security/database-vault/index.html1ALLALL4.04.03Protect,backup and purge the audit trailIf have to audit to sys.aud$ then can use auditing to protect the audit.Make sure the audit is backed up and purged so that the disk does not fill to cause DoS or lose audit logs.AUDIT ALL ON SYS.AUD$ BY ACCESSOS is preferred as previously stated.2ALLALL4.04.04Backup the audit trail---3ALLALL4.04.05Purge the audit trail---4ALLALL4.04.06Audit all SYS operations---1ALL>=9iR24.05.01Check date / time stamps on database objects---3ALLALL4.06.01Ensure reports and alerts are in place to deal with irregularities found through audit---3ALLALL4.07.01Use triggers for row level auditing upto 8ican use triggers to provide row level auditing even though fine grained auditing is not present in 8i.3ALLALL4.07.02VPD, RLS and label securityFGA came in with 9i and allows auditing of what a user selected at the row level. This is implemented using dbms_fga.add_policy.Linked to FGA is Virtual Private Databases which allows segregation of data between users so that they are as if they were in seperate databases. VPD configuration is done using DBSM_RLS.Oracle Label Security use user labels to grant access at the row level.dba_fga_audit_trail is the main view for seeing this row level audit and should be used.fine grained audit may be a requirement for compliancy sake so not negotiable but should only be needed for sensitive data.3ALL>= 84.08.01Be aware of possible failure to be alerted of suspicious activities---2ALLALL4.09.01Be aware of possible failure to audit the security profile.---2ALLALL4.10.01Monitor Other Oracle generated log filesThe other logs apart from Basic Oracle Auditing are:Event Viewer,Syslog, Listener.log, access_log, error_log, sqlnet.log. These can be used to correlate information after an incident.The location of these logs should be known before and incident occurs and practise should be made at correlating these logs so that problems that may occur during an incident are solved beforehand.1ALLALL5.00.00Networking5.01.01listener Password and Admin restrictionsThe Oracle Listener is controlled by the LSNRCTL utility which previous to 10g allowed remote administration of the listener without authentication by default. This meant that anyone could shutdown the listener remotely. The Listener can be passworded which keeps remote administration but the password can be inputted as a hash that has been sniffed instead. This is assuming that the Listener password has been encrypted.The secure way to configure the listener is with Admin Restrictions ON which means that the Listener configuration changes have to be done locally by editing the Listener.ora file at the OS.Set a password on the Listener and set Admin Restrictions to ON. To encrypt the listener password change it through lsnrctl:lsnrctl>change_passwordpassword changedlsnrctl>save_config

Then restart the listener.

USE SSH TO THE OS TO ADMIN THE LISTENER.Minimum passworded Listener and very preferably should be Admin Restrictions ON which is now the default in 10g.Please see this document for more detail on securing the Oracle Listener. http://www.integrigy.com/info/Integrigy_OracleDB_Listener_Security.pdf It should be noted that some clustering software such as SUN Solaris v3.0 cannot restart the Listener automatically if it fails and is passworded. The new 3.1 version does.1ALLALL5.01.02Prevent remote dba access on sql*net v1---4ALLALL5.01.03Audit the listener.ora file---5ALLALL5.01.04Enable shared socketsIf Oracle is networking through a firewall then set it so that it can shared sockets.USE_SHARED_SOCKETS added to init.oraHas a slight negative effect on performancy so only use when having to tunnel through a firewall.3winALL5.01.05Use a firewall to protect the Oracle serverOracle networks on 1521 by default at the server but as the connection is made MTS allocates a new server port for that connection. This will be blocked by most firewalls so one solution is to force MTS to allocate a known port after the initial exchange. An alternative to this is to use a Proxy firewall such as Checkpoint NG1 which keeps state of current connections and can therefore handle a change of port number.The Listener should not be connected to over the Internet.Set the fixed MTS dispatchers in the init.ora file.http://www.cs.umbc.edu/help/oracle8/server.815/a67775/ch2x_mts.htmCan also use an Oracle aware firewall instead but Oracle Server must be protected from direct access by untrusted network such as the internet.3ALLALL5.01.06Change the standard listener ports 1521, 1526These default ports are well known and it is easy to change the port.Change the port using listener.ora file.none needed.2ALLALL5.01.07Change the names of the SID and ListenerChange the default SID name from ORCL and the default Listener name of Listener.Edit the listener.ora filenone needed.2ALLALL5.01.08Do not use hostnames in listener.ora In small environments.IP addresses are safer and place less load on the DNS system but larger networks require hostnames so that traffic can travel between subnets and so that an IP related DoS can be averted.use IP address in the listener.ora for smalll networks.discretionary3ALLALL5.01.09Use a personal firewall on database administrator computers---2ALLALL5.01.10Secure listener.ora at the O/S levelIf the listener.ora is the main point of Listener configuration then it should be secured appropriately using OS permissions.chmod 600 listener.oraor using the NTFS file permissions.Also recommend taking a hash of the file so that it can be seen that is the same.none needed - not negotiable1ALLALL5.01.11listener logging enabledBrute force attempts are not stopped by the Listener but it can log them if logging is enabled.set:LOGGING_LISTENER=ONnone needed2ALLALL5.02.01Restrict sources of connectionsvalid node checking can be set so that only authorised source IP addresses can connect to the listener.set protocol.ora in 8i and sqlnet.ora in 9i/10g:tcp.validnode_checking=YEStcp.invited_nodes =(10.1.1.161, etc)tcp.excluded_nodes=(10.1.1.160, etc)discretionary3ALLALL5.02.02Use connection manager to restrict by sourceConnection manager can restrict connections based on origin, destination and SID and it can accept wildcards unlike valid node checking.needs configuring on each client in sqlnet.ora:USE_CMAN=TRUECan also use Oracle names or Oracel Internet Directory preferably OID.Architectural issue is complex and cannot presribe completely. OID seems to be preferred route.2ALLALL5.03.01Set the listener password---1ALLALL5.04.01Restrict listener banner information---3ALLALL5.05.01Use a firewall to protect the Oracle server.---2ALLALL5.06.01Audit Oracle client file permissions---4ALLALL5.06.02Audit client configuration file contents---5ALLALL5.06.03Audit the listener and sqlnet files on the serverThe networking files on the server should be audited to make sure that the permissions are adequate, the contents are correct and no nefarious copies of these files can be viewed by an unprivileged user.Please note that fat thumbed passwords may appear in the sqlnet.log from failed SQL*PLUS connections.Use Locate command on Linux, Find on Solaris or explorer search on Windows to find nefarious copies of listener.ora and sqlnet.ora.Check the permissions which should be 600 or similar.Secure the wallet directory for OID.Shoud not be much discussion needed.2ALLALL5.07.01database linksDatabase links are useful to make connections from one database to another. These links may contain clear text passwords and allow access to unsecured development databases. Links can be PUBLIC,PRIVATE or GLOBAL. PUBLIC can be used by any user and if this link is made using a fixed user the authentication details will be in the link. Database links between Production and Development should be avoided and all links should be audited so that least privilege is extended through the link to the target database.This will query the link$ table for stored passwords.select name,password from sys.link$;Do not set up links as the DBA user as this user can masquerade as any other and has too many privileges for a link.

Set DBLINK_ENCRYPT_LOGIN to TRUE.Shoud not be much discussion needed.1ALLALL5.07.02Discover what objects can be seen in the linked database---2ALLALL5.07.03Create a policy to manage database links---1ALLALL5.07.04Database link user should not be a dba---1ALLALL5.07.05Audit what links exist into and from the database---1ALLALL5.08.01Confirm the file permissions in the network admin directory---2ALLALL5.08.02Add only minimum configuration files to all clients---2ALLALL5.09.01Keep up to date with Oracle listener vulnerabilities and patch---2ALLALL5.10.01Secure remote dba access to the server---1ALLALL5.10.02Use an application gateway firewall---2ALLALL5.11.01Set server to dedicated in the tnsnames.ora file---1ALLALL5.11.02Oracle ports scanShould run a regular port scan on the oracle server to see if additional services have been added or if Oracle ports not required are running.There are many default Oracle ports:1521, 1526 default listener which should be changed. Please check the appendices for a list of Oracle default port numbers.Run a port scan using NMAP and vulnerability scan using Nessus or NGS SQuirreL for Oracle. The port number profile of that server should be recorded so that changes can be recognised. Remove needed services/ports.none needed.3ALLALL5.12.01intelligent agentThe intelligent agent which functions like an Oracle version of SNMP called DBSNMP which uses the DBSNMP account with default password DBSNMP. It is possible to improve the security of this greatly above the default but it should not be used on an untrusted network.OEM is very functional but its automation is built upon default account settings that are insecure and so for high security networks it is not recommended.Secure the snmp_ro.ora and snmp_rw.ora file as part of the IA audit.depends on the security of the network environment.At least put in place the previous securing DBSNMP recommendations and preferably do not use at all. SQL*PLUS command line over SSH is preferred admin tool.2ALLALL5.12.02Protect clear text passwords for SNMP---2ALLALL5.13.01encrypt data transferSQL*PLUS encrypts passwords (which can be broken if attacker has the hash) but it does not encyrpt the data.If the client connections are made via web browser then SSL should be used which is part of OAS but can be implemented seperately from OAS.If data sent is sensitive then the connection should be made over SSH. If the connection is permanent then setting up an IPSEC tunnel would be a more practicable solution. The best solution is the most expensive being Oracle Advanced Security.http://oracleheva1.oracle.com/docs/cd/B19306_01/network.102/b14268/asointro.htmnone needed.2ALLALL5.13.02Enable SSL to protect client transmissions---3ALLALL6.00.00Availability / backup / Recovery6.01.01Backup and recovery proceduresAvailability is one of the most important components of a security plan. Having good backup and recovery procedures is part of maintaining availability and therefore is part of a security plan. This is especially the case when backups can be restored by an attacker. Why attack the server when you can easily gain the backups for the server. Once copied then they may be altered and if a recovery can be forced the attackers malware could get onto the server. Backups are a current research topic for researchersIt is imperative to secure backup media and to practise using the backup processes so that a real recovery can be done efficiently in case of crisis.Remote Archive Logging is a key recommendation for good Oracle backup and recovery.Schedule both hot backups which take the data and Cold backups which will take all data and configuration for a complete rebuild. This will require some kind of failover secondary server if 24/7 is required.Rotate and renew backup media incase of worn tapes.DBA's often appreciate this very well perhaps more fully than many security researchers in the past though the potential for attack via backups is now becoming more well known.http://www.dbaoncall.net/references/ref_backup_strategy.html1ALLALL6.01.02Document recovery proceduresBackup procedures should not only be secured and practised this should also be documentedDocument both the process of backup and recovery and the testing of these processes with sign off from security and senior admins so that it can be proven that this has been done. Need to have a process owner who is accountable in case of failure.not negotiable.1ALLALL6.01.03Store backup media off siteIn case of fire, bomb or flooding it is wise to have off site backup which must be secured.Test the off site backup procedures.Should not be negotiable.2ALLALL6.01.04Schedule cold backups---3ALLALL6.01.05Validate the backup media regularly---3ALLALL6.01.06Do not allow backups to be available on-line---2ALLALL6.01.07Create and use media retrieval procedures---2ALLALL6.02.01On line redo logs mirroringThe Oracle database cannot work normally without the redo logs and so these should be mirrored.Mirroring simply involves making a copy of the redo log which can be done by Oracle Multiplexing or OS level mirroring. Put the mirrors on a different disk from the origina in case of disk failure.none needed2ALLALL6.03.01Ensure the database is in archive log mode and protectedremote archive logging is preferableselect log_mode from v$database;Ensure archive logs are written to backup and are purged and protected.none needed2ALLALL6.03.02----2ALLALL6.03.03----3ALLALL6.04.01Separate the Oracle software from data and from on-line redo and archive---3ALLALL6.04.02Keep Oracle data files on separate disks---3ALLALL6.04.03Use OFA---5ALLALL6.04.04Use striping and mirroring or RAID for Oracle data---4ALLALL6.05.01Destroy old disks that have contained database data.Data can be recovered from hard drives using forensics techniques both at the OS layer and DB layer.Use secure delete software to wipe the disks or magnetically wipe them. Then destroy them phsysically and if necessary distribute seperately. Physical reconstruction is possible though currently expensive.should not be needed.2ALLALL6.06.01Document and review disaster recovery procedures---4ALLALL6.06.02Include business users in disaster recovery planning---4ALLALL7.00.00Application Development7.01.01wrap PL/SQL code in the databaseWrapping encodes the source code of a package in the database.This process is recommended especially if the source has proprietary code within it. A good reason for wrapping for example would be to hide the mathematical calculation that is used to gain a result which is passed back.use the following command at the OS.Wrap iname =infile oname=outfileWrapping the PLSQL is not a high security measure as it has been reverse engineered.Search for unwrapped code using the following.

select owner,name from dba_source where text like'%wrapped%';

select owner,name from dba_source where text not like'%wrapped%';It is relatively easy to wrap the code. The question will be keeping the clear text version of the code and being able to keep a record of the state of the currently used version of the package which is where checksummng can be useful.2ALLALL7.01.02Checksum all PL/SQL objects in the databaseChecksumming all the objects in the database can be done using the packages within Oracle there is no need to do this externally unless there is a fear that the database has already been attacked.dbms_utility.get_hash_value can be used to get a hash value of a package.This process can be automated so should not take long.3ALLALL7.01.03Audit PL/SQL code for hard coded usernames and passwordsOracle 9i wrapped PLSQL has the ability to read strings by in the file. This can be a way to find usernames and passwords which should be checked for.run an automated grep like search on PLSQL packages to see the strings that are in them.none needed3ALLALL7.01.04Audit PL/SQL code for possible SQL injection attacksa common flaw with PLSQL packages both from Oracle and custom made is the susceptibility to SQL injection. See http://www.ngssoftware.com/papers/advanced_sql_injection.pdfIn essence the problem is code that forms dynamic SQL allowing SQL key symbols as input which instead of being parsed as string is parsed as SQL.There are a number of cures for this http://www.ngssoftware.com/papers/DBMS_ASSERT.pdfPrepared statements are used in Java as well to stop this problem.The classic way to find these bugs is to insert a single quote into a text input field. This can be interpreted as a break in attempt so should only be done on internal applications with permisssion in writing.This process is difficult to do automatically and if there is a lot of code it may be worth seeking a specialised Code Review consultancy.2ALLALL7.01.05Ensure as little information as possible about schema structure is available from the code in Oracle---3ALLALL7.01.06Pre-compile Java code before loading into the databaseJava source code can be read from sys.obj$ table and can also be read using DBMS_LOB.precompile java and load using the loadjava utility.should not be needed.3ALLALL7.02.01Secure accounts accessing through ODBCODBC will carry the privileges of the user over to Oracle and so these accounts should be checked too. Excel and Access can connect to Oracle via ODBC and will pick up all the PUBLIC privileges.lock down the privileges generally as previously described and test connecting to Oracle via MS Office applications.Applications that are allowed to access Oracle should be registered using DBMS_APPLICATION_INFOnone needed2ALLALL7.02.02Implement procedures to limit which applications can access the database and from where---2ALLALL7.02.03Audit software/admin tools accessing the databaseTools such as Toad, PLSQL Developer, SQL Developer and DBA studio can be used to remotely access an Oracle database just like SQL*PLUS. These tools can allow an overview of database structure that is not needed for the developer.Assign a specific account for applications like Toad so that it can be locked down in a way specifically to that application and its activitied monitored seperately.none needed3ALLALL7.03.01When decommissioning old applications remove all binaries and files---4ALLALL7.04.01Review procedures for adding new applications---4ALLALL7.05.01Establish procedures for movers, -rs and joiners---2ALLALL7.06.01Audit application file permissions---3ALLALL7.07.01Audit application development on production databasesApplication developers often work on a production system before it is actually put into production so it is important to secure what they have left behindOld application files should be removed and new ones should have the correct permissions assigned. Access to the database by development should be stopped before going to production and no more access granted unless requested and checked.Check for evidence of development work by comparing the timestamps on the view dba_objects. If the last_ddl_time is after development work should have stopped then there may have been unauthorised access.none needed3ALLALL7.08.01ad-hoc queries against production database---3ALLALL7.09.01test and development databasesseparate the two and try to mirror closely the environment so that developers do not need access to the production server to test applications.developer privileges present in the development database should be tested to make sure they are not in production.Also check for db links between the two as described previouslyAlso make sure that test data in development is not real data but does closely model it.There may be teething stage for a new application that requires temporary privileges to the production server to be granted to development. A process should be in place to make sure that any temporary accounts are deleted after a set period of time.If real data does get in to the development db then the top priority is to make sure that the DB account usenames and passwords transferred are deleted and new ones created.2ALLALL7.09.02Check for database links with access to production databases from development or test systems---2ALLALL7.09.03Ensure live data held in test or development is mangled or obfuscated.---2ALLALL7.09.04Do not locate test and development databases on the same server as production---2ALLALL7.09.05Ensure there is no access from test and development to production---2ALLALL7.09.06No developer access to production---1ALLALL7.09.07No developer database accounts should exist on production database---2ALLALL7.09.08Backups and exports copy passwords to test and development ensure they are not the same---2ALLALL7.09.09Place development and test on different network segment to production---2ALLALL7.10.01non application objects in application tablespacesAs described previously objects not owned the tablespaces schema owner can pose a risk if they grow and cause a DoS especially if the objects are owned by privileged users.select owner,segment_name,segment_typefrom dba_segmentswhere tablespace_name='appowner';2ALLALL7.10.02Ensure no privileged user owns application objects---2ALLALL7.11.01Resources used by the databaseResources can become overused especially with installation of third party applications therefore it is wise to check these resources after installation and running.use the v_$resource_limit view to compare resource usage before and after. Compare this to the maximum resources available on that server and increase if necessary using ALTER SYSTEM.should not be needed.2ALLALL7.12.01Application authenticaion vs Oracle authenticationCare should be taken when implementing and designing application authentication that it cannot be side stepped within Oracle.It is often a good idea where possible to use Oracles authentication system and secure it at the Oracle end. This also means that auditing and logging can be individual to the account being used rather than having all application users using the same Oracle account which the application manages.There is not always a choice in this depending on the third party application.1ALLALL7.12.02Do not use one database login to authenticate all users---2ALLALL7.13.01Do not use schema owners for administration tasksUsing a schema owner to access the databaes means that all objects within that schema become available as well as any higher privileges granted.Use a dedicated role that is assigned the required privileges and if possible lock the schema owners account.if not possible at least ensure that the schema owner has not been granted the DBA role.2ALLALL7.13.02Ensure the schema owner is not a dba---2ALLALL7.13.03Lock schema owner