Database Security and Auditing: Protecting Data Integrity and Accessibility

Chapter 6 Virtual Private Databases

Objectives

• Define the term “virtual private database” and explain its importance • Implement a virtual private database by using the VIEW database object • Implement a virtual private database by using Oracle’s application context • Implement the Oracle virtual private database feature

Database Security and Auditing 2 Objectives (continued)

• Use a data dictionary to view an Oracle virtual private database • Use Policy Manager to view an Oracle virtual private database • Implement row-level and column-level security

Database Security and Auditing 3

Overview of Virtual Private Databases

• A VPD deals with data access • VPD controls data access at the row or column level • SQL Server 2000: use VIEW data object • Oracle10g: – Specific functions – Row-level security, fine-grained access (FGA)

Database Security and Auditing 4 Overview of Virtual Private Databases (continued)

Database Security and Auditing 5

Overview of Virtual Private Databases (continued)

• Shared database schema: – Containing data that belongs to different users – User view or update only data he or she owns • Purposes/benefits: – Security requirements necessitate data access be restricted at row or column level (FGA) – One database schema serves multiple unrelated groups or entities

Database Security and Auditing 6 Implementing a VPD Using Views

• View object limits what users can see and do with existing data: hides columns or rows from users • CREATE VIEW statement: creates data views • Views can become hard to administer; solution is VPD • Implementation is limited and requires careful design and development

Database Security and Auditing 7

Implementing a VPD Using Views (continued)

• Example implementation steps: – Logon as DBSEC schema – Display the EMPLOYEES table – Create the table EMPLOYESS_VER1 – Create a VIEW object to display rows that belong only to the logged on user – Grant SELECT and INSERT on this view to another user – Insert a row using EMPLOYEES_VIEW1

Database Security and Auditing 8 Implementing a VPD Using Views (continued)

• Example implementation steps (continued) – Logon as the other user – Select the EMPLOYEES_VIEW1 VIEW object; you see only rows that belongs to the other user

Database Security and Auditing 9

Hiding Rows Based on the Current User

• System function USER: – Returns database user – Used to implement row-based security • Implementing row-based security with views: – Need a column in your tables for the row’s owner – Preface it with “CTL”

Database Security and Auditing 10 Hiding Rows Based on the Current User (continued)

Database Security and Auditing 11

Hiding Rows Based on the Current User (continued)

• Steps: – Alter table to contain column CTL_UPD_USER – Create database users in the database – Create the view users will use to access table – Test the code: • Login as one user and do some actions • Then login as a different user

Database Security and Auditing 12 Hiding Rows Based on the Current User (continued)

Database Security and Auditing 13

Hiding Rows Based on the Current User (continued)

Database Security and Auditing 14 Implementing a VPD Using Application Context in Oracle

• Triggers • Application context: – Functionality specific to Oracle – Allows to set database application variables that can be retrieved by database sessions – Variables can be used for security context-based or user-defined environmental attributes • Dynamic performance view V$SESSION • Application context function SYS_CONTEXT

Database Security and Auditing 15

Implementing a VPD Using Application Context in Oracle (continued)

Database Security and Auditing 16 Implementing a VPD Using Application Context in Oracle (continued)

• Set your own application context: use Oracle PL/SQL package DBMS_SESSION (SET_CONTEXT procedure) • Example steps: – Using DBSEC that has privileges to create tables and other database objects: • Application context table APP_CONTEXT_USERS • ORDERS table

Database Security and Auditing 17

Implementing a VPD Using Application Context in Oracle (continued)

• Example steps (continued): – As DBSEC insert rows into: • ORDERS table • APP_CONTEXT_USERS table – As DBSEC create a VIEW object to display rows based on application context SECURITY_LEVEL – As DBSEC create context for ORDERS_APP – Create a package; can be owned by SYS, SYSTEM or DBSEC

Database Security and Auditing 18 Implementing a VPD Using Application Context in Oracle (continued)

• Example steps (continued): – Grant the user CREATE ANY CONTEXT privilege and the execute privilege to DBSEC – Create a logon database trigger – Connect as HR and select from the view • Complex implementation: use VPD instead

Database Security and Auditing 19

Implementing Oracle Virtual Private Databases

• VPDs are a more direct solution • User functions: – DBSEC users: application schema owner – CUSTOMERS: used to demonstrate VPDs – VPD_CLERK1, VPD_CLERK2, and VPD_CLERK3 users: database users that are used to test VPDs

Database Security and Auditing 20 Implementing Oracle Virtual Private Databases (continued)

Database Security and Auditing 21

Implementing Oracle Virtual Private Databases (continued)

• Create table for customer users: – Create the CUSTOMERS table – Insert rows into the CUSTOMERS table – Create three users for testing, VPD_CLERK1, VPD_CLERK2, and VPD_CLERK3 – Grant the necessary privileges on the CUSTOMERS table to use each test • ROW_OWNER security: row-level security based on user that owns row

Database Security and Auditing 22 Implementing Oracle Virtual Private Databases (continued)

• Steps: – Create a policy function to add a predicate to the WHERE clause – Using DBMS_RLS add the VPD policy: Oracle- supplied package – Log in as VPD_CLERK1; display number of records that this user can see – Disable this policy

Database Security and Auditing 23

Implementing Oracle Virtual Private Databases (continued)

Database Security and Auditing 24 Implementing Oracle Virtual Private Databases (continued)

• APPLICATION-CONTEXT security: allows specific users to see only rows for a specific sales representative • Steps: – Create the DBSEC_CUSTOMERS_APP_CONTEXT table – Insert rows into this table – Create a trusted package that allows DBSEC to execute DBMS_SESSION

Database Security and Auditing 25

Implementing Oracle Virtual Private Databases (continued)

• Steps (continued): – Create an application context for this policy – Create a new VPD function policy to add a WHERE clause predicate – Add a VPD policy for the CUSTOMERS table – Create an after-logon trigger – Now log on as VPD_CLERK2

Database Security and Auditing 26 Implementing Oracle Virtual Private Databases (continued)

• ROLE SECURITY LEVEL: – Detects the role of the user – A predicate is used to filter the rows that can be seen by each user • Steps: – Disable any policies on the CUSTOMERS table – Disable the AFTER LOGON database trigger – Create three new roles

Database Security and Auditing 27

Implementing Oracle Virtual Private Databases (continued)

Database Security and Auditing 28 Implementing Oracle Virtual Private Databases (continued)

• Steps (continued): – Create application context for the security level – Create application context package to set the application context – Create a policy function to implement row-level security (VPD) – Create a policy to enforce a WHERE clause predicate

Database Security and Auditing 29

Implementing Oracle Virtual Private Databases (continued)

• Steps (continued): – Application logs on as VPD_CLERK3; run PKG_DBSEC_ROLE_SECURITY_LEVEL package – Repeat last step, this time use VPD_CLERK1 • VPD policies can be grouped for organizational purposes • Oracle enforces row-level security using all the DML statements

Database Security and Auditing 30 Viewing VPD Policies and Applications Context Using the Data Dictionary

Database Security and Auditing 31

Viewing VPD Policies and Applications Context Using Policy Manager

• Graphical tool called Policy Manage • Use SYSTEM credentials to log in • FGA control policies are divided into two parts: – Policy groups – Application context

Database Security and Auditing 32 Viewing VPD Policies and Applications Context Using Policy Manager (continued)

Database Security and Auditing 33 Viewing VPD Policies and Applications Context Using Policy Manager (continued)

Database Security and Auditing 34 Viewing VPD Policies and Applications Context Using Policy Manager (continued)

Database Security and Auditing 35

Implementing Row- and Column-level Security with SQL Server

• SQL Server 2000 does not support VPDs; you can mimic their functionality • Use views and expand security models

Database Security and Auditing 36 Row-based Security Using Access Levels

• Variation of both: – Application table-based security model – Application function-based security model • Access levels: – 0 = No access – 1 = select – 2 = select, insert – 3 = select, insert, update

Database Security and Auditing 37

Row-based Security Using Access Levels (continued)

• Access levels (continued): – 4 = select, insert, update, delete – 5 = administrator access • Steps: – Create the APPLICATION USERS table – Alter the CUSTOMER table to include the ACCESS CONTROL column – With the security structure in place use a view to retrieve data

Database Security and Auditing 38 Row-based Security Using Application Functions

• Steps (continued): apply privileges • Drawbacks: it allows insertion, update, and deletion of records • Alternatives: – Use stored procedures – Use application functions: access table list a function instead of a level

Database Security and Auditing 39

Column-based Security

• VPD and Column Access Using Oracle steps: – Log in as VPD_CLERK2 and view rows and columns in the CUSTOMERS table – Log in as the DBSEC user and recreate the policy on customers – Log in as VPD_CLERK2 and query the CUSTOMERS table

Database Security and Auditing 40 Column-based Security

• Column privileges in Oracle steps: – Log in as DBSEC and create a table called TEST – Grant SELECT on the TEST table to SCOTT – Grant UPDATE only on the column TEXT in the TEST table to SCOTT – Insert a row into the TEST table and save it – Log in as SCOTT and query the TEST table owned by DBSEC

Database Security and Auditing 41

Column-based Security (continued)

• Column privileges in Oracle steps (continued): – Update the TEXT column in the TEST table – Try to update the NUM column in the TEST table

Database Security and Auditing 42 Column-based Security (continued)

• Access-level control with SQL Server steps: – Create the APP_TABLES table – Create the APP_COLUMNS columns – All access to the tables must be performed with stored procedures

Database Security and Auditing 43

Column-based Security (continued)

• Column Privileges with SQL Server steps: set update permissions for sam on the column phone in the Customer table • Customized column-access control facilitates management

Database Security and Auditing 44 Summary

• A virtual private database allows or prevents data access at the row or column level; implemented using VIEW database object • VPDs are also referred to as row-level security (RLS) or fine-grained access (FGA) • SQL Server does not support VPDs • Microsoft SQL Server 2000 system function of USER

Database Security and Auditing 45

Summary (continued)

• Oracle Application context: – Allows setting of database application be retrieved by database sessions – SYS_CONTEXT function – PL/SQL package DBMS_SESSION – SET_CONTEXT procedure • Use Oracle-supplied package DBMS_RLS to add the VPD policy • Oracle data dictionary views Database Security and Auditing 46 Summary (continued)

• Oracle Policy Manager: graphical tool used to administer VPD policies • Oracle has the capability to restrict updates or inserts on columns, using GRANT UPDATE(column) and INSERT(column)

Database Security and Auditing 47

Database Security and Auditing: Protecting Data Integrity and Accessibility

Chapter 7 Database Auditing Models Objectives

• Gain an overview of auditing fundamentals • Understand the database auditing environment • Create a flowchart of the auditing process • List the basic objectives of an audit

Database Security and Auditing 2

Objectives (continued)

• Define the differences between auditing classifications and types • List the benefits and side effects of an audit • Create your own auditing models

Database Security and Auditing 3 Auditing Overview

• Audit examines: documentation that reflects (from business or individuals); actions, practices, conduct • Audit measures: compliance to policies, procedures, processes and laws

Database Security and Auditing 4

Definitions

• Audit/auditing: process of examining and validating documents, data, processes, procedures, systems • Audit log: document that contains all activities that are being audited ordered in a chronological manner • Audit objectives: set of business rules, system controls, government regulations, or security policies

Database Security and Auditing 5 Definitions (continued)

• Auditor: person authorized to audit • Audit procedure: set of instructions for the auditing process • Audit report: document that contains the audit findings • Audit trail: chronological record of document changes, data changes, system activities, or operational events

Database Security and Auditing 6

Definitions (continued)

• Data audit: chronological record of data changes stored in log file or database table object • Database auditing: chronological record of database activities • Internal auditing: examination of activities conducted by staff members of the audited organization • External auditing

Database Security and Auditing 7 Auditing Activities

• Evaluate the effectiveness and adequacy of the audited entity • Ascertain and review the reliability and integrity of the audited entity • Ensure the organization complies with policies, procedures, regulations, laws, and standards of the government and the industry • Establish plans, policies, and procedures for conducting audits

Database Security and Auditing 8

Auditing Activities (continued)

• Keep abreast of all changes to audited entity • Keep abreast of updates and new audit regulations • Provide all audit details to all company employees involved in the audit • Publish audit guidelines and procedures • Act as liaison between the company and the external audit team

Database Security and Auditing 9 Auditing Activities (continued)

• Act as a consultant to architects, developers, and business analysts • Organize and conduct internal audits • Ensure all contractual items are met by the organization being audited • Identify the audit types that will be used

Database Security and Auditing 10

Auditing Activities (continued)

• Identify security issues that must be addressed • Provide consultation to the Legal Department

Database Security and Auditing 11 Auditing Environment

• Auditing examples: – Financial auditing – Security auditing • Audit also measures compliance with government regulations and laws • Audits take place in an environment: – Auditing environment – Database auditing environment

Database Security and Auditing 12

Auditing Environment (continued)

• Components: – Objectives: an audit without a set of objectives is useless – Procedures: step-by-step instructions and tasks – People: auditor, employees, managers – Audited entities: people, documents, processes, systems

Database Security and Auditing 13 Auditing Environment (continued)

Database Security and Auditing 14

Auditing Environment (continued)

Database Security and Auditing 15 Auditing Environment (continued)

• Database auditing environment differs slightly from generic auditing environment • Security measures are inseparable from auditing

Database Security and Auditing 16

Auditing Process

• Quality Assurance (QA): – Ensure system is bug free and functioning according to its specifications – Ensure product is not defective as it is being produced • Auditing process: ensures that the system is working and complies with the policies, regulations and laws

Database Security and Auditing 17 Auditing Process (continued)

• Performance monitoring: observes if there is degradation in performance at various operation times • Auditing process flow: – System development life cycle – Auditing process: • Understand the objectives • Review, verify, and validate the system • Document the results

Database Security and Auditing 18

Auditing Process (continued)

Database Security and Auditing 19 Auditing Process (continued)

Database Security and Auditing 20

Auditing Objectives

• Part of the development process of the entity to be audited • Reasons: – Complying – Informing – Planning – Executing

Database Security and Auditing 21 Auditing Objectives (continued)

• Top ten database auditing objectives: – Data integrity – Application users and roles – Data confidentiality – Access control – Data changes

Database Security and Auditing 22

Auditing Objectives (continued)

• Top ten database auditing objectives (continued): – Data structure changes – Database or application availability – Change control – Physical access – Auditing reports

Database Security and Auditing 23 Auditing Classifications and Types

• Industry and business sectors use different classifications of audits • Each classification can differ from business to business • Audit classifications: also referred as types • Audit types: also referred as purposes

Database Security and Auditing 24

Audit Classifications

• Internal audit: – Conducted by a staff member of the company being audited – Purpose: • Verify that all auditing objectives are met • Investigate a situation prompted by an internal event or incident • Investigate a situation prompted by an external request

Database Security and Auditing 25 Audit Classifications (continued)

• External audit: – Conducted by a party outside the company that is being audited – Purpose: • Investigate the financial or operational state of the company • Verify that all auditing objectives are met

Database Security and Auditing 26

Audit Classifications (continued)

• Automatic audit: – Prompted and performed automatically (without human intervention) – Used mainly for systems and database systems – Administrators read and interpret reports; inference engine or artificial intelligence • Manual audit: performed completely by humans • Hybrid audit

Database Security and Auditing 27 Audit Types

• Financial audit: ensures that all financial transactions are accounted for and comply with the law • Security audit: evaluates if the system is as secure • Compliance audit: system complies with industry standards, government regulations, or partner and client policies

Database Security and Auditing 28

Audit Types (continued)

• Operational audit: verifies if an operation is working according to the policies of the company • Investigative audit: performed in response to an event, request, threat, or incident to verify integrity of the system • Product audit: performed to ensure that the product complies with industry standards

Database Security and Auditing 29 Benefits and Side Effects of Auditing

• Benefits: – Enforces company policies and government regulations and laws – Lowers the incidence of security violations – Identifies security gaps and vulnerabilities – Provides an audit trail of activities – Provides means to observe and evaluate operations of the audited entity

Database Security and Auditing 30

Benefits and Side Effects of Auditing (continued)

• Benefits (continued): – Provides a sense of security and confidence – Identifies or removes doubts – Makes the organization more accountable – Develops controls that can be used for purposes other than auditing

Database Security and Auditing 31 Benefits and Side Effects of Auditing (continued)

• Side effects: – Performance problems – Too many reports and documents – Disruption to the operations of the audited entity – Consumption of resources, and added costs from downtime – Friction between operators and auditor – Same from a database perspective

Database Security and Auditing 32

Auditing Models

• Can be implemented with built-in features or your own mechanism • Information recorded: – State of the object before the action was taken – Description of the action that was performed – Name of the user who performed the action

Database Security and Auditing 33 Auditing Models (continued)

Database Security and Auditing 34

Simple Auditing Model 1

• Easy to understand and develop • Registers audited entities in the audit model repository • Chronologically tracks activities performed • Entities: user, table, or column • Activities: DML transaction or logon and off times

Database Security and Auditing 35 Simple Auditing Model 1 (continued)

Database Security and Auditing 36

Simple Auditing Model 1 (continued)

• Control columns: – Placeholder for data inserted automatically when a record is created or updated (date and time record was created and updated) – Can be distinguished with a CTL prefix

Database Security and Auditing 37 Simple Auditing Model 1 (continued)

Database Security and Auditing 38

Simple Auditing Model 2

• Only stores the column value changes • There is a purging and archiving mechanism; reduces the amount of data stored • Does not register an action that was performed on the data • Ideal for auditing a column or two of a table

Database Security and Auditing 39 Simple Auditing Model 2 (continued)

Database Security and Auditing 40

Advanced Auditing Model

• Called “advanced” because of its flexibility • Repository is more complex • Registers all entities: fine grained auditing level • Can handle users, actions, tables, columns

Database Security and Auditing 41 Advanced Auditing Model (continued)

Database Security and Auditing 42

Advanced Auditing Model (continued)

Database Security and Auditing 43 Historical Data Model

• Used when a record of the whole row is required • Typically used in most financial applications

Database Security and Auditing 44

Historical Data Model (continued)

Database Security and Auditing 45 Auditing Applications Actions Model

Database Security and Auditing 46

C2 Security

• Given to Microsoft SQL Server 2000 • Utilizes DACLs (discretionary access control lists) for security and audit activities • Requirements: – Server must be configured as a C2 system – Windows Integrated Authentication is supported – SQL native security is not supported – Only transactional replication is supported

Database Security and Auditing 47 Summary

• Audit examines, verifies and validates documents, procedures, processes • Auditing environment consists of objectives, procedures, people, and audited entities • Audit makes sure that the system is working and complies with the policies, standards, regulations, and laws • Auditing objectives established during development phase

Database Security and Auditing 48

Summary (continued)

• Objectives: compliance, informing, planning, and executing • Classifications: internal, external, automatic, manual, hybrid • Models: Simple Auditing 1, Simple Auditing 2, Advanced Auditing, Historical Data, Auditing Applications, C2 Security

Database Security and Auditing 49 Database Security and Auditing: Protecting Data Integrity and Accessibility

Chapter 8 Application Data Auditing

Objectives

• Understand the difference between the auditing architecture of DML Action Auditing Architecture and DML changes • Create and implement Oracle triggers • Create and implement SQL Server triggers • Define and implement Oracle fine-grained auditing

Database Security and Auditing 2 Objectives (continued)

• Create a DML statement audit trail for Oracle and SQL Server • Generate a data manipulation history • Implement a DML statement auditing using a repository

Database Security and Auditing 3

Objectives (continued)

• Understand the importance and the implementation of application errors auditing in Oracle • Implement Oracle PL/SQL procedure authorization

Database Security and Auditing 4 DML Action Auditing Architecture

• Data Manipulation Language (DML): companies use auditing architecture for DML changes • DML changes can be performed on two levels: – Row level – Column level • Fine-grained auditing (FGA)

Database Security and Auditing 5

DML Action Auditing Architecture (continued)

Database Security and Auditing 6 DML Action Auditing Architecture (continued)

Database Security and Auditing 7

Oracle Triggers

• Stored PL/SQL procedure executed whenever: – DML operation occurs – Specific database event occurs • Six DML events (trigger timings): INSERT, UPDATE, and DELETE • Purposes: – Audits, controlling invalid data – Implementing business rules, generating values

Database Security and Auditing 8 Oracle Triggers (continued)

Database Security and Auditing 9

Oracle Triggers (continued)

• CREATE TRIGGER • Executed in a specific order: – STATEMENT LEVEL triggers before COLUMN LEVEL triggers – BEFORE triggers before AFTER triggers • USER_TRIGGERS data dictionary view: all triggers created on a table • A table can have unlimited triggers: do not overuse them

Database Security and Auditing 10 Oracle Triggers (continued)

Database Security and Auditing 11

SQL Server Triggers

• CREATE TRIGGER DDL statement: creates a trigger • Trigger condition: – Prevents a trigger from firing – UPDATE() and COLUMNS_UPDATE() functions • Logical tables: – DELETED contains original data – INSERTED contains new data

Database Security and Auditing 12 SQL Server Triggers (continued)

• Restrictions—Transact-SQL statements not allowed: – ALTER and CREATE DATABASE – DISK INIT and DISK RESIZE – DROP DATABASE and LOAD DATABASE – LOAD LOG – RECONFIGURE – RESTORE DATABASE – RESTORE LOG

Database Security and Auditing 13

Implementation of an Historical Model with SQL Server

• Create a history table: – Same structure as original table – HISTORY_ID column • Create a trigger: inserts original row into the HISTORY table

Database Security and Auditing 14 Fine-grained Auditing (FGA) with Oracle

• Oracle provides column-level auditing: Oracle PL/SQL-supplied package DBMS_FGA • DBMS_FGA procedures: – ADD_POLICY – DISABLE_POLICY – DROP_POLICY – ENABLE_POLICY

Database Security and Auditing 15

Fine-grained Auditing (FGA) with Oracle (continued)

• ADD_POLICY parameters: – OBJECT_SCHEMA – OBJECT_NAME – POLICY_NAME – AUDIT_CONDITION – AUDIT_COLUMN – HANDLER_SCHEMA

Database Security and Auditing 16 Fine-grained Auditing (FGA) with Oracle (continued)

• ADD_POLICY parameters (continued): – HANDLER_MODULE – ENABLE – STATEMENT_TYPES • DBA_FGA_AUDIT_TRAIL: view the audit trail of the DML activities

Database Security and Auditing 17

DML Action Auditing with Oracle

• Record data changes on the table: – Name of the person making the change – Date of the change – Time of the change • Before or after value of the columns are not recorded

Database Security and Auditing 18 DML Action Auditing with Oracle (continued)

Database Security and Auditing 19

DML Action Auditing with Oracle (continued)

• Steps: – Use any user other than SYSTEM or SYS; with privileges to create tables, sequences, and triggers – Create the auditing table – Create a sequence object – Create the trigger that will record DML operations – Test your implementation

Database Security and Auditing 20 History Auditing Model Implementation Using Oracle

• Historical data auditing is simple to implement; main components are TRIGGER objects and TABLE objects • Keeps record of: – Date and time the copy of the record was captured – Type of operation applied to the record

Database Security and Auditing 21

History Auditing Model Implementation Using Oracle (continued)

• Steps: – Use any user other than SYSTEM or SYS; with privileges to create tables, sequences, and triggers – Create history table – Create the trigger to track changes and record all the values of the columns – Test your implementation

Database Security and Auditing 22 DML Auditing Using Repository with Oracle (Simple 1)

• Simple Auditing Model 1 • Flag users, tables, or columns for auditing • Requires less database administrative skills: – Application administrators can do it – User interface is built in top of the repository • Auditing flags are flexible • Does not record before or after column values; only registers type of DML operations

Database Security and Auditing 23

DML Auditing Using Repository with Oracle (Simple 1) (continued)

Database Security and Auditing 24 DML Auditing Using Repository with Oracle (Simple 1) (continued)

• Steps: – Use any user other than SYSTEM or SYS – Create triggers – Create sequence object – Build tables to use for applications – Populate application tables

Database Security and Auditing 25

DML Auditing Using Repository with Oracle (Simple 1) (continued)

• Steps (continued): – Populate auditing repository with metadata – Create the stored package to be used with the trigger – Create triggers for application tables – Test your implementation

Database Security and Auditing 26 DML Auditing Using Repository with Oracle (Simple 2)

• Simple Auditing Model 2: requires a higher level of expertise in PL/SQL • Stores two types of data: – Audit data: value before or after a DML statement – Audit table: name of the tables to be audited

Database Security and Auditing 27

DML Auditing Using Repository with Oracle (Simple 2) (continued)

Database Security and Auditing 28 DML Auditing Using Repository with Oracle (Simple 2) (continued)

• Steps: – Use any user other than SYSTEM or SYS; with privileges to create tables, and triggers – Create the auditing repository – Establish a foreign key in AUDIT_DATA table referencing AUDIT_TABLE table – Create a sequence object – Create the application schema

Database Security and Auditing 29

DML Auditing Using Repository with Oracle (Simple 2) (continued)

• Steps (continued): – Add data to tables – A stored PL/SQL package will be used for auditing within the triggers – Create triggers for audited tables – Add auditing metadata – Test your implementation

Database Security and Auditing 30 Auditing Application Errors with Oracle

• Application errors must be recorded for further analysis • Business requirements mandate to keep an audit trail of all application errors • Materials: – Repository consisting of one table – Methodology for your application

Database Security and Auditing 31

Auditing Application Errors with Oracle (continued)

• Steps: – Select any user other than SYSTEM or SYS; with privileges to create tables, and procedures – Populate tables – Create the ERROR table – Create a stored package to perform the UPDATE statement – Test your implementation: perform and update using the CREATE package

Database Security and Auditing 32 Oracle PL/SQL Procedure Authorization

• Oracle PL/SQL stored procedures are the mainstay of implementing business rules • Security modes: – Invoker rights: procedure is executed using security credentials of the caller – Definer rights: procedure is executed using security credentials of the owner

Database Security and Auditing 33

Oracle PL/SQL Procedure Authorization (continued)

• Steps: – Create a new user – Select a user with CREATE TABLE and PROCEDURE privileges – Populate tables – Create stored procedure to select rows in a table – Grant EXECUTE privileges on new procedure – Log on as the new user and query the table – Execute procedure Database Security and Auditing 34 Summary

• Two approaches for DML auditing: – Set up an audit trail for DML activities – Register all column values before or after the DML statement (column-level auditing) • Fine-grained auditing (Oracle) • Triggers: – Stored PL/SQL procedure automatically executed – Oracle has six DML events Database Security and Auditing 35

Summary (continued)

• Triggers are executed in order • USER_TRIGGERS data dictionary view: shows all triggers • SQL Server 2000: – CREATE TRIGGER DDL statement – Conditional functions: UPDATE() and COLUMNS_UPDATED() • FGA allows generation of audit trail of DML activities Database Security and Auditing 36 Summary (continued)

• FGA is capable of auditing columns or tables; Oracle PL/SQL-supplied package DBMS_FGA • PL/SQL stored procedures security modes: – Invoker rights – Definer rights

Database Security and Auditing 37

Database Security and Auditing: Protecting Data Integrity and Accessibility

Chapter 9 Auditing Database Activities Objectives

• Use Oracle database activities • Learn how to create DLL triggers with Oracle • Audit database activities using Oracle

Database Security and Auditing 2

Objectives (continued)

• Audit server activities with Microsoft SQL Server 2000 • Audit database activities using Microsoft SQL Profiler • Use SQL Server for security auditing

Database Security and Auditing 3 Using Oracle Database Activities

• Several types of activities: – Application activities: SQL statements issued against application tables – Administration activities: commands issued for maintenance and administrative purposes – Database events: events that occur when a specific activity occurs

Database Security and Auditing 4

Creating DDL Triggers with Oracle

• Audit program provides: – Audit trail for all activities – Opportunity for using process controls • Database activities statements (in addition to DML): – Data Definition Language (DDL) – Data Control Language – Database events – SQL statements audit trail

Database Security and Auditing 5 Creating DDL Triggers with Oracle (continued)

• Use CREATE TRIGGER: – DDL statements – Database events

Database Security and Auditing 6

Example of LOGON and LOGOFF Database Events

• Steps: – Log on as SYSTEM – Create the APP_AUDIT_LOGINS table – Create two triggers: • One that fires after the logon event • One that fires before the logoff event – Log on as DBSEC; disconnect after a few minutes – Log on as SYSTEM to check the auditing table

Database Security and Auditing 7 DDL Event Example

• Steps: – Log on as SYSTEM – Create a trigger that fires before an ALTER statement is completed – Log on as DBSEC and alter a table • Pseudocolumns: – ora_dict_obj_name – ora_dict_obj_owner – ora_sysevent

Database Security and Auditing 8

Auditing Code with Oracle

• Steps: – Log on as DBSEC – Create an auditing table – Create a table and populate it with two records – Create a trigger to track code – Update the new table – Look at the contents of the APP_AUDIT_SQLS table

Database Security and Auditing 9 Auditing Database Activities with Oracle

• Oracle provides mechanisms for auditing all: – Who creates or modifies the structure – Who is granting privileges to whom • Two types of activities based on the type of SQL command statement used: – Defined by DDL (Data Definition Language) – Defined by DCL (Data Control Language)

Database Security and Auditing 10

Auditing DDL Activities

• Use a SQL-based AUDIT command • Verify auditing is on: – Check the AUDIT_TRAIL parameter – Values: • DB • DB_EXTENDED • OS • NONE

Database Security and Auditing 11 Auditing DDL Activities (continued)

Database Security and Auditing 12

DDL Activities Example 1

• Steps: – Use any user other than SYS or SYSTEM to create a table – Add three rows into the table – Log on as SYSTEM or SYS to enable auditing: For ALTER and DELETE – Log in as DBSEC: • Delete a row • Modify the structure of the table

Database Security and Auditing 13 DDL Activities Example 1 (continued)

• Steps (continued): – Check the audit records – Log in as SYSTEM and view the DBA_AUDIT_TRAIL table – Turn off the auditing option – Check the content of the DBA_AUDIT_OBJECT to see auditing metadata

Database Security and Auditing 14

DDL Activities Example 1 (continued)

Database Security and Auditing 15 DDL Activities Example 1 (continued)

Database Security and Auditing 16

DDL Activities Example 2

• Steps: – Log in as SYSTEM or SYS to enable auditing for the TABLE statement; ALTER, CREATE, and DROP TABLE statements – Log on as DBSEC and create a table, then drop the table – Log on as SYSTEM; view the content of DBA_AUDIT_TRAIL – Turn off auditing for the TABLE statement

Database Security and Auditing 17 DCL Activities Example

• Steps: – Log on as SYSTEM or SYS and issue an AUDIT statement – Log on as DBSEC and grant SELECT and UPDATE to SYSTEM – Log on as SYSTEM and display the contents of DBA_AUDIT_TRAIL – Review audit data dictionary

Database Security and Auditing 18

DCL Activities Example (continued)

Database Security and Auditing 19 Example of Auditing User Activities

• Steps: – Log on as SYSTEM or SYS, to issue an audit statement – Log on as DBSEC and create a temporary table – Go back to SYSTEM to view the contents of DBA_AUDIT_TRAIL

Database Security and Auditing 20

Audit Trail File Destination

• Steps: – Modify the initialization parameter file, INIT.ORA; set parameter AUDIT_TRAIL to the value OS – Create a folder/directory – Set AUDIT_FILE_DEST to the new directory – Shut down and restart the database – Connect as DBSEC

Database Security and Auditing 21 Oracle Alert Log

• Audits database activities: – Errors: • Errors related to physical structure are recorded in the Alert log • Monitor errors every five to ten minutes; can be done using a Windows or UNIX script • Syntactical errors are not recorded – Startup and shutdown • Date and time of each occurrence

Database Security and Auditing 22

Oracle Alert Log (continued)

Database Security and Auditing 23 Oracle Alert Log (continued)

• Database activities (continued): – Modified initialization parameters, each time a database is started – Checkpoints: configure Oracle to record checkpoint time – Archiving: view the timing for all redo log sequences, as well as archiving times – Physical database changes

Database Security and Auditing 24

Oracle Alert Log (continued)

Database Security and Auditing 25 Auditing Server Activity with Microsoft SQL Server 2000

• Way to track and log activity for each SQL Server occurrence • Must be a member of the sysadmin fixed server role • Two types of auditing for server events: – Auditing – C2 auditing • Auditing affects performance and can be costly

Database Security and Auditing 26

Implementing SQL Profiler

• User interface for auditing events • For each event you can audit: – Date and time of the event – User who caused the event to occur – Type of event – Success or failure of the event – Origin of the request – Name of the object accessed – Text SQL statement

Database Security and Auditing 27 Implementing SQL Profiler (continued)

Database Security and Auditing 28

Security Auditing with SQL Server

• Steps for setting security auditing level: – Open Enterprise Manager – Expand the appropriate SQL Server group – Right-click on the desired server – Click Properties – On the security tab, select the desired security level

Database Security and Auditing 29 Security Auditing with SQL Server (continued)

Database Security and Auditing 30

Security Auditing with SQL Server (continued)

• Auditable events: – ADD DB USER – ADD LOGIN TO SERVER ROLE – ADD MEMBER TO DB ROLE – ADD ROLE – APP ROLE CHANGE PASSWORD – BACKUP/RESTORE – CHANGE AUDIT

Database Security and Auditing 31 Security Auditing with SQL Server (continued)

• Auditable events (continued): – DBCC – LOGIN – LOGOUT – LOGIN CHANGE PASSWORD – LOGIN CHANGE PROPERTY – LOGIN FAILED – Login GDR (GRANT, DENY, REVOKE)

Database Security and Auditing 32

Security Auditing with SQL Server (continued)

• Auditable events (continued): – Object Derived Permissions – Object GDR – Object Permissions – Server Start and Stop – Statement GDR – Statement Permission

Database Security and Auditing 33 Security Auditing with SQL Server (continued)

Database Security and Auditing 34

Security Auditing with SQL Server (continued)

• New trace information: – A name for the trace – The server you want to audit – The base template to start with – Where to save the audit data, either to a file or to a database table – A stop time, if you don’t want the trace to run indefinitely

Database Security and Auditing 35 Security Auditing with SQL Server (continued)

Database Security and Auditing 36

Security Auditing with SQL Server (continued)

Database Security and Auditing 37 Security Auditing with SQL Server (continued)

• Steps to add Login Change Password event – Expand the Security Audit node under Available event classes – Click Audit Login Change Password Event – Click the Add button

Database Security and Auditing 38

Security Auditing with SQL Server (continued)

Database Security and Auditing 39 Data Definition Auditing

• Audit DDL statements: – Object:Created – Object:Deleted – Will audit all CREATE and DROP statements

Database Security and Auditing 40

Data Definition Auditing (continued)

Database Security and Auditing 41 Database Auditing with SQL Server

Database Security and Auditing 42

Database Errors Auditing with SQL Server

Database Security and Auditing 43 Summary

• Activities types: – Application activities – Administration activities – Database events • Oracle triggers provide a way to create an audit trail • Auditable Oracle database activities: logon, logoff, startup and shutdown

Database Security and Auditing 44

Summary (continued)

• Oracle provides the SQL AUDIT command: initialization parameter AUDIT_TRAIL • NOAUDIT used to stop auditing • DBA_AUDIT_TRAIL data dictionary view • Oracle Alert Log: – Database errors – Modified initialization parameters – Checkpoints

Database Security and Auditing 45 Summary (continued)

• Microsoft SQL Server 2000: way to track and log SQL Server activity • Must be a member of sysadmin fixed role to enable or modify auditing • SQL Profiler: – Visualization tool – Audit errors that occur within the database

Database Security and Auditing 46