Database auditing is the activity of monitoring and recording configured database actions from database users and non database users, to ensure the security of the databases.
An administrator can perform auditing on individual actions, such as the type of Structured Query Language (SQL) statement executed, or on combinations of data that can include the user name, application or time stamp, for example. Auditors need to audit for both successful and failed activities, and include or exclude specific users from the audit:
Good security requires physical access control, reliable personnel, trustworthy installation and configuration procedures, secure communications, and control of database operations such as selecting, viewing, updating, or deleting database records. Since some of these requirements involve applications or stored procedures as well as human action, security procedures must also account for how these programs are developed and dealt with.
Types of risk:
Mistake :
Failure to maintain or operate the database as required leads to accidental disclosure of information, and unauthorized changes lead to unauthorized and accidental disclosures, inserts, updates or deletions.
Misuse :
Failure to maintain access rights to the database leads to abuse of privileged access and leakage of information.
Malicious action:
Failure to maintain a secure, logical setup of the database leads to data theft or a denial-of-service (DoS) attack.
Com
Types of Common Vulnerabilities :
Phishing:
is an e-mail fraud method in which the perpetrator sends out legitimate-looking emails in an attempt to gather personal and financial information from recipients. Typically, the messages appear to come from well-known and trustworthy web sites. Web sites that are frequently spoofed by phishers include PayPal, eBay, MSN, Yahoo and Best Buy, for example.
SQL injection:
is a technique used to take advantage of nonvalidated input vulnerabilities to pass SQL commands through a web application for execution by a back-end database. Attackers take advantage of the fact that programmers often chain together SQL commands with user-provided parameters and, therefore, can embed SQL commands inside these parameters. The result is that the attacker can execute arbitrary SQL queries and/or commands on the back-end database server through the web application.
Data exfiltration :
is the unauthorized copying, transfer or retrieval of data from a computer or server. Data exfiltration is a malicious activity performed through various techniques, typically by cybercriminals over the Internet or other network. Data exfiltration is also known as data extrusion, data exportation or data theft.
Staging server :
is a server that enables assembling, deploying and testing a software or web site on a server instance, similar to the production server. Typically, software or a web site is deployed on the staging server from the development server when development is complete. A staging server helps to identify the software or web site behavior, experience and performance as it will be visible on the production server. This helps software developers or quality assurance (QA) staff identify and resolve any problems, bugs, performance or usability issues, or other issues before the software or web site is deployed on the production server. The staging server can be a staging database server, staging web site server or staging application server, for example. Analyzing data
Analyzing database configuration is critical to determine vulnerabilities and assure the standard auditing. Database auditing includes:
. Finding sensitive data and privileges
. Preventing data access
. Validating that detection and alert mechanisms are in place
Data redaction:
provides selective, on-the-fly redaction of sensitive data in SQL query results, prior to application display, so that unauthorized users cannot view the sensitive data. It enables consistent redaction of database columns across application modules accessing the same database information. Data redaction minimizes changes to applications because it does not alter actual data in internal database buffers, caches or storage, and it preserves the original data type and formatting when transformed data are returned to the application. Data redaction has no impact on database operational activities, such as backup and restore, upgrade, and patch, and on high-availability clusters.
Data masking:
obfuscates sensitive data by replacing them with other data—typically characters that will meet the requirements of a system designed to test or still work with the masked results. Masking ensures that vital parts of personally identifiable information (PII), such as the first five digits of a social security number, are obscured or otherwise deidentified.
Data encryption:
involves converting and transforming data into scrambled, often unreadable, ciphertext using nonreadable mathematical calculations and algorithms. Restoring the message requires a corresponding decryption algorithm and the original encryption key.t
1. Secure Installation and Configuration Checklist
Default privileged Oracle accounts continue to be the highest risk issue commonly encountered. It is an easy issue to fix and prevent. After installation, Oracle has a number of default accounts, each with a default preset value. Following database install, the Oracle database configuration assistant (DBCA) automatically locks and expires the majority of the default database user accounts. Additionally, DBCA changes the SYSTEM account to the value specified during the installation routine.
If an Oracle database is manually installed, the DBCA never executes, and those dangerous default privileged accounts are never locked and expired. By default, their password is the same as their username. These will be the first credentials that a hacker will attempt to use to connect to the database. As a best practice, each of these accounts should be configured with a strong unique password, and if an account is not required, it should be locked and expired.
Install only what is required.
Do a custom installation. Avoid installing options and products you do not need. Choose to install only those additional products and options, in addition to the database server, that you require. Or, if you choose to do a typical installation instead, then improve your security after the installation processes finish, by removing the options and products you do not need.
Lock and expire default user accounts.
Oracle Database installs with many default (preset) database server user accounts. Upon the successful creation of a database server instance, the Database Configuration Assistant automatically locks and expires most default database user accounts.
UserList : ('ANONYMOUS' ,'APEX_040200' ,'APEX_PUBLIC_USER' ,'APPQOSSYS' ,'AUDSYS' ,'BI' ,'CTXSYS' ,'DBSNMP' ,'DIP' ,'DVF' ,'DVSYS' ,'EXFSYS' ,'FLOWS_FILES' ,'GSMADMIN_INTERNAL' ,'GSMCATUSER' ,'GSMUSER' ,'HR' ,'IX' ,'LBACSYS' ,'MDDATA' ,'MDSYS' ,'OE' ,'ORACLE_OCM' ,'ORDDATA' ,'ORDPLUGINS' ,'ORDSYS' ,'OUTLN' ,'PM' ,'SCOTT' ,'SH' ,'SI_INFORMTN_SCHEMA' ,'SPATIAL_CSW_ADMIN_USR' ,'SPATIAL_WFS_ADMIN_USR' ,'SYS' ,'SYSBACKUP' ,'SYSDG' ,'SYSKM' ,'SYSTEM' ,'WMSYS' ,'XDB' ,'SYSMAN' ,'RMAN' ,'RMAN_BACKUP' ,'OWBSYS' ,'OWBSYS_AUDIT' ,'APEX_030200' ,'MGMT_VIEW' ,'OJVMSYS')
So, how to find Oracle built-in accounts with "default passwords" ?
SQL> select * FROM DBA_USERS_WITH_DEFPWD ;
SQL> select username,last_login,oracle_maintained from dba_users where oracle_maintained='Y';
SQL> select name, astatus from sys.user$ where name='ORDDATA';
List of Default password : http://www.petefinnigan.com/default/oracle_default_passwords.htm
2.Restrict operating system access.
Limit the number of operating system users.
Limit the privileges of the operating system accounts (administrative, root-privileged, or DBA) on the Oracle Database host (computer) to the fewest and least powerful privileges required for each user.
Disallow modifying the default permissions for the Oracle Database home (installation) directory or its contents, even by privileged operating system users or the Oracle owner.
Restrict symbolic links. Ensure that when any path or file to the database is provided, neither that file nor any part of that path is modifiable by an untrusted user. The file and all components of the path should be owned by the DBA or some trusted account, such as root. This recommendation applies to all types of files, such as data files, log files, trace files, external tables, bfiles, and so on.
4. Restrict network access.
https://docs.oracle.com/cd/B19306_01/network.102/b14266/checklis.htm#i1011179
5. Apply all security patches and workarounds.
Plug every security hole or flaw as soon as corrective action is identified. Always apply all relevant and current security patches for both the host operating system and Oracle Database, and for all installed Oracle Database options and components.
https://www.oracle.com/security-alerts/
6. Audit PUBLIC Role for Identification of Unnecessary Privileges
In Oracle, extended routines exist that allow minimally privileged users to execute functions that they otherwise would not be able to execute. These extended routines are called packages, and are roughly equivalent to Extended Stored Procedures in Microsoft SQL Server. A special role, called PUBLIC, acts as a default role assigned to every user in the Oracle database. Any database user can execute privileges that are granted to PUBLIC. This is commonly exploited for database privilege escalation.
These packages and subtypes should be revoked from PUBLIC and made executable for an application only when absolutely necessary.
7. Database Auditing
Audit SYS operations:
By default, Oracle databases do not audit SQL commands executed by the privileged SYS and users connecting with SYSDBA or SYSOPER privileges. If a database is hacked, these privileges are going to be the hacker’s first target. Fortunately, auditing SQL commands of these privileged users is very simple: sqlplus> alter system set audit_sys_operations=true scope=spfile.
Enable database auditing:
Again, by default, Oracle auditing of SQL commands is not enabled. Auditing should be turned on for all SQL commands. Database auditing is turned on with the audit_trail parameter: sqlplus> alter system set audit_trail=DB, EXTENDED scope=spfile. (Note: The command enables auditing from the database, but not the database vault information, into the table SYS. AUD$.) There are actually four database auditing types: OS, DB, EXTENDED and XML.
Enable auditing IMP OBJ:
Once auditing has been enabled, it can be turned on for objects where an audit trail is important.
8. Logon/Logoff Trigger
9. Password and Profile
Oracle provides fairly robust password management for Oracle logins. Unfortunately, none of these are applied in the default Oracle account profile.
In Oracle, logins are assigned an account policy through an Oracle profile. Every login can be applied to only one Oracle profile. If no Oracle profile is specified when the login is created, it is assigned the default Oracle profile.
Password complexity verification—Without a password complexity verification function, users most likely choose simple dictionary words that are easy to remember and easy for a hacker to guess. In Oracle, a user Procedural Language (PL)/SQL script must be set to check the complexity of a user’s password. In general, the password verification function should ensure that users’ passwords incorporate.
Resource Parameter
SESSIONS_PER_USER : Specify the number of concurrent sessions to which you want to limit the user.
CPU_PER_SESSION : Specify the CPU time limit for a session, expressed in hundredth of seconds.
CPU_PER_CALL : Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds.
CONNECT_TIME : Specify the total elapsed time limit for a session, expressed in minutes.
IDLE_TIME : Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit.
LOGICAL_READS_PER_SESSION : Specify the permitted number of data blocks read in a session, including blocks read from memory and disk.
LOGICAL_READS_PER_CALL : Specify the permitted the number of data blocks read for a call to process a SQL statement (a parse, execute, or fetch).
PRIVATE_SGA : Specify the amount of private space a session can allocate in the shared pool of the system global area (SGA), expressed in bytes.
COMPOSITE_LIMIT : Specify the total resource cost for a session, expressed in service units. Oracle Database calculates the total service units as a weighted sum of CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.
PAssword Parameter
FAILED_LOGIN_ATTEMPTS : Maximum times the user is allowed in fail login before locking the user account
PASSWORD_LIFE_TIME : Number of days the password is valid before expiry
PASSWORD_REUSE_TIME : Number of day after the user can use the already used password
PASSWORD_REUSE_MAX : Number of times the user can use the already used password
PASSWORD_LOCK_TIME : Number of days the user account remains locked after failed login
PASSWORD_GRACE_TIME : Number of grace days for user to change password
PASSWORD_VERIFY_FUNCTION : PL/SQL that can be used for password verification
SEC_CASE_SENSITIVE_LOGON : To control the case sensitivity in passwords
Password verification function : Oracle Database 12.1.0.1 $ORACLE_HOME/rdbms/admin/utlpwdmg.sql taken from Oracle 12.1.0.1 on Linux x86-64bit
10. Database Traffic Is Encrypted
This recommendation is rarely implemented, except in the most secure organizations. Oracle supports network-level encryption by both Secure Sockets Layer (SSL), using X.509v3 signed certificates, and native encryption without certificates.
The takeaway with network-level encryption is not only that sensitive data in transit are protected when encryption is employed, but also that the SID is protected. Without encryption, the SID can be easily enumerated through man-in-the-middle attacks.
11. Privilages
Practice the principle of least privilege. Oracle recommends granting necessary privileges only. Do not provide database users or roles more privileges than necessary. (If possible, grant privileges to roles, not users.) In other words, the principle of least privilege is that users be given only those privileges that are actually required to efficiently perform their jobs.
