1. Auditing Oracle Lisa Outlaw CISA, CISSP, ITIL Foundation
IS Audit Supervisor, North Carolina State Auditor

2. Objective To explain the following: Key Oracle Audit Areas
Risks in each Audit Area
Controls that should be implemented
Audit procedures to evaluate controls

3. Audit Areas Data Dictionary Privileges Parameters
Default Users Accounts
Profiles
Roles
Links
Audit Trail

4. Data Dictionary
Contains all the information about the structures and objects of the database
Tables, columns, users, data files, etc.
Owned by the Oracle account “SYS”
This is the most powerful account in Oracle
Contains all the security data
Tables, users, tab privs., etc

5. Data Dictionary Risks
Attackers can gain valuable information about the database
including accounts and encrypted passwords.
Attackers could destroy the database by deleting key tables.

6. Data Dictionary Controls
Ensure Access to the data dictionary is limited to only those accounts that need access to fulfill their job duties.
Normally, only the database administrators should have access to the data dictionary.

7. Audit Procedure to evaluate controls over Data Dictionary
O7_DICTIONARY_ACCESSIBILITY=FALSE
this is a database initialization parameter that controls access to objects in the SYS schema.
Set this to FALSE to prevent users with EXECUTE ANY PROCEDURE and SELECT ANY DICTIONARY from accessing objects in the SYS schema.
If set to TRUE, accounts with "ANY" privileges could get access to objects in the SYS schema, hence the data dictionary.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME)=‘O7_DICTIONARY_ACCESSIBILITY’;

8. Privileges Privileges are Types of privileges
the tasks that accounts or roles are allowed to perform.
used by the database to determine if access to resources will be allowed or denied.
Types of privileges
System Privileges - Apply to the entire database
Schema Object Privileges -Apply only to a portion of the database

9. Risks of Powerful Privileges
Excessive access to system tables and critical application tables may lead to:
Unauthorized changes to data
Denial of database services

10. Controls over Powerful Privileges
Privileges should be granted based on the need to know, need to use basis.
Polices, procedures, and standards should support privilege granting decisions.

11. Controls over Powerful Privileges
Privileges on system and database objects should be carefully assessed, documented, and granted to the proper accounts and roles
Typically end-user accounts should not be granted system privileges except create session
Insert, Update, Delete on critical tables should be limited to required users

12. System Privileges
System Privileges allow an account to perform a particular action on any schema
Ex. Read (Select) any table in the database
SELECT ANY TABLE privilege
Over 150 different system privileges in Oracle

13. Audit Procedures to evaluate controls over System Privileges

14. Audit Procedures to evaluate controls over System Privileges
Ensure that only authorized personnel has system privileges in critical databases.
Therefore, all system privileges except for CREATE SESSION should be restricted to the Database Administrators (DBA)
SQL Command to Evaluate Control
SELECT * FROM DBA_SYS_PRIVS WHERE PRIVILEGE <> 'CREATE SESSION';
Ensure REVOKE ALL <PRIVS> FROM <USER>;

15. Example of Script Output

16. Audit Procedures to evaluate controls over System Privileges
Prevent granting privileges for the entire catalog of objects
prevent granting of privileges that contain the keyword ANY.
The ANY keyword grants the ability for the user to set privileges for the entire catalogue of objects in the database.
Check for any user or role that has the ANY keyword and revoke this privilege where possible.
SQL Command to Evaluate Control
REVOKE ALL <PRIVS> FROM <USER>;
SELECT * FROM DBA_SYS_PRIVS WHERE PRIVILEGE like "%ANY%";
SELECT * FROM DBA_SYS_PRIVS WHERE PRIVILEGE like '%SELECT_ANY_%'

17. Audit Procedures to evaluate controls over System Privileges
Prevent granting of ALL privileges.
The GRANT ALL PRIVILEGES must not be used; it gives full access to all tables, views and objects to the user or role it is granted to.
SQL Command to Evaluate Control
REVOKE ALL PRIVILEGES FROM <USER/ROLE>
GRANT <SPECIFIC PRIVILEGES> TO <USER/ROLE>;
SELECT * FROM DBA_SYS_PRIVS WHERE UPPER(PRIVILEGE) like 'GRANT ANY %' OR PRIVILEGE like 'GRANT ALL %';

18. Audit Procedures to evaluate controls over System Privileges
Prevent granting of SELECT ANY TABLE.
If application data is sensitive, and it is possible, revoke this privilege from the DBA accounts as well.
SQL Command to Evaluate Control
 REVOKE SELECT ANY <OBJECT> FROM <USER>;
SELECT * FROM DBA_SYS_PRIVS WHERE PRIVILEGE like '%SELECT ANY %'

19. Audit Procedures to evaluate controls over System Privileges
Prevent granting of privileges that have CREATE.
Check for any user that has object creation privileges and revoke where possible.
Excessive create privileges can allow an attack to create arbitrary objects, tables, and views.
SQL Command to Evaluate Control
REVOKE CREATE <PRIV> FROM <USER/ROLE>
SELECT * FROM DBA_SYS_PRIV FROM PRIVILEGE LIKE 'CREATE %';

20. Schema Object Privileges
Privileges on tables, views, and stored procedures within a particular schema
Typically used to control access to critical application data

21. Schema A schema is Schema database objects
a collection of database objects.
owned by a database user and has the same name as that user.
Schema database objects
are logical structures created by users to contain, or reference, their data.
include structures like tables, views, and indexes.

22. Examples of Schema database objects
Tables
Indexes
Views
Synonyms
Sequences
Database links
Packages
Procedures
Functions
Etc.

25. Audit Procedures to evaluate controls over Schema Object Privileges

26. Audit Procedures to evaluate controls over Schema Object Privileges
Lock account access for application schema owners
 Lock the account for the application schema owner. Users must not connect to the database as the application owner.
SQL Command to Evaluate Control
ALTER USER <USERNAME> ACCOUNT LOCK PASSWORD EXPIRE
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS;
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME in (list of application schema owner accounts);

27. Audit Procedures to evaluate controls over Schema Object Privileges
Review users access to various application data and determine if access is granted based on a need to know, need to use basis.

28. Parameters Updatable configuration settings for the database
Default settings populated during installation
Typically stored in files on the host server, such as Unix

29. Parameter Risks Improperly configured parameters could allow
unauthorized access to sensitive data
unauthorized control of the database
Unauthorized access to configuration parameters could allow unauthorized modification of the database.

30. Parameter Controls
Gain an Understanding of all configuration parameters for the database.
The organization should develop a baseline defining secure parameter configurations.
Default configuration parameters should be modified,
Defaults Settings could lessen database security.
Authorized Access to files or tables with configuration parameters
The organizations should define those people who need access to these files or tables to perform their job duties.

31. Audit Procedures to evaluate controls over Parameters

32. Evaluate Controls over Parameters
 SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER;
Provides the runtime values of all the parameters

33. Key Parameters to Audit
Set REMOTE_OS_AUTHENT= FALSE
to disallow a user that is authenticated to the network domain to access the database without DB credentials.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME) LIKE ‘%REMOTE_OS_AUTHENT %’;

34. Key Parameters to Audit
Set _trace_files_public= FALSE
prevents users from having the ability to read trace files which may contain sensitive information about the running Oracle instance. This is an internal Oracle parameter. (default: FALSE)
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME) LIKE ‘%TRACE_FILES_PUBLIC%’;

35. Key Parameters to Audit
Set REMOTE_OS_ROLES=FALSE
to prevent Connection spoofing. Default is FALSE.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME) LIKE ‘%REMOTE_OS_ROLES %’;

36. Key Parameters to Audit
Set REMOTE_LISTENER=’ ’
to prevent the use of a listener on a remote machine separate from the database instance.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME) LIKE ‘%REMOTE_LISTENER%’;

37. Key Parameters to Audit
AUDIT_TRAIL = OS (recommended setting)
AUDIT_TRAIL parameter ensures basic auditing is turn on.
AUDIT_TRAIL to OS reduces the likelihood of a Denial of Service attack and it is easier to secure the audit trail.
Any auditing information stored in the database is viewable and modifiable by the DBA if set to DB or DB_EXTENDED.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME) LIKE ‘%AUDIT_TRAIL%’;

38. Key Parameters to Audit
Set OS_ROLES=FALSE
OS_ROLES allows externally created groups to be used to manage database roles. This can lead to misaligned or inherited permissions.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME) LIKE ‘%OS_ROLES %’;

39. Key Parameters to Audit
REMOTE_LOGIN_PASSWORDFILE=NONE
Prevent remote privileged connections to the database.
SQL Command to Evaluate Control
SELECT * FROM V$PARAMETER WHERE UPPER(NAME)=‘REMOTE_LOGIN_PASSWORDFILE’;

40. Default User Accounts Default accounts are created during installation
These accounts own different features of the database

41. Default User Risks
Initial passwords should be changed after database installation
Default user ids and passwords are well known and could be used to allow unauthorized access to the database.

42. Default User Controls All initial passwords should be changed
Some default user accounts should be removed or locked as appropriate.

43. Audit Procedures to evaluate controls over Default Accounts

44. Default User Account Audit Procedures
SQL Command to Evaluate Control
SELECT * FROM DBA_USERS_WITH_DEFPWD; (DBA_USERS_WITH_DEFPWD not in versions prior to Oracle 11g)
Note: the script was design to run on database versions 11g and prior.
The error message above is what you should see if you are running
this command on an Oracle database that is not 11g.

45. Sample Output From Script
SQL Command to Evaluate Control
SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME in (list of default accounts);
Note: the script looks for known default accounts, to determine
if the accounts are locked.

46. Default User Account Audit Procedures
Check if Default Passwords are Changed
Compare default password per hash values in Oracle white papers to password hash from database under audit to determine if default passwords were changed.
USERNAME
PASSWORD-HASH
From Oracle Whitepapers
PASSWORD-HASH From database under audit
ACCOUNT_STATUS
WKSYS
69ED49EE D
OPEN
CTXSYS
24ABAB8B06281B4C
LOCKED
MDSYS
72979A94BAD2AF80
EXPIRED & LOCKED
WMSYS
7C9BA362F
ORDSYS
7EFA02EC7EA6B86F

47. Profiles
Oracle Profiles are used for resource and password management.
Typically, a profile is created, then assigned to a user account.
The profile contains the password settings, failed login attempt setting, password complexity etc.
All user accounts are automatically assigned a DEFAULT profile.
Specific users profiles are not explicitly assigned a user profile.

48. Profile Risk Improperly configured profiles could allow:
unauthorized access to sensitive data
unauthorized control of the database
passwords that never expire
unlimited failed login attempts to the oracle database.

49. Profile Controls
Organizations should define secure profile settings in a configuration baseline.
Recommendation:
Set three separate profiles instead of using the default profile:
- application profiles,
- system profiles, and
- user profiles
Rationale:
User, System, and Application accounts require different resource and password settings.

50. Profile Audit Procedures
SQL Command to Evaluate Control
SELECT * FROM DBA_PROFILES;
PROFILE
CONFIGURATION SETTING
RESOURCE
VALUE
CPSPID_USER
FAILED_LOGIN_ATTEMPTS
PASSWORD 3
CUSTOMER 5
DEFAULT
DEVELOPER
PASSWORD_LIFE_TIME
UNLIMIT
PASSWORD_LOCK_TIME
.0208

51. Key Profile Settings to Audit
Check the values of the following resources listed in the RESOURCE_NAME column, and compare to organization or statewide security standards:
failed_login_attempts must be set to 3 (default 10 counts)
password_life_time must be set to 60 or 90 days (default 180 days)
password_lock_time must be set to 1 (default unlimited days)
password_reuse_max must be set to 20 (default unlimited counts),
limits the number of different passwords that must be rotated by the user before the current password can be reused
password_reuse_time must be set to 365 (default unlimited days)
sets the amount of time that must pass before a password can be reused;

52. Key Profile Settings to Audit
password_grace_time must be set to 3 (default unlimited days)
to specify the number of days that the user is warned to change their password before their password expires
idle_time must be set to a number (default unlimited minutes);
limits the maximum length of time (in minutes) a session can be idle connect_time must set to a number to limits the maximum length of time (in minutes) a session can be held open (default unlimited minutes);
password_verify_function
Contains the password complexity
The password verification function can be obtained from DBA_SOURCE table:
SQL Command to Evaluate Control
SELECT * FROM DBA_SOURCE WHERE TYPE='FUNCTION';

53. Roles A group of privileges that can be assigned to individual users
Oracle Databases have default roles already defined
Roles make management of individual users easier to control

54. Roles Risks Default roles can grant excessive privileges
Careless assignment of roles may grant users excessive elevated privileges
Changes in job assignments makes role maintenance difficult.

55. Roles Controls
Passwords should be assigned to roles with important privileges
Written maintenance procedures should exist
Evidence should exist to support that maintenance procedures are followed
Default roles should not be used

56. Audit Procedures to evaluate controls over Roles

57. Audit Procedures to evaluate controls over Roles
Review the following powerful role privileges:
DBA
DELETE_CATALOG_ROLE
EXECUTE_CATALOG_ROLE
EXP_FULL_DATABASE
IMP_FULL_DATABASE
RECOVERY_CATALOG_OWNER
SELECT_CATALOG_ROLE
SQL Command to Evaluate Control
SELECT * FROM DBA_ROLES ORDER BY ROLE;

58. Audit Procedures to evaluate controls over Roles
Determines if the persons in roles are appropriate.
SQL Command to Evaluate Control
Select * from DBA_USERs;
Select * from DBA_ROLE_PRIVS;
Select * from DBA_ROLES;
Select * from DBA_ROLE_PRIVS WHERE GRANTED_ROLE='DBA';

59. Link$
Connections that allow one database to interact with another

60. Link$ Risks Unknown users in the remote database
Causes Clear text password to be stored in the data dictionary
Multiple databases are at risk for unauthorized access
Public links are not uncommon

61. Links Controls Public links should not be used
Access should not be granted to the data dictionary table
may have passwords stored in clear text
User permissions and/or executable procedures should restrict a users ability to use links
Links should not exist from test or development databases into production databases

62. Audit Procedures to evaluate controls over LINK$

63. Audit Procedures to evaluate controls over LiNK$
Restrict Access to LINK$
Revoke access to the LINK$ table from all users and roles except for SYS and DBA accounts.
SQL Command to Evaluate Control
SELECT GRANTEE, PRIVILEGE FROM DBA_TAB_PRIVS WHERE TABLE_NAME in 'LINK$‘
SELECT * from DBA_TAB_PRIVS WHERE TABLE_NAME in 'LINK$',

64. Audit Trail
Built-in facility to monitor activity that occurs within the database
Logs are created of the activity that is audited
Logs are kept either on the operating system or in the database.
However, it is preferred to keep logs on the operating systems to avoid unauthorized modification from database administrators.

65. Audit Trail Risks Without an Audit Trail
No accountability is assigned to actions occurring within or to the database
Data could be stolen without the knowledge of the database owners
The database can be damaged or misconfigured without the knowledge of the database owners

66. Audit Trail Controls
Policies and procedures should exist defining the auditing that should be performed
Auditing should be enabled
Audit logs should be monitored
Audit logs should be secured within the operating system

67. Audit Procedures to evaluate controls over Audit Trail

68. Audit Procedures to evaluate controls over Audit Trail
Restrict Access to AUD$ and USER_HISTORY$',
Revoke access to the 'AUD$' table from all users and roles except for SYS and DBA accounts.
Allowing users to alter the AUD$ or USER_HISTORY$ table can compromise the audit trail or integrity of the Oracle database
Note: This is only applicable if the audit trail parameter is set to db or db_extended;
SQL Command to Evaluate Control
SELECT GRANTEE, PRIVILEGE FROM DBA_TAB_PRIVS WHERE TABLE_NAME in AUD$
SELECT GRANTEE, PRIVILEGE FROM DBA_TAB_PRIVS WHERE TABLE_NAME in USER_HISTORY$
SELECT * from DBA_TAB_PRIVS WHERE TABLE_NAME in AUD$
SELECT * from DBA_TAB_PRIVS WHERE TABLE_NAME in USER_HISTORY$

69. Discussion of Handouts
Oracle Scripts
Sample Work papers
Questions??
Sources:
Oracle Whitepapers
Oracle Website