Database Security EXPERT

29 May Database Security EXPERT

It should be logically organized and professionally done (no spelling errors, clear writing). The lab project must be submitted as ONE DOCUMENT in either WORD OR PDF FORMAT.  You might have to alter the tables a bit, create a new table or add rows that can be used to illustrate that your security works. If you don’t want to reuse an old project you have the option of starting from scratch (from a blank sheet of paper).  The comments below cover everything I can think of that could be in your project. There are options, e.g., if you can fully implement your security with roles, views, grants, procedures, and triggers you would not have to have any security labels or a VPD. If you implement your security with VPD you might not need any roles, views, or triggers. If  you implemented your security with the Oracle Security Labels you might not need any  VPD etc. Not every example I give below applies to every project. The lab project report should be as long as it needs to be. I have had reports from 20-30 pages to 160 pages. Long listings of big tables to not add value, but do inflate page length! You probably need less than 10-15 rows in most of the tables. Example of security implementation should be targeted (an update against 1-3 rows not the whole table so that you then demonstrate

It should have sections such as

Introduction

Timeline

Conceptual & Logical Data Model

Physical Design

Implementation

Security

Verification of Database Security Implementation

Introduction:

What is the project about? (A pet store, a small corner supermarket, a

doctor’s office, etc). What are the key users and what are their functions?

(A pet store has an owner, clerks, and maybe an office manger that does

the banking, payroll)

Timeline:

the logical series of steps that must be done and when they must be done

and what order

Conceptual Model:

The functional roles of the various users and database and user

requirements, design assumptions, entity types and relationships, ER

diagram(s), constraints/dependencies,

Logical Model:

Rules Used to Map ER Diagram to Relations, ER-to-Relational Mapping,

Map of ERD to relations (tables), functional dependencies, normalized

relations (should all be 3NF or BCNF) Notional Data Elements for each

Table

Physical Model:

DDL to create basic relations (tables, indexes if any, non security related

triggers, procedures or functions). Security DDL/DML should be in the

security section

Implementation:

Insert statements into Tables, queries to show table populations (Select *)

– you should only have a small number of rows in each table, enough not

to be trivial, but no need to have more that one-five record of each type

(one owner, 2-3 clerks, one office manager, three different types of pet,

etc); examples of the most frequent queries for the business (e.g., what

pets do we have in inventory, what is the cheapest or most expensive pet

(could list by price) what was the payroll last week, month, year)

Security:

The most important section: What is your security plan? What are your

security policies that support that plan? What security procedures will

support the plan and policies? What is your security model? And the

security implementation (users created with passwords, roles created,

privileges granted, views created for security reasons, security triggers,

procedures, functions, labels, etc). Evidence of the implementation (scripts that show the DDL to create the users, grant the privileges, etc and the results (able created, grants affected, etc). Evidence that the security works  as it is supposed to (users can do what they are supposed to be able and  can not do things that they are prohibited from doing or that they are not explicitly supposed to do

References: If any

Attached is only an example