Database Security Levels

A VIEW database object is a stored query that returns columns and rows from selected tables. Data provided by the view object is protected by database system functionality that allows schema owners to grant or revoke privileges. Data files in which data resides are protected by the database and that protection is enforced by OS file permissions. Finally, the database is secured by DBMS through accounts and password mechanism, privileges, permissions to a few.

Menaces to Databases

• Security Vulnerability
• security violation that can happen any time because of security vulnerability.
• A known security gap that the company intentionally leaves open.

Vulnerabilities

• Susceptible to attack
• Intruders, attackers exploit our environment to start their attacks.
• Hackers usually explore the weak points of a system until they gain entry through the gap in protection.
• Installation and configuration (results from default installation/configuration which is known publicly and we don’t enforce any security measures)
• User mistakes due to carelessness in implementing procedures.
• The software found in commercial patches is not applied.
• Design and implementation due to improper software analysis, design as well as coding deficiencies.
• Types of ThreatsPeople people intentionally inflict damage, e.g. hackers, terrorists.
• Malicious code software  that is intentionally written to damage the components, e.g. viruses

Natural disasters 

Technological disasters are malfunctioning equipment for example network failure, hardware failure.

1. Virus
2. Worm
3. Back Door
4. Trojan Horse
5. Rootkits

Types of Risks

• loss of people who are vital components of DB for example due to resignation.
• Hardware results are unavailability, down due to failure, malfunction.
• Data (data loss, corruption)
• Confidence.
• Security Methods
• People

Security policies & procedures

Process of identification and authentication and Training courses on the importance of security.

Physical limits on access to hardware and documents.

Applications

• Authentication of users who access
• Business rules
• Single sign-on 

Network

• Firewalls
• VPN
• Authentication

OS

• Authentication
• Intrusion Detection
• Password Policy
• User Accounts

Data Files

• File Permissions
• Access Monitoring

Data

• Validation
• Data access
• Encryption
• Data constraints

Database Security Methodology

• Identification investigation of resources reqd., policies to be adopted.
• Assessment analysis of vulnerabilities, threats, and risks.
• Design blueprint of the adopted security model.
• Implementation code developed, tools purchased.
• Evaluation testing system against attacks, failures, disasters.
• Auditing 

What is Auditing of Database Security

Auditing is the monitoring and recording of selected user database actions, from both database users and nondatabase users. You can base auditing on individual actions, such as the type of SQL statement executed, or on combinations of data that can include the user name, application, time, and so on. You can audit both successful and failed activities. To use auditing, you enable it, and then configure what must be audited. The actions that you audit are recorded in either data dictionary tables or in operating system files. Monitoring and sending reports to users.

Activities That Are Always Audited for All Platforms

Database startup. An audit record is generated that lists the operating system user starting the instance, the user terminal identifier, and the date and time stamp. This data is stored in the operating system audit trail because the database audit trail is not available until after the startup has successfully completed.

SYSDBA and SYSOPER logins. Oracle Database records all SYSDBA and SYSOPER connections. 

Database shutdown. An audit record is generated that lists the operating system user shutting down the instance, the user terminal identifier, and the date and time stamp.

Standard Auditing

• In standard auditing, you audit SQL statements, privileges, schema objects, and network activity. 
• You accomplish this by using the AUDIT SQL statement to enable the auditing, and NOAUDIT to disable it. 
• You can write the audit records to either the database audit trail or to operating system audit files.
• Any user can configure auditing for the objects in his or her own schema, by using the AUDIT statement. 
• To undo the audit configuration for this object, the user can use the NOAUDIT statement. No additional privileges are needed to perform this task. 
• Users can run AUDIT statements to set auditing options regardless of the AUDIT_TRAIL parameter setting. 
• If auditing has been disabled, the next time it is enabled, Oracle Database will record the auditing activities set by the AUDIT statements. 
• You, as the security administrator, enable or disable standard auditing for the entire database. If it is disabled, then no audit records are created. 
• When auditing is enabled in the database and an action configured to be audited occurs, Oracle Database generates an audit record during or after the execution phase of the SQL statement. Oracle Database individually audits SQL statements inside PL/SQL program units, as necessary, when the program unit is run. 
• The generation and insertion of an audit trail record are independent of a user transaction being committed. That is, even if a user transaction is rolled back, the audit trail record remains committed. 
• Statement and privilege audit options in effect at the time a database user connects to the database remain in effect for the duration of the session. When the session is already active, setting or changing statement or privilege audit options does not take effect in that session. The modified statement or privilege audit options take effect only when the current session ends and a new session is created. 
• Enables you to audit SQL statements by type of statement, not by the specific schema objects on which they operate. 
• Typically broad, statement auditing audits the use of several types of related actions for each option. For example, AUDIT TABLE tracks several DDL statements regardless of the table on which they are issued.
• You can also set statement auditing to audit selected users or every user in the database.

Application Security Models

We examine five different application security models that are commonly used by the industry to provide data security and access protection at the table level.

• Database role-based.
  
  
  
• Application role-based.
• Application function-based.
• Application role and function-based.
• Application table-based.

Security Model Based on Database Roles

This model depends on the application to authentication the application users by maintaining all end-users in a table with their encryption password. In this model, each end user is assigned a database role, which has a specific database privilege for accessing the application table. The user can access whatever privileges are assigned to the role

In this model, the proxy user is needed to activate assigned roles. All roles are assigned to the proxy user. The architectural view of the model has common control columns prefixed with CTL. 

These control columns contain information about manipulating records.

APPLICATION_USERS: 

This is used to store and maintain all end users of the application with their encrypted passwords.

APLLICATION_USERS_ROLES:

Contains all roles defined by the application and for each role, that privilege is assigned; privilege can be read, write, read/write.

• CTL_INS_DTTM contains the date and time when the record was created.
• CTL_UPD_DTTM contains the date and time when the record was last updated.
• CTL_UPD_USER contains the date name that created the record or last updated the record.
• CTL_REC_STAT can be used to indicate the status of the record. We can use this column for any purpose, we may set this column to “A” as an indicator that the record active and I as inactive

Data Encryption

1. Passwords should be kept confidential and preferably encrypted
2. Passwords should be compared encrypted:
3. Never decrypt the data
4. Hash the passwords and compare the hashes